The Breach Notification From 1997

My wife just got a breach notification from a college she never attended.

She applied decades ago. Didn't enroll. Didn't accept. Her application was rejected, her life moved on, and somewhere in the back of a university database — no business justification, no retention policy, no owner — her name, date of birth, Social Security number, and a long-abandoned home address sat quietly for a generation.

Now that data belongs to whoever breached the servers.

The envelope arrived at her childhood home. That's how old the record was. The address on file was three addresses and one marriage ago. The application predates Y2K. The form she filled out wasn't even Y2K compliant.

Here's the darkly funny part: that obsolete address is so outdated no modern identity-verification system will accept it. Every credit application, every background check, every identity service cross-references against recent residences. Decades of address drift became a form of accidental security. She got lucky. Most people in that file didn't.

The Breach Is Never the Interesting Part

I've spent two decades reviewing security programs for financial services firms, healthcare providers, and universities. I've sat through hundreds of post-breach debriefs. And here's what I've learned: the breach is rarely the interesting part of the story. The retention is.

Every data map I've audited starts the same way — confident diagrams, clean flows, documented purposes. And every one ends the same way: "…and then there's the legacy systems." That's where the exposure lives. In dusty application databases. In spreadsheets attached to email archives. In backup tapes no one budgeted to decommission. In student records from before the internet was commercial.

GLBA calls it data minimization. GDPR calls it storage limitation. HIPAA, SOX, NYDFS — every framework has a version of the same rule: don't keep it if you don't need it. Every firm nods. Every firm keeps it anyway.

Storage is cheap. Deletion is work. The data owner left in 2014. Nobody knows who approves the purge. So it just… sits.

Until the day a decades-old application file mails itself to a childhood bedroom.

The Railroad Principle

There's a pattern here I've watched play out across three technology cycles. Nobody gets fired the day the railroad arrives. The town just slowly empties out.

In the 1990s, we moved from paper files to digital databases and told ourselves we'd clean up the old records later. Later never came. In the 2000s, we migrated from on-premise systems to the cloud and told ourselves we'd rationalize the data footprint during the transition. We didn't. In the 2010s, we merged systems during M&A and told ourselves we'd harmonize retention policies post-close. The integration team disbanded before that item made it off the backlog.

Each technology transition was supposed to be the moment we finally got disciplined about what we keep. Each time, we just dragged the mess forward and added a new layer on top.

The infrastructure improved. The hygiene didn't.

I was advising a regional bank last year on their third-party risk program. Halfway through the assessment, we discovered they were still paying a vendor to host loan application data from a product line they'd discontinued in 2009. Not archived. Hosted. Live database. Monthly fee. The product manager who owned that relationship had retired. Nobody questioned the invoice.

When I asked how many other systems fit that pattern, the CIO went quiet.

The Uncomfortable Math

Here's the question nobody wants to answer: if you can't identify your oldest piece of customer PII, how do you know you have the right to keep any of it?

Most data governance programs are built backwards. We start with "what are we collecting today" and work forward. We document new data flows. We map new systems. We require privacy impact assessments for new initiatives.

But the risk isn't in the new stuff. The new stuff has owners, budgets, and executive attention. The risk is in the archaeology — the systems and datasets that predate the current governance regime.

I've seen this pattern enough times to name it: Legacy Debt Accumulation. Every year, you generate a little more data you can't quite justify deleting. Every merger adds another subsidiary's worth of orphaned records. Every system migration leaves behind a compatibility database "just in case." Every departed employee leaves behind a shared drive nobody inherits.

Individually, each decision is defensible. "We might need it for litigation." "It's only a few gigabytes." "We'll clean it up next quarter."

Collectively, they compound into exactly what breached that university: a database full of people who have no current relationship with your organization, no expectation that you still have their information, and no way to know they're at risk until the notification letter arrives.

What Regulators Actually Care About

I've sat in enough enforcement discussions to tell you what moves the needle. Regulators don't expect perfection. They expect you to know what you have and why you have it.

When the SEC examines a broker-dealer, they don't ask "have you ever been breached?" They ask "show me your data inventory" and "walk me through your retention schedule." When NYDFS audits a bank's cybersecurity program, they don't start with penetration testing. They start with data classification.

The framework language is dry: "maintain a comprehensive inventory of information systems" and "implement policies for the secure disposal of data." But the spirit is simple: if you can't defend keeping it, delete it.

Most firms miss that second part. They inventory beautifully. They classify diligently. They map data flows with expensive consultants and put it all in a governance portal.

Then nothing happens. Because deletion requires coordination across legal, compliance, IT, and business units. It requires someone to accept liability for the decision. It requires budget for a project with no revenue upside.

So the inventory becomes a monument to things we know we shouldn't keep but lack the organizational willpower to purge.

The Audit Finding You Already Have

If you're a controller, CFO, or audit committee member, here's what I'd ask your CIO this week:

What's the oldest piece of customer PII on our systems, and who authorized keeping it?

If the answer is "I'll get back to you," you've found your next audit finding.

If the answer is "we're working on a remediation plan," ask when the plan was created. If it's more than 18 months old, it's not a plan. It's a risk you've accepted.

If the answer is "we have a retention policy," ask for three things:

1. The date of the last executive-level review

2. Evidence that IT has the budget to execute it

3. A list of systems exempted from the policy and why

That third one is where the university database lives. In the exemptions. In the "we'll get to it next year" column. In the gap between policy and practice.

The Breach Is the Invoice. The Retention Is the Decision.

That's the line I keep coming back to. Because every breach notification I've seen follows the same script: "We take security seriously. We've engaged forensics experts. We're offering credit monitoring."

But credit monitoring doesn't fix the structural problem. The structural problem is that we're defending data we have no business keeping.

I'm not saying deletion is easy. I've led enough data remediation projects to know it's not. Legacy systems don't have delete functions — they were built in an era when storage was the constraint and deletion was unthinkable. Backup tapes require manual retrieval. Scattered spreadsheets require human review. Legal holds complicate everything.

But hard doesn't mean optional.

The firms that do this well treat data retention like they treat financial controls. They assign owners. They build it into system retirement processes. They tie executive compensation to remediation milestones. They make deletion someone's job, not everyone's aspiration.

The firms that don't… well, they send breach notifications to childhood homes.

What to Do Monday Morning

If you're responsible for risk, compliance, or information security, here's where I'd start:

Scope the archaeology. Identify your three oldest active systems that touch customer data. Not the newest. The oldest. The ones built before your current governance program existed.

Find the data owner. Not the IT owner — the business owner. The person who can answer "what business purpose does this serve today?" If that person doesn't exist, you've found data that should've been deleted years ago.

Pilot a purge. Pick one dataset. One orphaned system, one discontinued product line, one subsidiary you divested five years ago. Build the cross-functional process to delete it properly. Document what worked and what didn't. Then do it again.

Data minimization isn't a compliance checkbox. It's a risk reduction strategy. Every record you don't have is a record that can't be breached.

My wife's story had a happy ending — sort of. The breach exposed data so old it's mostly useless. But thousands of other people in that database weren't as lucky. Their addresses were current. Their information still matched identity verification systems. The bad actors got value.

The university is offering credit monitoring. They're upgrading their security. They're hiring consultants.

But nobody's asking the question that might have prevented this: why were we still keeping application records from people who never enrolled?

Storage is cheap. Breaches are expensive. But what do I know — I've only watched this movie a hundred times.

Your move: Ask your CIO what's the oldest customer record on your systems and who authorized keeping it. If you don't get a clear answer by Friday, you've got bigger problems than the next penetration test will find.