NIST CSF 2.0 RS.AN-03: Incident Analysis and Root Cause

RS.AN-03 says analysis is performed to establish what has taken place during an incident and the root cause of the incident. After you contain an incident you still owe yourself two answers: what exactly happened, in what order, and why it was possible. Without them the same incident comes back. CSF is voluntary guidance and there is no CSF certification, so you demonstrate this outcome with your own records.

What good looks like

Every meaningful incident gets a written timeline that lists events in order, the assets involved at each step, and the evidence for each claim. The analysis names the vulnerabilities, weaknesses or process failures that were exploited, and, where you can tell, the likely actor. It ends with a root cause that is systemic, not personal. "An engineer clicked a link" is a trigger. "Nothing blocked a credential from working from a new country" is closer to a cause.

How to implement it

• Assign an incident lead who owns the timeline from the first hour.
• Start the timeline in a shared document as soon as you open the incident. Record time, source, observation and who saw it.
• Pull logs early, before retention windows delete them: identity provider, cloud audit logs, endpoint alerts, email and source control.
• Identify which assets and accounts were touched at each step, and which vulnerabilities or misconfigurations let the step succeed.
• If you run deception accounts or files, check them for extra attacker behavior.
• Use a simple root cause method such as repeated why questions. Stop when you reach something you can change: a missing control, a weak default, an unowned process.
• Hold a blameless review within two weeks and turn findings into tracked tasks with owners and dates.

A worked example

A 25 person company finds that a support agent's email account sent phishing messages to customers overnight. The incident lead opens a timeline at 09:10 and writes what is known: sends began at 02:14 from an address in another country.

By noon the log pulls show the sequence. A password reset email was approved on a personal phone at 01:50. The sign in at 02:05 passed because MFA was only enforced for admins. The attacker created a mailbox rule to hide replies, then sent the messages. The assets involved are one mailbox, the identity provider and the customer contact list.

The root cause discussion takes four rounds of why. The account was taken over because MFA was not required for all users. That was true because the rollout was paused for a legacy mail client. The pause had no owner and no end date. The systemic cause is an exception with no expiry. The fixes are to enforce MFA for everyone, retire the client, and require an expiry date on every security exception.

Questions to ask in every review

• What was the first event we can prove, and what was the first we noticed?
• Which control should have stopped each step, and why did it not?
• Which of our assumptions turned out to be false?
• What would shorten the time to detect next time?

Evidence to collect

• The incident timeline with sources.
• A root cause statement and the contributing factors.
• The post incident review notes and attendee list.
• The resulting tasks and proof they were closed.
• Where relevant, the dependency or package history that shows which vulnerable component was involved.

Try it yourself

Click through it at your own pace, or open it full screen.

Common gaps

Timelines are rebuilt from memory days later. Logs expire before anyone collects them. The review stops at the first cause. Findings land in a document and never become tasks. Small incidents are skipped, so patterns across them go unseen.

Quick check

Sources

• NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
• NIST CSF 2.0 Reference Tool and implementation examples: https://csrc.nist.gov/Projects/Cybersecurity-Framework/Filters#/csf/filters