RS.MA-05 Recovery initiation criteria: requirements and evidence

What RS.MA-05 recovery initiation criteria requires

RS.MA-05 asks you to apply defined criteria before you start incident recovery, and to weigh the operational disruption that recovery activities may cause. It is a Subcategory of the Incident Management (RS.MA) Category in the RESPOND Function of NIST CSF 2.0. The Core wording is paraphrased here, so the outcome is that criteria exist and are applied, not that a specific list of criteria must be used. The containment work is often done, leadership wants systems back, and the team has no written agreement on what must be true first. That gap is what this Subcategory is meant to close. The decision needs an owner, the criteria need to be written down before the pressure arrives, and the people deciding should know what evidence each criterion depends on.

The risk runs in both directions. Recovering too early can restore systems that still contain the attacker's access, persistence mechanisms or backdoors, so the same incident returns within hours or days. It can also rebuild on an incomplete picture of scope, leaving accounts, hosts or data stores that were never checked. Recovering too late extends the outage, pushes business users toward unsanctioned workarounds and raises the cost of every hour of disruption. Recovery activities themselves can cause disruption, such as taking services offline for rebuilds, rotating credentials across dependent systems or restoring large data sets, so the criteria should weigh that cost honestly. The difficulty in practice is that incident facts are incomplete and change during the response, so the criteria must work with known and assumed characteristics of the incident.

Start by asking your incident team to write down, for each major system, the conditions that must hold before recovery begins, and who confirms each one. Confirm with NIST's CSF 2.0 Reference Tool which Implementation Examples apply to RS.MA-05, because they describe how to apply recovery criteria to known and assumed incident characteristics and how to consider recovery-caused disruption. Also check the informative references the Reference Tool lists for this Subcategory, since they point to incident response and incident handling controls you may already be testing. Record the decision, the evidence behind it and any risk you accepted, so an independent assessor can later see how the call was made. Confirm the wording and mappings against the current NIST publications before you cite them in a contract or audit file.

Which systems, teams and decisions does RS.MA-05 cover

RS.MA-05 is less about the criteria themselves than about where they apply and who applies them. The cards below cover the decisions that change the work: which incidents and services need recovery criteria, who holds authority to start recovery, and how hosted and managed systems fit in. Settle these before an incident, or the criteria will be applied inconsistently under pressure.

Incident types that need recovery criteria

Not every incident leads to a recovery activity. Ransomware, destructive malware, account compromise and data integrity events each call for different recovery triggers, and a DDoS may only need service restoration. List the incident categories your response plan recognizes and state, for each, whether recovery criteria apply. Check that categorization from RS.MA-03 feeds directly into this decision so responders do not improvise the trigger.

Business services in scope

Recovery criteria should be tied to the business services they protect, not only to hosts. Map each critical service to its systems, data stores and dependencies, then record which conditions must hold before that service is restored. Ask which services have contractual or regulatory recovery expectations, since those often set the bar that the criteria must meet.

Decision authority and escalation

Name the role that decides whether recovery starts, and the alternate who decides if that role is unavailable. The decision usually weighs security assurance against business pressure, so the decider needs input from the incident lead, system owners and, where relevant, legal or communications. Document the approval path and confirm it matches the escalation routes defined under RS.MA-04.

Operational disruption weighing

Recovery activities can themselves cause outages, data loss or a second incident, such as rebuilding systems that are still being analyzed. Before approving recovery, the decider should know which actions will take services offline, how long they may run and whether containment still holds. Confirm that the team has a documented way to estimate this disruption in advance rather than discovering it during the work.

Third-party hosted systems

Systems run by cloud providers, SaaS vendors or hosting partners may restrict what your team can restore or verify. Identify which recovery actions require the provider, which contracts give you rights to logs and restoration support, and how long those providers take to respond. Confirm these terms with each provider now, because they set practical limits on recovery timing.

Managed service provider responsibilities

When a managed security or IT provider operates systems or monitoring for you, the recovery decision may still sit with your organization while execution sits with the provider. Write down which party prepares recovery steps, which party executes them, and who signs off. Check whether the provider's own incident procedures match your recovery criteria, since mismatched triggers are a common source of conflict during an incident.

How an assessor tests recovery initiation criteria

This table sets out the steps an assessor takes to test RS.MA-05, the evidence each step requests, and the findings that most often fail. Read it as a checklist for preparing the recovery decision record before an assessment begins, since the same records answer several test steps at once.

Test step	What the assessor checks	Evidence requested
Request the documented criteria	A written standard for when incident recovery may start, with an owner, an approval and a review date	Approved incident response plan or recovery procedure, version history, approval record
Check known and assumed characteristics	Criteria refer to what is known about the incident (scope, affected systems, confirmed root cause) and to what is assumed, with the assumptions named	Criteria text, a worked example showing known and assumed inputs, list of assumptions tracked to closure
Check the disruption consideration	Criteria require the team to weigh the operational disruption recovery may cause, such as downtime, data loss risk or dependency impact	Impact assessment template, completed impact notes for past incidents, business owner sign-off
Sample past incidents	A selection of incidents where recovery started, to confirm a recorded go or no-go decision was made against the criteria	Incident tickets, timeline entries, decision log with time, decision maker and rationale
Sample no-go decisions	Incidents where recovery was deferred, to confirm the reason was recorded and the decision was revisited	Deferral records, re-decision entries, links to containment or eradicated status
Confirm the criteria are operational	Staff who lead recovery know the criteria and the criteria appear in tooling or runbooks used during an incident	Interview notes, runbook extract, tabletop exercise record showing the criteria were applied
Check the criteria are current	Criteria were reviewed after recent incidents or exercises and changes were approved	Review minutes, lessons-learned actions, revision history

Implementing recovery initiation criteria in sequence

This sequence turns RS.MA-05 from a principle into a repeatable decision: the criteria, the handling of unconfirmed facts, the disruption check, the decision owner and the record of each call. Each step produces an artifact that an assessor can trace back to the decision.

Define criteria tied to incident characteristics
Start by writing the criteria that must be satisfied before recovery begins. Tie each criterion to observable incident characteristics such as scope of affected assets, whether containment is confirmed, whether the attacker still has access, and whether the root cause is understood well enough to prevent reinfection. Involve the incident response lead, system owners and whoever holds the recovery plan. The output is a short, versioned criteria set that names each characteristic, the evidence that shows it, and the threshold that counts as met. Done means every criterion can be checked against a case record without interpretation.
Set rules for assumed and unconfirmed facts
Recovery decisions often rest on facts nobody has verified yet. Define how the team labels each fact as confirmed, assumed or unknown, who may accept an assumption, and what must happen before an assumption can support a go decision. For each assumption, record the verification step and the owner who will close it. The output is a fact-status convention and a rule set that blocks recovery on any assumption that governs whether the attacker is still present. Done means every fact feeding the decision carries a status and a named owner.
Assess the operational disruption of recovery
NIST's Implementation Examples for RS.MA-05 direct the team to consider the operational disruption that recovery activities may cause. Before each recovery action, list the services it will interrupt, the dependencies that break, the business owners affected and the rollback option if the restore fails. Involve operations, business continuity and the affected service owners, and where needed, the people who depend on the service. The output is a disruption assessment attached to the decision, with an explicit statement of whether the business accepts the interruption. Done means the decision record shows the disruption was weighed, not just the technical readiness.
Assign decision authority and the decision record
Name who can approve the start of recovery, who can stop it, and who must be consulted, including any external parties that the response plan involves. Define a standard decision record that captures the criteria status, the fact status, the disruption assessment, the approver, the time of decision and any dissent. Store the record in the case management system so it stays linked to the incident timeline and evidence. The output is an approval matrix and a record template. Done means a reviewer can reconstruct who decided, on what facts and with what trade-offs from the record alone.
Rehearse the decision in an exercise
Test the sequence before a real incident. Run a tabletop or technical exercise with a realistic but invented scenario in which some facts are incomplete, the business pushes for early restoration and an approver must decide. Check whether the criteria are applied, whether assumptions are labeled and whether the disruption assessment is completed before the call. Capture gaps in a corrective action list and feed them into the next version of the criteria. The output is an exercise report and an updated criteria set with a change log. Done means the team has made at least one recovery decision under test conditions and recorded the lessons. Confirm the exercise format and frequency with your own governance and any sector requirements.

How recovery decisions are recorded for an assessor

A recovery start decision for RS.MA-05 should be written down as a single dated record that an assessor can read without interviewing the responders. The record should state the facts known at the time of the decision, the facts assumed where evidence was incomplete, the recovery criteria applied to those facts, the operational disruption the team weighed against starting recovery, and the named person who approved the decision. Keep the known and assumed facts visibly separate. An assessor will test whether the decision followed from the information available at that moment, and a record that mixes later findings into the original facts makes that test impossible to pass.

The investigation record is the strongest source for the decision basis. If the incident was tracked in a case management tool, the case timeline should show when the scope was confirmed, when containment was judged sufficient, and what evidence supported each judgment. Tools such as DFIR-IRIS keep cases as a single record with tasks, assets, indicators and a full audit trail, which lets you show the sequence of events rather than a summary written afterward. Confirm with your vendor or your own configuration that audit entries cannot be edited or deleted by the people whose decisions they record.

Preserve the decision record, the criteria version used, the disruption assessment and the approval as evidence under your retention rules, and store a copy outside the system being recovered. Check that the record links to the backup verification and restoration evidence covered by RC.RP, since an assessor will often follow the chain from the start decision to the recovery outcome. Ask your independent assessor early which format and retention period they expect, because requirements for evidence are set by the framework profile or by the contract that requires it, not by the CSF itself.

Evidence that shows recovery initiation criteria are applied

An assessor testing RS.MA-05 wants to see that recovery criteria exist, that they were applied to real incidents, and that the disruption trade-off was weighed and approved. The cards below cover the artifacts that prove each step, and each one needs an owner who refreshes it on a set cycle rather than only before an audit.

Approved recovery initiation criteria

This is the written standard the decision is measured against: the incident characteristics that justify starting recovery, such as confirmed scope, containment status and availability of clean restore points. Check that the document names an owner, carries a version and approval date, and states which incident types it covers. Review it after each significant incident and after changes to the response plan, and record the review even when no edits are made.

Incident records with recovery decisions

Each incident record should show what was known when recovery was considered, which criteria were applied, and the decision reached with its timestamp. Assumed characteristics should be marked as assumptions and revisited once facts are confirmed. Keep these entries in the case management system with a full audit trail so the sequence of decisions can be reconstructed. Spot-check a sample each quarter for gaps between the recorded decision and the actions that followed.

Recovery disruption assessments

The Implementation Examples for RS.MA-05 call for considering the operational disruption that recovery activities may cause. A written assessment should list affected systems, business services, dependent third parties and the expected outage window for each option, such as restoring during business hours or waiting for a maintenance period. Confirm that the business owner who accepts the disruption is named. Update the assessment whenever service dependencies change.

Approver sign-offs and authority records

A recovery decision needs evidence of who had authority to start recovery and who accepted the operational impact. Keep a delegation list that names the roles allowed to approve recovery for each system tier, along with the sign-offs that exist for each incident. Check that approvals were given by someone on the list at the time of the decision. Review the delegation list whenever incident roles or staffing change, since stale names are a common finding.

Exercise reports and lessons learned

Tabletop exercises and recovery drills show whether the criteria work under pressure. A report should record the scenario, the decision points tested, who decided, how long the decision took, and which criteria were unclear or missing. Track each finding to a closed action with an owner and date. Run exercises on a documented schedule so the evidence shows regular testing rather than a single event before the assessment.

Periodic review and change records

Assessors also look for evidence that the criteria stay accurate as the environment changes. Keep a review log that records each review date, the reviewer, the outcome and any change made to the criteria, the disruption assessments or the approval list. Tie reviews to a fixed calendar and to triggers such as a major incident or a new critical system. Ask the organization to confirm its own review cadence, since no fixed interval is set by the framework itself.

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

This table breaks the effort of meeting RS.MA-05 into cost components, showing who does the work, whether each item is one-time or recurring, and what drives it up or down. Use it to scope internal time against any outside help, and to decide what to request in a written quote. No price figures are given because none are supplied for this subcategory.

Cost component	Who is paid or who does the work	One-time or recurring	What drives the cost
Writing and approving recovery initiation criteria	Internal incident response lead, business continuity owner and risk owner	One-time, then reviewed on a set cycle	Number of business services in scope and how many distinct incident types the criteria must cover
Defining the disruption assessment for recovery actions	Operations owners for each business service, with security input	One-time, then updated when services change	Complexity of service dependencies and how many recovery steps can interrupt live operations
Tabletop exercises that test the criteria	Internal staff time, or an external facilitator if the organization engages one	Recurring, usually tied to a planned exercise schedule	Number of scenarios, number of participating teams and whether an outside facilitator runs the session
Evidence upkeep for incident records	Incident response analysts and the tooling administrator	Recurring with each incident	Incident volume, the level of detail the organization records and how many systems hold incident data
Tooling hosting and maintenance	Internal platform team, or an implementation partner under a written scope	One-time setup, then recurring operations	Whether incident records sit on self-hosted open-source software or a commercial product, and how many integrations are needed
Software licenses for incident tooling	Software vendor	Recurring	Self-hosted open-source platforms generally avoid per-seat license fees, though hosting and staff time still apply
External review of criteria	Independent assessor or consultant, if the organization requests a review	Often one-time per revision	Scope of the review and whether it covers only the document or also exercise results
Recovery decision logging and sign-off	Incident commander and approving executive	Recurring with each recovery decision	Frequency of major incidents and how many approvers must sign off before recovery starts

Which open-source tools support recovery decision evidence

DFIR-IRIS is a self-hosted case management tool for incident response teams. Its central idea is that each incident lives in one case record, so the facts a responder relies on when weighing recovery sit in the same place as the investigation work. The case groups the affected assets, indicators of compromise, tasks and collected evidence, which gives the decision-maker a single view of what is known about the incident and what is still open.

Assets: affected systems and accounts are attached to the case, so the scope behind a recovery decision can be shown directly.
IOCs: indicators are recorded against the case, which helps show whether containment is complete before systems return to service.
Tasks: response actions and their owners are tracked, so open items that affect recovery are visible.
Evidence: artifacts are logged against the case, supporting later review of what the decision was based on.

Confirm with your own team which case fields and templates you will use for recovery-related records, because the structure only helps if it is applied consistently.

Where organizations fall short on recovery criteria

RS.MA-05 asks whether an organization applies defined criteria before it starts recovery, and weighs the disruption recovery itself may cause. The gaps below tend to appear together, so closing them as a set matters more than fixing any one in isolation.

No written recovery initiation criteria

Many teams start recovery on the judgment of whoever is on call. Without written criteria, the decision cannot be repeated, reviewed or shown to an assessor. Check whether the response plan names the conditions that must be true before recovery begins, such as containment confirmed, scope understood and the incident lead's sign-off recorded. Closure: draft a short criteria set, have the incident lead and system owners approve it, and store it with the response plan.

Criteria that ignore disruption

Some criteria only ask whether the threat is contained. They do not ask what recovery activities will do to running services, customers or safety-related operations. Restoring a database, rebuilding domain controllers or isolating a network segment can each cause outages of their own. Check whether the criteria require a documented estimate of that disruption and a named owner who accepts it. Closure: add a disruption assessment step with the affected business owner as the approver.

Undocumented decisions

A recovery start decision made in a chat thread or a bridge call leaves no trail. Later, nobody can say what was known, what was assumed and who accepted the risk. Check that each decision records the incident characteristics used, whether they were confirmed or assumed, the time of the decision and the approver. Closure: use a fixed decision record in the incident platform or ticketing tool, and retain it with the case file.

Recovery start not linked to RC.RP

Recovery initiation is the handoff into recovery plan execution, which covers prioritizing actions, verifying backups and restored assets, and declaring recovery complete. When the start decision is not tied to those steps, teams restore systems before backups are checked or before dependent systems are ready. Check that the recovery plan names the criteria it expects to be met before it begins. Closure: map each initiation criterion to the RC.RP step it unlocks, and review the map after every exercise.

Criteria untested in exercises

Criteria that exist only on paper often fail under pressure, when the incident lead is unavailable or the affected system owner disagrees. Tabletop exercises and post-incident reviews are where these weaknesses show. Check whether recent exercises included a recovery start decision and whether the outcome changed the criteria. Closure: include a recovery start decision in the next exercise scenario and record any change to the criteria in the improvement log.

Questions buyers ask about RS.MA-05

Can RS.MA-05 be certified against NIST CSF 2.0?

No. NIST does not certify organizations, products or services against the CSF, and it has no plans to create a conformity assessment program. RS.MA-05 is a Subcategory you address and can describe in your own terms, such as in a self-assessment or a Target Profile. If a customer or contract asks for proof, ask for an independent assessment report from an accredited assessor, or a certification under a different framework that maps to the same practice, such as ISO/IEC 27001. The organization owns its position on RS.MA-05, and only an independent auditor or certification body can issue a report or certificate that covers it.

What does it take to show RS.MA-05 is in place?

Effort depends on how mature your incident recovery process already is and how many systems fall under it. The work is mostly documentation and decision discipline: defining the criteria that start recovery, recording how they were applied during each incident, and showing that operational disruption from recovery was weighed. NIST publishes Implementation Examples for this Subcategory, and the NIST CSF 2.0 Reference Tool links it to SP 800-53 controls IR-4 and IR-8. Ask any implementation partner to size the work from a written scope that lists the systems, the incident types and the evidence you expect to produce.

How long does it take to put RS.MA-05 in place?

No researched duration is available for this Subcategory, so treat any timeline you hear as unverified until it is tied to a written scope. The main drivers are whether recovery criteria already exist in the incident response plan, how many environments and business units must agree on them, and whether the team has run recent exercises that show how recovery decisions were actually made. Ask for milestones such as criteria drafted, criteria tested in an exercise, and evidence records reviewed by the people who make recovery calls.

What does the internal team need to provide?

The internal team must own the decisions that RS.MA-05 covers. In practice, that means:

Named decision makers who can approve or defer recovery, with authority to accept operational disruption.
Business owners who can describe the operational impact of taking each system offline or restoring it.
Access to incident records, logs and tickets so that the criteria can be checked against real cases.

An implementation partner can prepare the workflow and the records, but it cannot make those calls for you.

Can an in-house security team meet RS.MA-05 alone?

Often yes, if the team already runs a documented incident response process and has access to the business owners who weigh disruption. The gap is usually not technical. It is in writing down recovery criteria, applying them consistently, and keeping records that show the reasoning. Teams without recent incident experience or without a clear way to reach operations leaders tend to need outside help. Outside help can be scoped in writing for specific parts, such as building the recovery workflow, configuring a case management platform, or preparing evidence for an assessor. Confirm the split of responsibilities before work starts.

How can open-source tools help show RS.MA-05 evidence?

A self-hosted case management platform can keep each incident as one record with its assets, tasks, evidence and audit trail, which makes it easier to show when recovery criteria were considered. For example, DFIR-IRIS, which is licensed under LGPL-3.0-or-later, can build a consolidated investigation timeline and generate reports from case data (illustrative: a team records its recovery decision as a task with a timestamp and a linked note on expected disruption). Check the platform's current capabilities and deployment requirements in its documentation before you rely on it for evidence.

Who pays for the work, and what should a quote include?

Costs fall into one-time work, such as drafting criteria, configuring tools and running an exercise, and recurring work, such as reviewing criteria after incidents and keeping records current. Costs rise with the number of systems, the number of decision makers and the number of incident types covered. No researched price applies to this Subcategory, so ask any provider for a quote that lists:

The systems and incident types in scope.
Deliverables, such as criteria, workflow and evidence templates.
Who performs each task and who must approve it.
Whether an independent assessor's fees are excluded.

How DeployOpen prepares RS.MA-05 evidence

DeployOpen plans, implements and documents self-hosted open-source incident tooling inside your own cloud accounts, data centers or air-gapped networks, and prepares the evidence an assessor will ask for when testing RS.MA-05. The work is fixed-scope: the systems in scope, the deliverables and the timelines are agreed in writing before any work starts, and a quote follows from that written scope. In practice this means configuring a case management platform such as DFIR-IRIS so that incident records hold the recovery decision points, the facts used to make each decision, the owner who approved it and the time it was approved, all within an audit trail that cannot be silently edited. Before you sign a scope, confirm which of your systems will feed that record and who in your organization will maintain the recovery criteria over time.

DeployOpen does not issue audit reports, attestations or certifications. Independent auditors, assessors and certification bodies do that work, and NIST itself does not offer certification of CSF implementations. Your organization owns its recovery initiation criteria, the threshold for accepting operational disruption, and every decision made under them. DeployOpen's role is to build the systems that record those decisions, prepare the procedures and sample records an assessor will review, and document what the configuration does and does not cover. Ask any provider to show you, in writing, which artifacts they will hand over and which judgments remain with your staff. You can read the Subcategory's informative references in the NIST CSF 2.0 Reference Tool export to check that the evidence list matches the controls your assessor uses.

RS.MA-05 Recovery initiation criteria