The word everyone fears, made simple
"Data breach" sounds like a hacker in a hoodie, but most breaches are far more ordinary - an email sent to the wrong person, a laptop left on a train, a cloud folder accidentally set to "public". The good news is that the response is the same no matter the cause, and it is not complicated. This hour has two jobs: show you exactly what counts as a breach so you can recognise one, and give you a calm four-move playbook so that if it ever happens, you act instead of freeze.
What a breach actually is 9 min live
Strip away the drama and a data breach is one thing: personal data ends up exposed, lost, altered, or reached by someone who should not have it. There are exactly three ways that can go wrong, and it helps to hold all three in your head - because the third one surprises people. It is not always about information leaking out; sometimes the problem is that you can no longer get to your own data.
LiveThe three failure modes, in one sentence each3 min▶
Security people call these the "CIA triad", but you do not need the jargon. You need the three plain questions to ask about any incident:
- Confidentiality - did someone see it who should not have? (A leak, a wrong recipient, a stolen login.)
- Integrity - was it changed or corrupted when it should not have been? (Altered records, a tampered file.)
- Availability - can you still get to it when you need it? (Deleted by accident, or locked up by ransomware.)
If the answer to any of these is bad, and personal data is involved, you are looking at a breach. Notice that only the first is about data "leaking" - the other two are just as real.
LiveHow breaches actually happen3 min▶
The causes are more human than Hollywood. In the real world, the top ways personal data goes wrong are:
- The misaddressed email - the classic. You type a name, autocomplete picks the wrong one, and a spreadsheet of customers lands in a stranger's inbox.
- The lost device - an unencrypted laptop or phone left in a taxi, a USB stick dropped in a car park.
- The misconfigured cloud - a storage folder set to "anyone with the link" that should have been private.
- Hacking - stolen passwords, phishing, or malware, including ransomware that locks your files.
- The insider - a staff member who takes or peeks at data they should not.
Self-studyNot every mishap is a reportable breach2 min read▶
An incident and a reportable breach are not the same thing. If you send an internal spreadsheet to the wrong colleague inside your own company and they delete it straight away, that is a wobble, not a headline. What matters is whether personal data was genuinely put at risk of harm, and how many people it touched. We will meet the "when do I have to tell someone" line in Part 2 - for now, hold the instinct: recognise the incident first, judge how serious it is second.
The email that went to the whole list. A clinic emailed appointment reminders but put every patient's address in the "To" field instead of "Bcc". Nothing was hacked, no file was stolen - yet hundreds of people could now see each other's names and the fact they were patients. That is a confidentiality breach of sensitive data, caused by one wrong field. The lesson: breaches are usually ordinary mistakes, not master criminals.
The first four moves 9 min live
The moment you suspect a breach, panic is the enemy. What you want is a sequence you can follow on autopilot, the same way a fire drill works. There are four moves, always in this order: contain, assess, notify, learn. Do them in order and even a bad day stays manageable.
LiveMove 1-2: contain, then assess3 min▶
Contain means stop the bleeding, right now. Revoke the shared link, reset the password, recall the email if you can, take the affected system offline. The goal is to make sure it is not still getting worse while you figure out what happened.
Assess means answer three questions calmly: what data was involved, how many people does it affect, and how bad could it be for them? A leaked list of newsletter emails is one thing; a leaked list of medical conditions is another. This assessment is what tells you whether you have to move to the next step.
LiveMove 3-4: notify, then learn3 min▶
Notify means telling the people who need to know - the regulator, and often the individuals affected - when the breach is serious enough. Not every incident crosses that line, which is why assess comes first. When it does, speed and honesty matter more than a perfect report.
Learn is the move everyone skips and shouldn't. Once the fire is out, ask what let it start: the autocomplete that sent the email, the folder nobody locked, the password everyone shared. Fix that root cause, and the same breach cannot happen twice. This is where a bad day turns into a stronger organisation.
LiveWhen do you actually have to tell someone?3 min▶
This is the question everyone asks, and the answer is a rule of thumb, not a formula. The two big regimes draw the line like this:
- GDPR (Europe): the 72-hour rule. If a breach is likely to put people's rights at risk, you notify the supervisory authority within 72 hours of becoming aware of it. That "72 hours" is the famous number worth remembering. If the risk to people is high, you tell the affected individuals too.
- Singapore's PDPA: significant harm or large scale. You notify the regulator (the PDPC) and the affected people when the breach is likely to cause them significant harm, or when it is large scale - a common rule of thumb is around 500 or more people affected.
Keep these as instincts, not statutes: serious harm, or lots of people, means you probably have to tell someone - and fast. The deeper PDPA and GDPR courses have the exact wording, timelines, and exceptions.
The lost laptop that stayed a non-event. A staff member lost a work laptop on the train. Because it was encrypted, the data on it was unreadable to whoever found it - so the actual risk to people was low. The team still logged it and assessed it, but a well-judged assessment meant this one did not need a public notification. Encryption did not prevent the loss; it changed how serious the loss was.
A mini tabletop: "we lost the customer list" ★ 12 min · pen and paper
A tabletop is just a walk-through of a pretend crisis while everyone is calm. Run this one for your own organisation - it is the cheapest breach insurance there is.
Set the scene. "It's tomorrow morning. We've discovered our whole customer list was emailed to the wrong person yesterday." Say it out loud - imagining it is real is the point.
Contain. What could you actually do to stop it spreading? Recall the email, call the recipient, change access? Write down who does what.
Assess. What was on that list - names, emails, anything sensitive? How many people? How bad for them? If you don't know, that gap is a finding.
Notify and learn. Given the harm and the numbers, would you have to tell the regulator and the people? And what one change would stop it happening again?
Three questions to answer before you need to ★ 8 min · your next team chat
You never want to be figuring these out during a real breach. Answer them now, while it costs nothing.
Who first? "If we found a breach at 9pm on a Friday, who is the first person we call?" If there is no clear name, that is your first fix.
How many? "Do we know how many people are in our biggest dataset?" You cannot judge "large scale" if you have never counted.
Could we reach them? "If we had to warn every affected person tomorrow, could we - do we have a way to contact them?" A list you cannot email is a problem in waiting.
Before Session 5 ◐ 20 min total
- Write your four moves on one page - contain, assess, notify, learn - with a name next to each. Stick it somewhere findable. That is a starter breach plan.
- Find out who your organisation would notify: does anyone know how to reach the PDPC, or your EU authority? Session 5 is about who owns this.
- Count the people in your biggest personal-data set, roughly. Knowing whether you are above or below "a few hundred" changes your instincts.
- Optional: search one recent breach headline and spot which failure mode it was - confidentiality, integrity, or availability.
- If a breach happened today, who makes the first call, and do they know it?
- Which of our datasets would hurt people most if it leaked?
- Could we actually contact affected people if we had to?
- What is the single most likely way we would have a breach - and have we closed it?
Where this fits on the shelf
This on-ramp distills the plain-English core of the deeper courses. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Ransomware locks up your customer files so nobody in your company can open them. No data left the building. Is this a breach?
A breach has three failure modes: confidentiality (seen), integrity (altered), and availability (lost or locked). Ransomware is a classic availability breach even though nothing leaked.
2 · The famous "72-hour" window to notify the authority after becoming aware of a risky breach belongs to which regime?
GDPR sets the well-known 72-hour clock for notifying the supervisory authority. Singapore's PDPA uses a different test - significant harm or large scale (rule of thumb, 500+ people).
3 · You have just discovered a breach. What is the right FIRST move?
The order is contain, assess, notify, learn. You contain first so it stops getting worse - you cannot assess or notify accurately while it is still leaking.