What to do after a data breach: a step-by-step response

Two tracks, two clocks

A breach notification starts two different responses, and mixing them up is how people lose the first day. The individual track contains account access; its only clock is how fast attacker automation reaches your other logins. The organisational track is legal notification, and its clocks are written down: GDPR Article 33(1) and, for in-scope entities, NIS2 Article 23(4).

If you have both hats on — your own account leaked, and it was a work account — run the individual steps now and hand the organisational track to whoever owns incident response. The two run in parallel.

If it is your own account, act in this order

1. Change the breached password, and change it everywhere you reused it. The reuse is the actual vulnerability; the original site is just where it surfaced.
2. Secure your email account before anything else — it is the reset gateway to everything, so it gets a unique password and the strongest second factor available.
3. Turn on multi-factor authentication there, then on banking and work logins. Prefer a passkey or hardware key: CISA rates FIDO/WebAuthn and PKI-based authenticators as the phishing-resistant tier, app-based codes and push as better than nothing, and SMS or voice codes as the weakest.
4. Sign out all other sessions on the affected service. A password change does not always invalidate a session token an attacker already holds.
5. Move to a password manager so every new password is unique. This is the step that stops the next leak from cascading.
6. Expect phishing that quotes the leaked data back at you. Verify any unusual request through a channel you chose, not one the message supplied.
7. If financial data leaked, tell your bank and consider a card reissue; monitor statements for small test transactions.

The first 72 hours

Laid out against the clock, with the legal deadlines in their correct lanes:

Both clocks start at awareness, not at the intrusion. Slow detection does not buy you extra time, it spends it.

The GDPR clock, precisely

Article 33(1) requires the controller to notify the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it" — unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Miss the 72 hours and the notification must be accompanied by reasons for the delay. A processor instead notifies its controller without undue delay, under Article 33(2).

Article 33(3) sets the minimum content: the nature of the breach including, where possible, the categories and approximate number of data subjects and records concerned; the DPO or other contact point; the likely consequences; and the measures taken or proposed, including mitigation. Article 33(4) allows all of that to be provided in phases without undue further delay, so file what you know on time.

Article 33(5) is the clause most often missed: the controller shall document any personal data breach — the facts, the effects and the remedial action — so the authority can verify compliance. That includes incidents you assessed as low risk and chose not to notify. A decision not to report is only defensible written down.

When you have to tell the people affected

Notifying the regulator and notifying individuals are separate decisions. Article 34(1) requires communication to the data subject without undue delay where the breach is likely to result in a high risk to their rights and freedoms.

Article 34(3)(a) removes that obligation where the controller had applied measures rendering the data "unintelligible to any person who is not authorised to access it, such as encryption". Article 34(3)(c) adds a second route: where individual communication would involve disproportionate effort, a public communication can substitute.

This is the most concrete business case for encryption at rest in the whole regulation. The same incident on the same data is either a mass notification exercise or a single filing — and the difference is a control you implement beforehand.

If it is a work account: the NIS2 clocks

For essential and important entities in scope of NIS2, one incident can trigger both regimes at once. The GDPR 72-hour clock and the NIS2 24-hour clock run in parallel; neither satisfies the other.

Article 23(3) sets the threshold: an incident is significant where it "has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned", or where it "has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage". Note "capable of causing" — the test is not limited to damage already done.

Article 23(4) sets the sequence: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, an intermediate report on request, and a final report not later than one month after the incident notification. A leaked corporate credential that gave someone a foothold has to be assessed against Article 23(3), not quietly reset.

Two of the ten mandatory measures in Article 21(2) apply directly here: 21(2)(i), human resources security, access control policies and asset management, and 21(2)(j), multi-factor or continuous authentication. A response that ends without revisiting either is incomplete.

Report it, do not fix it quietly

The single biggest avoidable delay in incident response is a person who is embarrassed. As the UK’s NCSC puts it, "the stigma of clicking can prevent people reporting it, which then delays the incident response".

Report the leaked credential to your security team immediately, even if you have already changed it — they may need to force resets, hunt for misuse, check whether it appears in infostealer logs, and start the Article 23(3) significance assessment. And if you run the team: never make the reporter feel stupid, because the next person is watching how you react.

What you cannot undo

Passwords are rotatable. Personal data is not. If your name, address, phone number or date of birth leaked, treat it as permanently public: targeted phishing, SIM-swap attempts and identity fraud all get more convincing when the caller can recite details only a legitimate organisation should know.

The credential side has a long tail too. Leaked pairs are distributed through marketplaces, paid channels, live infostealer feeds and free Telegram samples, which is why a password from a service you abandoned years ago is still replayed today. The mechanics are in how credential stuffing works, and what counts as a breach in what is a data breach.

Reduce the next breach’s impact

• Unique passwords everywhere, held in a manager — the one change that removes the cascade.
• Phishing-resistant MFA on email, banking and work accounts; app-based codes elsewhere as a floor.
• Encrypt personal data at rest if you are the organisation — Article 34(3)(a) makes that pay off during an incident.
• Keep monitoring active, so the gap between a leak and your response is measured in days rather than years.