RS.AN-03: Analysis is performed to establish what has taken place during an incident and the root cause of the incident

The rs.an-03: analysis is performed to establish what has taken place during an incident and the root cause of the incident requirement is easy to “say yes to” and surprisingly hard to prove under pressure. Most programs have an incident response plan, a ticketing system, and some post-incident notes. Examiners and customers look for something tighter: a repeatable method that (1) establishes factual sequence of events, (2) preserves and analyzes evidence, (3) states root cause in a way that’s testable, and (4) drives corrective action that prevents recurrence.

RS.AN-03 sits in the Respond function’s Analysis category in NIST CSF 2.0. It does not demand a specific tool or a particular methodology, but it does demand outcomes you can demonstrate. If you can’t show how you got from logs and artifacts to “this is what happened and why,” you will struggle to defend containment choices, reporting accuracy, and whether fixes were adequate.

This page gives requirement-level, operator-ready guidance: who owns what, the step-by-step flow to run on every incident, the evidence pack to retain, and the audit questions that commonly derail teams. Citations refer to NIST CSF 2.0 source materials (NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes).

Requirement: RS.AN-03 (what you must be able to prove)

RS.AN-03 expects documented analysis that establishes (a) what occurred during the incident and (b) the incident’s root cause (NIST CSWP 29). “Analysis” here means more than detection and containment. You need a structured investigation that produces an evidence-backed narrative and a root-cause conclusion that drives specific remediation.

Plain-English interpretation

You meet RS.AN-03 when, for each incident that meets your internal criteria, you can answer and evidence:

• What happened? A verified timeline of events with supporting logs/artifacts.
• How did it happen? The attack path or failure sequence (initial access → execution → persistence → impact) or operational breakdown sequence.
• Why did it happen? Root cause stated at the right level (control failure, configuration error, process gap, third-party issue, or human factors) and backed by facts.
• What changed because of it? Corrective actions, tracked to completion, with validation.

Root cause should be “testable.” A good root cause statement allows a reviewer to ask: “If you fix that, does the incident become unlikely to recur in the same way?”

Who it applies to

RS.AN-03 applies to organizations operating a cybersecurity program, especially those with:

• A formal incident response capability (internal or outsourced).
• Regulatory, contractual, or customer expectations for post-incident reporting.
• Material reliance on third parties (cloud, managed security providers, SaaS, payment processors) where evidence and accountability can fragment across organizations.

Operationally, it applies to:

• Security operations / IR teams performing triage, forensics, and containment.
• IT / cloud / engineering teams who implement fixes and provide system context.
• GRC and Compliance teams who set minimum analysis requirements, ensure retention, and verify closure.
• Third-party owners when incidents involve external service providers or supply chain events.

Regulatory text

“Analysis is performed to establish what has taken place during an incident and the root cause of the incident” (NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes).

Operator interpretation: you need a defined incident analysis procedure that forces consistent outputs: evidence captured, timeline built, scope and impact determined, root cause identified, and remediation verified. If analysis occurs ad hoc or only for “big” incidents without defined criteria, you will have a control operation gap.

What you actually need to do (step-by-step)

Use the steps below as your minimum operating procedure. Make them a checklist inside your IR platform (ticketing, SOAR, or GRC workflow).

1) Set the trigger: which events require RS.AN-03 analysis

Define “incident” thresholds for analysis packages, such as:

• Confirmed unauthorized access.
• Malware execution in production.
• Data exposure or exfiltration suspicion.
• Material outage caused by cyber event.
• Third-party compromise affecting your environment.

Write the trigger criteria into your IR procedure and make the incident commander responsible for opening an “analysis package” task.

2) Preserve evidence and lock the record early

Before systems change:

• Capture volatile indicators (running processes, active connections) when feasible.
• Collect key logs (identity, endpoint, network, cloud control plane, application).
• Preserve relevant tickets, alerts, and chat transcripts.
• Start a decision log: who approved containment steps, what was known at the time, and why the decision was made.

If a third party is involved, immediately request:

• Their incident reference number.
• Their timeline as known.
• Relevant logs or attestations of findings (as permitted).
• Their root-cause statement and remediation plan.

3) Build the “facts timeline” (what happened)

Create a timeline that is explicitly evidence-backed:

• Timestamp (with timezone)
• Event description
• Source artifact (log, alert ID, EDR case, cloud trail entry, email header, etc.)
• Confidence level (confirmed vs inferred)

Aim for a single timeline that reconciles IR actions and attacker/system actions. Auditors regularly find multiple conflicting timelines across security notes, tickets, and stakeholder emails.

4) Determine scope and impact (what was affected)

Document:

• Affected assets (systems, identities, applications, data stores).
• Lateral movement indicators (if any).
• Data exposure assessment approach (what logs/telemetry you used, what gaps existed).
• Operational impact (downtime, degraded service, safety implications where relevant).

Do not overreach beyond evidence. If telemetry gaps exist, record them and treat them as findings with follow-up actions.

5) Identify root cause using a defined method

Pick a method and standardize it:

• 5 Whys for process/control failures.
• Fishbone (Ishikawa) for multi-factor operational contributors.
• Kill chain / ATT&CK-style mapping for attacker sequence (useful for “how”), paired with a control failure analysis for “why.”

A root cause statement should include:

• Primary root cause (the most direct enabling failure).
• Contributing factors (secondary issues that amplified impact).
• Control mapping (which control failed or was missing, at least at your internal control catalog level).

Example (good):

• “Initial access occurred via a legacy VPN account without phishing-resistant MFA; the account remained active after role change due to an access review gap. Contributing factors: insufficient alerting on impossible travel and incomplete VPN logging retention.”

Example (weak):

• “User clicked a phishing email.” (This is a trigger, not a root cause.)

6) Define corrective actions and prove closure

For each root cause/contributor:

• Assign a control owner.
• Define the corrective action (configuration change, policy change, monitoring improvement, training, third-party contract change).
• Set acceptance criteria (how you will verify the fix worked).
• Track to closure with evidence (screenshots, config diffs, change tickets, test results).

7) Run a lessons-learned review and feed governance

Hold a structured review with Security, IT, and GRC:

• Confirm final timeline and root cause wording.
• Validate reporting obligations were met (legal/regulatory notifications are out of scope for NIST CSF text but often operationally tied).
• Capture program-level improvements (logging strategy, detection rules, third-party requirements).

If you use Daydream for control mapping and evidence collection, tie RS.AN-03 to a control owner, a required “incident analysis package” template, and recurring evidence checks so audits don’t depend on searching old tickets.

Required evidence and artifacts to retain

Maintain an “incident analysis package” with consistent naming and storage controls:

Core artifacts (minimum)

• Incident record (ticket/case) with severity and classification
• Evidence inventory (what was collected, where stored, hash/chain-of-custody where applicable)
• Unified timeline with references to supporting artifacts
• Scope and impact assessment memo
• Root cause analysis write-up (primary + contributing factors)
• Decision log (containment/eradication choices and approvals)
• Remediation plan with owners and closure evidence
• Lessons-learned meeting notes and action items

Supporting artifacts (as applicable)

• Forensic images or snapshots
• Relevant system/app/cloud logs exports
• Communications archive (customer notices drafts, internal stakeholder updates)
• Third-party correspondence and their post-incident report/executive summary

Retention duration depends on your legal/regulatory context; set a policy aligned to your broader security logging and incident records requirements.

Common exam/audit questions and hangups

Expect reviewers to probe these areas:

1. “Show me the timeline and the evidence behind it.”
   Hangup: timeline exists but is not traceable to artifacts.

2. “How did you determine root cause vs contributing factor?”
   Hangup: root cause is stated as human error without control/process analysis.

3. “How do you know remediation worked?”
   Hangup: remediation ticket closed with no verification artifact.

4. “Which incidents get this level of analysis?”
   Hangup: unclear criteria; analysis only done for high-profile events.

5. “What about third-party incidents?”
   Hangup: no structured process to obtain third-party evidence, timelines, and remediation status.

Frequent implementation mistakes (and fixes)

Mistake	Why it fails RS.AN-03	How to avoid it
Root cause written as a narrative with no testable statement	Hard to validate or remediate	Force a “root cause in one sentence” field plus contributing factors
Evidence scattered across chat, email, and multiple tickets	Can’t reconstruct what happened	Require a single analysis package with links and exports
Timeline built after remediation	Facts get overwritten	Add an early “preserve evidence” gate before major changes
No link between root cause and control remediation	Lessons learned don’t change risk	Map each cause to a corrective action and an owner
Third-party “we’re investigating” accepted as closure	No accountability	Require a third-party post-incident summary and remediation commitments

Enforcement context and risk implications

No public enforcement case sources were provided in the cited source catalog for this requirement, so this page does not list specific cases. Practically, weak incident analysis increases regulatory reporting risk, customer dispute risk, and repeat-incident risk because teams cannot demonstrate what happened or prove fixes were effective. Treat RS.AN-03 as both a technical investigation requirement and a governance documentation requirement (NIST CSWP 29).

Practical 30/60/90-day execution plan

Use this as an execution sequence. Adjust to your environment and incident volume.

First 30 days: standardize outputs

• Assign an RS.AN-03 control owner (usually Head of IR/SOC with GRC oversight).
• Publish an incident analysis package template (timeline, evidence inventory, root cause, corrective actions).
• Define the incident threshold criteria that triggers full analysis.
• Validate log sources needed for timelines (identity, endpoint, network, cloud, email) and document known gaps.

Days 31–60: make it repeatable

• Embed the template into your case management workflow (required fields, mandatory attachments/links).
• Train incident commanders and responders on root cause quality standards.
• Add a remediation verification step (closure requires evidence).
• Create a third-party incident intake checklist (what you will request, who requests it, where it is stored).

Days 61–90: prove operating effectiveness

• Run a tabletop or retrospective against a past incident using the new template and identify gaps.
• Perform an internal audit-style review of a sample of incidents to confirm the package is complete.
• Report recurring root causes and systemic contributors to the risk committee (or equivalent) and track program improvements.
• If using Daydream, map RS.AN-03 to policy, procedure, control owner, and recurring evidence collection so audits pull from a consistent record set.

Frequently Asked Questions

Do we have to perform full root cause analysis for every security alert?

No. RS.AN-03 is about incidents, so define criteria that promote events into “incident” status and require the full analysis package for those cases (NIST CSWP 29).

What counts as an acceptable “root cause”?

A root cause is a specific, evidence-backed failure that, if corrected, would materially reduce the chance of recurrence in the same way. “User clicked a link” rarely qualifies without tying it to control gaps such as MFA, filtering, segmentation, or access governance.

How do we handle incidents where evidence is incomplete?

Document the evidence you have, the specific telemetry gaps, and how those gaps affect confidence in conclusions. Then open corrective actions to close logging/visibility gaps so future incidents are more analyzable.

What if a third party won’t share logs or a detailed report?

Record what you requested, what you received, and what conclusions you can and cannot support. Treat the limitation as a third-party risk issue and address it through contract terms, security addenda, or provider selection criteria.

Can a managed security provider (MSSP/MDR) “own” RS.AN-03 for us?

They can perform analysis tasks, but you still need governance: defined requirements, access to artifacts, and proof of remediation closure inside your program. Auditors will hold your organization accountable for outcomes and recordkeeping.

How should we store incident analysis artifacts for audit readiness?

Store them in a controlled repository with consistent naming, access controls, and retention rules. Ensure the incident record links to all supporting artifacts so a reviewer can reconstruct the timeline without chasing evidence across tools.