How Long Can You Keep an Applicant’s ID & Data — and What If It’s Breached?

Short answer: keep an applicant’s ID, SSN, and screening data only as long as you actually need it to make the rental decision — then securely destroy it. US law has no single retention clock, but the FTC Disposal Rule requires secure destruction of screening data. Canada’s PIPEDA requires deletion once the purpose ends. A breach triggers state-by-state notification in the US, or OPC reporting in Canada if the breach poses a real risk of significant harm.

During a discovery conversation with one property manager, a detail surfaced that stopped the conversation cold. A widely-used self-showing tool had quietly started requiring applicants to enter their Social Security number before unlocking a lockbox — and the PM had no idea it was happening. “I’ve had prospective tenants say, ‘I’m not comfortable entering my social security number,’” they told us. “I’m like — I didn’t know you had to do that.”

That is the invisible-custodian problem. A vendor adds a data-collection step to a workflow you own, and the liability lands on you — not the tool. The PM did not collect the SSN. The PM did not want the SSN. But the PM is now the custodian of the most sensitive personal data a person owns, and they did not even know it.

The uncomfortable truth behind that story is that PMs want identity verification at the self-showing gate. The reason comes through clearly in conversations with property managers across the US and Canada: “nothing but squatters, nothing but scam artists grabbing codes,” one PM told us. Another described an impersonator who took their keys and started running their own leasing operation out of the unit. The demand for an identity check at the door is real and rational.

But every ID scan and SSN you collect — or that a vendor collects on your behalf — becomes a retention liability and a potential breach liability that you now own. This guide resolves that tension: what your legal obligations actually are, what a breach costs, and how to verify identity at the gate without becoming a long-term custodian of raw ID scans.

This is general guidance, not legal advice — confirm the specific rules in your state or province before making compliance decisions.

How long can a landlord legally keep an applicant’s ID, SSN, and screening data?

There is no fixed federal number. The governing principle across both US and Canadian law is “only as long as you need it for the purpose you collected it.” For a rental applicant, that purpose is making the leasing decision and being able to defend it — not indefinitely.

The practical split matters. A retained tenant’s records have a clearer ongoing purpose: you need their information to manage the tenancy, handle maintenance, and process rent. A rejected applicant’s records are a different story. Once the decision is made and any short window for defending an adverse-action or fair-housing challenge has passed, the justification for holding sensitive data is thin — and the exposure is not.

Holding a rejected applicant’s SSN or government-issued ID scan in a filing cabinet or cloud folder for months (or years) because no one got around to deleting it is not a neutral act. It is pure liability with no corresponding benefit. The FTC Disposal Rule — which governs how consumer-report data must be destroyed — makes the legal duty concrete: if you received a credit, background, or tenant-screening report on that applicant, you are required by federal law to securely destroy that data when you dispose of it. That duty is active and it applies now, not “someday.”

The real obligation is not a clock. It is: keep only what you need, for only as long as you need it, then destroy it properly. Everything else is liability you are choosing to hold.

Do landlords have to delete or destroy a rejected applicant’s personal information — and by when?

In substance, yes. Once the decision is made and the adverse-action or fair-housing defense window closes, you should securely destroy a rejected applicant’s personal data. There is no universal “by X days” federal deadline in the US — but holding sensitive data with no live purpose is exactly the exposure that turns a minor incident into a reportable breach.

The rule most property managers do not know is the FTC Disposal Rule, which implements the Fair and Accurate Credit Transactions Act (FACTA). Under this rule, any landlord who uses a tenant-screening report, credit report, or background check is required to take “reasonable measures” to securely destroy that consumer-report information when disposing of it. Paper records must be shredded or pulverized. Electronic files must be wiped or destroyed so the information cannot be read or reconstructed. The source authority is the Federal Trade Commission. (FTC: Disposing of Consumer Report Information.)

This reframes the question. It is not “how long can I keep it?” It is “I have an active legal duty to destroy it properly when I am done with it.” That is the line worth writing down.

What “done with it” means in practice:

• The rental decision has been made
• The adverse-action notice has been sent (required under the FCRA if you used a consumer report)
• Any short window during which the applicant could challenge the decision has passed

After those boxes are checked, there is no defensible reason to retain a rejected applicant’s SSN, ID scan, or screening report — and the FTC Disposal Rule means you have an affirmative obligation to destroy it correctly, not just delete the file from your desktop.

What are a property manager’s legal obligations if applicant data is breached?

If ID scans, SSNs, or screening reports are exposed — whether through a hack, a misconfigured cloud folder, a stolen laptop, or a vendor incident — you generally must notify affected individuals on a legally-defined timeline. In most US jurisdictions, you must also notify a state regulator. The cost of getting this wrong is not theoretical.

The US average cost of a data breach reached a record $10.22 million in 2025, compared to a global average of $4.44 million — marking the 15th consecutive year the US ranked highest. The most-compromised data type was customer personally identifiable information (PII). Source: IBM Cost of a Data Breach Report 2025.

For a property management operation, the PII picture is particularly sharp. Rental applicants hand over exactly the data types that drive breach costs: government-issued ID, Social Security numbers, employment records, financial account information. A single self-showing tool that stores raw ID scans across thousands of applicants creates a concentration of high-value PII — and the PM is the custodian.

The breach-response obligation itself adds to the cost: notification letters, credit monitoring for affected individuals, legal counsel, regulatory reporting, and potential fines — all before you account for the reputational damage of telling prospective tenants their information was compromised while they were applying to rent from you.

The practical defense is minimization: the less you collect and store, the less you can ever breach, and the shorter your notification list if the worst happens.

Is there one federal data-breach notification law for landlords, or is it different in every state?

There is no single US federal breach-notification law. What exists instead is a 50-state-plus-DC patchwork, and a property manager operating across state lines faces multiple, conflicting obligations the moment applicant data is exposed.

All 50 states, the District of Columbia, Guam, Puerto Rico, and the US Virgin Islands have enacted their own breach-notification statutes. They differ on the definition of “personal information,” the notification deadline (some say 30–60 days; others say “without unreasonable delay”), what triggers a mandatory notification (some require notification only above a risk threshold; others are categorical), and which state attorneys general or regulators must be notified. Source: National Conference of State Legislatures (NCSL).

What this means for multi-state property managers:

• You cannot assume one process handles all your obligations
• A breach affecting applicants in three states may trigger three different clocks and three different reporting requirements simultaneously
• The “personal information” that triggers notification in one state may be defined more broadly in another — meaning data you think is low-risk may be reportable in a state with a wider definition

The practical takeaway is the same as everywhere else in this piece: the most defensible position is collecting and retaining less. The fewer raw ID scans and SSNs sitting in your systems, the shorter your notification list if a breach occurs — and the simpler your multi-state compliance problem becomes. Being a minimal custodian is itself a risk-management strategy.

How does data retention and breach reporting work in Canada (PIPEDA) vs the US?

Canadian property managers face a framework that is, if anything, more explicit than the US patchwork — with a direct retention-limitation duty written into federal privacy law.

Under Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA), organizations may retain personal information only as long as necessary to fulfill the purpose for which it was collected. For a rental applicant, that purpose ends when the leasing decision is made. A rejected applicant’s personal data — ID documents, financial information, screening results — should generally be destroyed or anonymized once the decision is final. There is no ambiguity about ongoing retention with no active purpose: PIPEDA’s retention-limitation principle does not permit it. Source: Office of the Privacy Commissioner of Canada (OPC).

On breach reporting, Canada has had mandatory federal requirements since November 1, 2018. Under PIPEDA’s breach-reporting provisions:

• Report to the OPC if a breach poses a “real risk of significant harm” (RROSH) to affected individuals — as soon as feasible after determining a breach has occurred
• Notify affected individuals of any RROSH breach directly
• Keep a record of ALL breaches — even ones that do not meet the RROSH threshold and do not require OPC reporting — for a minimum of 24 months

The record-keeping duty for all breaches is the part that catches Canadian PMs off guard. Even a minor incident that does not rise to RROSH must be documented and retained.

The contrast with the US is instructive: the US has no retention-limitation duty in a single federal statute and a 50-state breach patchwork. Canada has an explicit retention-limitation principle under one federal law and a unified breach-reporting regime with a single regulator. A property manager operating in both countries answers to both frameworks — and the Canadian rules are in some ways the more demanding baseline.

What should I ask a leasing or tenant-screening vendor about how they store and delete applicant ID?

Before you let any tool collect an applicant’s ID scan or SSN, get straight answers to these questions — because whatever it collects, you become the custodian of, and the FTC Disposal Rule and breach-notification obligations follow you, not the vendor.

These questions are specific to retention, deletion, and ID-document handling. Security posture broadly (encryption, audit logs, access controls) is a separate conversation worth having — but this checklist is about what data exists and who owns the liability for it.

• Does the tool store raw ID scans, or does it verify and discard? This is the single most important question. A tool that verifies identity at the moment of access and does not retain the raw document eliminates most of the retention and breach exposure. A tool that stores raw scans is creating a vault of high-value PII — in your name.
• What is the deletion timeline for rejected-applicant data — and is it automatic? Ask specifically: does data get deleted on a fixed schedule, or only when you manually request it? “We delete on request” means it accumulates until someone remembers to ask.
• Who is the data controller vs the data processor for the ID image — you, or the vendor? In a breach, this determines who is legally responsible for notification. If the answer is unclear, that is itself a red flag.
• Is SSN actually required — and is the applicant told before they enter it? The invisible-collection problem is real. If a vendor is collecting SSNs from your applicants without your knowledge, you now have a disclosure problem on top of a retention problem.
• Can you export and purge applicant data on demand? You need to be able to fulfill deletion requests — from applicants, from regulators, or from your own retention policy — without being dependent on vendor support tickets.
• Where is the data stored, and is it encrypted at rest? Knowing whether applicant PII sits on servers in your jurisdiction matters for which breach-notification laws apply.

If a vendor cannot answer these questions clearly, that itself is an answer. The compliance exposure from a vague answer is yours, not theirs.

Can I verify a prospect’s identity for self-showings without becoming a long-term custodian of raw ID scans?

Yes — and the goal is exactly that. The property managers in our discovery conversations are not trying to avoid identity verification. They want it. The squatter problem and the impersonator problem are real, and a self-showing without any identity check is a genuine operational risk.

The problem is not verification. The problem is what happens after the verification moment: raw ID scans sitting in a vendor’s database, attributed to your account, for months or years after the applicant was rejected. That is the liability — not the verification itself.

The principle that resolves the tension is straightforward: verify at the gate, keep as little as possible afterward. A self-showing tool that checks identity at the moment of access — confirming the person at the door is who they say they are — and minimizes what it retains gives you the security benefit without the ongoing custody problem. The best outcome is a verified showing with no raw ID scan accumulating in a database.

This is exactly what to look for when evaluating a self-showing tool: identity verified at the gate, a clear deletion policy for rejected-applicant data, and honest answers to every question on the checklist above. LetHub is one option built around verifying identity at the self-showing gate — confirm any vendor’s storage and deletion specifics, including ours, against that checklist before you proceed.

The durable fix for retention and breach liability is not better breach insurance or a more detailed incident response plan. It is being a custodian of less — collecting only what you need, for only as long as you need it, then destroying it properly. Everything else is a problem you are choosing to carry.

Frequently Asked Questions

How long can a landlord keep a rejected applicant’s information?

Only as long as needed to make and defend the rental decision — once the adverse-action window closes, you should securely destroy it. There is no universal federal deadline, but holding sensitive data with no live purpose is pure liability with no corresponding benefit.

Does a landlord have to shred tenant screening reports?

In substance, yes. The FTC Disposal Rule requires landlords who receive consumer-report data (credit, background, or tenant-screening reports) to take “reasonable measures” to securely destroy it when disposing of it — shredding or pulverizing paper, wiping electronic files so they cannot be read or reconstructed.

Is there a federal data-breach notification law for landlords in the US?

No. There is no single federal breach-notification law — all 50 states plus DC have enacted their own statutes, with different definitions of personal information, different notification deadlines, and different AG-reporting requirements.

What counts as “personal information” in a breach?

It varies by state — most statutes cover name combined with SSN, driver’s license or government-issued ID number, and financial account data; some states define the term more broadly. Check the specific statute in each state where your applicants reside.

How fast do I have to report a data breach?

It depends on jurisdiction: some US states require notification within 30–60 days of discovery, others use “without unreasonable delay” as the standard; in Canada, RROSH breaches must be reported to the OPC “as soon as feasible” after the breach is identified.

Do I have to delete applicant data under PIPEDA in Canada?

Yes — PIPEDA’s retention-limitation principle requires keeping personal information only as long as necessary for the purpose it was collected; for a rejected rental applicant, that purpose generally ends when the decision is made, and the data should then be destroyed or anonymized.

Does Canada require reporting every data breach?

You must report breaches posing a “real risk of significant harm” to the Office of the Privacy Commissioner of Canada and notify affected individuals, but you must also keep a record of all breaches — including those that do not meet the RROSH threshold — for a minimum of 24 months.

Should a self-showing tool collect applicants’ Social Security numbers?

Only if it is genuinely necessary for identity verification and the applicant is clearly informed before entering the number — and you should ask the vendor directly whether it stores raw SSN data or verifies and discards it, since whatever it retains becomes your custody and your breach liability.

Is this legal advice?

No — this is general guidance; confirm the specific rules in your state or province, and consult legal counsel before responding to an actual breach.

Want to verify who is at the door without inheriting a vault of ID scans? See how LetHub verifies identity at the self-showing gate.