What RS.AN-03 root cause analysis requires in NIST CSF 2.0
RS.AN-03 asks the organization to establish what happened during an incident and why it happened. It is a Subcategory of the Incident Analysis (RS.AN) Category in the RESPOND Function of NIST CSF 2.0, and it continues CSF 1.1 RS.AN-3 at the same identifier, so teams that already tracked that outcome keep the same reference. In plain terms, the outcome has five parts: a reconstructed sequence of events, the assets involved, the vulnerabilities and threats exploited, the threat actors where they can be identified, and the systemic conditions that allowed the incident. The Core states the outcome briefly. NIST's Implementation Examples for RS.AN-03 describe the work behind it, including checking deception technology for attacker behavior, and the wording is worth reading in the CSWP 29 PDF before you write a procedure.
The difficulty is that most post-incident reviews stop at the trigger. A phishing click, a misconfigured storage bucket or a stolen credential gets named, the containment is recorded as complete, and the ticket closes. That answers what started the incident but not why a single failure could cause it, which is the question an assessor will ask. Closing the gap usually means connecting the timeline to asset records, vulnerability data, threat intelligence and the change history, and then asking whether the same condition exists elsewhere. Those sources sit with different teams, so the analysis is often the first time they are combined.
For a security lead or auditor, the practical test is whether a sample of closed incidents contains a written causal chain with evidence behind each link, and whether recurring root causes trigger changes to controls or the risk register. Confirm with your assessor how they want that evidence presented, since CSF 2.0 does not prescribe a format. Also confirm which of your incident tickets and analysis notes are retained long enough to support a review, and who in the organization owns the final root cause statement, because the Govern Function expects that accountability to be defined.
Which incidents, systems and teams RS.AN-03 covers
Root cause analysis under RS.AN-03 only works when the organization decides in advance which incidents get a full examination, which systems feed the evidence and who must take part. The cards below set out those decisions, the assets that usually hold the answers and the teams whose input the analysis depends on.
Incident classes that need full analysis
Set a written threshold for which incidents receive a full root cause analysis: confirmed compromise of sensitive data, persistence in identity systems, ransomware, and any incident that triggered external notification. Lower-impact events, such as a blocked phishing attempt with no clicks, can receive a lighter review that records the trigger and the containing action. The threshold belongs in the incident response plan, so that the decision is made before a busy shift tempts the team to skip it. Ask your auditor how the threshold was set and who approved it.
Endpoints and host telemetry
Endpoints usually hold the process, network and file history that reconstructs how an attacker moved. Confirm that process execution, network connections and file hashes are retained long enough to cover the dwell time of the incidents you expect to investigate. Open-source query tools such as osquery can answer questions across many hosts at once, which helps when an incident spans a fleet. Verify retention on each host group rather than assuming the central collector holds everything.
Cloud accounts and identity systems
Many modern intrusions begin with a stolen credential or a changed permission, so the analysis must cover the identity provider, directory and cloud control plane logs, not only servers. Confirm that sign-in events, role assignments and administrative changes are logged, centrally stored and time-synchronized with endpoint data. Without a shared clock, the sequence of events in the timeline cannot be trusted. Check which accounts are excluded from logging, such as break-glass or service accounts, because those are common attacker targets.
SaaS and self-hosted application audit logs
Business applications record actions that endpoints never see, including data exports, sharing changes and configuration edits. For a self-hosted platform, for example Nextcloud, confirm that the audit application is enabled and writes to a log location that is protected from routine changes. Decide which application events feed the root cause timeline and who can read them. Ask each SaaS vendor which audit events are available, how long they are kept and whether they can be exported for independent review.
Third-party hosted components
When a supplier hosts part of the service, the root cause may sit outside your own infrastructure. Agree in advance what incident data the supplier will provide, within what timeframe and in what format, and record those terms in the contract or service description. Identify which systems you can see directly and which you can only see through the supplier's reports. Gaps here are common in root cause findings, so the analysis should state explicitly where evidence was unavailable.
Teams that contribute to the analysis
The SOC reconstructs the timeline, IT operations supplies configuration and change history, and application owners explain what the affected system was designed to do and where it deviated. Legal advises on which evidence may be shared and what privilege applies, while leadership approves the scope and the conclusions. Assign one incident lead who owns the final write-up so that the root cause statement reflects input from each group. Name these roles in the plan before an incident occurs.
How an assessor tests root cause analysis
An assessor starts with the raw record. They select a sample of incidents from the incident register and ask for the tickets, case notes, alert history and timeline that describe what happened. The question is whether the sequence of events can be rebuilt from evidence that existed at the time, not from memory written afterward. Strong records show when an alert fired, who triaged it, which assets were touched and when containment began, with timestamps that agree across tools.
- Sample selection: Assessors usually pick incidents of different severities and types, not only the largest ones, and ask for every record in that set.
- Timeline completeness: Look for gaps between detection, triage, escalation and containment. A timeline that jumps from alert to closure without explaining the middle is a common finding.
- Time synchronization: Timestamps from the SIEM, endpoints and ticketing system should be reconcilable. Ask how clocks are kept in sync before accepting any ordering of events.
- Asset list: The record should name the systems, accounts and data involved, linked to the asset inventory where one exists.
- Unsupported timeline: A timeline with no source references, or one that conflicts with the logs, tells the assessor the reconstruction was not built from evidence.
Confirm with your team which log sources are retained, for how long and where, because an assessor can only test a sequence the logs still show.
The second area tests how the organization moved from events to cause. The assessor is not looking for one correct answer. They look for a method that considers the vulnerabilities exploited, the threats and threat actors involved, and the conditions in the environment that allowed the incident, then checks whether the stated root cause follows from that work. The organization owns the conclusion. The assessor tests whether the process produced it and whether the reasoning is visible.
- Stated method: A written procedure should describe how analysts identify contributing factors, such as the "five whys" approach or a fault tree, and when systemic causes are examined beyond the immediate trigger.
- Vulnerability and threat linkage: The record should connect the initial access path to a specific weakness, such as an unpatched service or a missing control, and identify the actor or threat type where known.
- Deception and monitoring evidence: Where honeypots, canary tokens or similar tools were in place, assessors check whether their data was reviewed and used in the analysis.
- Competing explanations: Good analyses record alternatives considered and why they were rejected.
- Unsupported root cause: A conclusion such as "user error" or "unknown" with no supporting evidence, or a root cause that does not account for the timeline, is a frequent finding.
Ask for the analysis template and two completed examples to see whether the method is applied consistently.
The third area tests whether the analysis led to change. An assessor traces each identified root cause to the corrective actions recorded for it and then checks whether those actions were completed and verified. A root cause with no action, or an action with no owner or due date, shows that the analysis did not feed the improvement cycle. This area ties RS.AN-03 to the wider Improvement and Incident Management work in the framework.
- Action linkage: Each root cause should map to one or more tracked actions, such as a configuration change, a new detection rule, a training update or a policy revision.
- Ownership and closure: Actions need an accountable owner, a target date and evidence of completion, reviewed by someone other than the owner where practical.
- Verification: Assessors look for proof that the fix worked, such as a retest, a tabletop exercise or a monitoring check.
- Trend review: Repeated root causes across incidents suggest that actions were closed without addressing the systemic issue.
- Missing follow-through: Root causes recorded in a report that never appear in the change or risk register are a clear gap.
Before an assessment, confirm which system holds the action tracker and whether closed items retain their evidence.
Implementing root cause analysis step by step
This sequence turns an incident into a documented account of what happened, which assets and weaknesses were involved, who or what acted against them, and why the conditions existed, so that the findings can change the organization's controls.
Define the analysis procedure and triggers
The incident lead, with security operations and the owners of the affected systems, writes a short procedure that states when a root cause analysis starts, who leads it, who must be consulted and what the final record must contain. Triggers usually include any incident declared under the organization's response plan and any incident with material impact on customers, regulated data or availability. The step is complete when the procedure is approved, stored with the incident response plan and linked from the case record, so that every analysis follows the same questions.
Reconstruct the sequence of events from logs
Analysts build a timeline of the incident from preserved logs, alerts, endpoint telemetry and network records, placing each event in order and noting gaps where logs were absent or retention had expired. A case management tool such as DFIR-IRIS can consolidate alerts and evidence into one investigation timeline, while osquery or Velociraptor can supply host-level artifacts. The output is a timeline with source references for every entry and a list of unexplained gaps that the analysis must address.
Map affected assets and vulnerabilities
Using the asset inventory and the timeline, the team lists every system, account, data store and service the attacker touched or could have reached, then records the weaknesses that enabled each step, such as unpatched software, misconfiguration, excessive permissions or missing segmentation. Asset owners confirm the list, because inventories are often incomplete. The output is an asset and vulnerability map linked to timeline entries, with each vulnerability tied to an identifier in the organization's vulnerability records.
Identify threats and threat actors
The team determines the attack techniques used, the indicators of compromise and, where the evidence supports it, the threat actor or activity group behind the intrusion. Threat intelligence feeds and the organization's own prior cases help distinguish opportunistic activity from targeted activity. Where attribution cannot be confirmed, the record should say so and state the confidence level. The output is a threat summary that lists techniques, indicators and any attribution with its basis.
Record systemic root causes
The analysis moves from the immediate cause to the conditions that allowed it, such as gaps in change control, unclear ownership of a system, training shortfalls or a monitoring blind spot. Teams usually test each proposed cause against the timeline by asking whether removing it would have stopped or shortened the incident. The output is a root cause statement, supported by evidence and reviewed by someone outside the response team, that separates the trigger from the underlying systemic causes.
Check deception technology for attacker behavior
Where honeypots, decoy accounts or canary tokens are deployed, analysts review their logs for attacker interaction, which can confirm the scope of the intrusion or reveal reconnaissance that other sensors missed. If the organization has no deception technology, the record should note that no such evidence was available. The output is a short statement of what decoy interactions showed, or why this source contributed nothing, attached to the root cause record.
Feed findings into improvement records
Each systemic cause is converted into a tracked corrective action with an owner, and the root cause record is linked to the organization's improvement and lessons-learned process, along with any changes to the incident response plan or detection rules. Legal and regulatory notifications that depend on the findings are checked against the record before it is closed. The output is a closed analysis record that lists each corrective action, its owner and its status, so that auditors can trace a finding to a change.
Evidence that satisfies RS.AN-03
RS.AN-03 asks whether your analysis establishes what happened and why. An assessor will test that claim by reading the records the analysis produced, so the evidence below should link together: one timeline, the assets and weaknesses it touched, a written reasoning trail, and corrective actions that someone owns. Keeping these current between audits matters as much as producing them once.
Reconstructed incident timeline
A single, time-ordered account of the incident, built from alerts, host and network logs, and responder notes. It should show when each event occurred, which system recorded it, and where the clock sources differ. The Implementation Examples for RS.AN-03 call for reconstructing the sequence of events, so the timeline is the first artifact an assessor will read. Check that every entry cites a source record and that gaps in the timeline are stated rather than filled by assumption. Each entry needs a source record. DFIR-IRIS can hold a consolidated investigation timeline inside the case record, which keeps the timeline tied to its evidence.
Affected asset and scope list
A list of every system, account and data store the incident touched, with owner, role and the evidence that ties each one to the event. This list answers the RS.AN-03 question of which assets were involved. Confirm that it comes from your asset inventory rather than memory, and record assets that were examined and cleared as well as those that were compromised. Fleet queries across endpoints can show process, network and file state on many hosts at once, which helps build a list that is complete rather than anecdotal.
Vulnerability and threat actor records
Records of the vulnerabilities, misconfigurations and threats that enabled the incident, including the threat actor or actor profile where it could be identified. The Implementation Examples for RS.AN-03 cover identifying these items, so each one should link to a finding in your vulnerability management or risk register. Note where attribution is uncertain. An assessor will look for a clear distinction between confirmed facts and working hypotheses, and for a reason each vulnerability was or was not the cause.
Written root cause analysis
The narrative that states the root cause, the contributing factors and the reasoning that links the evidence to the conclusion. It should address systemic causes, such as a patching process, a change approval gap or a training gap, and not stop at the technical trigger. Ask whether a reviewer who was not on the response team could follow the logic from evidence to conclusion. Record who approved the analysis and when, so the document can be dated and traced during an audit.
Deception technology observations
Logs, alerts and analyst notes from honeypots, decoy accounts or canary files, where your environment deploys them. The RS.AN-03 Implementation Examples include checking deception technology for attacker behavior, so these records can show what an attacker tried, in what order and against which decoys. Where no deception technology is deployed, the expected evidence is a documented decision explaining why it is absent, and how other sources covered that gap. Confirm that decoy logs are retained and access-controlled like other incident data.
Corrective actions with named owners
A register of the fixes and process changes that follow from the root cause, each with an owner, a due date and a status. Link each action to the contributing factor it addresses, so an assessor can see that the analysis drove a change. Track actions to closure and retain the proof, such as a change record or a updated runbook. Review open items at a regular cadence. An overdue action with no owner is the most common gap an assessor will raise against this subcategory.
What root cause analysis costs to meet
The table lists each cost component of meeting RS.AN-03, who is paid for it, whether it is one-time or recurring, and what drives it up. Read it as a checklist for a quote: most of the spend is recurring analyst time and log retention, and license spend can be reduced where open-source tools replace commercial ones. No figures are given because none were supplied for this subcategory.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives the cost |
|---|---|---|---|
| Analyst time per incident | Internal incident responders or the external incident response firm | Recurring, per incident | Number and complexity of incidents, depth of the sequence-of-events reconstruction, and how many systems are involved |
| Log retention and SIEM storage | Internal platform team, or the storage and SIEM vendor if commercial | Recurring, usually monthly or annual | Log volume, retention period set by policy and regulation, and how much data must be searchable for root cause work |
| Forensic tooling licenses | Software vendor if commercial; none for open-source tools under their own licenses | Recurring if commercial, one-time for deployment | Number of endpoints, users and cases; open-source options such as osquery, Velociraptor and DFIR-IRIS can remove most license spend but still need hosting and staff |
| Self-hosted hosting and administration | Internal infrastructure team or implementation partner for setup | One-time setup, recurring operation | Whether tools run in existing infrastructure, backup and upgrade effort, and access controls on the evidence store |
| Deception technology, if used | Vendor license or internal build effort | Recurring if licensed, one-time if built | Number of decoys, integration with detection tools, and whether root cause findings from decoy activity are reviewed |
| External forensic support | Independent forensic firm, billed per engagement or retainer | Recurring only when incidents occur or a retainer is held | Incident severity, scope of systems affected, and whether the firm must preserve evidence for legal proceedings |
| Assessor sampling effort | Internal compliance staff who prepare samples; the independent assessor who tests them | Recurring, each assessment cycle | Number of incidents in the period, how well root cause records are kept, and how quickly the assessor samples them |
Who owns root cause analysis and what partners do
Your organization owns the root cause analysis. Your incident lead and security leadership decide what the sequence of events was, which assets and vulnerabilities were involved, whether a systemic cause exists, and when the analysis is complete. No outside party can accept that risk on your behalf, and an assessor will look for named individuals with documented decision rights rather than a tool output presented as a conclusion.
- Decision rights: Name who can open, scope, close and sign off a root cause analysis, and who can overrule a preliminary finding.
- Sequence and assets: Own the reconstructed timeline and the list of affected systems, and record where the evidence is incomplete.
- Systemic causes: Decide whether the cause is a process, configuration, staffing or design problem that needs a corrective action, not only a patch.
- Lessons and follow-up: Track corrective actions to closure and feed them into your improvement process.
Before relying on any analysis, check that the sign-off record names the approver, the date and the evidence reviewed.
An implementation partner can prepare the systems and records that make root cause analysis possible. This work usually covers log sources, case management, collection tooling and templates. The partner does not decide the cause of an incident and does not sign the analysis. Scope and deliverables are agreed in writing before work starts, so you can see exactly what is configured and what remains with your staff.
- Logging: Configure log sources and retention so that event sequences can be reconstructed, for example audit logging in a self-hosted application such as Nextcloud, written to a path you control.
- Case tooling: Set up a case management platform such as DFIR-IRIS so that assets, indicators, tasks and evidence sit in one record with an audit trail.
- Collection: Deploy endpoint query and forensic collection tools such as osquery or Velociraptor, with access limited to your authorized responders.
- Procedures and templates: Draft analysis templates, evidence handling steps and sign-off forms for your team to adopt and approve.
Ask the partner to name each deliverable, the system it lives in, and who will operate it after handover.
An independent auditor, assessor or certification body tests whether your root cause analysis practice works and reports on it. Only that independent party issues findings or attestations. Outside consultants, including DeployOpen, prepare evidence but do not issue reports or certifications. Auditors also generally test samples of past incidents, so they need records that were produced at the time rather than reconstructed for the audit.
- Sample selection: Expect the auditor to choose incidents and check each for a documented sequence, asset list, cause and sign-off.
- Independence: The auditor should not design the analysis they test or write the conclusions they review.
- Evidence checks: Auditors look for log integrity, consistent timestamps and evidence that the case record was not edited without a trail.
- Reporting: Findings are issued by the auditor under its own process, and NIST does not offer a conformity assessment program for CSF 2.0.
Before engaging an assessor, confirm which standard or contractual requirement they will test against and how they will treat tool-generated records.
Where root cause analysis usually falls short
Most weak RS.AN-03 analyses fail in predictable places: the investigation stops early, the evidence is thin, and the findings never reach a change. The cards below name six of these gaps and the check or fix that closes each one.
Analysis stops at the initial vector
Teams often record how the attacker first got in, such as a phishing email or an exposed service, and close the analysis there. RS.AN-03 asks what happened across the whole incident, including the assets touched after entry and the threat actors involved. Check whether the write-up traces lateral movement, privilege changes and persistence mechanisms, and whether each one has an owner who confirmed it against host and network records.
Missing or incomplete logs
A root cause cannot be established from events that were never recorded or were overwritten before anyone looked. Gaps often sit in endpoint telemetry, authentication events and admin actions on collaboration platforms. Confirm which log sources covered the affected assets during the incident window, where they were forwarded, and whether audit logging was enabled on self-hosted applications before the event, not after it.
Timelines built from memory
Reconstructed timelines drawn from interviews tend to drift by hours, and the sequence is what separates cause from consequence. Build the timeline from timestamped records instead, normalize time zones and clock sources, and mark any entry that rests on a person's recollection. Tools that consolidate alerts, assets and evidence into one case timeline make it easier to show which event came first and which source supports it.
No link to corrective action
A root cause that is documented but never tied to a fix leaves the same weakness in place for the next incident. For each finding, record the corrective action, its owner, the systems it changes and the date it was verified. Check that the findings feed into the vulnerability backlog, configuration baselines and the risk register, so that RS.AN-03 results appear in the program's improvement work rather than only in the closed incident file.
Root causes that restate symptoms
Statements such as "malware infected the server" or "user clicked a link" describe what happened but not why the environment allowed it. A useful root cause names the systemic condition, such as an unpatched service exposed to the internet, a missing approval step or an absent alert rule. Test each stated cause by asking what would have prevented or detected the event, and revise the statement until that answer is specific and actionable.
No retention of analysis records
Root cause reports often sit in a shared drive with no retention rule, and the underlying queries, exported logs and hash records disappear when the platform is upgraded or storage is cleaned up. Set a retention period for analysis records and their supporting evidence, store them with access controls and integrity checks, and confirm that the period satisfies your contractual and regulatory obligations. Ask your auditor which records they will sample.
Questions buyers ask about RS.AN-03
How much effort does a root cause analysis take?
Effort depends mainly on how much happened and how well it was logged. A contained event on one host with complete logs is a short exercise. A multi-system intrusion with gaps in the timeline takes far longer, because responders must rebuild the sequence, confirm assets, test vulnerabilities and check whether the cause was systemic. The cost is mostly staff time from incident responders, system owners and whoever writes the report, plus any forensic tooling used. The analysis itself is a one-time effort per incident, but the capability to run it recurs as a program cost. Ask any provider for effort by phase (timeline reconstruction, evidence review, root cause findings and reporting) in the written scope before work starts.
Can our own team run root cause analysis without outside help?
Many teams can, provided they have three things: log coverage that reaches back far enough, people who can reconstruct a timeline from that data, and enough independence from the responders who handled the incident. Limits usually appear in staff capacity during a live incident, a shortage of forensic tooling and the risk that analysts review their own containment decisions. Before deciding, confirm who will lead the analysis, which log sources are retained and for how long, and whether the team has documented procedures for recording the sequence of events. A partner can supplement these gaps without taking over ownership of the conclusions.
What does an implementation partner add to root cause analysis?
A partner adds capacity, method and tooling. DeployOpen plans, implements and hardens self-hosted open-source platforms in your own environment, so it can help deploy the log collection, case management and endpoint query tools that the analysis depends on. It can also run security testing and private cyber range exercises so your team practices reconstructing an incident before a real one. What a partner does not do is own the findings or issue assurance. The organization owns its controls and conclusions, and only an independent auditor or assessor issues a report on them. Scope these responsibilities in writing so the split is clear from the start.
What does the organization need to provide for this work?
The work depends on access and decisions that only the organization can give:
- Retained logs from identity, network, endpoint and application sources, with synchronized clocks so events line up
- An current asset inventory and a map of which systems hold which data
- Read access to the SIEM, EDR and case tools, plus a named incident lead with authority to make decisions
- Change records, backup copies and a secure location for evidence, so findings can be checked later
- Time from system owners who can explain how their services behaved during the incident
If any of these are missing, the analysis will still proceed, but conclusions will be weaker and take longer to reach.
How long does setting up root cause analysis capability usually take?
No duration applies across all organizations, so confirm the timeline in the written scope rather than relying on a general figure. Setup length is driven by the number of log sources to onboard, how many hosts need endpoint coverage, whether incident response runbooks already exist, and how quickly staff and system owners can be scheduled. Ask the provider for milestones, the dependencies between them, and which items depend on the organization's own work, such as granting access or approving changes. A fixed-scope engagement should state its deliverables and dates before any work begins.
Does NIST certify that our organization meets RS.AN-03?
No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. The CSF is voluntary for most organizations, although some customers or suppliers require it. In practice, you demonstrate alignment by showing the outcome that RS.AN-03 describes, which is establishing what happened in an incident and why, and by keeping evidence such as analysis reports and timelines. If a contract requires independent proof, an external assessor provides that opinion. No one can issue a NIST certificate for this subcategory.
How do CIS Safeguard 17.8 and ISO 27001 controls 5.25 and 5.27 relate to RS.AN-03?
NIST's CSF 2.0 Reference Tool lists informative references that connect RS.AN-03 to CIS Safeguard 17.8 and to ISO/IEC 27001:2022 Annex A controls 5.25 and 5.27. The control 5.25 covers assessing information security events and deciding whether they are incidents, and 5.27 covers learning from incidents. The same tool also lists SP 800-53 controls AU-7, IR-4 and SI-2(7). These are informative mappings, not equivalences. One well-run root cause analysis can produce evidence for several frameworks, but each assessor decides whether that evidence satisfies its own requirement. Confirm the exact wording of each control with its owning body before relying on the mapping in an audit. The NIST CSF 2.0 Reference Tool export is the place to check the current mappings.
How DeployOpen prepares systems and evidence for RS.AN-03
DeployOpen plans, implements and documents self-hosted tooling and procedures for root cause analysis inside your own cloud accounts, data centers or air-gapped networks. For RS.AN-03, that typically means setting up a case record in DFIR-IRIS that links affected assets, indicators, tasks and a consolidated timeline, so the sequence of events can be reconstructed from one source. Scope is agreed in writing before work starts, and the deliverables list names the systems, log sources, analysis procedures and evidence outputs you will receive. Decisions that remain yours include which systems are in scope, who owns the root cause conclusion, and how findings feed corrective actions in ID.IM and RS.MA.
DeployOpen does not issue audit reports, attestations or certifications. Its role is to prepare systems and evidence that an independent auditor, assessor or certification body can test, such as sample case records, timeline exports, query definitions for osqueryd fleet collection, Velociraptor hunt configurations, and documented procedures for distinguishing systemic causes from proximate triggers. Security testing can be run against the same environment to check whether detection and analysis hold up under realistic attack paths. Before engaging, confirm with your assessor which artifacts they will request and the retention period they expect, and confirm with your vendors which features each platform version provides, since a capability that is not verified in your environment should not be assumed.
How DeployOpen scopes root cause analysis readiness
DeployOpen plans and builds the systems that support RS.AN-03 root cause analysis inside your own infrastructure, from log sources and case records to the forensic tooling analysts use. Your organization keeps ownership of its controls, and an independent auditor or assessor issues any report or certificate.
How we scope
- Engagements are fixed-scope, with the covered log sources, case records and analysis tools agreed in writing before work starts.
- The written scope names which systems feed the event sequence, asset and vulnerability picture for each incident analysis.
- Scope records who owns each analysis step, including the incident lead, forensic analysts and the people who approve root cause findings.
How we build
- We deploy self-hosted case management such as DFIR-IRIS so each incident keeps assets, indicators, tasks and evidence in one record.
- We configure timeline building from SIEM, EDR and audit sources so analysts can reconstruct the sequence of events.
- We set up endpoint and fleet query tooling, such as osquery and Velociraptor, and test that collected artifacts support the analysis.
How we hand over
- Handover includes configuration documentation, runbooks for root cause analysis and a list of the evidence each step produces.
- We document how systemic root causes are recorded and reviewed, so findings can be shown to an assessor on request.
- Your team receives walkthroughs of the case records, timelines and reports, and confirms that each step works in your environment.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Retainers can cover tool upgrades and periodic checks that log sources and analysis workflows still capture what root cause analysis needs.
- Ask any implementation partner to confirm in writing which parts of RS.AN-03 remain your team's responsibility after handover.
