RC.CO-04 Public recovery updates: requirements and evidence

What RC.CO-04 public recovery updates requires in plain terms

RC.CO-04 asks that public statements about incident recovery are shared through approved methods and messaging, so that what customers, regulators and the press read about a recovery matches what the organization has actually done and verified. In practice, the outcome is that someone is authorized to speak, the channels for speaking are defined in advance, and the content of each update is checked against the recovery record before it goes out. The subcategory also points to two specific topics NIST illustrates for this outcome: following breach notification procedures when recovering from a data breach, and explaining the recovery steps taken and the measures adopted to prevent a recurrence.

The risk it addresses is familiar to anyone who has run a public incident. A status page says service is restored while a subset of customers still cannot log in. A spokesperson states that no personal data was accessed before forensics has finished. A blog post describes a root cause that the engineering team later revises. Each contradiction damages trust, invites speculation, and can create legal exposure, particularly where a notification clock under a privacy or sector regulation is running. Late statements carry a similar cost, because silence is filled by the press and by social media before the organization has a verified account.

The difficulty is that legal, communications and engineering each hold part of the truth during an active incident and tend to work at different speeds. Engineering knows what is restored and what is still being validated, legal knows which notification duties apply and what admissions to avoid, and communications knows what audiences need to hear. Before the next incident, confirm who holds final approval for each type of public update, which channels are authorized (status page, website, email, regulator portal, press statement), and how a factual claim is traced back to a recovery record. Ask whether your breach notification procedure names the regulators and contract counterparties involved, and whether it has been rehearsed in a tabletop exercise that includes a recovery update.

Which public statements and teams RC.CO-04 covers in practice

RC.CO-04 only works if the organization decides, in advance, who counts as a public audience, which incidents trigger a public update, and who drafts and approves each message. The cards below cover the decisions an organization has to make and the third parties that touch the wording. Scope shifts with sector and jurisdiction, and the organization owns these decisions even when an implementation partner helps prepare the procedures.

Defining public audiences

Public updates reach several groups with different needs: customers, the general public, regulators, media and investors. Each group needs a distinct level of detail, and a statement written for customers may be wrong for a regulator or a listed company's market disclosure. Document which audiences receive a public statement, which channel reaches each one, and who signs off. Check whether contracts, sector rules or securities disclosure duties add audiences you would not otherwise list.

Setting public update triggers

Write down the conditions that move an incident from internal handling to a public update, such as confirmed personal data exposure, service outages customers notice, or a suspected intrusion that media has already reported. Triggers should reference the severity categories your incident response plan already uses under RS.MA. Review them after each exercise, since a trigger that waits for certainty can delay a legally required notice.

Assigning drafting and approval owners

Communications typically drafts, while legal checks liability and notification wording, privacy confirms personal data facts, and security leadership verifies technical accuracy and recovery status. Name one accountable approver for each message and set a fallback if that person is unavailable during an incident. Record who approved each statement, because the approval trail is often the evidence an assessor or regulator asks to see.

Controlling messages sent by third parties

PR agencies, breach notification vendors and status page hosts often publish or send text on the organization's behalf. Confirm which vendor can post without internal sign-off, how credentials for status pages are stored and rotated, and whether the vendor's templates match your approved wording. Include these parties in tabletop exercises so the first public message does not go out through an account nobody on the response team controls.

Adjusting scope to sector and jurisdiction

The same incident can require different public statements depending on where the organization operates and which regulator oversees it. Breach notification duties, timing and recipients vary by law and sector, so map the statements you must make against each jurisdiction in which you hold customer or patient data. Ask counsel to confirm which deadlines apply before you finalize the trigger list and templates.

How RC.CO-04 differs from RC.CO-03 and RS.CO

RC.CO-04 covers what the public hears about recovery, and it is the only one of the three Subcategories that addresses outside audiences directly. RC.CO-03 covers recovery progress shared with designated internal and external stakeholders, such as senior leadership and critical suppliers. RS.CO sits earlier in the incident lifecycle, in the RESPOND Function, and covers notifying stakeholders and sharing incident information while the event is still being handled. Each has its own audience and its own timing, so a program should keep three distinct message sets rather than reuse one incident statement for all of them. The practical test is who receives the message and whether that party is already expected to hear it through a defined channel.

Under RC.CO-04, the content an assessor will look for includes the breach notification procedure followed when recovering from a data breach, and an explanation of the recovery steps taken and the measures adopted to prevent a recurrence. Confirm that your breach notification procedure names the approver for public statements, the channels used (for example, a status page, a press statement or a regulator filing), and the legal review step. Then confirm that the public explanation of prevention measures matches what the internal recovery records actually show. A public statement that promises controls the team has not yet verified is a risk to plan for, not a completed outcome.

Organizations moving from CSF 1.1 need to find where older content now sits. According to NIST's transition changes spreadsheet, RC.CO-04 absorbs part or all of CSF 1.1 RS.CO-2, RC.CO-1 and RC.CO-2, so policies and procedures written against those identifiers should be remapped rather than assumed to carry over. NIST's Reference Tool also lists informative references for RC.CO-04, including ISO/IEC 27001:2022 clause 7.4, SP 800-53 Rev. 5.2.0 controls CP-2 and IR-4, SP 800-171 Rev. 3 requirement 03.06.01, and CIS Controls v8.1 Safeguards 17.2 and 17.6. These are NIST's published mappings, not proof that meeting one control satisfies another, so an assessor will still expect evidence written against each framework's own requirements.

How an assessor tests public recovery updates

This table compares what an assessor does, what evidence they ask for and where organizations usually fall short when testing RC.CO-04. NIST does not run a conformity assessment program, so the assessor is an internal reviewer, an independent auditor or a regulator, never the implementation partner who prepared the evidence. Use the rows as a pre-assessment checklist.

Test area	Evidence requested	Common findings
Defined channel and approval chain	Written procedure naming approved public channels, the approvers for each message type and the order of sign-off	Channels exist only in practice; approvers are named by role without deputies, or the chain was never tested in an incident
Sample of past public statements	Published statements, website notices and press responses, each traced back to the incident record and its timestamps	Statements contain facts that the incident record does not support, or contradict an earlier update without correction
Breach notification steps followed and dated	Notification decision log, regulator and individual notice copies, and the dates of each step against the legal deadline in force	Notices sent without a recorded decision, or dates that cannot be reconciled with the incident timeline
Prevention explanations match root cause	Public statement on prevention compared with the root cause analysis and the corrective action tracker	Public text promises controls that were not implemented, or describes a cause different from the internal analysis
Legal and communications review	Review records showing legal and communications sign-off for each external message, with version history	Reviews are informal or after publication, or the reviewer did not see the final wording
Consistency with recovery progress	Recovery status records and any stakeholder updates issued under RC.CO-03 compared with public messages	Public messages describe recovery as complete before restoration and verification records show otherwise

Building a public recovery update process that holds up under test

This sequence turns RC.CO-04 into a working process: who receives public updates, how messages are approved, when breach notices must go out, when recovery is declared, what prevention the public hears about, and proof that the process works under a tabletop exercise. Each step ends with an artifact an assessor can ask to see.

Define public audiences and approved channels
Start by listing who outside the organization needs recovery information: customers, patients or members, regulators, partners, the media and, where relevant, the public at large. For each audience, record the channels you will use, such as the corporate status page, email, regulator portals or press statements, and name who is allowed to publish on each. Confirm the list with legal, communications and the incident response lead. The output is an audience and channel register with a named owner for each channel. An assessor will check that every channel used during a past or simulated incident appears on it.
Write a pre-approved message structure
Draft reusable templates for the common public statements: initial acknowledgment, progress update, service restoration notice and final closure. Each template should separate facts that have been verified from facts still under investigation, and should avoid speculation about cause or attacker identity until analysis supports it. Define the approval roles, such as legal, communications, the chief information security officer and an executive sponsor, and state which roles must sign off before release. The output is a template library with an approval matrix, version-controlled and dated. Ask your counsel which statements carry legal exposure before you finalize the wording.
Map breach notification timing to legal clocks
Build a register of every notification obligation the organization owns, including contractual notices to customers, sector regulators and data protection authorities, and any notices to affected individuals. For each obligation, record the trigger, the responsible role, the deadline as stated in the governing law or contract, and the template that applies. Confirm each deadline against the current text of the relevant regulation with your legal team, because obligations differ by jurisdiction and sector. The output is a notification obligations register linked to the incident playbook. An assessor will test whether the register matches the obligations that apply to the organization.
Set update cadence and a recovery declaration rule
Agree in advance how often public updates are issued during an incident, and who decides when the cadence changes. Define the criteria for declaring recovery complete, such as restoration of affected services, verification of restored systems and closure of the incident in the response record, so that the declaration is tied to evidence and not to a feeling that the worst is over. Write these rules into the incident communication procedure and name the approver of the final declaration. The output is a written cadence rule and recovery declaration criteria. Confirm that the cadence fits your customer commitments and any service level terms you have already agreed.
Draft the prevention explanation from root cause analysis
Prepare the statement that explains the steps taken to prevent recurrence, and build it only from the findings of root cause analysis and the verified corrective actions. Each claim in the explanation should trace to a documented finding, a completed change or a control that has been tested. Avoid promises about future capability that the organization has not funded or scheduled. Legal and the technical lead should both review the wording against the investigation record. The output is a prevention statement with a traceability table linking each claim to its source record. An assessor will often compare the public statement with the internal analysis to confirm they agree.
Run a tabletop exercise and keep a dated record
Test the whole sequence with a tabletop exercise that uses a realistic but fictional scenario, such as a ransomware event affecting a customer-facing service. Participants should walk through audience identification, template selection, approvals, a notification decision and a recovery declaration, and should time the decision points in the exercise log. Record gaps, assign owners and due dates, and update the templates, register and rules to close them. The output is a dated exercise report with an action tracker and evidence of the revised documents. Assessors will ask for this record because it shows that the process was tested and improved, not only written. Independent assessors determine whether it satisfies the outcome, and DeployOpen can prepare the exercise design and records as part of a scoped engagement.

Evidence that shows RC.CO-04 is met and how to keep it current

An assessor testing RC.CO-04 looks for a clear procedure for public recovery updates and proof that the organization followed it during real incidents and exercises. The cards below name the artifacts to sample and the routines that keep each one accurate between assessments, so the evidence reflects current practice rather than a snapshot prepared for the review.

Approved public communication procedure

This is the document that sets who may speak publicly about incident recovery, which channels are used (website status page, customer notices, regulator filings, media statements) and the order of approvals. Check that it names an accountable owner, lists each channel and identifies the legal, communications and executive approvers by role. Record a review date and the last approval date on the document itself. Between audits, review it after every incident that used public channels and after any change to legal or contractual notice duties, so the assessor sees a procedure that matches what happened.

Log of published recovery statements

A running register of every public recovery update, with the publication timestamp, channel, approver and the incident identifier it relates to. An assessor samples this log to confirm that statements went out through approved methods and were not improvised. Link each statement to its incident record so the reader can trace the claim back to the underlying facts. Export and review the log monthly, and reconcile it against the status page history to catch statements posted outside the log.

Breach notification records

For incidents involving personal or regulated data, keep the records showing which notification steps were taken, when, to whom and under which obligation. These records show that breach notification procedures were followed during recovery, not only written down. Include the decision record explaining why notification was or was not required. Assign a named owner for each notification clock and review open items weekly until closure. Confirm the specific notification timelines with counsel for each jurisdiction and contract, since those obligations vary.

Approved message templates

Pre-approved templates for common recovery messages, such as service degradation, restoration in progress, restoration complete and data-related notices. Assessors check that templates exist, carry version numbers and were reviewed by legal and communications before use. Keep each template tied to its approval record and to the procedure version it belongs to. Review templates after each incident that required a deviation, and retire any template that no longer matches the systems or channels in use.

Post-incident prevention summaries

Public summaries that explain the recovery steps taken and the measures adopted to prevent recurrence. Each summary should trace back to the root cause analysis and the corrective actions tracked in the improvement process, so the claims in public can be checked internally. Confirm that every prevention claim has an owner and a completion record before publication. Between audits, verify that the corrective actions named in each summary are still open or closed as stated, and flag any summary whose commitments have lapsed.

Communication exercise records

Records from tabletop or live exercises that rehearse public recovery messaging, including the scenario, participants, timing of the first statement, approval delays and lessons logged. Assessors use these to judge whether the procedure works under time pressure. Track each exercise action to closure and update the procedure and templates when the exercise exposed a gap. Schedule exercises on a fixed calendar with a named facilitator, and keep the agenda and attendance sheet with the results.

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

This table lists each cost component of publishing recovery updates under RC.CO-04, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote, since no figures are published for these components. The main takeaway is that the largest recurring cost is usually reviewer time, not software.

Cost component	One-time or recurring	What drives it	How to keep it down
Staff time for drafting and approval	Recurring, per incident	Number of public channels, number of approvers, and how many drafts each update needs	Pre-approve message templates and define who can release each update type
Legal and privacy review	Recurring, per incident; one-time for template review	Whether personal data or regulated data is involved, and the number of jurisdictions named in the notice	Have counsel approve reusable wording for common incident types in advance
Communications tooling and status page hosting	Recurring license or hosting fee	Number of channels, subscriber volume and integrations with ticketing or identity systems	Compare self-hosted publishing tools against hosted licenses and confirm which features you need
Breach notification vendor fees	Recurring, only where a vendor is used	Number of affected individuals, mailing methods and call center needs	Ask the vendor for a written scope with unit basis and volume tiers before engaging
Tabletop exercise time	Recurring, usually annual or per major change	Number of participants, scenarios tested and whether public messaging is included	Run one scenario that covers public updates alongside other recovery roles
Evidence upkeep	Recurring, after each incident and each review cycle	Number of published updates, retention rules and how many sources must be linked to each claim	Store update history, approvals and timestamps in one place from the first incident
External review by counsel or an assessor	Recurring for assessments; per engagement for counsel	Assessment scope, regulator involvement and the number of public statements reviewed	Agree review scope in writing and send assessors a complete evidence set in advance
Implementation partner preparation	One-time setup, with optional retainer	Number of channels to configure, existing runbooks and template gaps	Fix the scope in writing before work starts and reuse templates across incidents

Who owns public recovery updates, who can help and where the auditor stops

Your organization owns RC.CO-04 in full. CSF 2.0 expects public updates on incident recovery to go through approved methods and messaging, and that approval starts inside your own leadership, legal and communications functions. No outside party can accept the legal exposure of a breach statement or decide how much recovery detail is safe to publish while an investigation is still open.

Approval chain: Name who drafts, who reviews, who approves and who may publish, and record the sequence before an incident occurs.
Final statement: The accountable executive signs off on the wording, the timing and the channels used, including the website, regulator filings and customer notices.
Legal judgment: Counsel decides breach notification obligations, privilege, wording that could affect litigation and what must be disclosed to regulators or individuals.
Recurrence explanation: Your technical leaders confirm the steps taken to prevent a recurrence before anything is said about them publicly.
Standing decisions: Your board or executive committee sets the risk appetite for disclosure and approves the procedure.

Confirm that your approval chain and legal review steps are written down and tested in an exercise, not just assumed.

Where public recovery updates usually fall short

Public recovery updates tend to fail in predictable ways: the wording runs ahead of the facts, nobody owns the decision to publish, and the statement drifts from what security actually found. The cards below name six gaps that undermine RC.CO-04 and one closing step for each, so the team can check its own process before an incident forces the question.

Statements published before facts are confirmed

Under pressure, teams publish a first update that describes scope, cause or data exposure before forensics has confirmed them. Later corrections then read as concealment, even when the original error was honest. Before any statement goes out, require that each factual claim is tied to a named source, such as the incident lead's confirmed finding, and mark anything unverified as unverified. Check whether your templates have a placeholder for "under investigation" wording so teams do not improvise it.

No named approver on weekends

Many incidents begin outside business hours, and the approval chain for public messaging often assumes that the general counsel, communications lead and CISO are all reachable. When none of them answers, either the update is delayed for hours or someone publishes without authority. Assign a named approver and a named alternate for every on-call rotation, and record both in the incident runbook. Test the chain with a tabletop exercise that runs over a weekend, so you learn whether the contact details actually work.

Breach notification steps held only by legal

Breach notification procedures are often documented in a legal memo or contract annex that operations staff have never opened. In a live incident, the security team does not know which regulator, customer or data subject must be told, in what window, or with what content. Convert the notification steps into a runbook that lists each audience, the trigger, the owner of the notice and the approved wording, and store it alongside the incident response plan. Ask counsel to confirm the notification triggers for each jurisdiction you serve.

Prevention explanations that miss the root cause

Public updates often promise that the organization has "strengthened our controls," without naming what changed or linking it to what failed. Readers, regulators and customers can tell when the explanation does not match the root cause analysis. Before publishing, have the incident analyst confirm that each preventive measure addresses a specific root cause, and drop any measure that is planned but not yet in place. Describe completed actions in the past tense and planned actions with dates that the team has committed to.

No record linking statements to tickets

When a regulator or customer asks why a sentence appeared in a public update, many teams cannot show which ticket, log entry or decision supported it. Without that trail, the organization cannot defend its wording or reconstruct the sequence of messages. Keep a communications log in the incident management system that records each published version, its approval, the time it went out and the ticket or finding that supports each claim. Confirm that the log can be exported with the rest of the incident record.

Communications and security using different facts

The communications team works from a summary written at one hour, while the security team updates the technical picture at the next. Within a day, the public statement, the internal briefing and the technical timeline describe different scope, dates or affected systems. Name one incident record as the single source of facts, and require that every public draft is checked against its current version before approval. Hold a short sync between the incident commander and the communications lead before each scheduled update.

Questions buyers ask about meeting RC.CO-04

How much effort does RC.CO-04 take to meet?

The effort depends mostly on how many audiences need public updates, how many approval steps sit between a draft and publication, and how much of the recovery story already exists in written form. Organizations with a tested incident response plan and a named spokesperson usually have less to build than those starting from nothing. Effort also recurs, because each real incident needs a new set of updates. Ask a partner to break the work into one-time items (approved channels, message templates, breach notification decision paths) and recurring items (drafting, review and publication during an event). A fixed-scope written proposal should show both lists separately.

How long does it take to put a public update process in place?

The duration depends on how quickly your leadership, communications and legal teams can agree on channels, approvers and wording, which is usually the slowest part of the work and rarely a technical one. Technical preparation, such as documenting where updates are published and how they are archived, is comparatively short once decisions are made. No fixed duration applies to every organization. Ask any partner for a timeline tied to the written scope, with dependencies on client reviews marked explicitly so that delays on either side are visible.

What does RC.CO-04 need from our communications and legal teams?

RC.CO-04 depends on decisions that sit outside the security team. Communications owns tone, channels and the approved wording of public statements. Legal decides what can be said about personal data, regulator notifications and potential liability, and it should review breach notification procedures before they are needed. Executive leadership should confirm who may approve a public statement during an incident. Without those decisions written down, public updates tend to be delayed or inconsistent. Your organization owns these decisions, and any implementation partner can only document and test the process you approve.

Can a small team meet RC.CO-04 in-house?

A small team can often meet RC.CO-04 in-house if it has a named incident lead, a designated spokesperson, a legal contact who can respond quickly, and a plan that covers breach notification. The harder part for small teams is capacity during an event, when the same few people handle containment, recovery and communication at once. Test that assumption by running a tabletop exercise that includes drafting and approving a public update. If the exercise exposes gaps, an outside partner can help prepare templates, runbooks and evidence, but the organization still performs the communications.

Does NIST certify that we meet RC.CO-04?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. Any claim of compliance with RC.CO-04 is therefore a statement your organization makes, supported by evidence. If a customer or regulator asks for independent confirmation, that comes from an assessor or auditor engaged under its own terms, not from NIST. Be cautious with any vendor or consultant who presents NIST certification as available.

Who signs off on the evidence that RC.CO-04 is met?

Your organization signs off on its own controls and evidence, and it is accountable for accuracy. An implementation partner prepares systems, procedures and records, but does not issue reports or attestations. Where an independent view is required, a qualified assessor or auditor reviews the evidence and issues the outcome under its own engagement. Useful evidence includes approved message templates, the approval record for a past public update, breach notification decision logs, and post-incident notes explaining steps taken to prevent recurrence. Confirm with your assessor which artifacts they expect before work begins.

What should we ask a partner for in a fixed-scope quote?

Ask for a written scope that names each deliverable, the systems and channels in scope, and the roles you must provide. The quote should separate one-time work, such as approved channels, templates and runbooks, from recurring work, such as retainer support or testing. It should list client dependencies, including review turnaround and legal sign-off, and state what is excluded, such as drafting statements during a live incident unless that service is contracted. Ask how evidence will be delivered and who owns it after the engagement. Most DeployOpen engagements are fixed-scope, and a quote follows from that written scope.

How DeployOpen prepares recovery communication evidence

DeployOpen helps organizations prepare the systems, records and written procedures that show how public recovery updates are approved, sent and reviewed for RC.CO-04. The organization owns its communication decisions and its outward messages, while DeployOpen works on the self-hosted platforms and documentation behind them.

How we scope

The written scope names which public channels, approval roles and message types the engagement covers for RC.CO-04.
Scope also records which breach notification procedures and regulator timelines the organization must follow, confirmed by its own legal and compliance teams.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure self-hosted platforms in your own infrastructure to hold approved message templates, approval workflows and recovery status records.
We set up access controls so only designated spokespeople and approvers can publish or change public recovery updates.
We test the workflow with tabletop exercises that walk a sample recovery update through review, approval and publication, labeled as illustrative.

How we hand over

We document the approval chain, channel list, message templates and the steps taken to explain prevention measures after recovery.
We deliver evidence packs that map records, such as approval logs and published update archives, to RC.CO-04 for your assessors.
We walk your communications, legal and security staff through the runbook so they can operate it without DeployOpen present.

How we support

Ongoing support, upgrades and continuous testing of the communication workflow are available as retainers.
We can refresh templates and runbooks when breach notification rules, regulators or your public channels change.
Confirm with your auditor which evidence they will accept, since only an independent auditor or certification body issues reports or certificates.