RS.CO-02: Internal and external stakeholders are notified of incidents

RS.CO-02 requires you to notify the right internal and external stakeholders when an incident occurs, using defined triggers, timelines, roles, and approved message paths. To operationalize it quickly, establish an incident notification matrix, pre-approved communications, and an evidence trail that proves notifications happened (or were properly deferred) for each incident. ¹

Key takeaways:

• Build a single notification “source of truth”: who must be told, when, by whom, and how, per incident type and severity. ¹
• Pre-approve templates and escalation paths to avoid delays, inconsistent messaging, and legal/regulatory missteps. ¹
• Retain evidence that links each incident to decisions, timestamps, recipients, and approvals for notifications. ²

The rs.co-02: internal and external stakeholders are notified of incidents requirement sounds simple until you run it during a real event. Operators fail it in predictable ways: nobody knows who is authorized to notify a regulator or a customer; teams debate whether the event “counts” as an incident; communications are delayed while Legal reviews a draft; or notifications happen informally (chat/email) with no durable record for audit or post-incident learning.

NIST CSF 2.0 frames this as a communications outcome: when an incident happens, the organization informs the stakeholders who need to act or who have a right to know. ¹ For a Compliance Officer, CCO, or GRC lead, the job is to turn that outcome into a control that runs under stress: clear triggers, predefined audiences, message governance, and proof.

This page gives requirement-level implementation guidance you can execute immediately: a notification matrix, step-by-step operating process, artifacts to retain, common audit questions, and a practical execution plan to get the control working and defensible. ¹

Regulatory text

Requirement (excerpt): “Internal and external stakeholders are notified of incidents.” ¹

What the operator must do: Implement and run an incident notification process that (1) identifies which stakeholders must be informed for a given incident, (2) sends timely and appropriate notifications through approved channels, and (3) retains evidence that notifications and approvals occurred. The requirement covers both internal stakeholders (executives, Legal, IT/SecOps, Privacy, business owners) and external stakeholders (customers, regulators, law enforcement, cyber insurer, critical third parties), as applicable to the incident. ¹

Plain-English interpretation

RS.CO-02 means you cannot treat incident communications as improvisation. For each incident category and severity level, you must already know:

• Who gets notified (named roles or distribution lists, not “someone in Legal”).
• Who is allowed to notify (authorized sender and approver).
• What triggers notification (decision criteria tied to your incident taxonomy).
• How notifications are delivered (tooling and channels).
• How you prove it happened (timestamps, recipients, approvals, and copies of messages). ¹

This is compatible with many regulatory regimes, but RS.CO-02 itself is a framework outcome. Your implementation should therefore be adaptable: you may notify different external parties depending on jurisdiction, contract terms, and sector rules, but the governance mechanism should stay consistent. ¹

Who it applies to

Entities: Any organization operating a cybersecurity program that uses NIST CSF 2.0 as a framework reference, including enterprises, regulated financial services, healthcare, SaaS, and critical infrastructure organizations. ¹

Operational context where it matters most:

• You have customer contractual notice obligations (security addenda, DPAs, SLAs, breach clauses).
• You rely on critical third parties (cloud/SaaS/managed services) where coordinated comms reduce harm and confusion.
• You operate 24/7 services where delayed comms increases operational and reputational impact.
• You have a formal incident response program and need consistent, auditable execution across incidents. ¹

What you actually need to do (step-by-step)

Step 1: Define “incident” and notification triggers

1. Adopt an incident taxonomy that distinguishes security events from incidents and maps to severity levels.
2. Define notification triggers per category (examples: confirmed data access, material service outage due to security event, ransomware, third-party compromise impacting your environment).
3. Document decision authority for incident declaration and external notification decisions (often CISO/SecOps for technical confirmation, Legal/Privacy for external content approval). ¹

Operator tip: Add “insufficient information” handling. Many delays come from waiting for perfect facts. Your procedure should allow preliminary notifications when required, with controlled language. ¹

Step 2: Build an incident notification matrix (your control backbone)

Create a matrix that maps incident type x severity to:

• Internal recipients: IR lead, IT ops, CISO, CIO/CTO, General Counsel, Privacy Officer, Comms/PR, Customer Support lead, product owner, Risk/Compliance, executive on-call.
• External recipients (as applicable): affected customers, key partners, regulators, cyber insurer, law enforcement, impacted third parties, industry ISAC/ISAO (if you participate).
• Timing expectations: “Immediate,” “same business day,” “within contractual window,” etc. (Keep times flexible unless you have specific legal obligations defined elsewhere.)
• Sender/approver: who sends and who approves for each external audience.
• Channel: email from designated mailbox, customer portal notice, support ticket broadcast, phone tree, insurer hotline, etc.
• Content constraints: what must be included vs prohibited (avoid speculation; include known facts, actions taken, what recipients should do). ¹

Step 3: Pre-approve messages and establish comms governance

1. Create templates for the most common incident types (customer notice, internal exec brief, third-party coordination request).
2. Establish approval workflow (Legal/Privacy/Comms) and an emergency path if approvers are unavailable.
3. Set a single system of record for outbound notifications (ticketing/IR platform, GRC evidence repository) so you can reconstruct what happened later. ¹

Step 4: Operationalize with roles, on-call, and handoffs

1. Assign control ownership (usually IR Program Owner or GRC + IR co-ownership).
2. Maintain current contact lists and distribution groups; test deliverability.
3. Define handoffs between SecOps and Compliance/Legal: who drafts, who reviews, who sends, who logs evidence.
4. Train incident commanders on notification decision points and evidence capture. ²

Step 5: Run it during incidents (minimum viable workflow)

For every declared incident:

1. Open/confirm an incident record (unique ID).
2. Select the notification profile from the matrix.
3. Draft messages using templates; record approvals.
4. Send notifications; capture timestamps, recipients, and delivery artifacts.
5. Record exceptions: if you do not notify a typical stakeholder, log the rationale (e.g., false positive, no impact, counsel direction).
6. Post-incident, perform a communications after-action review: what was sent, what was missed, and what to adjust in the matrix/templates. ¹

Required evidence and artifacts to retain

Auditors and examiners look for “prove it” evidence. Retain:

• Incident notification matrix (version-controlled) and named control owner. ²
• Incident response procedure section that describes notification triggers, roles, approvals, and channels. ¹
• Contact rosters and distribution list governance (ownership, update cadence, last review date).
• Templates (customer notice, regulator outreach draft, internal executive brief) with approval history.
• Per-incident evidence package:
  • incident timeline (key timestamps)
  • approvals (Legal/Privacy/Comms)
  • copies of notices or screenshots/PDF exports
  • email headers or ticket artifacts showing recipients
  • call logs/insurer claim reference where applicable
  • decision memo for deferred/withheld notifications. ¹

Practical evidence standard: If you cannot reconstruct who was told, when, and under whose approval, you should treat the control as failing for that incident.

Common exam/audit questions and hangups

Expect these lines of inquiry:

• “Show me the last incident and evidence of internal and external notifications.” ¹
• “Who decides whether customers/regulators are notified, and where is that documented?”
• “How do you ensure contact lists are accurate and available during an outage?”
• “What’s your process for third-party-caused incidents, and who coordinates comms with the third party?”
• “How do you avoid inconsistent messaging across Support, Sales, and PR?” ¹

Common hangup: teams provide a policy statement but no executed artifacts (emails, approvals, timelines). RS.CO-02 is outcome-oriented; you need operational proof. ²

Frequent implementation mistakes (and how to avoid them)

1. No explicit external stakeholder list. Fix: maintain a stakeholder register tied to contracts, jurisdictions, and critical relationships; connect it to the matrix.
2. Approval bottlenecks. Fix: pre-approved templates and a documented backup approver path.
3. Shadow notifications by engineering/support. Fix: require that outbound incident communications route through the incident record and approved senders.
4. Notification decisions not recorded. Fix: add a mandatory “notify / do not notify / pending” section in the incident ticket with rationale and approver.
5. No evidence retention. Fix: define an evidence checklist per incident and store it centrally (GRC repository or IR platform export). ²

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific cases.

Operational risk is still clear: delayed or inconsistent notifications can increase customer harm, create contractual disputes, complicate insurer coordination, and trigger regulator scrutiny under separate legal obligations that may apply to your organization. Treat RS.CO-02 as a control that reduces downstream legal and reputational exposure by making communications repeatable and provable. ¹

Practical execution plan (30/60/90 days)

First 30 days: Stand up the minimum viable control

• Assign a control owner and backups; document RACI for incident communications. ²
• Draft the notification matrix v1 for your top incident types.
• Create two to three templates for the most likely external notifications (customer notice, insurer notice, internal exec update).
• Decide where evidence lives (IR tool, ticketing, or GRC repository) and publish an evidence checklist. ¹

Days 31–60: Make it reliable under stress

• Run a tabletop exercise focused on notifications: approvals, handoffs, and evidence capture. ¹
• Tighten distribution lists, on-call coverage, and backup approvers.
• Add third-party coordination playbooks for incidents involving critical providers (who contacts the third party, who consolidates facts, who communicates to customers). ¹

Days 61–90: Make it auditable and scalable

• Convert lessons learned into matrix v2 and updated templates.
• Implement recurring evidence collection and spot checks on incidents (including “near misses”).
• If you use Daydream, map RS.CO-02 to the policy/procedure/control owner and set recurring evidence requests so the notification matrix, templates, and incident evidence packages stay current without manual chasing. ²

Frequently Asked Questions

Do we have to notify external stakeholders for every incident?

RS.CO-02 requires that internal and external stakeholders are notified “of incidents,” but which external stakeholders apply depends on the incident and your obligations. Use a notification matrix so the decision is consistent and documented. ¹

Who should own RS.CO-02: Security, Legal, or Compliance?

Security usually runs incident operations, while Legal/Privacy often governs external messaging. Compliance/GRC should own the control design and evidence expectations, with Security as the primary operator. ¹

How do we handle incidents at a third party that might impact us?

Treat third-party notifications as a defined branch in your matrix: who engages the third party, who assesses impact, and who communicates to your customers if your services/data are affected. Record all third-party communications in the incident evidence package. ¹

What evidence is “good enough” for an audit?

Keep an incident timeline, the final messages (or exported notices), recipient lists, and approvals. If you withheld or delayed notification, retain the decision record and approver. ¹

Our Legal team won’t pre-approve templates. What’s the workaround?

Ask Legal to approve “safe language blocks” and a minimal structure (what you can say with limited facts). Pair that with an expedited review workflow and named backup approvers. ¹

How do we prevent inconsistent customer messaging across Support, Sales, and PR?

Centralize outbound statements in the incident record and require approved senders and templates. Provide a short internal FAQ for customer-facing teams that matches the approved external message. ¹

Footnotes

1. NIST CSWP 29

2. NIST CSF 1.1 to 2.0 Core Transition Changes