RC.CO-04 says public updates on incident recovery are shared using approved methods and messaging. For a small company this means one voice, one channel and wording that has been checked by the right people.
What good looks like
You know in advance who is allowed to publish, where updates appear (a status page, a customer email list, a blog post), and who approves the text. Updates explain what is being done to recover and to stop a repeat, without guessing at causes you have not confirmed. If personal data is involved, your breach notification procedure sets the timing and content for regulators and affected people.
How to implement it
- Name a communications owner and a legal reviewer, with deputies.
- Keep templates for a first notice, a progress update and a closing update.
- Set an update rhythm, for example every few hours while service is down.
- Check each statement against facts confirmed by the incident lead.
- Link to your breach notification procedure for data incidents.
Evidence to collect
- The communications plan and approved templates.
- Past public updates with approval trail.
- The breach notification procedure.
Common gaps
- Staff answer customers on social media off the cuff.
- Updates promise a restoration time that then slips.
- No legal review path at night or on weekends.
Quick check
Should an update name the root cause?
Only once it is confirmed. Say what you know, what you are doing and when the next update comes.
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-04, 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.
