You're building a rental application form. Your product team wants to add fields for gender, student status, and citizenship. Your real estate clients say it helps them "get a complete picture." Your legal team hasn't flagged any hard stops. So you add the fields.
Then the privacy commissioner determines you've been collecting excessive personal information from 8.5 million applicants.
That's what happened to 2Apply, the Australian rental platform that became the first RentTech provider to face a formal determination for over-collection. The ruling matters beyond Australia: it establishes a clear test for necessity that applies to any platform operating in a power-imbalanced market.
If you're designing data collection flows for housing, employment, credit, or any sector where users can't easily walk away, you're facing the same decision: which fields are defensible, and which are a liability.
The Decision You're Facing
Every data field you collect creates three obligations:
- Justify why you need it (purpose limitation under GDPR Article 5(1)(b), Privacy Act 1988 APP 3)
- Secure it for its entire retention period
- Honor deletion, access, and portability requests that include it
The question isn't "Could this field be useful?" It's "Can I defend this field's necessity to a supervisory authority after a complaint?"
The 2Apply determination gives you a practical test: if the field doesn't directly enable the transaction (in this case, assessing the ability to pay rent and maintain property), it fails the necessity standard.
Key Factors That Affect Your Choice
Before you decide whether to collect a data point, evaluate these four factors:
Power imbalance severity: The privacy commissioner noted that 2Apply operated "as an intermediary to individuals' access to housing" during a rental crisis. When your users face scarcity (housing shortage, job market tightness, credit access constraints), their consent is structurally compromised. Fields that might be optional in a balanced market become coercive in an imbalanced one.
Confirmshaming pressure: 2Apply's form stated that providing information would "help speed up your application process" and that not providing it "may affect whether you are considered as a suitable tenant." The commissioner found this language unfair even though it wasn't technically false. If your UI suggests that optional fields affect outcomes, you've converted them into mandatory fields under a fairness analysis.
Breach surface expansion: The commissioner explicitly connected over-collection to security risk, citing reporting that seven rental platforms had millions of documents potentially exposed. Every field you collect appears in your breach notification if your database leaks. Gender, citizenship status, and bankruptcy history are higher-sensitivity categories that amplify notification obligations under GDPR Article 34 and state breach laws.
Downstream processing limits: Once you collect a field, you're locked into the purpose you disclosed. If you later want to use citizenship data for marketing segmentation or student status for product analytics, you're conducting incompatible processing under GDPR Article 6(4). The 2Apply determination blocks this path by establishing that these fields had no legitimate collection purpose to begin with.
Path A: Collect the Field (High Bar)
Choose this path only if you can document all three conditions:
The field directly enables the core transaction: For rental applications, the commissioner accepted income verification, employment details (employer name and contact), and certain ID documents because they assess the ability to pay. For your context, ask: does this field determine eligibility, prevent fraud specific to this transaction type, or fulfill a legal obligation you can name by statute?
You collect the minimum sufficient version: 2Apply collected full employment history; the commissioner said employer name and contact information suffices. If you need income verification, collect current income, not five years of tax returns. If you need an emergency contact, collect name and phone number, not their employment status and relationship history.
You can articulate the harm of not collecting it: The commissioner required 2Apply to stop collecting gender, dependents, student status, bankruptcy status, retirement status, previous living history, property ownership, other applications, assistance status, and citizenship. None of these met the test because 2Apply couldn't explain what risk the absence of this data created for the landlord.
Representative scenario: You're building an employment verification platform. You collect current employer name, job title, and employment start date (defensible: directly verifies employment). You skip collecting supervisor name, internal employee ID, and performance rating (not defensible: not necessary to confirm employment status).
Path B: Make the Field Optional with No Consequence (Medium Bar)
Choose this path if the field provides convenience but isn't necessary:
Remove all confirmshaming language: Don't say the field "speeds up processing" or "improves your application." If it's truly optional, present it neutrally: "You may provide vehicle details if you plan to use parking facilities."
Ensure backend systems don't penalize omission: The 2Apply determination turned on whether non-provision "may affect whether you are considered as a suitable tenant." If your scoring algorithm, review queue prioritization, or approval workflow treats blank fields as negative signals, the field isn't actually optional. Audit your data flows to confirm that NULL values in optional fields don't trigger downstream penalties.
Provide a clear purpose statement per field: Under GDPR Article 13(1)(c), you must specify purposes at collection. Generic privacy policies don't satisfy this. Next to each optional field, state what you'll use it for: "Vehicle registration: to issue parking permits if requested."
Representative scenario: You're building a healthcare appointment platform. You make insurance information optional and clearly state: "Providing insurance details allows us to verify coverage before your visit. If you prefer to pay directly, leave this blank." Your scheduling system treats insured and uninsured appointments identically in queue priority.
Path C: Don't Collect the Field (Default Position)
Choose this path for any field that doesn't meet Path A's three conditions:
Demographic data unrelated to the transaction: Gender, age range, student status, retirement status, dependents. These failed the 2Apply test because they don't assess rental suitability. Unless you're conducting age-restricted transactions (alcohol sales, senior housing with legal age requirements), demographic fields are indefensible.
Historical data beyond current status: Previous addresses, prior employment, application history with other providers. The commissioner found that current status suffices; historical data is over-collection unless you can cite a specific fraud pattern it prevents.
Proxy data for protected characteristics: Citizenship status and visa expiry are proxies for national origin. Bankruptcy status is a proxy for economic class. Collecting these fields in a discriminatory market (housing, employment, credit) creates liability under both privacy law and anti-discrimination statutes.
Emergency contact details beyond name and phone: 2Apply collected employment status and relationship type for emergency contacts. The commissioner said name and contact information suffices. If you can't explain why you need to know your user's emergency contact's job title, don't collect it.
Representative scenario: You're building a vacation rental platform. You collect guest count and check-in date (necessary for booking). You skip collecting guests' ages, relationships to each other, employment status, and home addresses beyond city (not necessary; creates needless breach surface).
Summary Matrix
| Factor | Collect (Path A) | Optional (Path B) | Don't Collect (Path C) |
|---|---|---|---|
| Necessity test | Directly enables transaction; can name specific harm if absent | Provides convenience; no penalty for omission | No clear connection to transaction purpose |
| Power imbalance | Field is standard across industry and legally required | Field is genuinely optional in practice | Field exploits user's lack of alternatives |
| Breach risk | Low-sensitivity; narrow retention period | Medium-sensitivity; clear deletion trigger | High-sensitivity; indefinite retention |
| UI presentation | Marked required; purpose stated per field | Marked optional; no confirmshaming language | Field not present in form |
| Example (rental) | Current income, employer contact | Vehicle details for parking access | Gender, citizenship, bankruptcy history |
| Regulatory precedent | 2Apply accepted these fields | Must prove no downstream penalty | 2Apply determination requires deletion |
The 2Apply ruling establishes that "it might be useful" doesn't satisfy necessity. If you're designing forms in imbalanced markets, start from Path C and justify your way to Path A. The privacy commissioner expects other platforms to adapt their practices accordingly. That means your current data collection flows are now under implied review, even if you haven't received a complaint.
Every field you can't defend is a field you'll eventually have to purge from production databases. Better to make that decision now, before you're holding 8.5 million records you shouldn't have collected in the first place.
