RC.RP-04 Post-incident operational norms: requirements and evidence

What RC.RP-04 asks for when you restore after an incident

When a recovery is underway, leaders need two answers quickly: which services come back first, and what normal looks like again. RC.RP-04 asks that post-incident operating norms be set around critical mission functions and cybersecurity risk management, so that the order of restoration and the conditions for running restored systems reflect what the business needs most. RC.RP-04 is a Subcategory of the Incident Recovery Plan Execution Category in the RECOVER Function of CSF 2.0, and NIST flags it as new in CSF 2.0, so organizations coming from CSF 1.1 have no existing line item to point to. It is easy to confuse with its neighbors. RC.RP-02 covers selecting and performing recovery actions as needs are reassessed. RC.RP-05 covers verifying that restored assets are intact and that root causes were fixed. RC.RP-04 sits upstream of both: it decides what the sequence and the operating baseline should be.

The hard part is the input. NIST's Implementation Examples point to business impact and system categorization records, including service delivery objectives, as the basis for restoring essential services in the right order. In many organizations those records are stale, incomplete, or missing objectives for the systems that matter most, and the people who know the real dependencies may not be the people who wrote the documents. Before an incident, confirm that each critical mission function maps to named systems, that recovery time and service delivery objectives are documented and approved by the system owner, and that dependencies such as identity, DNS, and databases are visible. Ask who signs off the restoration order during an incident and how that sign-off is recorded.

After services return, RC.RP-04 also expects monitoring of restored systems against the agreed norms. NIST's examples describe confirming restoration with system owners and watching the performance of restored systems. Decide in advance which metrics define normal for each critical service and where they are collected. Open-source tools such as Prometheus, which collects metrics over HTTP and stores them as time series, and Grafana Alerting, which builds alert rules across data sources, can hold that baseline if they are configured before the incident. Confirm with your own team which dashboards and alert thresholds will be used, and who acts on them.

Which systems, teams and third parties fall under RC.RP-04

RC.RP-04 is only as good as the scope behind it. The cards below cover the decisions that determine which mission functions, systems, owners and external providers must be reflected in post-incident operating norms, and what to confirm for each before restoration starts.

Critical mission functions

Start by deciding which business functions count as critical enough to set norms around. Use the organization's mission statement, service commitments and regulatory obligations rather than IT ownership to draw the list. For each function, record the acceptable downtime, the minimum service level during recovery and the people who can accept a degraded state. Without this list, the order of restoration has no agreed basis, and the norms cannot be tested. Confirm the list with executives before an incident, not during one.

Supporting systems and data stores

Map each critical function to the applications, identity services, networks, databases and file stores it depends on. Include the dependencies people forget, such as DNS, certificate authorities, time sources and message queues. Use the business impact and system categorization records as the starting point and check that they reflect current architecture. Each dependency that appears on a path to a critical function becomes a restoration step that must be sequenced and verified.

Business and system owners

Name the business owner who accepts that a service is operating normally and the system owner who can confirm its technical state. RC.RP-04 expects restoration to be confirmed with these people, so the norms need named individuals, backups for each role and a contact route that works when corporate systems are down. Record who may sign off a restored service and who may accept residual risk while work continues.

Cloud, managed service and SaaS providers

Identify every external provider that holds a restore responsibility, including cloud platforms, managed service providers and SaaS vendors. For each, document what the provider restores, what the organization restores and what the contract guarantees. Confirm the provider's recovery timelines, support escalation path and any limits on restoring customer data. Post-incident norms must reflect these dependencies because a provider's queue can set the restoration order for the whole organization.

Legal, regulatory and contractual constraints

Some restoration sequences are shaped by obligations rather than operations. Contracts may promise service levels to customers, and sector rules may require certain services to be restored first or within a set window. Review these obligations with legal and compliance before an incident and record which norms they override. Where a rule's exact requirements are unclear to your team, confirm them with counsel or the regulator rather than assuming.

Monitoring of restored systems

Restored systems need a defined monitoring baseline so the team can tell normal behavior from residual compromise or fault. Decide which metrics and logs must be watched for each critical function, which alert thresholds apply and who receives the alerts. Tools such as Prometheus, which collects metrics over HTTP and stores them as time series, and Grafana Alerting, which builds alert rules across multiple data sources, can support this if they are deployed and tested in advance. Confirm that monitoring itself is restored early in the sequence.

How business impact records set the restore order

The restore order for RC.RP-04 should come from business impact and system categorization records, not from whoever is loudest during the incident. NIST's Implementation Examples for this Subcategory point to records that show which systems support essential services and what service delivery objectives apply to each. Those records tell the recovery team which service comes back first, which depends on it, and which can wait. Before the next incident, confirm that each critical mission function maps to named systems, that the categorization for each system is current, and that the delivery objectives are written in a form a recovery lead can read at 2 a.m. The Implementation Examples describe this use of the records, but the content of your records is yours to define and your auditor will test whether they match how you actually operate.

Once a system is restored, the Implementation Examples call for confirming the restoration with the system owner before the system is treated as back in service. This step is easy to skip under pressure, and it matters because the owner knows which configurations, data sets and integrations the service depends on. Build the sign-off into the recovery runbook as a named decision with a named approver, and record who confirmed what and when. Separate that decision from the technical checks that belong to RC.RP-05, so the reader can see that the business owner accepted the service, not only that the infrastructure responded.

Monitoring is the third link. The Implementation Examples expect the performance of restored systems to be watched after they return, so that degraded behavior is caught before it becomes a second incident. In practice, this means defining baseline metrics and alert thresholds for each restored service ahead of time and knowing which dashboards and alert rules the operations team will use. Open-source tools such as Prometheus and Grafana can hold those baselines and alerts, but the organization must decide what counts as normal for each service. Write the restore order, the owner sign-off and the monitoring thresholds into the plan now, and test them in an exercise, because a norm that exists only in someone's memory will not hold during an incident.

How an assessor tests post-incident operational norms

This table compares what an assessor does, what evidence they request and where RC.RP-04 most often fails. Read it as a test plan: each row is a check the organization should be able to pass before an assessment begins. The main takeaway is that a written norm alone is weak evidence unless it is traced to business impact records, applied in past events and confirmed by system owners.

Test area	What the assessor checks	Evidence they request	Common finding
Documented norms	Whether written norms exist for restoring critical mission functions after an incident, and who approved them	Current post-incident operating norms, approval record, review date	Norms predate current service priorities and were never re-reviewed
Link to business impact	Whether restore order traces to business impact and system categorization records, including service delivery objectives	Business impact analysis, system categorization records, mapping from each essential service to its restore position	Norms cite a service tier that no longer matches the business impact records
Past incidents and exercises	Whether actual restore sequences in past incidents or exercises followed the documented norms, or the team documented a reason for deviating	Incident or exercise timelines, restore logs, deviation notes approved by leadership	No sampled event shows the norm was applied, and deviations are not recorded
System owner confirmation	Whether system owners confirmed that each restored essential service was ready for use	Signed or recorded owner confirmations tied to specific restored systems and dates	Restoration is marked complete by the responder team with no owner sign-off on file
Monitoring of restored systems	Whether performance of restored systems is watched against expected behavior after return to service	Monitoring dashboards or alert rules, alert history, handover notes to operations	Monitoring covers pre-incident systems only, or alerts were never configured for restored services
Post-incident review of norms	Whether lessons from incidents feed back into updated norms and business impact records	Post-incident review records, revision history of the norms, related improvement actions	Lessons are captured in after-action reports but the norms are not updated
Organization's own sampling	Whether the organization tests the norms before an assessor does, using a sample of systems and recent events	Internal test plan, sample list, results with corrective actions	Testing is limited to tabletop discussion with no evidence from real or simulated restores

Implementing RC.RP-04 in sequence

This sequence turns the RC.RP-04 outcome into written, tested norms: which critical functions come back first, which systems support them, who confirms restoration, and how restored systems are watched afterward.

Confirm critical mission functions from business impact records
Start from the business impact analysis and any system categorization records the organization already keeps. Business owners, with the incident response lead, list the mission functions that must keep running or return first, such as payments, patient care, dispatch or customer authentication. The output is a short, signed list of critical functions with the business owner named for each. The step is done when every function has an owner who agrees it is critical and the list has been reviewed against the current business impact analysis, not an older copy.
Map service delivery objectives and dependencies to systems
For each critical function, trace the systems, data stores, identity services, network paths and third-party services it depends on. Record the service delivery objectives stated in the business impact records next to each dependency, so that the restore order reflects what the business needs rather than what is easiest to rebuild. Platform engineering and application owners do this work, and the output is a dependency map per function. The step is complete when each dependency has a named system owner and no critical function relies on a system that is missing from the map.
Write the restore-order norms and approval path
Using the dependency map, write the order in which essential services are restored, with the reasoning for each position, such as identity and core networking before the applications that rely on them. Define who may change the order during an incident, who approves a restore that departs from it, and how that decision is recorded. The output is a short norms document that sits alongside the recovery plan. The step is done when incident responders, system owners and the executive decision maker have each confirmed in writing that they understand the order and the approval path.
Define owner confirmation for restored systems
Specify what each system owner must check and confirm before a restored system is treated as back in service for its function. Checks usually cover functional behavior, data currency against the restore point, access settings and dependencies that were restarted. The owner's confirmation should be recorded with a timestamp and the person who gave it. The output is a confirmation checklist per critical system and a log template. The step is complete when every restored critical system has a defined owner sign-off that the response team can cite later, and the sign-off is separate from the technical verification handled under RC.RP-05.
Set monitoring baselines for restored systems
Before any restore, capture the normal performance and behavior of each critical system so that post-restore deviations can be recognized. Baselines typically cover request volumes, error rates, latency, resource use and authentication failures. In a self-hosted environment, a metrics collector such as Prometheus can gather these signals and Grafana Alerting can route threshold alerts to the owners named in the norms. The output is a baseline record and an alert set for each critical function. The step is done when alerts fire in a test, the owners receive them, and the thresholds have been reviewed by the people who run the service.
Rehearse the norms in an exercise
Run a tabletop or technical exercise that walks the team through a realistic recovery scenario using the restore order, approval path, owner confirmations and alerts. Exercise facilitators record where the norms were unclear, where a dependency was missing from the map, and where an approval took longer than the process assumed. The output is an exercise report with a list of corrections to the business impact records, dependency map, norms and alerts, each assigned to an owner. The step is complete when the corrections are tracked to closure and the norms document carries the revision date and the approver's name.

Evidence that shows RC.RP-04 is met

RC.RP-04 is met when post-incident norms are set from business impact and system records, restoration follows that order, and system owners and monitoring confirm the restored services. The cards below cover the artifacts that prove each link, and the review habits that keep them current between assessments.

Approved post-incident operational norms

This is the written set of norms that defines how essential services return after an incident, including which critical mission functions take priority and how cybersecurity risk is considered before normal operations resume. Check that it names an approver, a version, and an owner, and that it references the business impact and system categorization records it draws on. Review it on a fixed date and after every incident or exercise that exposes a gap, recording each change in a revision log.

Business impact and system categorization records

These records show which functions the organization considers critical and how each system was categorized, which is the basis for deciding restoration order. An assessor will trace a restored service back to a documented impact rating. Confirm that the records include service delivery objectives for each critical function, and that the owners named in them still exist. Tie each update to a dated review and to changes in the asset inventory.

Service delivery objectives per critical function

Service delivery objectives state the level and timing of service the business needs after disruption, and they set the order in which systems return. Keep them in a form that can be compared against actual restoration times from incidents or exercises. Where an objective has not been tested, record that gap and the plan to close it. Ask leadership to approve changes, because these objectives affect priorities across teams.

Restoration sequence records from incidents and exercises

Restoration sequence records show the order in which systems were actually brought back, who decided it, and how long each step took. Exercise records count as evidence when they test the norms rather than only the technical steps. Compare each record with the norms and the objectives, and note deviations with reasons. Keep the records for the period the assessor will sample, and link each one to the exercise or incident ticket it came from.

System owner confirmations

A system owner confirmation is a dated, signed record that the owner of a restored system agrees it is back in service and performing to the agreed level. It prevents the recovery team from declaring a service restored when only its infrastructure responds. Keep a standard template with fields for the system, the objective it meets, the time of confirmation, and any open issues. Collect confirmations for each restoration in tests and real events, and confirm that owners still hold their roles.

Monitoring dashboards and alert history for restored systems

Dashboards and alert history show whether restored systems behaved normally after return, which is the monitoring part of the outcome. Grafana Alerting can combine metrics and logs in alert rules, and Prometheus stores metrics as time series that can be queried with PromQL, so the history can be retained and reviewed. Confirm that the dashboards cover each restored service, that alert rules still point at the right data sources, and that retention covers the period an assessor will sample.

What meeting RC.RP-04 costs in money and effort

This table breaks down the cost components of meeting RC.RP-04 and marks which ones are paid once and which recur. Use it to structure a request for a written scope quote, since no fee or duration figures are supplied for this Subcategory. The main takeaway is that most of the cost sits in business impact and dependency work, and tooling spend can shrink when monitoring is self-hosted.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up or down
Business impact analysis for critical functions	Internal business owners, risk staff and any consultant facilitating workshops	One-time, then refreshed when services change	Number of critical mission functions and how many business owners must agree on priority
Mapping service dependencies and system categorization	Platform engineers and architects, sometimes an implementation partner	One-time baseline, recurring updates	System complexity, number of shared services and how current the asset inventory already is
Defining service delivery objectives	Business owners with engineering input	One-time, reviewed periodically	Number of restore-order decisions and the tolerance each owner accepts for downtime
Monitoring tooling and licenses	Commercial monitoring vendors charge licenses, while self-hosted open-source stacks such as Prometheus and Grafana carry no license fee	Commercial licenses recur; self-hosted tools carry hosting and staff time	Data volume, number of monitored systems and whether alerts must span metrics and logs
Monitoring configuration and alert rules	Internal platform or SRE staff, or a partner building dashboards	One-time build, recurring tuning	Number of restored systems to watch and how often alert noise needs adjustment
Exercise time and tabletop testing	Recovery team members, system owners and facilitators	Recurring, usually on a set schedule	Number of critical functions included and whether exercises cover restored-system monitoring
Evidence upkeep	Compliance leads and system owners collecting dashboards, runbooks and restore sign-offs	Recurring	How many frameworks reuse the same evidence and whether collection is automated
External review and auditor sampling	Independent auditors or assessors, who test and report; the organization pays their fees	Recurring at each assessment cycle	Sample sizes the assessor selects and how well evidence is already organized before fieldwork

Open-source monitoring that supports restored-system checks

Once essential services are back, someone has to show that they are performing as expected. The tools below can produce monitoring evidence for restored systems, but the norms, the restore order and the sign-off still come from the organization's own recovery plan and business impact records.

Prometheus metric collection

Prometheus collects metrics from instrumented jobs by pulling them over HTTP on a schedule, then stores them as time series identified by metric name and labels. For RC.RP-04, the useful question is whether each restored service exposes the metrics that the organization agreed to watch, such as request latency, error rates and queue depth. Confirm that exporters are deployed on rebuilt hosts and that scrape targets were not lost in the rebuild.

Pull-based scraping and target health

Because Prometheus pulls data from targets, a restored system that is not being scraped can look quiet rather than failed. Check the target status view after each restoration and treat a missing target as an open item for the system owner. Keep the list of expected targets in version control so it can be compared against what is actually being scraped during recovery.

PromQL queries for restoration baselines

PromQL is the query language used to compare current metrics with a baseline. Teams can write queries that show whether a restored service has returned to the performance range recorded in its service delivery objectives. Store the queries alongside the recovery runbook so that the same checks are repeated for every restored system and the results can be attached to the verification record.

Grafana Alerting across metrics and logs

Grafana Alerting builds rules from queries and expressions across multiple data sources and can alert on metrics and logs together. This lets a team write one rule that flags a restored service when its error metrics rise and its logs show a related failure. Confirm which data sources are connected during recovery, who receives alerts, and that alert routing still works after the recovery environment changes.

Single view for recovery monitoring

Grafana lets teams create, manage and act on alerts from a single view. During recovery this gives incident staff and system owners one place to see restored services and their alert state, rather than several consoles. Decide in advance who may silence or acknowledge alerts, and record those actions, because they become part of the evidence that restored systems were monitored.

License terms to review before adoption

Prometheus is licensed under Apache-2.0. Grafana is licensed under AGPL-3.0-only, which carries source-availability obligations if the software is modified and offered to users over a network. Legal or procurement teams should confirm how these terms apply to the planned deployment and any custom changes before the platforms are placed in production.

Who owns norms, who helps build them and who assesses them

Your organization owns the post-incident operating norms. Leadership and the business owners of critical mission functions decide which services must return first, what normal performance looks like for each restored system, and who signs off that a system is back in service. CSF 2.0 frames RC.RP-04 around critical mission functions and cybersecurity risk management, so these decisions cannot be delegated to a vendor or left to whoever is on call.

Essential service order: Business owners confirm the restoration sequence drawn from business impact and system categorization records, including service delivery objectives.
Normal operating thresholds: Owners define what healthy performance means for each restored system so monitoring has a baseline to compare against.
Sign-off authority: Named system owners confirm restoration in writing before a service is treated as recovered.
Exception handling: The norms state who may accept degraded operation, for how long, and what compensating controls apply.
Ownership of changes: A named role maintains the norms after each incident and exercise.

Before relying on the norms, check that each critical service has a current business owner and that the sign-off roles appear in your incident recovery plan.

Where RC.RP-04 programs usually fall short

RC.RP-04 asks that restoration follow business priorities, not whoever shouts loudest. The gaps below tend to appear together: stale impact records feed undefined targets, which feed norms nobody has tested. Each card pairs one gap with the action that closes it.

Business impact records out of date

The Implementation Examples for RC.RP-04 point to business impact and system categorization records as the basis for restoring services in the right order. When those records predate a platform migration or a new business line, the restore sequence reflects an organization that no longer exists. Check that each record names current owners, dependencies and the systems that now carry each function, and set a review date tied to change management so the records are refreshed when systems change.

Service delivery objectives undefined

Restoring in order requires a stated recovery target for each essential service, often expressed as the service delivery objective. Many programs rank systems by intuition and never write down how long a service may be unavailable. Agree targets with the business owner of each critical mission function, record them beside the system inventory, and confirm that the recovery team can read them during an incident without opening a separate document.

Norms written but never exercised

A document describing post-incident operating norms gives little assurance until a team has used it under pressure. Programs often store the norms in a policy folder and never test whether engineers can apply them. Run a tabletop or technical exercise that restores two or three essential services in the documented order, and record where the sequence broke. Feed the findings into the improvement cycle described under the Improvement Category.

No owner confirmation step

The third Implementation Example for RC.RP-04 calls for confirming restoration with system owners. Without a named confirmation step, a responder may declare a service back while the business owner still sees errors in its own workflow. Add a sign-off line for each restored service that names the owner, the test performed and the time of confirmation, and keep those records with the incident file so they can be produced to an assessor.

Monitoring baselines absent for restored systems

The monitoring Implementation Example for RC.RP-04 asks teams to watch restored systems for performance. If no baseline exists for latency, error rates or resource use, a degraded system looks normal. Before restoring, capture pre-incident metrics for each critical service and build alert rules that compare restored behavior against them. Open-source options such as Prometheus for metric collection and Grafana Alerting for rules and notifications can hold these baselines, provided the team confirms each rule works against live data.

Questions buyers ask about RC.RP-04

What drives the cost of meeting RC.RP-04?

The cost depends on how much of the restoration order is already documented and how many critical mission functions the organization runs. Organizations pay for three kinds of work: internal staff time from operations, application and business owners who confirm which services come back first; engineering time to build or tune the monitoring of restored systems; and, if they choose, outside help to prepare the order of restoration and the evidence. Costs rise with the number of systems, the number of service delivery objectives that must be documented, and the number of teams that sign off on restoration. Most of the work is one-time (documenting the order and building dashboards), while monitoring and periodic review recur. Ask any quote to split these items, name who performs each one, and state which records are assumed to exist already.

How long does it take to put RC.RP-04 in place?

No NIST source supplied for this page gives a duration, so the time needed depends on your environment and should be confirmed in writing. The main variables are the state of your business impact records and system categorization records, the number of critical services involved, and how quickly system owners can confirm restoration order. An organization with current records usually needs less time than one that must build them first. Ask any implementation partner to list the milestones in the written scope, including who must approve the restoration order and when monitoring goes live for each restored system.

What does RC.RP-04 require from our internal staff?

RC.RP-04 depends on people who own business services and systems more than on specialist tools. Internal staff need to provide the business impact records and system categorization records that show which functions matter most, along with the service delivery objectives that set how fast each service must return. System owners need to confirm that a restored system is ready for use, and operations staff need to watch restored systems after they return. Leadership must agree on the restoration order before an incident, because it is hard to settle during one. Name these owners in the written scope so that no restoration step waits on an unassigned role.

Can a small team handle RC.RP-04 alone?

A small team can cover RC.RP-04 if its services are few and its records are current, but it should assume that the work is shared across roles rather than given to one person. The team must still document the restoration order, confirm it with system owners, and watch restored systems for performance. A useful test is whether one person can name every critical service, its recovery target and its owner from a single document. If not, bring in outside help for the documentation and monitoring setup, while the organization keeps ownership of the decisions. Any partner can prepare the systems and evidence, but only the organization owns its controls.

How does RC.RP-04 map to ISO/IEC 27001:2022 clause 8.1?

The NIST CSF 2.0 Reference Tool lists ISO/IEC 27001:2022 clause 8.1 as the informative reference for RC.RP-04. Clause 8.1 concerns operational planning and control, meaning the processes an organization runs to meet its security requirements. In practice, a restoration order documented under RC.RP-04 can serve as operational evidence for that clause, but the mapping is a reference provided by NIST, not a finding of conformity. Confirm the clause text and its scope with the standard itself and with your certification body if you are pursuing ISO/IEC 27001:2022, because the intent of a reference and the requirements of an audit can differ.

How do SP 800-53 PM-8 and IR-8 relate to RC.RP-04?

The NIST CSF 2.0 Reference Tool lists SP 800-53 Rev. 5.2.0 controls PM-8, PM-9, PM-11, IR-1 and IR-8 as informative references for RC.RP-04. PM-8 concerns the critical infrastructure plan, PM-9 the risk management strategy, PM-11 mission and business process definition, IR-1 incident response policy and procedures, and IR-8 the incident response plan. Read these as pointers to where the same topic is covered in more detail, not as a checklist. Confirm the current control text and any baseline that applies to you directly in SP 800-53, because a federal or contractual baseline may require more than a reference implies.

Why doesn't NIST certify organizations against the CSF?

NIST does not certify organizations against the Cybersecurity Framework. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. NIST is also not a regulatory agency, and most organizations use the CSF voluntarily. For RC.RP-04, this means no body issues a NIST certificate for restoration order. Evidence is judged by your customers, regulators or an independent assessor against the requirements they set. Any firm that says it can certify you against the CSF is making a claim NIST does not support, so ask for the assessor's own credentials and the scope of its report.

What evidence shows that RC.RP-04 is working?

Evidence should show that your restoration order was agreed before an incident, that it was confirmed with system owners during a real or exercised recovery, and that restored systems were monitored afterward. Useful artifacts include the business impact and categorization records, the approved restoration order, sign-off records from system owners, and dashboards or alert history from monitoring tools. Open-source platforms such as Prometheus, which collects metrics over HTTP and stores them as time series, and Grafana Alerting, which builds alert rules across multiple data sources, can hold this monitoring evidence inside your own infrastructure. Confirm with your assessor which retention period and format they will accept.

Where to read the RC.RP-04 text and mappings

To read the exact wording of RC.RP-04, start with Appendix A of *The NIST Cybersecurity Framework (CSF) 2.0* (NIST CSWP 29), which contains the CSF Core. The Subcategory outcome is short, so read it alongside the Category it sits in, RC.RP (Incident Recovery Plan Execution), and its neighbors RC.RP-03 and RC.RP-05. Before you write a policy clause or a control narrative, copy the Subcategory identifier and outcome into your own tracker so that every later mapping points to the same text. Confirm the version you cite as CSF 2.0 and the February 2024 publication date, because the older Version 1.1 uses a different structure and does not contain RC.RP-04 in the same form. The NIST CSWP 29 PDF is the document an assessor will expect you to quote.

The three Implementation Examples for RC.RP-04 are not in the PDF. They are published in the NIST CSF 2.0 Reference Tool export, which also carries the informative references to SP 800-53 Rev. 5.2.0, SP 800-171 Rev. 3 and ISO/IEC 27001:2022. Download the export and filter on RC.RP-04 to read the examples on business impact records, confirming restoration with system owners and monitoring restored systems. Treat the examples as illustrations of how the outcome can be met, not as a checklist that the organization must pass. Because NIST updates these online resources more often than the framework document, record the download date next to any mapping you rely on. Ask your auditor or customer which version of the mappings they will accept before you build evidence around them, and confirm any mapping that matters to a contract with the source spreadsheet.

How DeployOpen prepares RC.RP-04 evidence

DeployOpen works on RC.RP-04 by helping the organization turn its business impact records and restoration order into operating norms it can show an assessor. We prepare the systems, monitoring and evidence inside your own infrastructure, while the organization owns its controls and independent assessors issue any reports.

How we scope

Engagements are fixed-scope, with the RC.RP-04 deliverables and systems named in writing before work starts.
We confirm which business impact and system categorization records exist and who owns each critical mission function.
The written scope lists the restored systems and services whose performance monitoring is in scope for the engagement.

How we build

We configure self-hosted monitoring so restored systems report performance against their defined service delivery objectives.
Alert rules are built from metrics and logs across data sources, so degradation after restore appears in one place.
We set up dashboards that show restoration sequence and status for each essential service, using your own recovery order.

How we hand over

We document the restoration order, owner sign-off steps and monitoring thresholds as written operating norms.
Handover includes configuration records and runbooks so your staff can run and adjust the monitoring themselves.
Evidence packs show what was configured, tested and confirmed with system owners, ready for an independent assessor to review.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can review alert rules and restoration norms when business impact records or critical functions change.
Confirm with your assessor which evidence format and retention period they expect before the engagement begins.