Today the Singapore Land Authority (SLA) disclosed a cybersecurity incident that compromised personal data belonging to about 70,000 people. SLA didn’t get hacked directly. Their vendor, IBM, did.
The incident happened because of unauthorized access to a dataset that IBM managed for vendor development and testing. IBM notified SLA of the incident, and SLA kicked off its own investigation.
Here’s where it gets interesting. The dataset that was compromised was created in 1998. Old, right? Maybe that should’ve been deleted years ago. Cough, best practice. But it gets worse. The dataset wasn’t just sitting there untouched, it was updated periodically for almost 30 years.
Wait, you said this was for testing? Shouldn’t a test dataset have contained mock data, not real information? Yup. That would’ve been the best practice. Instead, real names, NRIC numbers, and past property addresses ended up in there.
SLA is now working with IBM, Singapore’s Government Technology Agency, and the Cyber Security Agency to figure out what happened. SLA says its live systems, the ones handling actual property records today, weren’t affected. Good. But was this whole thing avoidable? Yes.
So what’s the actual lesson here, for the business leader reading this and not the security team?
Know what you own. Teams need a clear picture of what resources and environments are actually running, and whether they’re still active or should’ve been decommissioned years ago. A dataset from 1998 quietly living on somebody’s cloud environment isn’t a technical footnote, it’s a sign nobody was asking the question.
Decommission on purpose. If something’s no longer needed, shut it down and get rid of the data. Don’t leave it sitting there because deleting it wasn’t anyone’s job. “We forgot about it” isn’t a security control, it’s a gap with a name attached to it eventually.
And rule number one, the one that should never get broken: if it’s built for testing, use test data. Never real data. That’s not a nuanced call. Test environments get a lower security bar because the assumption is nothing sensitive is in them. The second real data shows up in a test environment, that assumption is dead and the exposure is already baked in.
This wasn’t a sophisticated attack on a hardened system. It was real data sitting somewhere it was never supposed to be, for almost three decades, until someone found it. That’s the kind of risk that doesn’t show up on a dashboard. It shows up when it’s too late to do anything but clean up after it.