What Is a Data Breach and How to Respond

A data breach is one of the events every website owner dreads, and yet the single biggest determinant of how badly it goes is not the breach itself but how you respond to it. In plain terms, a data breach is a security incident in which personal or sensitive data is exposed, stolen, altered or destroyed without authorisation — and it covers far more than dramatic hacking. This guide defines what actually counts as a breach, the common causes, a step-by-step incident-response plan, your legal notification duties (including the GDPR's well-known 72-hour rule), and how to prevent the next one.

It is the response counterpart to the prevention advice in how to protect your website from common attacks, and overlaps with detecting a compromise in how to tell if a website has been hacked.

What a data breach actually is

People picture a hooded hacker, but the legal and practical definition is broader. A data breach is any loss of control over data that should have been protected — whether through malice, accident or negligence. The EU's General Data Protection Regulation (GDPR) defines a personal-data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Note what that includes:

• A hacker exfiltrating your customer database — the obvious case.
• A lost or stolen laptop, phone or USB stick holding unencrypted personal data.
• A misconfigured database or cloud storage bucket left publicly accessible on the internet.
• An email sent to the wrong recipients, or a "reply-all" exposing addresses.
• Staff accessing or sharing records they were not authorised to.
• Ransomware that encrypts (and often also steals) your data.

The common thread is unauthorised access, disclosure, loss, alteration or destruction. Recognising this breadth matters, because teams sometimes fail to treat a misconfiguration or a mis-sent email as the breach it legally is, and miss their obligations as a result.

It also helps to distinguish a security incident (any event that may affect the security of systems or data) from a breach (an incident that actually compromised data). Not every incident is a breach, but every breach is an incident, and your plan should handle both.

The common causes

Breaches make headlines as sophisticated attacks, but most exploit a short list of well-understood, avoidable weaknesses — the same ones catalogued in the OWASP Top 10.

• Stolen, weak or reused credentials. The leading cause. Passwords leaked elsewhere are replayed against your login (credential stuffing), weak passwords are guessed, and reused ones unlock multiple systems at once.
• Phishing and social engineering. Tricking a person into revealing credentials or installing malware remains devastatingly effective and sidesteps technical controls.
• Unpatched vulnerabilities. Known flaws in a CMS, plugin, library or server that were never updated; attackers scan for them because the exploit already exists.
• Misconfiguration. A cloud storage bucket, database or admin panel left open to the internet, default credentials unchanged, or overly permissive access — an extremely common and entirely preventable cause.
• Malware and ransomware. Malicious software that steals data, encrypts it for extortion, or both.
• Lost or stolen devices and media, especially when unencrypted.
• Insider error or malice. A well-meaning employee mis-sends data, or a disgruntled one takes it.
• Third-party and supply-chain compromise. A breach at a vendor, plugin or integration that holds or can reach your data.

The reassuring implication is that since most causes are known and preventable, most breaches are too — which is why the prevention section at the end carries so much weight.

The incident-response plan: a clear sequence

When a breach hits, a plan beats panic. Industry frameworks — notably from the US National Institute of Standards and Technology (NIST) and the SANS Institute — describe incident response as a repeatable lifecycle. Distilled for a website owner, it runs as follows. The most important rule across all of it: act quickly, but methodically, and preserve evidence as you go.

Step	What you do
1. Prepare	Before anything happens: have a written plan, named responsibilities, contacts (legal, IT, comms), logging and backups in place, and know your legal duties
2. Detect & identify	Confirm an incident is real, and determine whether data was actually affected — turning a suspicion into a known breach
3. Contain	Stop further loss: isolate affected systems, revoke/reset compromised credentials and keys, block the attacker's access — short-term and then longer-term containment
4. Assess	Determine scope: what data, how many people, what type (financial, health, identifiers), and the likely risk to those individuals
5. Eradicate	Remove the cause: delete malware, web shells and backdoors, close the exploited vulnerability, remove rogue accounts
6. Recover	Restore systems from clean backups, validate they are secure, and return to normal operation under heightened monitoring
7. Notify	Inform the required authorities and affected individuals within the legal timeframes, and other stakeholders as appropriate
8. Post-mortem	Review what happened and why, fix the root cause, and improve the plan — blamelessly

Prepare (before it happens)

The single highest-leverage step happens before any breach: a written incident-response plan, clear roles (who decides, who investigates, who communicates, who handles legal), up-to-date contact lists, reliable logging so you can reconstruct events, and tested backups so you can recover. An organisation that has rehearsed this responds in hours; one improvising responds in days, and the difference shows in the outcome.

Detect and contain

When something surfaces — an alert, a customer report, a researcher's notice, a ransom note — first confirm it is real and that data was affected, drawing on the detection signals in how to tell if a website has been hacked. Then contain immediately: isolate affected systems, revoke or reset compromised credentials, API keys and sessions, and if necessary take vulnerable services offline. Crucially, preserve evidence — snapshot systems and copy logs before you start deleting, because you will need them to understand scope and root cause, and possibly for legal or law-enforcement purposes. Containment is the priority that limits the damage.

Assess the scope

Now establish what actually happened: which data was involved, how many individuals, and what type — names and emails are sensitive, but financial, health, government-identifier or password data raises the risk and the obligations sharply. This assessment drives everything downstream, especially the notification decision, because the law keys off the risk to the affected individuals.

Eradicate and recover

Eradicate the cause so you are not breached again the moment you reopen: remove malware, backdoors and web shells, close the exploited vulnerability (patch the software, fix the misconfiguration), and remove any rogue accounts or scheduled tasks. Then recover — restore from known-good backups taken before the compromise, verify the restored systems are clean and hardened, and bring services back under heightened monitoring to catch any re-infection. Resist the urge to rush back online before eradication is complete; a premature recovery onto an un-patched system simply restarts the incident.

Notification: your legal duties

Breach notification is a legal obligation in many jurisdictions, and getting it wrong adds regulatory penalties to the original harm. The rules vary, but the GDPR's regime is the most widely referenced.

The GDPR 72-hour rule. Where a personal-data breach is likely to result in a risk to the rights and freedoms of individuals, the data controller must notify the relevant supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach. If you report later than 72 hours, you must explain the delay. The clock starts when you become aware of the breach, not when it occurred — which is why prompt detection matters so much.

Notifying individuals. Separately, where the breach is likely to result in a high risk to individuals, the GDPR requires you to inform those individuals without undue delay, in clear language, describing what happened, the likely consequences, and the steps you are taking and they can take.

Recording. Even breaches you assess as low-risk and do not report externally should be documented internally — the facts, effects and remedial action — which regulators can ask to see.

Other jurisdictions. Breach-notification laws exist far beyond the EU. The UK has its own GDPR-aligned regime; many US states have breach-notification statutes (and sectoral rules such as HIPAA for health data) with their own thresholds and timelines; and numerous other countries impose similar duties. If you serve users across regions, you may face several overlapping obligations at once. The practical takeaway: know which laws apply to you before a breach, not during one, and involve legal counsel early. Where uncertain, treat the duties as real and seek qualified advice rather than guessing — this article is general information, not legal advice.

Communication

Beyond the legal minimum, how you communicate shapes whether you keep people's trust. A few principles:

• Be prompt and honest. Late or evasive disclosure compounds the damage; a clear, timely account — even an early "we are investigating and will update you" — preserves credibility.
• Be useful. Tell affected people exactly what was exposed and what to do: change passwords (especially reused ones), enable MFA, watch for phishing that references the breach, and monitor financial accounts where relevant.
• Coordinate internally. Align legal, technical and communications so the public message matches the facts and the regulatory filing.
• Do not overstate the fix. Claiming everything is resolved before eradication is confirmed risks a humiliating correction.

Silence and spin are what turn a manageable incident into a reputational crisis; transparency is usually the better commercial choice as well as the right one.

Post-mortem and prevention

Once the dust settles, run a blameless post-mortem: what happened, how the attacker got in, what worked in the response, what did not, and what concrete changes will stop a recurrence. Blameless matters — if people fear punishment, they hide the very details you need to learn from.

Then close the gaps, because prevention is dramatically cheaper than response. The controls that stop most breaches are well known and map directly onto the common causes:

• Strong authentication with MFA on every account that matters — the most effective single defence against the credential attacks that cause so many breaches.
• Patch relentlessly — keep the CMS, plugins, libraries and servers current so known vulnerabilities cannot be exploited.
• Least-privilege access so a single compromised account reaches as little as possible, and prompt removal of unused accounts.
• Encrypt sensitive data in transit (HTTPS everywhere) and at rest, so lost or stolen data is far less useful.
• Careful configuration — never leave databases, storage or admin panels exposed; change defaults; suppress verbose errors.
• Monitoring and logging so you detect incidents early and can reconstruct them — insufficient logging is itself an OWASP category.
• Tested, off-site backups so you can recover from ransomware or destruction without paying or rebuilding from scratch.
• Vet third parties, since their breach can become yours.

Most of these are covered in depth in how to protect your website from common attacks; the breach lens simply underlines that each prevented weakness is a breach you never have to respond to.

A quick breach-response checklist

• Have a written, rehearsed incident-response plan and know your legal duties before a breach.
• On detection: confirm it is real, then contain immediately — isolate systems, reset credentials, preserve evidence.
• Assess scope: what data, how many people, what risk.
• Eradicate the cause and recover from clean backups under heightened monitoring.
• Notify the supervisory authority within 72 hours where the GDPR applies, and affected individuals where the risk is high.
• Document every breach internally, even minor ones.
• Communicate promptly, honestly and usefully.
• Run a blameless post-mortem and close the root-cause gaps.

Go deeper

• Prevent the weaknesses that cause breaches: how to protect your website from common attacks.
• Detect a compromise early: how to tell if a website has been hacked.
• Encrypt data in transit: what is HTTPS and why your site needs it.
• Filter attacks before they land: what is a web application firewall (WAF).

Want a quick read on your site's headers, HTTPS and configuration gaps before something goes wrong? Analyse any URL with StackOptic — free, no sign-up.