Cyberwall Blog · January 29, 2025

Recent Privacy Breaches: A Wake Up Call

Two recent large scale breaches show how much sensitive data organizations still hold onto, and why data minimization is as important as any technical control.

By Alex Plotkin, CEO

Two incidents in the past year are worth paying attention to, not because they’re unusual, but because they’re a preview of what keeps happening. One involved a widely used education platform, where old student records, some dating back years, were exposed alongside current data simply because nobody had gotten around to deleting them. The other involved a managed file transfer tool used by banks, insurers, and government agencies, where a single vulnerability rippled outward through every organization that depended on it.

The pattern in both cases is the same: the data an organization no longer actively needs is often the data that causes the most damage when it leaks. Retention policies aren’t just a compliance checkbox; they’re a direct way to shrink what an attacker can get to in the first place. If a record has no active business purpose and no legal requirement to keep it, every extra month it sits on a server is pure downside. It doesn’t generate revenue, it doesn’t help serve a customer, and it doesn’t reduce risk. It just waits to become part of a breach notification.

The file transfer incident points at a second, equally important lesson: a lot of an organization’s real exposure lives outside its own network. Managed file transfer tools, payroll platforms, HR systems, and other third-party software sit in the middle of sensitive workflows precisely because they’re convenient, and a vulnerability in any one of them can expose every organization plugged into it at once. That’s a supply chain problem, not just a vendor problem, and it means vendor due diligence has to go beyond a signed contract. Asking a vendor what data they hold, how long they keep it, and what their own security posture looks like should be a standing part of any procurement process, not a one time checkbox during onboarding.

It’s also worth separating two things that get lumped together: a security assessment asks whether your systems can be broken into, and a privacy assessment asks whether the data you’re holding should still be there, who can access it, and whether you’re meeting obligations like GDPR, HIPAA, PIPEDA, or OSFI where they apply. Organizations that treat these as one conversation tend to miss half the picture. A system can be technically well defended and still hold a decade of data nobody remembers exists, with access permissions nobody has reviewed since the record was created. Neither a firewall nor an EDR tool catches that. It takes someone actually mapping what data exists, where it lives, who touches it, and why.

A real privacy program combines both angles: data minimization, a clear stated purpose for everything you keep, encryption for data at rest and in transit, defined retention windows tied to actual legal or business need, and a plan for what happens when something does go wrong despite all of that. In practice this usually starts with a data inventory: what personal or sensitive information does the organization actually hold, across every system and every vendor, and does each piece of it still need to be there. From there, retention schedules get set by data type rather than by default, access gets reviewed on a regular cadence instead of accumulating forever, and encryption becomes a standard rather than an exception for anything sensitive.

For an IT Director reporting up to a board, this framing also changes the conversation. “We patch everything” is a technical answer. “We know exactly what sensitive data we hold, why we hold it, and for how long” is a governance answer, and it’s the one a board, an auditor, or a cyber insurance underwriter actually wants to hear. It’s a smaller, better defined target, and a much easier one to defend and to explain after the fact if something does happen.

There’s also a practical, day-to-day payoff that goes beyond risk reduction. Breach notification laws generally require organizations to identify and notify every individual whose data was involved once an incident is confirmed, and that process gets dramatically harder when nobody is confident about what data existed in the first place, where every copy of it lived, or whether a given record was even still active. An organization with a current data inventory and clear retention records can answer “whose information was affected, and how do we reach them” in hours instead of weeks. That speed matters legally, since most notification laws work on a clock, and it matters reputationally, since a fast, accurate notification reads very differently to an affected client or regulator than a vague one issued under pressure months later.

The same discipline pays off well before anything goes wrong, too. A clean, current data map makes every subsequent security investment more effective, because it tells the team exactly where the sensitive data actually sits rather than leaving that judgment to guesswork. It also shortens the vendor and client due diligence process, since organizations increasingly ask for exactly this kind of documentation as part of their own procurement and audit requirements. Treating data minimization as ongoing hygiene rather than a one-time cleanup project is what keeps that answer current instead of it quietly going stale again within a year.

That’s the exact gap our privacy consulting engagements are built to close.

Related reading: Cyberwall Successfully Passes SOC 2 Type II Audit · What Credit Unions Should Ask a Managed Security Provider

Not ready to wait on a blog post?

Book a preparedness call and get a straight answer for your specific situation, no searching required.