The First 72 Hours After a Data Breach
6 min read
What separates a data breach from other security incidents is that two clocks run at once. One is the technical investigation: how they got in, what they took, whether they are still there. The other is the duty facing outward: when the affected people have to be told, when the regulator has to be notified. Most companies run only the first, remember the second once the investigation is done, and by then the time has usually gone. This is about the order of work in the first 72 hours, and about the question people get wrong most: when the clock starts. The deadlines and duties described here come from Taiwan's Personal Data Protection Act, so if you operate elsewhere your own regime is what binds you. This is general information, not legal advice. Whether a duty to notify applies turns on the facts of a case, and anything involving penalties or a dispute belongs with a lawyer.
1. Two clocks have to run at the same time
After something turns up, usually only one thing moves inside the company: find someone to investigate, read the logs, work out the scope. Nothing wrong with that, but it is open-ended. It can take three days or three weeks. The outward-facing duty has a deadline, and the deadline does not wait for the investigation.
So both should start the moment you find out. One track establishes what technically happened. The other establishes whether this falls inside the notifiable range, how the deadline is counted, and who has to be told. Different people run them, because whoever is investigating gets absorbed by detail and has no capacity left for the notification question.
2. The clock starts on knowledge, not on certainty
This is the point most often misread, and the one that causes most of the delay. The instinct is to wait: once I have confirmed there really was a leak and confirmed who it touched, then we can talk about telling people. That instinct is how deadlines get missed.
Article 12 of the Personal Data Protection Act, as amended, reads this way. On becoming aware that personal data it holds has been stolen, altered, damaged, destroyed or disclosed, the holder shall notify the people concerned. Where the case falls within the notifiable range, the regulator must be notified as well. The trigger is becoming aware, not having established the facts.
The content, method, deadline and scope of that notification are left to sub-regulations the competent authority has yet to finalise. Those remain at draft stage, and the effective date of the amended provisions is still to be set by the Executive Yuan. So whether the figure lands exactly on 72 hours depends on the final version, but the logic of the starting point will not change.
What counts as knowing is also earlier than most people assume. It is not the moment the owner hears about it, and not the moment an engineer confirms it. Support taking the first call from somebody saying their details appear to have leaked, an engineer finding the database was exported wholesale, a supplier writing to say they were breached: any of those can start the count.
3. The first few hours: stop the bleeding, keep the evidence
There are only two goals at this stage. Stop the leak from growing, and avoid destroying what you will need later. The two occasionally conflict, and when they do, stopping the leak wins. Just write down what you did.
Stopping it usually means rotating the relevant passwords and keys, switching off whatever is still leaking, and isolating the affected systems. Every one of those changes the state of the system, so log each action as you take it, with the time and the person who did it.
What not to do matters just as much. Do not reinstall, do not delete files, do not upload a suspicious file to an online scanning service, and do not tell anyone outside that no personal data was involved before you know. That last sentence is the expensive one, because there is a good chance you will have to contradict it a few days later. Checking and preserving a single machine is covered in the article on a compromised company PC, so it is not repeated here.
4. Who decides: three roles named in advance
What jams up during an incident is rarely the technical side. It is that nobody knows whether the decision is theirs. Do we notify, do we tell customers, do we take the service down: raise those on the day and the answer tends to be everyone waiting for everyone else.
So name three roles beforehand. They can be three people, and in a small company two people can cover all three, but none of them can be nobody.
| Role | Responsible for | What to arrange in advance |
|---|---|---|
| Decision maker | Whether to notify the regulator, tell affected people, or suspend the service | Confirm they can speak for the company, and that they can be reached |
| Recorder | Logging times, actions, decisions and the reasoning behind them | A simple sheet, kept somewhere other than the affected machine |
| External contact | One voice answering customers, media and the regulator | Agree beforehand that nobody else speaks separately |
The decision maker is not the IT person, and that is worth saying out loud. Judging whether to notify involves legal exposure and a commercial trade-off. That is outside a technical role and should not be carried by one. The technical job is to supply facts. The decision belongs to whoever can answer for it.
5. What has to be written down
Beyond notifying people and the regulator, Article 12 also requires prompt and effective measures to stop the incident spreading, and requires that the relevant facts, the impact and the measures already taken be recorded and kept for the authority to inspect. The record is part of the duty, in other words, not paperwork produced afterwards.
Start recording from the first minute
- The timeline. When it was found, who found it, how, and the time of every action taken since.
- The scope estimate and its basis. How many people, which categories of data, and what you based that on. Estimates change, so add a new entry rather than overwriting the old one.
- Actions taken. Which passwords were rotated, which feature was switched off, which machine was isolated, and who carried it out.
- Decisions and reasons. Whether to notify or not, whether to tell people or not, with the reasoning at the time. What gets questioned later is the reasoning, not the conclusion.
- Everything said publicly. The email to customers, the wording of any notice, the reply given to a journalist. Keep a copy of each.
Keep the record somewhere other than the affected machine. A shared document or paper both work. Give one person the job, and do not expect the group to reconstruct it afterwards, because by then everyone remembers a different version.
6. Inside and outside: different messages, no contradictions
Internally, the first thing to communicate is the single point of contact, not the details of the incident. Tell colleagues that any customer question goes to that contact, that they should not explain it themselves, and that they should not discuss it on social media. This is not concealment. It stops seven people producing seven versions, each of which has to be cleaned up later.
Externally, say what is known and say what the reader should do now. State what is established, say plainly that the rest is still being confirmed, and give a time for the next update. Do not promise nothing leaked in order to calm people, and do not offer compensation you cannot deliver in order to look sincere.
As for the regulator, the notifiable range, the method and the deadline all come from the sub-regulations, and announcements from the Personal Data Protection Commission are the place to check. Bear in mind that the effective date and the accompanying regulations are still moving, so do not work from a summary somebody wrote online two years ago.
What the first 72 hours decide is not whether the data comes back. It is whether you can account for yourself afterwards. Three things matter most: write down the time the moment you find out, run both clocks together, and let the person with authority make the decision. None of the three needs technical skill, and all three need to have been thought about once before the day arrives. Left until the day itself, that is exactly how the time disappears. As a reminder, this is general information about Taiwan's rules rather than legal advice. What is notifiable and by when follows the regulator's announcements at the time, and anything involving penalties or a dispute belongs with a lawyer.
Common questions
- Does every leak have to be reported to the regulator?
- No. The law requires telling the affected people once you become aware, while notifying the regulator applies to cases within a notifiable range, and that range and its deadline are set by sub-regulations. Those regulations are still at draft stage and the thresholds may change before they are finalised. Practically, establish how many records you hold and which categories they cover, because that number decides which tier you fall into. Where the answer is unclear, ask a lawyer.
- Do I have to tell customers before the investigation is finished?
- The trigger is knowledge rather than certainty, so you cannot wait for the full picture before the clock starts. The workable approach is staged: state the scope you have confirmed, say what people can do to protect themselves now, name what is still being checked and when the next update comes. Waiting until every detail is settled usually means the deadline has passed, and customers have generally heard it from elsewhere first.
- What counts as becoming aware of a breach?
- Earlier than most people assume. It is not when the owner hears about it and not when the investigation closes. Support taking a first call about details appearing to have leaked, an engineer finding the database was exported wholesale, a supplier writing to say they were breached: any of these can start the count. Which is why the first action on finding something is to record the time and how it surfaced. That entry is the only evidence you will have about when you knew.