NIST CSF 2.0 RS.CO-03: Share Incident Information

RS.CO-03 says information is shared with designated internal and external stakeholders. It differs from notification: it covers the ongoing flow of facts during and after an incident to people who need them, such as leadership, HR, suppliers, customers and information sharing communities. The point is controlled sharing, not secrecy and not oversharing. There is no CSF certification, so you show this with your plan and records.

What good looks like

You have a list of designated recipients and what each may receive. Updates go to senior leadership on a fixed rhythm during major incidents. Contracts with suppliers define how incident information is exchanged. Sensitive details are removed before sharing outside the company. HR is told when a malicious insider is involved, and legal reviews what goes out.

How to implement it

• Create a stakeholder table: who, what they need, how often, through which secure channel.
• Set an update cadence for major incidents, for example every few hours at first, then daily, with a standard format: status, impact, next steps, decisions needed.
• Use a secure channel for sensitive material. Do not paste incident details into open chat rooms or personal email.
• Review supplier and customer contracts for incident information clauses, and follow them.
• Define rules for sanitizing: remove customer data, credentials and personal details before sharing indicators or techniques.
• Consider joining an information sharing community for your sector so you can send and receive attacker technique information. This is voluntary.
• Set a protocol for insider cases: HR and legal first, tightly limited circle.

A worked example

During a ransomware scare, the incident lead sends a status update every four hours using a fixed format. Leadership sees status, impact, next steps and decisions needed in under ten lines. A supplier whose system was involved receives only the facts their contract entitles them to, over a secure channel.

After the incident, the team writes up the attacker's observed techniques with all customer names, hostnames and credentials removed. A second person checks the document before it goes to the information sharing community the company belongs to. The sanitizing checklist is attached to the record so the review is provable.

Evidence to collect

• The stakeholder table and update templates.
• Sample status updates from an incident or exercise.
• Information sharing clauses and any sharing agreements.
• The sanitizing checklist.
• Membership or contact records for any sharing community.

Common gaps

Leadership gets updates only when they ask. Information goes to suppliers without any agreement in place. Indicators shared externally still contain customer data. Insider cases are discussed in a channel the suspect can read. Lessons are never shared back with the teams that need them.

Quick check

Sources

• NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
• NIST CSF 2.0 Reference Tool and implementation examples: https://csrc.nist.gov/Projects/Cybersecurity-Framework/Filters#/csf/filters