Incident basics
Why it matters Sooner or later a site you use will leak data, or something you run will. What you do in the first hours decides how much harm follows. A calm, practised order of steps beats panic, whether it is your own account or your customers' data.
A burst pipe
When a pipe bursts you do not start by redecorating. You turn off the water, you protect what you can, you find out how bad it is, you fix the pipe, and only then you repair the damage and ask why it happened. Data incidents follow the same order.
Incident: something that has put data at risk, or may have: a breach at a company, a lost laptop, a file shared with the wrong people, a stolen password.
Breach: an incident where data actually reached someone who should not have it.
Part 1: when a service you use leaks your data
You get an email saying "we had a security incident". First, check it is real: go to the service by typing its address yourself, not by clicking the link in the email, because scammers copy these messages. Then:
- Change the password for that service, and anywhere else you used the same one. A reused password is how one leak becomes five.
- Switch to a passkey, or turn on two-step login, so a leaked password alone is not enough.
- Find out what leaked. An email address means more spam and phishing. A password means step 1 is urgent. Card or ID details mean contacting your bank or the issuer, using the number on your card or their official site.
- Expect targeted phishing. Criminals use leaked details to sound convincing: "We see you ordered from shopa.example on 3 March...". Be extra careful with messages that mention the incident.
- Write down what you did and when. If anything strange happens later, you will know where you stand.
Part 2: when it is your data or your users' data
Now you are the one who must act. A simple order of five steps:
- Contain. Stop the leak: turn off the exposed page, revoke the shared link, disable the stolen account, rotate the leaked key.
- Preserve. Keep logs and copies of what happened before you change much more. You will need them to understand the incident.
- Assess. What data, about how many people, for how long, and who might have it? Be honest about what you do not know yet.
- Tell people. Tell affected people clearly and soon: what happened, what data, what you have done, and what they should do. Plain words, no blame-shifting.
- Learn. Fix the cause, not just the symptom, and write a short review of what went wrong and what changes.
Rotate a key: replace a secret (a password, API key or token) with a new one and switch off the old one, so a leaked copy stops working.
Depending on where you are, there may also be formal rules about who you must tell and by when. This course does not cover law, so get qualified advice for that part.
Less data, smaller incidents
The best incident plan starts before any incident. Data you never collected cannot leak, and data you deleted on schedule cannot leak either. Every "kept too long" flag from the last lesson is a future incident made smaller.
A common misconception
"Stay quiet until you know everything." Waiting feels safer, but people cannot protect themselves from a leak they do not know about. Tell them what you know, say clearly what you are still checking, and update them as you learn more.
Try it Write a three-line incident card for yourself and keep it with your notes: which account you would secure first, where you would change passwords, and who you would call about cards or IDs. Thinking about it now means you will not have to think in a panic later.
Recap
- When a service leaks your data: verify the notice yourself, change reused passwords, add a passkey or two-step login, and watch for phishing.
- When you leak data: contain, preserve, assess, tell people, learn.
- Rotate leaked secrets so stolen copies stop working.
- Collecting and keeping less is the cheapest incident plan there is.
This lesson is locked
Lessons open one at a time. Finish the previous lesson to unlock this one.