RS.MA-01 Incident response plan executed: requirements and evidence

What RS.MA-01 asks for once an incident is declared

RS.MA-01 applies at the point where an incident has already been declared and the real question is whether the written incident response plan is being run, including the parts that depend on outside parties. The Subcategory's outcome, paraphrased, is that the plan is carried out in coordination with relevant third parties once an incident is declared. Auditors and assessors will not accept a plan that sits in a document repository and is only opened after the fact. They will look for evidence that the plan was activated, that the right people acted, and that suppliers and responders were brought in on the timeline the plan describes. NIST publishes four Implementation Examples for this Subcategory: detection tools that report confirmed incidents automatically, requesting help from an incident response outsourcer, designating an incident lead for each incident, and starting business continuity and disaster recovery plans as needed. Together they describe a chain from detection to activation to continuity.

RS.MA-01 sits in the Incident Management Category of the RESPOND Function. It takes over the outcome of CSF 1.1 RS.RP-1, which covered executing the response plan, under a new identifier, and it absorbs part or all of CSF 1.1 RS.CO-4, which concerned coordinating with external stakeholders during response. NIST's CSF 1.1 to 2.0 Core Transition Changes spreadsheet is the place to confirm exactly how your existing 1.1 mappings carry over. If your program already cites RS.RP-1 or RS.CO-4 in an assessment, update those references rather than assuming they still line up one to one.

In practice, the hard part is rarely writing the plan. Organizations usually run into three gaps. First, the plan has no activation trigger, so nobody knows which alert or decision moves an event from triage into an declared incident. Second, authority is unclear: it is not written down who may isolate systems, engage an outsourced responder, or notify a regulator. Third, third-party arrangements exist on paper but were never exercised, so the retainer, contact path or escalation terms fail under pressure. Ask for the activation criteria, the named incident lead for each category of incident, the contract terms for any response provider, and the date of the last exercise that used them. If you cannot produce these, RS.MA-01 is not yet met, whatever the document says.

Which systems, teams and third parties RS.MA-01 reaches

RS.MA-01 is only as wide as the scope you draw around the incident response plan. The cards below cover the decisions that change the work most: which signals start a response, who may declare one, which outside parties are pulled in, and whether continuity planning is triggered by the same declaration. Each decision is worth settling in writing before an assessor asks how the plan is executed.

Detection sources that feed automatic reporting

The Implementation Examples for RS.MA-01 describe detection tools that report confirmed incidents automatically. Decide which sources qualify, such as SIEM correlation rules, EDR alerts, cloud audit logs and email security events, and what confirmation threshold each must meet before a case is opened. Every source you add widens the alert volume your responders must triage, so list each one with its owner and its expected false-positive rate, and confirm the reporting path works outside business hours.

Business units authorized to declare

Declaring an incident should be a defined authority, not a judgment left to whoever notices a problem first. Name the business units, product owners and regional leads who can declare, and the single incident lead who takes ownership once they do. Wider declaration rights mean more declared incidents to track and more executives pulled into calls. Narrower rights risk delay when a unit is hit before central security knows. Document the criteria and test them in an exercise.

Retained incident responders

If your plan relies on an outsourced incident response firm, the retainer determines how fast help arrives. Decide whether the firm is on a standing retainer or engaged on demand, which services it covers (containment, forensics, recovery support), and whether it has been granted the access it needs before an incident happens. Contracts, onboarding and access reviews are one-time effort. Retainer fees and on-call terms recur. Ask any provider for written response-time commitments and its conflict-of-interest rules.

Legal counsel and forensics firms

Counsel shapes what gets written down, who sees the investigation, and how evidence is preserved for regulators and litigation. Decide in advance whether forensic work runs under counsel's direction, which firm performs it, and how chain of custody is recorded. Outside counsel and forensic engagements are usually a recurring retainer plus per-incident work. Pre-agreed scope and contact lists reduce the time lost to finding someone at 2 a.m. Confirm which jurisdictions' notification rules your counsel covers.

Cloud providers and managed security providers

Cloud providers and managed security providers hold logs, controls and sometimes response authority that your plan must reach. Map which providers can act on your behalf, which ones only supply logs, and how to request preserved evidence from each. Contractual notice periods and escalation contacts differ by provider, so confirm them against the actual agreements. A managed security provider that monitors your environment needs the same declaration criteria as internal teams, or its alerts will sit in a separate queue.

Shared declaration with continuity and recovery plans

The RS.MA-01 Implementation Examples include starting business continuity and disaster recovery plans as needed. Decide whether one declaration activates those plans automatically or whether a separate decision is required. A shared trigger keeps teams aligned but can start costly failover when only a containment step was needed. Separate triggers add a handoff that can stall. Write the activation criteria once, state who may activate continuity, and rehearse both paths. Recovery initiation criteria are covered under RS.MA-05.

How an assessor tests RS.MA-01

This table sets out what an assessor reviews, samples, asks for and typically flags when testing whether the incident response plan is executed once an incident is declared. Read each row as one test step, the evidence the organization should be ready to produce, and the gap that most often causes a finding.

Test area	What the assessor does	Evidence requested	Common findings
Plan and activation criteria	Reviews the incident response plan and confirms it states when and how it is activated, who declares an incident and how the plan links to incident triage	Approved plan with version history, declaration criteria, activation procedure and review dates	Plan exists but activation criteria are vague, undefined or not approved by leadership
Sampling declared incidents	Selects a sample of declared incidents and traces each one from declaration through the steps the plan requires	Incident tickets or cases with timestamps, declaration records and actions taken in order	Incidents declared outside the plan, missing timestamps or steps skipped without a recorded reason
Automatic reporting	Checks whether detection tools report confirmed incidents into the case process as the plan describes	Alert-to-case configuration, sample alerts with their resulting cases and rule definitions	Detection tools configured but confirmed incidents still raised by email or manually, with delays not explained
Incident lead designation	Confirms that each sampled incident has a named incident lead and that the lead had the authority the plan assigns	Assignment records, on-call roster, role descriptions and handover notes for sampled incidents	Lead recorded as a team name, changed without notes, or the named person lacked documented authority
Third-party engagement	Reviews whether outside responders, legal counsel or other relevant third parties were engaged when the plan requires it, and when	Retainer or contract terms, engagement records, communications log and time of first contact	Contracts exist but contact details are out of date, or engagement happened late with no record of the decision
Continuity and recovery activation	Checks that a decision on whether to start continuity or disaster recovery plans was taken and recorded for each relevant incident	Decision records, meeting notes or case entries showing activation or a documented decision not to activate	No record that the decision was considered, or activation occurred with no link to the continuity plan
Post-incident review of execution	Looks for evidence that the team reviewed how well the plan was executed and fed changes back into the plan	Lessons-learned notes, plan change requests and dates of plan revisions	Reviews are not held for minor incidents or findings are not tracked to closure

Implementing RS.MA-01 step by step

This sequence turns RS.MA-01 from a plan on paper into a process that starts on declaration, reaches the right outside help and hands off to continuity and recovery without guesswork. Each step produces a record that an assessor or internal reviewer can inspect.

Define declaration criteria and who may declare
Write the conditions under which an event becomes a declared incident, such as confirmed unauthorized access or confirmed loss of a critical service, and name the roles allowed to make that call. Assign an alternate for each role so a declaration can be made when the primary is unavailable. The output is a declaration record template and a short authority list approved by leadership. The step is done when a reviewer can read the template and say who declared what, when, and on what basis.
Wire detection tools to automatic reporting
Configure your SIEM, EDR and other detection tools so that confirmed incident alerts create a case or ticket and notify the incident lead without manual relay. Test each route with a benign sample event and keep the rule configuration under change control. The output is a routing matrix listing each source, its destination queue, and the test result. The step is done when a test event reaches the case system and the notification log shows the delivery.
Pre-select outsourced response assistance
Identify the external incident response providers you would call, confirm how they accept a request, and agree the commercial terms before an incident occurs. Record who is authorized to request help, which contact channel to use out of hours, and what information the provider will need at the start. The output is a contact register and, where you contract for retainer support, the signed retainer or engagement terms. The step is done when the register is tested with a contact call or request and the response is logged.
Name an incident lead and a deputy
Appoint one incident lead for each declared incident, with a named deputy who can take over during absence or fatigue. Define the lead's authority to pull in staff, approve containment actions and brief executives, and confirm that the role is written into the response plan and on-call rota. The output is a role card for each person and a current rota. The step is done when the rota shows coverage for every period and the lead can state their authority without consulting the plan.
Define the hand-off to continuity and recovery
Set the trigger and decision owner for starting business continuity and disaster recovery plans during an incident, and specify what information the incident lead must pass to those teams. Coordinate with the recovery owner so containment and restoration do not work against each other. The output is an activation decision log template that records the time, the decision, the approver and the plans invoked. The step is done when a sample decision can be traced from declaration through activation in the log.
Rehearse the full sequence
Run a tabletop or technical exercise that walks through declaration, automatic reporting, outside assistance, lead assignment and continuity activation using a scenario you write for your environment. Record gaps in the plan, the routing matrix, the contact register and the rota, and assign owners to fix them. The output is an after-action report and a list of corrections with dates set by your organization. The step is done when each gap has an owner and the fixed items are verified in a second run.

How the plan runs in practice after a declaration

RS.MA-01 starts at the point where a detection has been confirmed and an incident has been declared. The sequence in practice runs from a confirmed detection, to a formal declaration, to assigning one incident lead, to engaging the third parties the plan names, and finally to a decision about whether business continuity or disaster recovery plans must start. Each handoff needs a timestamped record: when the detection was confirmed, who declared the incident, when the lead was named, when the outsourced responder or legal counsel was contacted, and when continuity plans were activated or deliberately held. Those timestamps are what an assessor will ask for when testing whether the plan was executed as written rather than improvised. In a case management tool such as DFIR-IRIS, which the open-source option documentation describes as keeping each case as one record with a full audit trail, these entries can sit in the same record as the evidence, which reduces the gap between what happened and what was written down.

The Implementation Examples for RS.MA-01 describe detection tools reporting confirmed incidents automatically, a request for help from an incident response outsourcer, a named incident lead for each incident, and the start of business continuity and disaster recovery plans as needed. Confirm with your own environment which of these your detection stack can trigger without a person in the loop, which contracts already allow an outsourced responder to be engaged on short notice, and who holds the authority to start continuity plans. Those answers are organization-specific, and a design gap usually appears at the point where a lead is unclear about whether a business function can be paused. Test that decision in an exercise before a real incident forces it.

This page stops at execution with third parties. Triage and validation of reports belong to RS.MA-02, categorization and prioritization to RS.MA-03, escalation and status tracking to RS.MA-04, and the criteria for starting recovery to RS.MA-05. Where a handoff in this section depends on one of those decisions, record the decision as an input here and leave its design to the sibling page. Partners that prepare the systems, runbooks and evidence for this flow can help, but the organization owns the decisions, and only an independent assessor can test and report on whether the control operated.

Evidence that passes RS.MA-01

RS.MA-01 is tested by looking for a plan that exists, has been approved, and was actually run when an incident was declared. The cards below cover the records that show this chain, from the approved plan through declaration, automation, staffing, third-party help and continuity decisions. Each one needs an owner and a refresh routine so the evidence still matches the environment at audit time.

Approved incident response plan

The plan is the anchor artifact. Keep the approved version with its version history, approval date, approver and a list of the changes made since the last review. An assessor will compare the plan against the systems and contacts that exist today, so check that named roles, escalation paths and tooling references match the current environment. Record the review cycle in the document itself and retain superseded versions so earlier incidents can be matched to the plan in force at the time.

Declaration logs with timestamps

Declaration logs show when an incident was declared, by whom and on what basis. Each entry should carry a timestamp in a single time standard, the declaring role, the triggering alert or report and the decision. Logs held inside the case management system are usually acceptable if access is restricted and entries cannot be edited silently. Sample a few past declarations and confirm the timestamps line up with the detection records before the assessor does.

Detection-to-case automation records

The Implementation Examples for RS.MA-01 describe detection tools reporting confirmed incidents automatically. Evidence for this is the configuration of the rule or integration that opens a case from a SIEM, EDR or other source, plus a sample of cases it created. Confirm which alerts are automated, which still need a human to open a case, and how failed deliveries are detected. For DFIR-IRIS, the alert triage and case creation configuration, and the case audit trail, serve this purpose.

Named incident lead assignments

The Implementation Examples call for an incident lead to be designated for each incident. Keep a roster that names a primary and an alternate for each incident type, with the authority the role carries, and a record that shows who was assigned to each real case. Review the roster against current staff and on-call rotations, since a lead who has left the organization is a common finding. The assignment should appear in the case record itself, not only in a spreadsheet.

Third-party engagement and retainer records

Where the plan relies on an outsourced incident response provider, the assessor will look for a signed agreement or retainer, the escalation contact and the activation procedure. Records of actual engagements, including the date of activation, the scope given and the handover, are stronger evidence than the contract alone. Confirm the contract covers after-hours contact, data handling during the engagement and who can authorize activation. Outside parties' reports are their property to share, so agree in advance what you can give an assessor.

Continuity activation decisions and post-exercise reports

When an incident triggers business continuity or disaster recovery plans, record the decision, the criteria applied, the approver and the time of activation. Post-exercise reports from tabletop tests and drills show the plan works as written and that gaps were tracked to closure. Keep the report, the findings list and evidence that each action was completed. Refresh the contact lists and tabletop schedule quarterly, and record each refresh with the date and the person who made it, so the file stays current between audits.

What meeting RS.MA-01 costs in money and effort

This table lists each cost component of executing an incident response plan under RS.MA-01, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Read it as a checklist for a quote: ask the implementation partner to price each row separately so you can see which costs are license spend and which are labor.

Cost component	One-time or recurring	Who is paid, and what drives the cost
Incident response plan drafting	One-time, then recurring upkeep	Internal staff and any outside advisor write the plan, roles and escalation paths. Cost rises with the number of business units, systems and third parties the plan must cover.
Plan maintenance and review	Recurring	Staff time to update contacts, authority lists and procedures after org changes, tests and real incidents. Frequent changes to systems or vendors increase the effort.
Case management and reporting tooling	Recurring if licensed, one-time for setup	Commercial case platforms charge license or subscription fees. Self-hosted open-source case management, such as DFIR-IRIS (LGPL-3.0-or-later), removes the license line, but hosting, patching and administration remain your cost.
Integration engineering for automatic reporting	One-time build, recurring maintenance	Engineers connect SIEM, EDR and other detection sources so confirmed incidents open cases automatically. Cost depends on the number of sources, their APIs and how often the integrations break after upgrades.
Retainer or on-call contracts with outside responders	Recurring retainer plus per-engagement fees	Retainers pay for guaranteed availability; incident work is billed separately. Ask whether retainer hours roll over, what response times are committed in writing and how out-of-hours work is priced.
Incident lead designation and training	Recurring	Staff time for named leads, backups and training on the plan. Cost rises when few people hold the authority the plan requires.
Exercise and tabletop time	Recurring	Staff hours for planned exercises that test the plan with third parties. Frequency, participant count and whether an outside facilitator is used are the main drivers.
Continuity and recovery plan activation	One-time plan build, recurring testing	Business continuity and disaster recovery plans must be ready to start. Cost depends on how many plans must be written, maintained and tested against the same incident scenarios.
Evidence upkeep for assessors	Recurring	Staff time to keep incident records, timelines, approvals and exercise reports current and retrievable. Auditors sample these records, so gaps found late are costly to fix.
Independent auditor sampling	Recurring per assessment cycle	Only an independent auditor or assessor issues conclusions. Their fees depend on the audit scope and the volume of incident samples they select. Ask your auditor which evidence they will sample before the cycle starts.

Who owns RS.MA-01 and what a partner can take on

Your organization owns RS.MA-01 in full. The Subcategory asks that the incident response plan is carried out once an incident is declared, and that carries accountability that cannot be delegated away: someone inside the organization must have the authority to declare an incident, to name the incident lead, and to decide when continuity plans start. Contracts with outside responders, forensic firms and notification services also sit with you, including who is called, under what terms and on what timeline.

Plan ownership: Approve the incident response plan, keep it current and record who signed off on each version.
Declaration authority: Name the roles and the people who can declare an incident, with a deputy for out-of-hours cover.
Incident lead: Assign a lead for each incident and make sure the role is written into the plan, not improvised on the day.
Third-party contracts: Hold the retainers with incident response providers and confirm their response obligations in writing.
Continuity activation: Decide, with business owners, when business continuity and disaster recovery plans start.

Check that each named role has a current contact path, that the declaration authority is documented, and that every outside responder has a signed agreement before you need it.

Where RS.MA-01 implementations usually fall short

RS.MA-01 asks that the response plan actually runs once an incident is declared, with third parties and continuity plans engaged. The gaps below tend to appear between a written plan and a working response, and most of them are visible long before an incident if someone tests the plan.

No defined declaration trigger

Many plans describe how to respond but not what moves an event from a monitoring alert to a declared incident. Without a written trigger, responders wait for a manager to decide, and the clock on containment and notification runs unmanaged. Check that the plan names the conditions that declare an incident, who may declare it, and whether automated detections can open a case directly. Ask for a recent example of a declaration and the time it took.

Incident lead named only on paper

The plan often lists an incident lead role, but the person named may be unavailable, unaware of the assignment, or without authority to pull in staff or approve actions. RS.MA-01 expects a lead designated for each incident. Confirm that the role has named deputies, that the assignment is recorded at declaration, and that the lead has decision rights written down. A tabletop exercise in which the named lead is absent will quickly show whether the role works.

Third-party responders never contracted

Plans frequently name an outside incident response firm, but no retainer, contact path or statement of work exists, so the firm's first call happens during the incident. Legal review of data handling, access to systems and evidence custody can then take days. Confirm that the contract is signed, that the retainer terms cover activation hours, and that the responder has received a test engagement or at least a documented onboarding call with your environment.

Continuity activation not tied to declaration

Business continuity and disaster recovery plans are often maintained by a different team and activated by a different process. When an incident is declared, nobody is certain whether the recovery plans should start, so they start late or in the wrong order. Map each incident category to the continuity or disaster recovery plans it may trigger, and document who makes that call. Review whether the decision criteria are the same ones used for recovery initiation under RS.MA-05.

Evidence created only for the audit

Teams sometimes reconstruct the timeline, approvals and third-party engagement records after the fact to satisfy an assessor. Assessors test whether the evidence was produced as the response happened. Check that the incident record captures declaration time, lead assignment, responder engagement and continuity decisions as they occur, with an audit trail. Open-source case management tools such as DFIR-IRIS can keep this record in one place, but the team must use them during the incident, not afterward.

Small-business plans lack clear authority

Smaller organizations often rely on one or two people who both run IT and make business decisions, so nobody is clearly authorized to carry out the plan. NIST's Small Business Quick-Start Guide asks small businesses to understand their plan, who has authority to carry it out, and how ready they are to respond. Write down who can declare, contain, engage an outside firm and spend money during an incident, and test that list with a short exercise at least once a year.

How small organizations can meet RS.MA-01

A small organization meets the intent of RS.MA-01 by answering three questions before an incident happens: who has the authority to run the response, what the written plan says they should do, and how ready the team is to act on it. NIST's *SP 1300*, the CSF 2.0 Small Business Quick-Start Guide published in February 2024, cites RS.MA-01 when it asks small businesses to check exactly these points. The first decision is naming one person, often the owner, an office manager or an outside IT provider, as the incident lead with explicit authority to pull systems offline, call in help and speak for the business. Write that name down, with a backup, in the plan itself.

A proportionate plan is short. It can be a few pages that list the contact details for the incident lead, the IT provider, the cyber insurer and legal counsel, the first steps for the incident types most likely to hit the business (such as a phishing-driven account takeover or a ransomware event), and the conditions under which the business activates its backup and recovery steps. Confirm the insurer's notice requirements and any contractual deadlines for telling customers before an event occurs, because those timelines often drive the response more than the technical steps do. Readiness is tested with a tabletop exercise that walks the lead through one realistic scenario, followed by a note of what the team would change.

The CSF is voluntary for most organizations. NIST states that it is not a regulator and most organizations use the framework on their own initiative, though some customers and suppliers now require alignment as a condition of contract. If a customer or insurer asks for evidence against RS.MA-01, the honest answer is a dated plan, a named lead, a contact list and a record of the last exercise. Ask the requesting party which format they expect, because they, not NIST, will decide whether that evidence is enough. Where a small business wants outside help, a fixed-scope review of the plan and one exercise is usually easier to scope and budget than an ongoing program, and the written scope should state who owns the plan after the work is delivered.

Questions buyers ask about RS.MA-01

Does RS.MA-01 add cost to our security program?

Yes, but the cost sits mostly in people and exercises rather than tooling. RS.MA-01 asks that your incident response plan be carried out with relevant third parties once an incident is declared, which means someone must maintain the plan, name an incident lead, agree how automatic reporting from detection tools reaches responders, and set up access to an outsourced response provider before anything happens. The main recurring costs are staff time for plan upkeep and exercises, retainers or contracts with outside responders if you choose them, and any licensed or self-hosted tooling you run. The main one-time costs are the initial plan build, integration of detection tools with case handling, and documenting continuity plan activation. No public cost figure for RS.MA-01 is supplied here, so ask any vendor or partner for a quote built from a written scope that lists each of these components separately.

Can we implement RS.MA-01 in-house without outside help?

Yes, many organizations do, provided they have people who can own the plan and run it under pressure. NIST's Implementation Examples for RS.MA-01 describe four practices: detection tools reporting confirmed incidents automatically, requesting help from an incident response outsourcer, designating an incident lead for each incident, and starting business continuity and disaster recovery plans as needed. An internal team can build all four. Outside help tends to make sense where you lack a standing response capability, need a second opinion on plan design, or want an independent party to run the exercises. Be clear about roles: your organization owns the controls and the plan, an implementation partner can prepare systems, integrations and documentation, and only an independent auditor or assessor reports on conformance. NIST does not certify anyone against the CSF.

How long does it take to get RS.MA-01 working?

The duration depends on how much of the response capability already exists, and no fixed timeline is supplied here. The work usually runs in stages: confirming the current plan and who holds authority under it, wiring automatic reporting from SIEM, EDR and other detection sources into a case process, agreeing terms with any outsourced response provider, and testing continuity and recovery handoffs. Drivers that lengthen the schedule include a plan that exists only on paper, several disconnected detection tools, unclear authority between IT, legal and business units, and contracts that take time to negotiate. Ask for a schedule in the written scope that ties each stage to a deliverable and names the people who must approve it.

What does RS.MA-01 need from our organization?

It needs named people, working integrations and agreed third-party arrangements. Specifically, you need a documented incident response plan, a named incident lead or a rule for designating one per incident, and written authority for who can take response actions. Your detection and alerting sources must be able to send confirmed incidents to a central record. If you rely on an outsourced responder, you need a contract or retainer that defines activation and access. Your continuity and disaster recovery plans must state the conditions under which they start. Evidence an assessor will expect includes the plan version history, incident records showing the lead assigned, and exercise reports. The NIST Small Business Quick-Start Guide (SP 1300, February 2024) frames the same questions as understanding the plan, knowing who has authority, and knowing how ready you are to respond.

Does NIST certify that we comply with RS.MA-01?

No. NIST states that it 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 a voluntary framework, so no NIST body issues a certificate for RS.MA-01 or any other Subcategory. If a customer or regulator asks for evidence, the organization shows its own alignment with the Subcategory, and an independent assessor may test that claim and report on it. Be wary of any provider who offers a NIST certification or a NIST-endorsed badge. Ask instead which independent party will review your evidence and what form that review takes.

Can a partner run the RS.MA-01 tabletop exercise for us?

Yes, a partner can plan, facilitate and document a tabletop exercise, and DeployOpen offers security testing and private cyber ranges that can support hands-on incident response practice. Still, your organization owns the plan and decides what the exercise tests, and the exercise should involve the people who would actually act under the plan, including the incident lead, IT, legal and communications. Ask a prospective partner to define in the written scope the scenario, participants, objectives, the output document and the follow-up actions that will update the plan. Exercise outcomes should feed back into the plan and into the improvement records that the CSF expects.

Where DFIR-IRIS fits the evidence trail

A self-hosted case management tool such as DFIR-IRIS (LGPL-3.0-or-later) can hold each declared incident as one case record, which gives RS.MA-01 a single place to show that the incident response plan was executed. Once the incident lead declares an incident, the case can carry the affected assets, indicators of compromise, assigned tasks, logged evidence and a consolidated investigation timeline, with a full audit trail of who changed what and when. Those records are the material an assessor will ask for when testing whether the plan was actually carried out rather than only written down. The reports generated from case data can then be reused for internal review and for any third party that needs a summary of activity.

The tool is most useful as evidence for three decisions within this Subcategory: the moment an incident is declared, the designation of the incident lead, and the record of when outside responders were engaged. Alerts from SIEM, EDR and REST sources can be triaged into cases, so the declaration timestamp and the first alert that triggered it are both traceable. Evidence entries with SHA-256 verification and chain of custody also support later questions about whether third-party responders handled material correctly. Before relying on this, the organization should check the audit trail configuration and retention settings in its own deployment, since those determine whether the record will hold up.

The caveat is that a case tool proves only what flows into it. The organization must confirm that its own detection sources actually feed DFIR-IRIS, that the alert formats and connectors match its SIEM and EDR products, and that the named incident lead and retained responders have accounts, roles and a documented way to work in the platform. If an outsourced responder works in a separate system, the case record needs a reliable link to that work. The organization still owns the decision to declare an incident and the plan itself, and an independent assessor will judge whether the record matches what happened.

Testing the plan before an auditor does

This sequence turns RS.MA-01 from a written plan into a rehearsed capability. It shows whether declaration, lead assignment, third-party engagement and continuity activation work in practice, and it produces records an assessor can read.

Define the exercise objectives and scope
The exercise owner, usually the incident response lead or a GRC lead, writes down which RS.MA-01 behaviors are under test: how an incident is declared, who is named incident lead, how an outsourced response provider is engaged, and when continuity or disaster recovery plans start. Each objective is paired with a pass condition that a reviewer can check. The output is a signed scope note listing the systems, teams and third parties in play, and what is deliberately excluded. Confirm with the leadership sponsor that the exercise can be stopped safely if it affects production.
Design a scenario that forces declaration
Build a scenario in which the detection tools would plausibly report a confirmed incident, for example a credential compromise followed by lateral movement, written as an illustrative case. The scenario should include points where the team must decide whether the event meets the declaration threshold in the plan, and where the outsourced responder would need to be called. Map each inject to the plan step it tests. The output is a scenario script with timed injects, expected decisions and the evidence each decision should generate.
Assign roles and observers
Confirm who plays the incident lead, the responders, the communications owner, the legal and privacy contact, and the external provider contact, and whether the external party participates live or through a pre-agreed simulated call. Assign at least one observer who records timings and decisions but does not intervene. Check that contact details and escalation paths in the plan are current before the run. The output is a roster with named roles, backups and the observer assignment.
Run the tabletop or live exercise
Deliver the injects in sequence and let the team work through declaration, lead designation and third-party engagement as they would in a real event. The facilitator stops the clock only to confirm facts, not to coach the response. For a live exercise, record which systems are touched and confirm the rollback steps before each change. The output is a completed run with every inject answered or explicitly marked as not reached.
Keep the timed record
The observer logs each decision with a timestamp, the person who made it, the plan section followed, and any deviation from the plan. Automated tool output, such as alerts or case creation in a case management system, is captured as a screenshot or export with its time. Where a platform such as DFIR-IRIS is used to hold the exercise case, the case timeline and audit trail can serve as this record, but confirm its export and retention settings with your own assessor first. The output is a time-stamped log that shows the gap between declaration and each subsequent action.
Hold the debrief and classify findings
Within the team, review the timed record against the pass conditions set in the first step. Classify each finding as a plan gap, a missing contact, a tooling gap, a training need or a decision the plan never anticipated. Agree which findings the incident lead and the external provider each own. The output is a findings register with owners and a status for every item.
Feed corrective actions into ID.IM
Send the findings register into the improvement process that ID.IM describes, where lessons from exercises are turned into changes to the incident response plan, contracts, contact lists and tooling. Update the plan, re-issue it to the named roles, and record the version and approval date. Schedule a follow-up check that confirms the corrected steps work, without treating the exercise itself as proof of the Subcategory. The output is a revised plan version and closed corrective actions linked to the original exercise record.

How DeployOpen prepares RS.MA-01 evidence

DeployOpen prepares the systems, runbooks and records that show an incident response plan being executed once an incident is declared. The organization keeps ownership of its plan, its incident lead and its third-party relationships, and an independent assessor decides whether the evidence meets the outcome.

How we scope

Written scope names which detection tools, case records and reporting paths are covered for RS.MA-01.
Scope lists the internal roles and external responders the plan must reach, such as an incident response outsourcer.
Scope states which continuity and disaster recovery plans are activated and how their triggers are documented.

How we build

Configure detection tools to forward confirmed incidents into a case management system automatically.
Set up case records with assets, indicators, tasks, evidence and an audit trail for each declared incident.
Document the incident lead designation process and test activation of continuity plans with the organization's staff.

How we hand over

Deliver runbooks, configuration records and exercise logs that show how the plan is executed in practice.
Provide an evidence map linking each RS.MA-01 implementation example to the artifacts that support it.
Confirm with the organization's auditor which evidence formats and sampling periods they expect before handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover updates to runbooks and case workflows when outsourced responders or contacts change.
Ask for the support scope in writing so responsibilities for each evidence item stay clear over time.