72-Hour Personal Data Breach Response: Decision Matrix, Timeline, and Filing Templates

3 a.m.: 120,000 records just left the database — the clock is already running

Disclaimer: This is a first-response triage document for practitioners, based on the Personal Information Protection Act and its Enforcement Decree as interpreted as of August 2026. Statutory text can change, and conclusions will vary with the facts of a given incident. Always run legal review in parallel with the actual response.

Let’s correct the first misconception incident responders usually have.

72 hours is not a “finish the investigation” deadline. It is a “first notification and regulatory filing” deadline.

The clock keeps running even if forensics is unfinished, the record count is not final, and the root cause is unknown. Recent PIPC enforcement has a clear pattern of treating late filing itself as a separate violation. “We waited so we could file one accurate report” is a weak mitigation argument. File what you have confirmed, then supplement with follow-up filings.

One more point. GDPR’s 72 hours and the Korean rule are different regimes. Both use the number 72, which causes constant confusion, but the notice recipients, the clock-start, and the exemption tests differ. For a domestic incident, decide under the Korean statute. If EU data subjects are mixed in, treat the two regimes as concurrently applicable and review them separately.

What “time of awareness” actually means

The 72-hour clock starts when you became aware of the leak. In practice, how you pin that timestamp is what decides whether you were late.

Four triggers that are likely to count as legal “awareness”:

Draw the line this way. Suspicion ≠ awareness — but delaying confirmation can be read as evasion of awareness. If you sat on an alert for three days and then confirmed it, you will have a hard time arguing the clock started three days later.

Practitioner tip — lock the awareness timestamp in writing.

• Open a [suspected-breach] ticket and put UTC/KST on the first comment
• Attach the original evidence to the ticket (SIEM screenshot, email headers, tip text)
• Leave one sentence on “who decided it was a leak, when, and on what basis”
• If log timestamps and ticket timestamps disagree, check NTP sync first — that goes straight to log credibility

If you are not confident in log retention and timestamp integrity, review the collection and retention principles in A 3-step error-log analysis process first.

30-second decision matrix: notify / report / not required

There are only three axes.

1. Scale of the leak — 1 or more records? 1,000 or more data subjects?
2. Data type — unique identification information / sensitive information / account credentials (ID + password) / ordinary personal information
3. Encryption — was it encrypted, and did the decryption key leak with it?

Remember two core rules first.

• Data-subject notice does not depend on scale. A leak of one record still triggers the duty to notify.
• Regulatory reporting (PIPC / KISA) splits on scale and data-type tests.

[Table 1] Decision matrix by combination

The “regardless of count” language in rows 3 and 4 sits in an area of the Enforcement Decree that has been amended before. Confirm the latest PIPC notices and interpretive guidance before a final call. Do not hard-code it into internal policy as settled text; operate it with a “confirm required” annotation.

Four boundary cases that trip people up

① Encrypted, but the key server was compromised in the same incident Encryption is a defensive control, not an exemption. If the decryption key was inside the same blast radius, treat it as a plaintext leak (Table 1, row 7). Writing only “it was encrypted with AES-256” on the report and omitting key-management status will hurt you later.

② Password hashes with no salt Plain MD5/SHA-1 hashes are effectively recoverable via rainbow tables. Treat this as an account-credential leak and, in the notice, tell people to change passwords immediately. Document whether salted slow hashes (bcrypt/Argon2) were in use, plus the algorithm and iteration count.

③ Unauthorized access by an insider (no confirmed exfiltration) “They only viewed it; nothing left the building” holds only if the logs prove it. Until you have fully checked download, screen-capture, and personal-email logs, leave leak as a live possibility. If you have no detection for this class of event, park it as a follow-up work item using How to build an insider-threat detection system.

④ Accidental CC on an email The most common incident, and the most underestimated. Personal information (the email address itself is personal information) was exposed on the recipient list, so treat it as a leak. Keep records of whether recall succeeded and of deletion requests sent to recipients.

Why the decision itself must be documented

When investigators later ask “why didn’t you report,” you need the basis as of the time you decided. Even if the call turns out wrong, a record that you judged in good faith on reasonable grounds can work as mitigation. No record reads as “you never even decided.”

• Export the matrix result to PDF, including decision time, decision-maker, and CPO signature
• Attach screenshots of the log queries you relied on
• Store it in an incident-only secured folder and retain access history

72-hour timeline: 0h → 24h → 72h → after

[Table 2] Timeline by window

Rules for managing work products

A document you created but do not control might as well not exist. Lock these three.

• Signers: ①③⑦⑨⑫ require the CPO’s signature. ④⑤⑥: security lead. ⑧⑩: practitioner signs, CPO confirms.
• Storage: One incident-only folder. No scattering across personal PCs or personal mailboxes.
• Access control: Response-team members only, with access logging. You must be able to show “who edited which document, when” during an investigation.

The most common evidence-preservation mistake is logging into the original server “to investigate” and rummaging through files. Access times and atime get contaminated, and in-memory evidence disappears. Containment and evidence preservation run at the same time, but as separate procedures.

Filing channels and forms — three fill-in-the-blank templates

Filing paths

• Online: Personal Information Portal (privacy.go.kr) → personal information infringement/leak menu → personal information leak report. Authenticate as a business, complete the form, submit.
• KISA: File a technical incident report in parallel through the intrusion-incident intake channel. Personal-data leak reporting and intrusion-incident reporting have different purposes — confirm whether you need both.
• If online filing is unavailable: Paper / fax and other fallback intake exists. If the portal is down, screenshot the attempted filing screen and proceed via the fallback path. A record that “we tried and could not” becomes your lateness explanation.
• Immediately after filing, capture: receipt number, filing date/time, handling division, deadline for additional materials. Document those four items right away.

Exact menu paths and form layouts can be redesigned. Check official PIPC guidance immediately before you file.

[Template 1] Sample language by leak-report field

The report has five fields. For each, a bad example vs. a good example.

① Time and circumstances of the leak

• ❌ Bad: “Personal information appears to have been leaked due to a recent hack.”
• ✅ Good: “At 2026-08-09 02:41 (KST), unauthorized access occurred to the web application server’s admin page; member-DB query activity ran between 02:41 and 03:15. Awareness at 2026-08-09 03:52 via a SIEM bulk-query alert. Initial intrusion path is under investigation.”

At {{time of incident}}, {{attack or incident type}} occurred on {{system/asset name}}.
From {{start time}} to {{end time}}, {{observed activity}} was confirmed.
The leak was identified at {{time of awareness}} via {{awareness channel}}.
{{current investigation status}}

② Data elements and scale

• ❌ Bad: “Some member information”
• ✅ Good: “Elements leaked: name, email address, mobile number, encrypted password (bcrypt). Confirmed scale: 122,431 records (as of 2026-08-10 12:00, based on query-log analysis). Resident registration numbers and account numbers are not stored in the affected table and are excluded.”

Elements leaked: {{element 1}}, {{element 2}}, {{element 3}}
Confirmed scale: {{count}} records (as of {{cutoff datetime}}, based on {{basis}})
Elements not leaked: {{element}} — {{basis for exclusion}}
Encryption: {{algorithm}} / decryption key leaked: {{yes/no and basis}}

③ Steps data subjects can take

• ❌ Bad: “Please be careful.”
• ✅ Good: “Immediately change passwords on any other service that reused the same password; do not click links in texts or emails impersonating us; guidance on identity-theft prevention services.”

④ Controller response and redress

• ❌ Bad: “We will strengthen security.”
• ✅ Good: “① Compromised accounts disabled immediately and all admin passwords force-changed (completed 08-09 04:10) ② Affected IP ranges blocked (04:25) ③ All user sessions force-expired (05:00) ④ Dedicated intake desk opened; individual redress process explained upon confirmed harm.”

⑤ Responsible team and contact

• List the team name, handler name, direct phone number, and a dedicated email. A main switchboard number alone can look like uncooperative handling because of contact delay.

[Template 2] Data-subject notice email

Subject: [Important] {{company name}} personal data breach notice and requested actions

Hello, this is {{company name}}.

On {{time of awareness}} we confirmed that users’ personal information was leaked externally.
We sincerely apologize for the inconvenience and concern this causes.

■ Time and circumstances of the leak
- Estimated time of occurrence: {{time of incident}}
- Time of awareness: {{time of awareness}}
- Circumstances: {{short summary}}

■ Personal information elements leaked
- {{element 1}}, {{element 2}}, {{element 3}}
- Elements not leaked: {{elements not leaked}}

■ Actions you can take
1. Please change your {{company name}} account password immediately. ({{reset link}})
2. Also change the password on any other service where you reused the same password.
3. Do not click links in texts or emails impersonating us.
   We will never ask for a password or financial information by email.
4. We recommend an identity-theft prevention service if needed.

■ Actions we have taken
- {{containment action}} ({{completed at}})
- {{additional action}} ({{completed at}})
- {{recurrence-prevention plan}}

■ Redress and inquiries
- Dedicated desk: {{phone number}} (hours: {{hours}})
- Email: {{dedicated email}}
- Regulator / law-enforcement reporting: Personal Information Infringement Report Center (privacy.go.kr), Korean National Police Agency Cyber Investigation Bureau

We have completed filings with the relevant authorities as required by law,
and we will provide further updates if the investigation status changes.

{{name}}, Personal Information Protection Officer, {{company name}}

[Template 3] Website notice (substitute notice)

When you do not have contact details for some data subjects, website posting can substitute for notice. Always send individual notice first to everyone you can reach, and use posting only to cover the unreachable remainder.

[Notice] Personal data breach

Posted: {{start date}}
Posting period: {{start date}} through {{end date}} (post for at least 30 days)

1. Time and circumstances of the leak
   {{time of incident}} {{short summary}}

2. Personal information elements leaked
   {{list of elements}}

3. Scale of the leak
   {{confirmed scale}} (as of {{cutoff date}}; may change as the investigation proceeds)

4. Actions users can take
   {{guidance}}

5. Our response and recurrence-prevention measures
   {{actions taken}}

6. Harm intake and contact
   Team: {{team name}} / Phone: {{number}} / Email: {{email}}
   Intake hours: {{hours}}

{{company name}}
Personal Information Protection Officer {{name}}

Posting checklist

• Placed where it is reachable in one click from the main page
• Accessible without login
• Full-page screenshot saved, with posting time visible
• No ad-hoc deletion before the posting period ends (confirm the required period under applicable rules)

Three failure branches — decide → act → document

① Scale is not confirmed inside 72 hours

Decide Unconfirmed scale is not a reason to pause filing. Waiting for a final number is delay. File first on the range confirmed so far, then supplement with amended / additional filings.

Act

1. Size the minimum range confirmed as leaked (the range you can prove from logs)
2. State on the report that “investigation is ongoing and expansion is possible,” and file now
3. Set your own follow-up investigation deadline (e.g., +7 days) and calendar the amended filing
4. When a larger scale is confirmed, send supplemental notice immediately

Sample language for the report:

The leak scale confirmed from log analysis to date is {{count}} records (as of {{cutoff datetime}}).
Analysis of {{unanalyzed log range}} is still in progress, and the scale may change
with the investigation. Upon confirmation we will file an amendment and send
supplemental notice without delay.
(Investigation target completion: {{target date}})

Document

• Basis for the first-pass count (queries, log range, aggregation method)
• A technical explanation of why it could not be finalized at that time
• After the amended filing, a delta table vs. the original filing

② The leak occurred at a processor (entrusted vendor)

Decide Cloud / SaaS outsourcing has multiplied fights over who is on the hook. The starting point for response is still clear. As a rule, the controller (the personal information processor that entrusted the work) is the party that notifies data subjects and files with the authorities. “The vendor already filed, so we don’t have to” is a dangerous call. Supervisory responsibility also stays with the controller (Art. 26 of the Act, as of August 2026 — exact allocation of liability needs legal review).

Act

1. Demand materials from the processor in writing, immediately.
   • Time of occurrence and time of awareness (on the processor’s clock)
   • Scope and elements that include your data
   • Record count leaked and the basis for that count
   • Processor containment actions and completion times
   • Originals or copies of relevant access / audit logs
   • Whether the processor has filed, and the receipt number
2. Review the contract: notice-obligation clause (is a deadline specified?), audit rights, log-production duty, damages / indemnity
3. Check for sub-processing (the processor re-entrusted to someone else) — whether a sub-processing approval process existed will be a live issue

Document

• The written demand and the processor’s reply (including time of receipt)
• Extracts of the relevant contract clauses
• Current inventory of processing arrangements (which vendor holds which elements)

If your inventory of processing arrangements is weak, you will lose days at this step. Day-to-day controls overlap heavily with the outsourcing / third-party provision items in the 2026 ISMS-P certification prep checklist, so tightening both together is efficient.

③ The data sits in an overseas cloud

Decide An overseas data location does not turn off Korean PIPA notice and filing duties. “It’s in a US region, so it isn’t a domestic filing” does not work. At the same time, if EU-resident data is included, GDPR and other extra-territorial rules can apply in parallel.

First-pass test for extra-territorial overlap:

• Are any data subjects EU/EEA residents?
• Is the service offered toward the EU market?
• Do California or other US state laws, Japan, Singapore, or other countries of service raise applicable rules?

Act

1. Pin the incident region and the data-residency region exactly (including multi-region replication)
2. Secure cloud logs — if retention is short, export first
   • Many services cap log retention at 90 days; export to separate storage immediately
   • If you have no log pipeline, register the retention settings covered in AWS CloudWatch monitoring, alarms, and log collection in practice as a follow-up work item
3. Open a formal ticket with the cloud provider’s incident response (IR) desk — response speed depends on support plan, so set Severity correctly
4. Confirm the Shared Responsibility boundary — provider infrastructure issue vs. your misconfiguration (public bucket, over-privileged access)

Document

• Inventory of regions, accounts, and resource identifiers
• Cloud IR ticket number and provider replies
• Hashes and storage location of log-export artifacts
• Legal memo on whether extra-territorial rules apply

Sanction baselines, mitigating factors, and what to build today

Sanctions by violation type

Specific fine and surcharge amounts and rates change with statutory amendments and imposition-criteria notices. That is why this post does not lock in numbers. Verify directly against official PIPC materials.

Factors commonly treated as mitigating

• Self-reporting and prompt notice / filing
• Immediate technical measures to stop spread
• Real effort to redress data-subject harm (dedicated desk, compensation process)
• Evidence of ordinary-course security measures (encryption, access control, log management)
• Good-faith cooperation with the investigation

Aggravating factors

• Late or concealed notice / filing
• Repeat occurrence of the same or similar incident
• Absence of basic security measures (plaintext storage, weak access control)
• Refusal to produce materials / non-cooperation

Three things to build today

If you build these on the day of the incident, you are already late. Spend 30 minutes now.

① Awareness-time record form Register it as a ticket template. Five fields are enough — time of awareness (KST), awareness channel, first person who became aware, one-line basis, attached evidence.

② Internal version of the decision matrix Rebuild [Table 1] mapped to the data elements you actually hold. “Which tables hold which grade of information” is what determines decision speed. With no data-element inventory, the decision itself takes a day.

③ Pre-approved notice drafts Adapt [Template 2] and [Template 3] to your voice and get legal and comms pre-approval. Negotiating copy on incident day burns half a day. The goal is a state where you only fill placeholders and send.

Disclaimer, again. The decision matrix and timeline in this post are aids for first-response triage. Statutory interpretation and the final call depend on the facts of each matter; always run review by legal counsel in parallel. The statute and notices may have been amended after August 2026.

FAQ

Q1. When exactly is “time of awareness”? A. When you became aware of the leak. In practice, take it as “the time you confirmed this was a data leak, not normal business,” and record the basis with it (alert text, log-query results). Bare suspicion is hard to treat as awareness, but deliberately delaying confirmation can be read as evasion of awareness.

Q2. Do weekends and holidays count inside the 72 hours? A. The safe operating assumption is that leak notice and filing deadlines run on calendar hours. A Friday-night incident means Monday morning is already ~60 hours in. You need a weekend on-call roster and a CPO emergency contact tree. Legal interpretation of the deadline calculation still needs case-by-case counsel.

Q3. If it is under 1,000 people, can we skip reporting? A. Looking only at the scale test, there is room to say so — but if unique identification information, sensitive information, or account credentials are included, or the leak came from external hacking, it can be reportable regardless of count. And data-subject notice is mandatory even for one record. Do not decide on scale alone.

Q4. If it was encrypted, are notice and reporting waived? A. Do not treat encryption as an automatic waiver. Encryption is evidence of security measures and a harm-mitigation factor, but if the decryption key leaked with the data, or the algorithm is weak (unsalted MD5, etc.), it is treated as equivalent to a plaintext leak. You must explain the algorithm, key-management method, and whether the key leaked.

Q5. What if we don’t have contact details for some subjects? A. Send individual notice first to everyone you can reach, and substitute website posting for the remainder whose contacts you do not have (see [Template 3]). Keep a basis for “why individual notice was impossible” (count with no contact on file, bounce logs). Confirm placement and duration requirements under the applicable rules.

Q6. Law enforcement is investigating and asked us to delay disclosure. Can we hold? A. There is room to adjust the manner and content of disclosure in cooperation with an investigation, but it is hard to treat the notice/filing duty itself as extinguished. Get the request in writing, inform PIPC of that fact, and decide only after legal review. Holding on an oral request and then eating a lateness finding is the highest-risk pattern.

Q7. After we filed, the investigation showed a larger scale. What now? A. File an amendment / supplemental report without delay, and send supplemental notice to newly identified data subjects. If the original filing said “investigation ongoing, figures may change,” the follow-up is much easier. Document the delta between the original and the amendment in a comparison table. Expanding scale is less damaging than sitting on the correction.

Q8. How should we prepare for notice cost and inquiry staffing? A. Bulk notice bottlenecks on email/SMS cost and send-infrastructure limits. At tens of thousands of records, check the send provider’s daily throughput cap in advance. Inquiry volume concentrates in the 24–48 hours after notice goes out, so staff that window and pre-write an FAQ script to keep answers consistent. Log every response — it becomes your later justification file.