RC.CO-03 says recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders. Different from public statements, this is about the people who need to know how the restoration is going: leadership, customers who are directly affected, suppliers, insurers and regulators.
What good looks like
You decided in advance who needs recovery updates, how often, and by what channel. Senior leaders get a regular short status for major incidents. Information is shared securely, consistent with response plans and any information sharing agreements. Contracts with suppliers say what each side must tell the other, and for critical suppliers there is a way to coordinate crisis communication.
How to implement it
- Build a stakeholder table: who, what they need, how often, who sends it, which channel.
- Use a fixed status format: what is restored, what is not, next step, expected time, open risks.
- Share sensitive details only over channels you trust. Do not assume your normal email is safe if the incident touched it.
- Review customer and supplier contracts for notification duties and put the deadlines in the plan.
- Hold an agreed bridge call with critical suppliers during major incidents.
- Log each update sent.
Evidence to collect
- The stakeholder table and communication plan.
- Copies of updates sent during past incidents or exercises.
- Contract clauses on incident information sharing.
- Supplier contact and escalation lists.
Common gaps
- Leadership asks for status ad hoc and responders keep stopping work to answer.
- Customers hear about recovery from a status page that is out of date.
- Supplier contract duties were never put into the plan.
- The incident touched email, and updates still go out over it.
A worked example
A ransomware event takes down the order system on a Tuesday evening. By Wednesday morning the stakeholder table is in use. The CEO receives a three line status at fixed times: what is restored, what is not, and the next decision needed. The head of customer support gets a separate version with wording suitable for affected customers, including an expected time that is labeled as an estimate.
The company's payment processor and its hosting provider are both critical suppliers. The hosting provider's contract names a security contact and a bridge number, so the incident lead opens a call there each morning until restoration is complete. The insurer, whose policy requires prompt notice and approval for certain spend, is updated by the finance lead.
Because the incident affected email, status updates go out over a messaging platform that was not touched, to a distribution list agreed beforehand. Each update is pasted into the incident ticket, so the record of what was told to whom is complete.
When restoration finishes, a closing update confirms what was restored and when, and states what will follow.
How to start this week
- Draft the stakeholder table with columns for who, what they need, how often, sender and channel. Fill in at least leadership, support, legal, insurer and your top three suppliers.
- Choose a backup channel that does not depend on your main email and tell the people who would need it.
- Read the notification clauses in your top supplier contracts. Add any deadlines to the plan.
- Write a status template with five fixed lines and store it with the plan.
Questions auditors and customers ask
- Who gets told about recovery progress, and how often? Show the table and past updates.
- How do you share sensitive recovery details safely? Show the channel choice and its rationale.
- What do your suppliers owe you in an incident, and you them? Show contract clauses and contact lists.
Quick check
How is this different from RC.CO-04?
RC.CO-03 covers designated stakeholders such as leaders, affected customers and suppliers. RC.CO-04 covers public updates using approved methods and wording.
How often should leaders get an update?
Agree it before an incident. Many teams use a fixed rhythm for major incidents, with an extra message when something significant changes.
Sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- NIST CSF 2.0 implementation examples for RC.CO-03, as listed in the CSF 2.0 Reference Tool: https://www.nist.gov/cyberframework
CSF is voluntary guidance. There is no CSF certification, so use it to organize and show your own work.
