6.4 Post-Incident Activity & Compliance Reporting
Key Takeaways
- NIST recommends holding the lessons-learned meeting within several days of the incident closing, while recollection is accurate, and answering a fixed set of questions about what happened and what should change.
- Incident metrics — MTTD, MTTC, MTTR, and dwell time — turn post-incident review into measurable improvement rather than opinion.
- NIST bases evidence retention decisions on three factors: whether prosecution is likely, the organization's data retention policy, and the cost of storage.
- GDPR requires notifying the supervisory authority within 72 hours of becoming aware of a personal data breach; HIPAA requires individual notice within 60 days, with breaches of 500 or more records also requiring HHS and media notification.
- FERPA imposes no federal breach-notification deadline, while FISMA requires federal civilian agencies to report incidents to CISA within one hour and major incidents to Congress within seven days.
Post-Incident Activity & Compliance Reporting
Quick Summary: Post-Incident Activity is Phase 4 of the NIST SP 800-61 Rev. 2 lifecycle, and it is the phase organisations most often skip. Its purpose is to convert an expensive incident into durable improvement: hold a structured lessons-learned meeting while memories are fresh, establish root cause rather than blame, measure performance with incident metrics, decide how long evidence must be retained, and feed every finding back into Preparation. Running in parallel is a set of legal obligations — GDPR, HIPAA, PCI DSS, FERPA, and FISMA each impose their own reporting and notification requirements, and those clocks usually start well before the technical response is finished.
Continuity planning is covered in Section 5.4. Business continuity and disaster recovery — BIA metrics, backup strategies, alternate sites, and DR testing — map to blueprint sub-topic 4.4 and are taught in full there. This section covers blueprint sub-topics 5.3 (compliance frameworks' impact on incident handling) and the Phase 4 portion of 5.4 (elements of incident response).
1. The Lessons Learned Meeting
NIST SP 800-61 Rev. 2 recommends holding a lessons-learned meeting within several days of the end of the incident. The timing is deliberate: wait weeks and the detail that makes the review valuable — who saw what, at what time, and why they made the call they made — has already decayed.
Who attends
Everyone who was materially involved, not just the technical responders: the incident handler and the CSIRT, the affected system and business owners, help desk staff who took the first calls, and — for a significant incident — legal, communications or public relations, human resources if an insider was involved, and executive leadership.
The questions NIST expects the meeting to answer
NIST lists these explicitly, and they make an excellent agenda:
- Exactly what happened, and at what times?
- How well did staff and management perform in dealing with the incident? Were the documented procedures followed, and were they adequate?
- What information was needed sooner?
- Were any steps or actions taken that might have inhibited the recovery?
- What would staff and management do differently the next time a similar incident occurs?
- How could information sharing with other organisations have been improved?
- What corrective actions can prevent similar incidents in the future?
- What precursors or indicators should be watched for in future to detect similar incidents earlier?
- What additional tools or resources are needed to detect, analyse, and mitigate future incidents?
The tone that makes it work
A lessons-learned meeting is blameless. The moment it becomes a search for someone to hold responsible, people stop volunteering the information that makes the review useful — and the next incident gets reported later, or not at all. Focus on systems and processes: "the alert fired at 01:12 but nobody was on call until 08:00" is a finding; "Sam missed it" is not.
The output
The meeting produces a follow-up report and a set of tracked action items, each with a named owner and a completion date. Action items without owners and dates do not get done, and the same incident recurs. Typical outputs include updated playbooks and runbooks, new or tuned detection rules, revised escalation paths and on-call coverage, additional training, budget requests for tooling gaps, and amendments to the incident response policy itself.
2. Root Cause Analysis
Establishing what actually allowed the incident is what separates a fix from a patch over the symptom.
- The 5 Whys. Ask "why" repeatedly until you reach a systemic cause. The server was encrypted by ransomware. Why? An attacker had domain admin. Why? A service account password was reused. Why? There was no password policy for service accounts. Why? Service accounts were exempted from the policy when they were created in 2019. Why? Nobody owned the exemption review. The fix is at the bottom, not the top.
- Ishikawa (fishbone) diagram. Groups candidate causes into categories — people, process, technology, environment — which is useful when the cause is genuinely multi-factor.
- Timeline reconstruction. Build a single authoritative timeline from log sources, ticket records, and responder notes. Gaps in the timeline are themselves findings: they mark where you had no visibility.
Distinguish the root cause (no exemption review for service accounts) from the initial access vector (a phishing email) and from the impact (encrypted file server). Remediating only the vector leaves the systemic weakness intact.
3. Incident Metrics: Using Collected Incident Data
NIST devotes a subsection to using collected incident data, because metrics are what make the improvement claim testable. The core measures:
| Metric | What it measures | Why it matters |
|---|---|---|
| MTTD — Mean Time to Detect | Compromise until the organisation notices | The metric that most directly correlates with damage. Reducing it is usually the highest-value investment. |
| MTTA — Mean Time to Acknowledge | Alert raised until a human picks it up | Exposes on-call and staffing gaps rather than tooling gaps |
| MTTC — Mean Time to Contain | Detection until spread is stopped | Measures how quickly containment actions can actually be executed |
| MTTR — Mean Time to Recover | Detection (or containment) until normal service resumes | The business-facing number leadership cares about. Define which endpoint you mean and use it consistently. |
| Dwell time | Initial compromise until eradication | The attacker's total window inside the environment |
| Incident volume and category mix | How many incidents, of what type | Shows whether preventive controls are working; a rising phishing count justifies training investment |
| False positive rate | Proportion of alerts that were not incidents | High rates cause alert fatigue, which is itself a security failure |
Caution on metrics. Measure them to improve the programme, never to rank individuals. The moment MTTR becomes a personal performance target, incidents get closed early rather than resolved — and the metric improves while security gets worse.
4. Evidence Retention
NIST identifies three factors that determine how long incident evidence should be kept:
- Prosecution. If legal action against the attacker is possible, evidence must be retained until all proceedings conclude — which can be years. Chain of custody (Section 6.3) must hold for the whole period.
- Data retention policy. The organisation's general retention policy, plus any regulatory retention requirement, sets a floor and sometimes a ceiling. Some regulations require retention for a fixed term; privacy law may require deletion once the purpose has passed.
- Cost. Full disk images of many systems consume real storage. This is a legitimate factor, but it is the one to weigh last.
Retention decisions should be made during the incident, not afterwards — by the time someone asks whether the images were kept, they have often already been deleted. A defensible default is to preserve forensic images and relevant logs for a defined period set by legal counsel, and to document the decision.
5. How Compliance Frameworks Shape Incident Handling
Blueprint sub-topic 5.3 asks for the impact of compliance frameworks on incident handling. The key insight is that regulatory clocks run independently of your technical response. An organisation can still be inside the containment phase and simultaneously past a notification deadline. That is why the incident response plan must name who determines whether a regulatory trigger has been met, and who is authorised to notify.
| Framework | Scope | Reporting / notification requirement |
|---|---|---|
| GDPR (EU General Data Protection Regulation) | Personal data of individuals in the EU/EEA, regardless of where the processor is | Notify the supervisory authority within 72 hours of becoming aware of a personal data breach. Where the breach poses a high risk to individuals' rights and freedoms, notify affected individuals without undue delay. If the 72 hours cannot be met, the notification must explain the delay. |
| HIPAA (US health information) | Protected Health Information held by covered entities and business associates | Notify affected individuals without unreasonable delay and no later than 60 calendar days from discovery. Breaches affecting 500 or more individuals additionally require notice to HHS and to prominent media in the affected state within the same 60 days. Smaller breaches are reported to HHS in an annual log. Business associates must notify the covered entity. |
| PCI DSS (payment card data) | Merchants and service providers handling cardholder data | Contractual rather than statutory. Notify the acquiring bank and the affected payment brands immediately on suspicion of a compromise. A significant breach typically triggers a mandated forensic investigation by a PCI Forensic Investigator (PFI), plus card reissuance, fines, and potential loss of the ability to process cards. |
| FERPA (US student education records) | Educational institutions receiving federal funding | No federal breach-notification deadline. FERPA governs disclosure of education records and requires a record of disclosures, and institutions must report unauthorised disclosures to the Department of Education, but the specific notification timeline most institutions follow comes from state breach-notification law rather than FERPA itself. |
| FISMA (US federal information systems) | Federal civilian executive branch agencies and their contractors | Report incidents to CISA within one hour of identification by the agency's SOC, CSIRT, or IT department. Major incidents must be reported to Congress within seven days of the agency having a reasonable basis to conclude one occurred, with a supplemental report following. |
Related obligations worth recognising
- CIRCIA (Cyber Incident Reporting for Critical Infrastructure Act, 2022) will require covered critical-infrastructure entities to report covered incidents to CISA within 72 hours, and any ransom payment within 24 hours, once the final rule takes effect.
- US state breach-notification laws apply in all fifty states with differing thresholds and deadlines, and they apply on top of any sector regulation.
- Contractual and cyber-insurance clauses frequently impose the tightest deadline of all — some policies require notice to the insurer within 24 or 48 hours, and late notice can void coverage.
What this means operationally
- Identify the trigger early. The response team must know, during Detection & Analysis, what categories of data are in scope, because that determines which clocks have started.
- Notification is not the technician's decision. Escalate to legal, privacy, and executive leadership. Premature or inaccurate public disclosure creates its own liability.
- Document as you go. Regulators ask what you knew and when. Contemporaneous notes and an accurate timeline are the evidence that the deadline was met.
- Never delay notification to finish remediation. Regulatory deadlines run from awareness, not from resolution.
- Preserve evidence before cleaning. Rebuilding a host is the fastest route back to service and also destroys the evidence a regulator or investigator may require.
6. Closing the Loop Back to Preparation
The NIST lifecycle is a cycle, not a line. Everything produced in Phase 4 becomes an input to Phase 1:
- Updated playbooks and runbooks reflecting what actually worked.
- New detection rules built from the precursors and indicators identified in the review.
- Revised escalation paths, on-call rotas, and contact lists.
- Targeted training for the specific gap the incident exposed.
- Tooling or visibility investments justified by a documented blind spot.
- Amendments to the incident response policy, plan, and procedures themselves.
An incident response capability that never changes after an incident is not a capability; it is a document. The measurable sign that Phase 4 is working is that MTTD and MTTR fall over successive incidents and that the same root cause does not appear twice.
A ransomware incident affecting EU customer records is contained on day two, but full recovery will take another week. Under GDPR, when does the 72-hour notification clock start?
A US hospital discovers a breach exposing the protected health information of 1,200 patients. Which notification obligations does HIPAA impose?
NIST SP 800-61 Rev. 2 identifies three factors that determine how long incident evidence should be retained. What are they?
Why does NIST recommend holding the lessons-learned meeting within several days of an incident closing, rather than several weeks later?
A federal civilian agency's SOC identifies a confirmed information security incident on one of its systems. Under FISMA and CISA guidance, what is the initial reporting requirement?