Data Breach Triage (U.S.): A 24-Hour Checklist Non-Experts Can Actually Run

Purpose. This hands-on playbook shows a small, non-specialist team how to triage a suspected U.S. data breach in the first 24 hours. It translates legal concepts into concrete actions: what to collect, who to notify, how to freeze the facts, and which clocks may already be running. It assumes you do not have a mature SOC or legal department and may rely on outside partners. It is not a substitute for legal advice; laws vary and change.

Scope. The guidance covers incidents involving consumer, employee, or client data across SaaS, cloud, on-prem, email, and devices. It treats four common patterns: (1) mailbox compromise with forwarding rules, (2) lost or stolen device, (3) cloud storage misconfiguration or public link, and (4) server or database access with possible exfiltration. Ransomware-specific issues are referenced only as needed (e.g., exfiltration, sanctions) because this is a breach triage checklist, not a ransom playbook.

Incident vs breach — what you must decide in 24 hours

• Incident: any adverse event affecting confidentiality, integrity, or availability (e.g., suspicious login, lost laptop, misrouted email).
• Breach: under most U.S. state laws, the unauthorized acquisition of personal information (PI), or sometimes unauthorized access to PI, depending on the state. Sector rules (e.g., HIPAA, GLBA) have their own definitions.
• Practical test for day one: did someone without a legitimate purpose view, copy, or obtain data elements that can harm an individual if misused (names paired with SSN, driver’s license, account credentials, medical info, etc.)? If “likely yes,” treat clocks as running while you confirm.

24-hour triage timeline (phases and decision gates)

00–01h  Detect & Freeze   [#####---------------]
01–04h  Scope & Preserve  [#########----------]
04–08h  Risk Snapshot     [##########---------]
08–12h  Notification Map  [###########--------]
12–24h  Comms + Restore   [##############-----]
      

Hour 0–1: Detect, freeze, and set command

• Open an incident bridge (single call/chat) and assign roles: Incident Lead, Technical Lead, Legal/Privacy Lead, Comms Lead, Scribe. Use UTC timestamps.
• Contain quietly: isolate affected accounts/devices (disable tokens, revoke sessions, EDR network containment). Avoid wiping or reimaging before evidence capture.
• Stop mass harm: kill malicious forwarding rules, reset compromised credentials, remove public links, disable access keys.

Hour 1–4: Preserve evidence and bound the blast radius

• Evidence kit: memory captures (if feasible), disk images for critical hosts, inbox audit logs, cloud control-plane logs, storage access logs, firewall/DNS/proxy telemetry, SaaS audit exports. Hash and label artifacts; record chain-of-custody.
• What moved where? Identify unusual sign-ins, API key uses, mailbox rules, shared links, large object reads/exports, or forwarding destinations.
• Data map overlay: mark which stores contain regulated data (PII, PHI, financial, credentials). If you have no map, build a mini-map today: list top 5 systems, owners, and data elements.
• Vendor angle: if SaaS or processor is implicated, pull the DPA and contact their security line for logs and a written incident statement.

Hour 4–8: Preliminary breach assessment and risk-of-harm snapshot

• Population estimate by jurisdiction: count unique people whose data may have been accessed or acquired; bucket by state; include employees and consumers.
• Data elements lens: SSN/driver’s license/passport; financial account + codes; medical/health; credentials; biometrics; precise location. The more sensitive the element, the more likely notices are required.
• Access vs acquisition: if you can show no evidence of access beyond failed logins or blocked attempts, the event may be an incident only. If logs show open/read/list or exfil, treat as likely breach.
• Encryption safe harbor check: was the data encrypted to strong standards and were keys kept separate? If yes, some states may not require notice.

Hour 8–12: Build the notification map and draft content

• Controller vs processor: confirm whether you acted as controller (your users/employees) or processor (processing for a client). Controllers usually notify consumers and regulators; processors notify controllers quickly and provide facts.
• Regime clocks to consider:
  • State breach laws: “most expedient time without unreasonable delay,” with some fixed ceilings (e.g., 30 or 45 days) and attorney general thresholds.
  • Health sector: HIPAA Breach Notification Rule (individual + HHS; up to 60 days outer limit) or FTC HBNR for certain consumer health apps.
  • Financial sector: GLBA Safeguards Rule notification to the FTC for defined events (promptly, often with a 30-day ceiling referenced in guidance/alignments).
  • Public companies: SEC Form 8-K Item 1.05—file within four business days after materiality determination; this is investor-facing and separate from consumer notices.
• Law enforcement hold (if applicable): obtain written request and a review cadence; restart notifications promptly when lifted.
• Draft letters and FAQs in parallel: describe what happened, what information was involved, what you’re doing, and what individuals can do. Avoid confirming attacker identity or payment decisions in consumer copy.

Hour 12–24: Communications, restoration gates, and executive brief

• Communications alignment: internal bulletin (need-to-know), holding line for press/inquiries, customer support scripts. Keep messaging fact-based and avoid speculation.
• Restoration gates: do not reconnect compromised systems until persistence checks pass, credentials/keys rotate, vulnerable services patch, and logging improves. Stage recovery by business priority.
• Executive/board one-pager: incident summary, preliminary legal assessment, populations by jurisdiction, clocks, immediate mitigations, and a 30-day improvement plan.

Field kit — forms and checklists you can copy

1) Single timeline (UTC) & decision log

[Time]  [Owner]  [Action/Decision]                       [Evidence/Link]               [Next review]
08:10   IC       Opened incident bridge                   /bridges/IR-2025-11-03        09:00
08:14   Tech     Disabled token; exported IdP logs        IdP export #4451              08:45
08:22   Legal    Privilege memo opened; vendor notified   /legal/IR-priv-memo.docx      Continuous
  

2) Data-at-risk worksheet (minimal version)

3) Notification matrix

4) Consumer letter skeleton (controller use)

What happened; When it happened; What information was involved; What we are doing; 
What you can do (credit freeze, password changes, phishing tips); How to contact us; 
Regulatory rights where applicable. Avoid speculation and promises you cannot verify.
  

Common day-one scenarios and how to triage them

Mailbox compromise (business email)

• Indicators: impossible travel logins; OAuth grants; forwarding rules; replies to invoices; mass reads.
• Triage moves: reset + revoke tokens, remove rules, export audit logs, identify contact lists accessed, search for data elements inside attachments. If attachments contain PI, treat as likely breach.
• Scope tip: “Read” of a message containing PI may equal access; you need content search with samples and log correlation.

Lost or stolen device (laptop or phone)

• Indicators: unreturned asset, theft report, geolocation pings.
• Triage moves: verify full-disk encryption, remote wipe status, and screen-lock policy. If encryption is strong and intact, many states do not consider this a reportable breach.

Cloud storage misconfiguration (public link or ACL)

• Indicators: open bucket/folder, search engine caching, 3rd-party crawler hits.
• Triage moves: lock down permissions, rotate access keys, review object access logs, check for indexing/crawl artifacts. If external reads occurred, treat as breach; if not, document search-engine tests and absence of reads.

Database or file server access

• Indicators: admin login from new IP, SQL exports, anomalous data transfer, privilege escalation.
• Triage moves: capture process lists and memory, export DB and host logs, calculate volume read vs normal, review DMZ egress. If large selective reads or exports are present, treat as likely breach.

What not to do in the first day (legal and technical pitfalls)

Lightweight metrics you can capture on day one

• Time to bridge: minutes from first alert to command channel open (target < 15 minutes).
• Time to legal engaged: minutes until counsel looped in (target < 30 minutes).
• Evidence completeness: % of systems with logs exported and hashed (target ≥ 80% within 8 hours).
• Population confidence: low/medium/high rating with rationale by 12 hours.
• Notification readiness: letters + matrix v0.1 drafted by 12 hours.

Sector and cross-cutting rules (orientation only)

• HIPAA Breach Notification Rule (unsecured PHI): individual notices and HHS portal; up to 60-day outer limit; media in large events; risk assessment factors (nature, who, viewed/acquired, mitigation).
• FTC Health Breach Notification Rule (HBNR): consumer health apps/PHRs outside HIPAA—individual + FTC notices; trackers and app data are in scope.
• GLBA Safeguards Rule breach notice for certain non-bank financial institutions: regulator notice for defined “notification events,” typically promptly with an outer limit commonly aligned around 30 days.
• SEC 8-K Item 1.05 for public companies: file within four business days after materiality determination; separate from state or sector privacy notices.
• State breach laws: all 50 states, D.C., and territories—definitions and deadlines vary; many require AG notice above thresholds and have content requirements (description, categories, steps, contacts).

Conclusion

The first 24 hours of breach response are about capturing truth and buying options. Freeze the scene, save the logs, and record decisions under a single timeline. Build a minimal but defensible answer to four questions: what happened, what data was at risk, who is affected by jurisdiction, and which clocks apply. Draft notifications as evidence of readiness even if you never send them. Align containment and recovery with legal realities—encryption safe harbors, controller/processor duties, and sector rules. If you follow this triage sequence, non-experts can move fast without breaking the case, protect individuals sooner, and give leadership credible choices for day two and beyond.

This material is for general informational purposes only and does not constitute legal advice. Consult qualified counsel licensed in your jurisdiction for advice about your specific facts and deadlines.

FAQ

1) What makes an “incident” a legal “breach”?

Most state laws trigger when there is unauthorized acquisition of PI; some trigger on unauthorized access. If logs show viewing/reading or selective exports of covered elements, treat as a likely breach while you confirm.

2) If we pay a ransom, do we still have to notify?

Yes, if data was accessed/acquired under applicable laws. Payment does not erase notification duties or sanctions/AML risks.

3) Can we delay notices for law enforcement?

Often, yes—but only with a written request from law enforcement. Track when the hold ends and resume promptly.

4) Does strong encryption mean no breach?

Some laws provide safe harbor if data was encrypted to strong standards and keys were not compromised. You need evidence of key custody to rely on this.

5) We use a vendor. Who notifies?

Vendors (processors) must notify you quickly and supply facts/logs. As controller, you often carry consumer/regulator notices.

6) What should be in the consumer letter?

What happened, what information was involved, what you’re doing, what individuals can do (e.g., credit freeze, password changes), and contact details—without speculation or attacker promises.

7) How do we prove we acted reasonably?

Maintain the timeline, decision log, evidence register (with hashes), population estimates by state, notification matrix, and drafts under privilege. These artifacts show diligence.

8) What metrics matter on day one?

Time to bridge (<15m), time to legal (<30m), % systems with logs exported (≥80% in 8h), population confidence by 12h, draft notices ready by 12h.

9) Are employee incidents treated differently?

Employees count as “individuals” under many breach laws. Include them in counts by state and apply sector rules (e.g., benefits/health data).

10) When is it safe to reconnect systems?

After eradication checks pass (no persistence), credentials/keys rotate, vulnerable services patch, and logging/alerts improve—then stage restoration by business priority.

Technical Basis & Legal Sources (orientation)

• NIST SP 800-61 (Computer Security Incident Handling Guide) — incident lifecycle, evidence handling, coordination.
• NIST Cybersecurity Framework 2.0 — outcome-based governance across Identify/Protect/Detect/Respond/Recover.
• CISA #StopRansomware — containment/recovery checklists and inject ideas for exercises.
• HIPAA Breach Notification Rule (45 CFR §§164.400–414) — definitions, risk assessment factors, patient/HHS/media timelines.
• FTC Health Breach Notification Rule (16 CFR Part 318) — notices for certain health apps/PHRs outside HIPAA.
• GLBA Safeguards Rule breach notice (16 CFR Part 314) — regulator notice for defined events for non-bank financial institutions.
• SEC Form 8-K Item 1.05 — public companies disclose material cyber incidents within four business days after materiality determination.
• State breach statutes (50 states + D.C./territories) — varying access/acquisition standards, AG thresholds, content and timing requirements.

Disclaimer

This information is for general educational purposes only and does not constitute legal advice. It does not replace an attorney, does not create an attorney–client relationship, and may not reflect the most current legal developments. Consult qualified counsel licensed in your jurisdiction for advice about your specific facts and deadlines.