Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
How to perform root cause analysis after a security incident
Updated
After a security incident, run a blameless root-cause analysis: separate the proximate cause from the root cause, list contributing factors, and assign corrective actions with owners. Outputs may feed audit evidence. This page is not legal advice.
Operational guidance, last verified 7 September 2026 against NIST SP 800-61 Revision 2 (Computer Security Incident Handling Guide — guidance, not a statute; post-incident activity includes lessons learned and using the experience to improve), and CISA's Federal Government Cybersecurity Incident and Vulnerability Response Playbooks (operational procedures written for US federal civilian executive branch information systems; CISA notes other organizations may use them to standardize practice). 5 Whys, causal-factor analysis, and fault-tree analysis are practitioner methods, not statutes and not a required depth. This page does not rank DFIR firms, does not start a notification clock, and is not a substitute for counsel, your insurer, or a retained DFIR firm. The incident-timeline page on this site is the UTC template, timezone and clock-skew notes, dwell markers, and evidence-citation discipline. The document-containment-recovery page on this site is the action-log template and recovery-validation checklist. The post-incident-review page on this site is the lessons-learned checklist and corrective-action register. Not legal advice.
Blameless RCA — this is not a statute
Audience: the engineering leader who has to fix the condition that allowed the incident, the commander who holds the timeline, and counsel who may later hand the write-up to an auditor or a regulator. The we've-been-breached page on this site is the first-moves hub. The preserve-evidence page on this site is the capture list the analysis must cite. The first-week page on this site is the handoff into this work. This page is the method: a blameless root-cause analysis that names what failed, which factors contributed, which cause is proximate and which is root, and which corrective actions have an owner. It does not rank DFIR firms, does not name any, and does not start a notification clock.
NIST SP 800-61r2 is a guide to handling computer security incidents — guidance, not a statute. Its last phase is post-incident activity: hold a lessons-learned meeting, write what happened, and use the experience to improve the process, the controls, and the training. CISA's incident-response playbooks treat after-action review as part of handling for FCEB systems — operational procedure, not a law that files a notice for you. A blameless frame is industry best practice in incident review: the write-up names systems, incentives, missing detections, and missing controls, not a person to punish. That is practice, not a statute, and not a finding that nobody made a mistake. Last verified 7 September 2026. Not legal advice.
- Start from the timeline and the images, not from a blame session. The incident-timeline page on this site is the UTC template; keep UTC and cite evidence IDs.
- Name what failed as a system, a control, a detection, or a process. Names of people belong on the attendance list, not in the cause line.
- Separate the proximate cause (the last event that produced the harm) from the root cause (the condition that allowed that event).
- Write corrective actions with an owner, a due date, and how you will know the action worked. 'Be more careful' is not an action.
- RCA outputs may feed audit or regulator evidence. They are not a GDPR Article 33 notice, not a CRA Article 14 filing, and not insurer notice. This page does not start a clock.
- This page does not rank DFIR firms, does not interpret YOUR policy, does not start a notification clock, and is not legal advice.
Proximate cause versus root cause
Mixing the two is how you patch a symptom and keep the next incident. The proximate cause is the last event in the chain that produced the harm you actually saw. The root cause is the condition without which that event would not have been possible — or would have been detected and stopped in time. Contributing factors sit between them: each one made the event easier, slower to see, or harder to contain. Last verified 7 September 2026. Not legal advice.
| Term | Meaning on this page | Kind of source | What this page is not saying |
|---|---|---|---|
| Proximate cause | The last event that produced the harm: the command that ran, the account that signed in, the host that was imaged too late, the restore from a dirty primary. | Practitioner usage in incident RCA. Not a legal proximate-cause test from tort law. Counsel owns legal causation. | Not saying the person who typed the command is the root. Not saying fixing only this event is enough. |
| Root cause | The underlying condition that allowed the proximate event: a missing control, a detection that could not fire, an incentive that rewarded speed over a hold, a design that made local-admin RDP the normal path. | Practitioner usage. 5 Whys / causal-factor / fault-tree are methods for reaching it — methods, not statutes. | Not saying there is only one root. Not saying a named human is the root. Not a legal finding. |
| Contributing factor | A condition that made the event more likely, larger, slower to detect, or harder to contain, but is not by itself the root. Several usually sit on the path. | Practitioner usage (causal-factor analysis). Not a statute. | Not saying a contributing factor is optional to record. Not saying it is blame. |
| Corrective action | A change that removes or reduces a named cause or factor, with an owner, a due date, and a test that it worked. Preventive action is a change that stops a similar event elsewhere. | Practitioner usage. ISO/IEC 27001 Clause 10.2 (nonconformity and corrective action) is a requirement only when that standard applies to you — it is not an RCA method and this page does not apply it. | Not saying an action without an owner is tracked. Not saying this product assigns the owner. |
Methods — 5 Whys, causal factor, fault tree (not statutes)
Pick a method that fits the evidence you have. They are practitioner tools for walking from the proximate event to the condition that allowed it. None of them is a statute, a regulator form, or a required depth. Stop when the next 'why' is speculation you cannot cite. NIST SP 800-61r2 wants the lessons written so the process can improve; it does not name 5 Whys. Last verified 7 September 2026. Not legal advice.
- Cite the timeline row or the evidence ID under every why. Recollection without an ID is labelled recollection.
- If two methods disagree, keep both answers and write why. The disagreement is a fact for the review.
- The post-incident-review page on this site is the lessons-learned checklist. Start the RCA now; the review uses this write-up and does not replace it.
| Method | How you use it here | Limit |
|---|---|---|
| 5 Whys | Ask why the event happened, then why that answer was true, until you name a condition you can change. Write each why as a cited fact from the timeline or the image, not a guess. | A method, not a statute, and not a rule that five is the correct depth. Stopping at 'human error' is stopping too early. Stopping at an invented motive is going too far. |
| Causal-factor analysis | List every condition without which the event would not have occurred as it did (or would have been seen in time). Mark which are proximate, which are contributing, which you will treat as root. | A method, not a statute. A long list is not a finding that everything is equally causal. Owners attach to actions, not to every factor. |
| Fault tree | Draw how conditions combine (AND / OR) to the event you actually saw. Useful when two misses had to coincide (no MFA resistance AND no RDP alert). | A method, not a statute, and not a requirement to use a named tool. A diagram without evidence IDs is a whiteboard, not an RCA. |
RCA template
Copy the fields. Fill them from the timeline and the images, not from a meeting that starts with names. Unknowns belong on the list. This product does not ship a downloadable template file, an RCA wizard, or a blameless-postmortem form; the table is the template. Last verified 7 September 2026. Not legal advice.
| Field | What to write | Owner / due | Limit |
|---|---|---|---|
| What failed | The harm you actually saw, in one clause, tied to evidence (host, identity, data class, window in UTC). | Commander records it. Not a person to punish. | A press sentence is not this field. Do not write 'we were breached' here; write the technical state you can cite. |
| Proximate cause | The last event that produced that harm. Cite the timeline row. | Examiner / commander. | Not legal causation. Not 'human error' as a full sentence. |
| Contributing factors | Each factor as a cited condition (control missing, detection blind, process skipped, incentive). Method used (5 Whys, causal factor, fault tree) goes in the notes. | The person who ran the method, named. | A brainstorm list with no evidence IDs is not this field. |
| Root cause | The condition you will treat so the proximate event cannot recur the same way — or will be detected and stopped in time. More than one is allowed if the evidence supports it. | Engineering leader who accepts the finding. | Not a named human. Not a CVE number you have not evidenced. Not a legal conclusion. |
| Corrective actions | One row per change: what will be different, in which system, how you will know it worked. | Named owner and due date in UTC. A team name is not an owner. | 'Be more careful', 'train everyone', and 'monitor more' are not actions until they name a control, a detection, or a gate. |
| Residual / accepted | What you will not change, and why. If the residual stays, record it as an accepted risk under YOUR process. | The person who may accept risk in YOUR process — not this page, not this product by itself. | Silence is not acceptance. The product's accepted-risk gate is a recorded decision on a risk register row, not an RCA close-out. |
Corrective actions with owners — tracking, not a vibe
An RCA that ends at a finding is a symptom report. Each action needs a named owner, a due date, and a test. Track them until the test passes or a recorded acceptance says the residual stays. NIST SP 800-61r2 uses the lessons to improve the process; CISA after-action work is the same idea for FCEB playbooks. That is guidance and procedure, not a statute that closes YOUR ticket. Last verified 7 September 2026. Not legal advice.
- One owner per action. A group inbox is how the due date passes in silence.
- The test is observable: MFA required on that path, local-admin RDP gone, the alert fired in a drill. 'We feel safer' is not a test.
- Do not close the incident because production is up. Recovery is not RCA. The document-containment-recovery page on this site is the action-log template; keep the action log with the package.
- RCA outputs may feed audit or regulator evidence when counsel says they should. Package the write-up with the timeline and the images. Do not treat the RCA as a notification.
- If you will not fix a named cause, write that as residual and route it through YOUR risk-acceptance process. The product's accepted-risk gate is under Security → Risk register → Accepted; it does not close this RCA.
Worked example (fictional)
Fictional. Not a real incident, not customer data, not a named CVE, not an org on this product. The names, hosts, and times are invented so the fields are visible. Do not treat the actions as a playbook for YOUR estate. Last verified 7 September 2026. Not legal advice.
| Field | What they wrote | Owner / due |
|---|---|---|
| What failed | A stolen IdP session for j.reed@northpine.example reached vpn-gw-01, then RDP as local admin to app-web-03, then a scheduled task. First access 2026-08-12T03:11:22Z; discovery 2026-08-19T14:02:00Z (dwell recorded on the timeline as a practitioner interval, not an SLA). Access is not exfiltration; theft of data is a separate claim and was not concluded here. | Commander (log INC-FIC-0142). |
| Proximate cause | The attacker used a valid IdP session (MFA succeeded) and RDP as local admin to persist via scheduled task on app-web-03. Timeline rows EVD-0142-001 through EVD-0142-004. | Examiner. |
| Contributing factors (5 Whys, cited) | Why persistence? Scheduled-task create after local-admin RDP (EVD-0142-004). Why RDP as local admin? VPN users could RDP to app-web-03 as local admin (config export). Why a valid session? MFA succeeded on a session from an ASN not in the usual set (EVD-0142-001) — phishing-resistant MFA was not required on that path. Why no stop in seven days? No detection for 'unusual RDP then scheduled-task create' until the EDR page on 19 August. Why was that the design? Remote-admin path treated local admin as the normal break-glass, with no compensating alert. | Examiner; method recorded as 5 Whys. |
| Root cause | The remote-admin design allowed a phished or stolen IdP session to become local admin on a production host without a blocking control and without a detection that fired in time. Not 'j.reed made a mistake'. Not a named CVE. | VP Engineering accepted the finding 2026-08-20. |
| Corrective actions | 1. Require phishing-resistant MFA on VPN and on any path that can become local admin. Test: a password-only or push-only sign-in is denied. 2. Remove standing local-admin RDP from VPN users; break-glass through a recorded, time-bound path. Test: a VPN user cannot RDP to app-web-03 as local admin. 3. Alert on unusual RDP then scheduled-task create, paged. Test: the drill fires the page. 4. Residual: older service accounts on app-web-03 stay until the Q4 rebuild — recorded as accepted risk, not as 'done'. | 1. Identity owner, due 2026-09-03Z. 2. Platform owner, due 2026-09-10Z. 3. Detection owner, due 2026-09-03Z. 4. Risk owner via accepted-risk process, review 2026-12-01Z. |
What to do now
Do this once containment is in force and the evidence hold exists. Do not skip it because the site is up. Last verified 7 September 2026. Not legal advice.
- Open a write-up from the UTC timeline and the images. If the timeline is still a Slack thread, make it a table first. The incident-timeline page on this site is the UTC template.
- Fill what failed, proximate cause, contributing factors, root cause, and corrective actions with owners. Use the template above.
- Run one method (5 Whys, causal factor, or fault tree) against cited rows. Stop when the next why is speculation.
- Assign each action a named owner and a due date. Track until the test passes or a recorded acceptance holds the residual.
- Keep the write-up with the evidence package. Counsel decides whether it is handed to an auditor, an insurer, or a regulator. Mapping is not filing.
- Schedule the post-incident review. The post-incident-review page on this site is the checklist; NIST SP 800-61r2 still wants the meeting while the facts are in living memory.
Where this shows up in ShipReady Metrics
The signed-in app does not run an RCA wizard, does not produce a blameless postmortem, and does not assign RCA owners. It does not walk 5 Whys, draw a fault tree, or decide what failed. The cyber risk register lives under Security. An accepted-risk gate lives under Security → Risk register → Accepted — a recorded decision that a residual risk will not be treated now; it is not an RCA close-out. Compliance remediation tasks open from control gaps (signed-in app → Compliance → Remediation) and auto-close when the control is re-evidenced; that queue is not an incident corrective-action register and does not assign RCA owners. Continuous monitoring (signed-in app → Compliance → Continuous monitoring) holds a security-incident register that grades containment clocks and whether a high/critical incident still owes a post-mortem flag — a boolean, not a blameless write-up — and an ISO 27001 Clause 10.2 nonconformity CAPA form (root-cause text plus corrective action on a logged nonconformity). Neither is an incident RCA. If you already have a session: signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness for findings the org has classified as CRA-in-scope. That ladder is not an RCA, it does not start a clock for you, and it is not a determination that CRA applies. A named human still submits.
Primary sources (last verified 7 September 2026)
Every operational claim on this page is taken from one of these. If a later revision of a source changes the advice, the date above is how you can see we have not re-checked yet.
NIST SP 800-61 Revision 2 remains the current final Computer Security Incident Handling Guide (August 2012) this cluster cites for post-incident activity — lessons learned, a write-up of what happened, and using the experience to improve — guidance, not a statute, last verified still final on 7 September 2026. CISA's Federal Government Cybersecurity Incident and Vulnerability Response Playbooks are operational procedures for US FCEB systems; CISA notes other organizations may use them to standardize practice; they include after-action review as part of handling. 5 Whys, causal-factor analysis, and fault-tree analysis are practitioner methods cited generically on this page; they are not statutes, not NIST requirements, and not a required depth. ISO/IEC 27001 Clause 10.2 is named only as a standard clause that applies when that standard applies to you; it is not reproduced here, is not an RCA method, and is not a law. A blameless frame is industry best practice in incident review, not a statute. RCA outputs may feed audit or regulator evidence; this page does not file them.
Frequently asked questions
How do you perform root cause analysis after a security incident?
Run a blameless RCA from the timeline and the images. Write what failed, the proximate cause, contributing factors, the root cause, and corrective actions with a named owner and a due date. Use 5 Whys, causal-factor analysis, or a fault tree as a method, not as a statute. NIST SP 800-61r2's post-incident activity is guidance. Not legal advice.
What is the difference between proximate cause and root cause?
Proximate cause is the last event that produced the harm you saw. Root cause is the underlying condition that allowed that event — a missing control, a blind detection, a design that made the unsafe path normal. Contributing factors sit between them. Fixing only the proximate event leaves the next incident in place. These are practitioner distinctions, not legal causation. Not legal advice.
What is a blameless postmortem in a security incident?
A write-up that names systems, incentives, missing detections, and missing controls rather than a person to punish. Names of people belong on the attendance list, not in the cause line. It is industry best practice in incident review, not a statute and not a finding that nobody made a mistake. This product does not produce a blameless postmortem. Not legal advice.
Does ShipReady Metrics run RCA or assign RCA owners?
No. The signed-in app does not run an RCA wizard, does not produce a blameless postmortem, and does not assign RCA owners. It does have a cyber risk register under Security, an accepted-risk gate under Security → Risk register → Accepted, and compliance remediation tasks that open from control gaps. Those are not an incident RCA. Not legal advice.
Is this legal advice?
No. It is operational guidance distilled from NIST SP 800-61r2 and CISA incident-response playbooks, with 5 Whys, causal-factor analysis, and fault-tree analysis cited as practitioner methods, not statutes. Whether a write-up is admissible, whether privilege attaches, whether a notification duty applies, and which firm to retain are questions for counsel on YOUR facts. This page does not rank DFIR firms and does not start a notification clock.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.