Why Do Data Breaches Happen, and What Should You Do When One Does?

A breach doesn't just mean a hacker attack

Part 10 of 12 in "Databases for Non-Developers". If Part 9 was about 'defense,' this one is about 'when you've been breached.' The quality of your incident response is what determines the scale of the damage.

---

An employee sent a customer list to the wrong email address. A cloud storage bucket's public settings let anyone download the files. A former employee's account was still active, and data was taken out through it. Ransomware encrypted both the database and its backups.

All of these can be a data breach. "Breach" is a broad term covering any incident where someone without authorization accesses sensitive data, takes it, publishes it, alters it, or makes it unusable. The legal definition and reporting thresholds vary by region and industry.

A security incident and a data breach are not the same thing

There may have been a suspicious login attempt that was blocked, with no access to data. That is a security incident worth investigating, but not necessarily a confirmed data breach. Conversely, what first looked like an ordinary outage may turn out, on investigation, to have involved data leaving the building.

Rather than jumping to conclusions early on, you need to preserve the facts and investigate. If you declare "it wasn't a hack" prematurely and it turns out three days later to have been one, the loss of trust in your statements can hurt more than the incident itself.

Why do breaches happen?

Account takeover

Reused passwords, phishing, and missing multi-factor authentication hand employee or administrator accounts over to attackers. A large share of attacks aren't about "breaking in" — they're about "being handed the keys."

Wrong permissions and public settings

Databases, storage, backups, and admin panels are exposed more widely than necessary. Storage buckets mistakenly set to 'public' are a recurring cause of major breaches.

Unpatched vulnerabilities

Servers or applications with known security flaws left unfixed become attack routes. For attackers, these are weaknesses that already come with an instruction manual.

Application access-control failures

A logged-in user changes a number in the address bar and sees someone else's records, or can call admin functions they shouldn't be able to.

Insiders and human error

It's not just deliberate theft — misdirected emails, lost laptops, and bad share links cause breaches too.

Vendors and the supply chain

It's not your company that gets breached but an outside service processing your data. As we saw in Part 8, outsourcing the work doesn't outsource the risk, or your responsibility to customers.

What real cases teach us

In 2017, US credit bureau Equifax announced that a breach had exposed the personal information of roughly 147 million people. The US Federal Trade Commission (FTC) later published the settlement and consumer-support details. This case shows that identifiers and credit information — data that, unlike a password, can't simply be changed once copied — can put individuals at risk for a very long time.

The key lesson doesn't stop at "even big companies get hit." It's that the sensitivity of the data you hold, the management of known vulnerabilities, detection, executive accountability, and victim support are one connected problem. And the cost of an incident isn't just fines — lawsuits, investigation costs, victim support, and, above all, customer churn and brand damage follow.

What to do immediately after discovering a breach

1. Activate the response team

Not just security and IT — executives, legal, the privacy officer, customer support, communications, and relevant outside vendors all need to take part according to their roles. Contact details and backup personnel should be decided in advance.

2. Contain the damage, but preserve evidence

Lock down compromised accounts, isolate affected systems, and replace exposed secret keys and credentials. But if you rush to delete logs and wipe systems, the evidence you need to establish cause and scope disappears. It's best to act together with investigation specialists.

3. Determine what was affected

• What data was seen, copied, or changed?
• Whose information is it?
• When did it start, and when was it discovered?
• Can the attacker still get in?
• Were backups and other systems affected too?

Record separately what is confirmed, what is still unknown, and what is assumed. This distinction determines the credibility of everything you communicate afterward.

4. Check legal and contractual notification obligations

Who must be notified, and by when, varies by region, industry, type of data, and contract. Under South Korea's Network Act, a personal data breach must be reported within 24 hours, while the GDPR requires notification to the supervisory authority within 72 hours. Medical, financial, and children's data can be subject to separate rules. For specific situations, consult a qualified legal professional.

5. Notify in a way that reduces harm

Notification is not a liability-shielding statement — it should be information that helps victims protect themselves. Explain in plain language what information was affected, what happened and when, what you're doing now, and what steps individuals can take and how to reach you. Never present what you don't know as if you know it.

6. Recover and prevent recurrence

Restore from safe backups, fix the vulnerabilities, and re-review permissions and settings. The post-incident report should look at systems and processes — why one person's mistake was able to turn into major damage — rather than blaming an individual.

Build the response plan before the incident

On the day a breach happens, it's too late to look up the legal counsel's phone number for the first time or to figure out where your backups are. At a minimum, prepare the following.

• Incident severity levels and escalation criteria
• Emergency contact list and role assignments
• Procedures for isolating systems and preserving evidence
• An inventory of data and outside vendors
• Legal and contractual notification review procedures
• A template for customer communications
• Backup restoration order
• A schedule of regular drills

Key takeaways A data breach can start not only with outside hacking but also with mistakes, misconfigured settings, insiders, and outside vendors. After one occurs, containment, evidence preservation, scoping, legal review, victim notification, and safe recovery must all connect. The best response plan is the one you built and rehearsed before the incident — with roles and contact lists already in place.

Questions to check right now

• Where should employees report a suspected breach?
• Can you instantly produce a list of which outside vendors hold customer data?
• Who preserves the logs and evidence, and who investigates?
• Who approves what gets communicated to customers?
• After recovery, how do you confirm the same problem won't happen again?

Next: How cloud and serverless change database operations, and what remains your responsibility.

References: FTC Data Breach Response Guide for Business, FTC Equifax Breach Settlement, CISA Ransomware Guide

---

Series contents

1. What Is a Database — How Is It Different from a Spreadsheet?
2. How Databases Keep Data Accurate
3. What Kinds of Databases Are There?
4. Databases, Data Warehouses, and Data Lakes
5. Why Choosing the Right Database Matters
6. Data Models and Data Quality
7. What Is Data Governance?
8. Collect Less Personal Data — Only What You Need
9. The Basics of Data Security
10. Why Do Data Breaches Happen, and What Should You Do When One Does? ← You are here
11. Cloud and Serverless Databases
12. Databases in the AI Era