RS.CO-02 Incident notification: requirements and evidence

What RS.CO-02 incident notification asks for in NIST CSF 2.0

If a customer contract, a regulator or a supervisor now asks you to show CSF 2.0 alignment, the question you will face is whether incidents reach the right people in time. RS.CO-02 requires that internal and external stakeholders are notified of incidents. It sits in the Incident Response Reporting and Communication Category (RS.CO) of the RESPOND Function, and its outcome is about notification itself, not about how the incident was contained. NIST's three Implementation Examples describe the paths you need to be able to prove: following breach notification procedures for affected customers, notifying partners and customers as their contracts require, and notifying law enforcement and regulators according to criteria in the response plan and with management approval. The decision rights behind each path matter as much as the messages. Someone must decide that an event is a confirmed incident, which notices it triggers, and who signs off.

Late or missed notices create the risk this Subcategory exists to control. A customer may learn of an exposure from the press, a partner may breach its own contract because you did not pass on a required notice, and a regulator may treat a delayed report as a failure of the program itself. Legal and contractual clocks often start at discovery or at a defined confirmation point, so the hard part is less the letter than the record of when you knew and when each party was told. Map each notice to its trigger, its owner and its deadline in your incident response plan, and confirm with counsel which deadlines apply to your sector and jurisdictions. Your records should show timestamps for detection, confirmation, approval and dispatch.

The CSF 1.1 lineage explains why older assessments look different. In CSF 1.1, RS.CO-2 covered notifying stakeholders, and RS.CO-3 covered sharing information. In CSF 2.0, RS.CO-02 keeps the CSF 1.1 RS.CO-2 identifier and absorbs part or all of RS.CO-3, according to NIST's transition spreadsheet. If your earlier assessment cited RS.CO-3 for notifications, re-map that evidence to RS.CO-02 and check the transition spreadsheet for the exact overlap. Confirm the mapping with your assessor, because the mapping supports your own evidence trail but does not replace it. Sharing with information-sharing bodies is covered separately under RS.CO-03.

Which notification obligations and stakeholders fall in scope for RS.CO-02

RS.CO-02 does not list who must be told or when. Each notice depends on the incident type, the contracts you have signed, the laws that apply to your data and operations, and who holds the authority to decide. The cards below cover the decision points that change the work and the third parties whose incidents can create notices for you.

Incident types that trigger notice

Start by defining which confirmed incident types create an obligation, not every alert. A confirmed loss of customer records, ransomware that halts service, or unauthorized access to a partner's data usually triggers different notices. NIST's Small Business Quick-Start Guide frames notice around a confirmed incident where a law, regulation, contract or policy requires it. Check that your response plan states the confirmation criteria and that triage records when a suspected event became confirmed, because that timestamp often starts a notice clock.

Stakeholders named in the plan

Map the recipients before an incident: affected customers, partners, law enforcement, regulators and internal executives such as legal, communications and the board. Implementation Examples for RS.CO-02 describe notifying affected customers, notifying partners and customers as contracts require, and notifying law enforcement and regulators under response plan criteria. Keep current contact details for each group in the plan, and confirm who approves each external notice.

Contractual notice obligations

Customer and partner contracts often set their own notice duties, including who must be told, what details to include, and how fast. Extract these terms into a register that lists the clause, the counterparty, the trigger and the delivery channel. Teams commonly miss notices that a contract requires even when no law applies. Ask legal to confirm whether any contract treats a supplier incident as your incident.

Statutory and regulatory duties

Breach notification laws, sector regulators and data protection rules each set their own triggers, recipients and deadlines. A single incident can require notices to several authorities at once, each with a different threshold. Build a jurisdiction map from where your customers, data subjects and operations sit, then have counsel confirm the triggers. Record which authority needs what, so the response team does not reconstruct the rules during an incident.

Who owns the notification decision

Notification is a business and legal decision, so name one accountable owner and a delegate. Incident responders supply facts, while legal, privacy, communications and an executive approver decide whether and what to disclose. RS.CO-02 implementation guidance ties law enforcement and regulator notices to response plan criteria and management approval. Document the approval path, the sign-off record and the time limit for decisions, and test it in an exercise.

Third-party incidents that trigger your notices

Managed security providers, hosting companies and software suppliers can hold your data or run controls for you. An incident in their environment may still require your notices to customers, partners or regulators. Review each supplier contract for incident reporting duties that flow to them, and confirm how quickly they must tell you. Your register should record which supplier incidents would start your own notification workflow.

How an assessor tests incident notification

This table sets out what an assessor typically tests for RS.CO-02, the evidence each test asks for, and the gaps that appear most often in practice. Read it as a checklist for preparing notification records before an assessment, and treat the findings column as the places where documentation most often falls short.

Test approach	Evidence requested	Common findings
Review response plan notification criteria and management approval	Current incident response plan sections defining which confirmed incidents trigger customer, partner, law enforcement or regulator notices, plus named approvers	Criteria written in general terms with no thresholds; approver roles named but no delegate or escalation path
Sample past incidents for notice timing and recipients	Incident records showing detection time, decision time, notice dispatch time and the list of recipients for each notice	Notices sent without a recorded approval; recipient lists that differ from the criteria in the plan; timing gaps with no explanation
Check contract notice clauses against notification procedures	Register of customer and partner contracts with notice clauses, mapped to the procedure steps that trigger them	Contract clauses with shorter notice windows than the internal procedure; clauses for key suppliers missing from the register
Confirm law enforcement and regulator reporting decisions are documented	Written decision records for each reporting choice, including the reasoning, the legal or regulatory basis and the person who decided	Decisions not to report that lack a written rationale; regulator reporting handled by individuals with no documented authority
Verify notices are consistent with the incident record	Copies of notices issued, compared against the case timeline and the scope of confirmed impact	Notices that describe impact differently from the investigation record; no version history for updated notices
Test whether notices are reviewed for accuracy and legal wording	Review sign-off by legal, privacy or communications staff for sampled notices	No evidence of legal review for regulator or customer notices; reviewers not identified

How to implement incident notification step by step

This sequence turns RS.CO-02 into a working notification process: it maps who must be told, when and by whom, and leaves a record that the notices were sent, approved and rehearsed. Each step produces a document or check that an assessor or auditor can inspect.

Inventory notification obligations across laws, contracts and policies
Legal, privacy and contract owners list every party that may need to hear about a confirmed incident: affected customers, partners under contract, law enforcement, regulators and internal stakeholders. For each entry, record the trigger, the content required and the source of the obligation, such as a statute, a contract clause or an internal policy. The step is done when the register is signed off by legal counsel and every entry names a source document. NIST's small business guide cites RS.CO-02 when it recommends this kind of review for laws, regulations, contracts and policies, so the register should also be reviewed whenever contracts or regulations change.
Define notification criteria and decision authority in the response plan
Write the criteria that decide when a suspected event becomes a confirmed incident that triggers notification, and name who has authority to approve each type of notice. The response plan should state the criteria in plain terms, the roles that assess them and the escalation path when a decision is contested. Done means the incident response plan contains these criteria and roles, and the people named have acknowledged them in writing. This is the decision point that the RS.CO-02 Implementation Examples describe as based on response plan criteria and management approval.
Build recipient lists and notification templates
Create a recipient list for each audience with current contact details, backup contacts and the channel to use. Draft templates for customer notices, partner notices under contract, law enforcement reports and regulator filings, using the fields each obligation requires. Legal counsel and communications staff review the wording so statements of fact stay consistent across audiences. The step is complete when each template has a named owner, a version number and an approved recipient list, and the lists have been tested for stale addresses.
Set approval, sequencing and timing rules
Define the order in which notices go out, which notices need sign-off from which role, and how the team tracks the clock for each obligation. Where a regulation or contract sets a deadline, record the exact figure from the source document rather than an internal estimate, and confirm it with counsel. The output is a written approval matrix and a timing table that name the obligation, the trigger, the approver and the sender. Done means the matrix is attached to the response plan and each row cites its source.
Connect notification steps to the case record
Link each notification task to the incident case so that every notice, approval and recipient is recorded alongside the investigation. Open-source case management platforms such as DFIR-IRIS keep each case as one record of assets, indicators, tasks and evidence, with an audit trail and a generated report, which helps show when a notice was approved and sent. Confirm that your chosen platform can record notification tasks and timestamps in your own environment before relying on it. The step is done when a test case shows the full notification trail, from trigger to approval to sent message, in one record.
Rehearse the process with a tabletop exercise
Run a tabletop exercise based on a realistic scenario that forces the team through the criteria, approvals, recipient lists and templates. Observers record where decisions stalled, where contact details were wrong and where a template did not fit the facts. Each gap becomes a tracked action with an owner, and the response plan and register are updated to match. The step is complete when the exercise report, the action log and the revised documents are filed together, which gives the assessor evidence that the process was tested and improved.
Maintain the notification process after each review
Schedule reviews of the obligation register, recipient lists and templates, and update them after any incident, exercise, contract renewal or regulatory change. Keep version history so you can show which version applied at the time of a given incident. Ask any external partner, including an implementation partner, to confirm in writing which parts of the process they prepared and which parts your organization owns. Done means the review log is current and each change traces back to a documented reason.

Evidence that shows incident notifications were made correctly

An assessor testing RS.CO-02 looks for a chain that runs from the legal and contractual duties the organization owns, through the response plan and approval decisions, to the notices actually sent. The cards below are the artifacts that connect those links, and each one should be traceable to the same incident record.

Notification obligations register

A register listing every law, regulator, contract and internal policy that requires notice of an incident, with the trigger, recipient, deadline and the owner responsible for each. Assessors check whether the register is current and whether it covers the notification duties named in the organization's customer and partner contracts, not only the ones legal counsel remembers. Check that each entry names a trigger that the incident team can actually observe, such as confirmed exposure of personal data.

Response plan notification section

The part of the incident response plan that sets out who decides to notify, the criteria for notifying law enforcement and regulators, and the template or pathway for each audience. This is the document that RS.CO-02 implementation examples point to when they call for procedures tied to response plan criteria. Confirm that the section is approved, dated and matched to the obligations register, so the two documents do not disagree on timing.

Decision and approval records

Records showing when the incident was confirmed, who assessed whether a notification duty applied, and which manager or executive approved each external notice. Assessors use these to judge whether notification followed the plan's criteria and management approval, and whether decisions were made in time. Store the reasoning alongside the approval, including decisions not to notify, since a missing rationale is the most common gap.

Sent notices with timestamps

Copies of each notice as sent, with the recipient, channel, sender and time it left the organization, held in the case record rather than only in an email inbox. Compare the timestamps with the detection and confirmation times to show whether deadlines were met. Where a regulator portal or secure channel was used, keep the submission receipt. Confirm that the case management tool can export these entries with an audit trail.

Contract notice clause map

A map linking each customer and partner contract's incident notice clause to its required content, recipient, timing and the contact the notice must reach. It shows that contractual notices were not overlooked when a single incident affected several customers. Review the map whenever contracts are renewed or a new supplier is onboarded, since clause wording and notice addresses change over time.

Exercise reports

Reports from tabletop and technical exercises that rehearse notification to customers, partners, law enforcement and regulators, with the findings and the corrective actions assigned. Assessors look for exercises that test the notification path itself, including contact details that are out of date and approvals that stall overnight. Feed each finding back into the obligations register and the response plan so the next exercise can show the fix.

What meeting RS.CO-02 costs in money and effort

This table breaks down the work behind RS.CO-02 notification into cost components, showing who is paid for each, whether the cost is one-time or recurring, and what drives it up. Use it to build a quote request and to decide which parts your own staff, counsel or an implementation partner should carry. No prices or durations are stated because none are supplied for this subcategory.

Cost component	Who is paid or who spends time	One-time or recurring, and main drivers
Obligation mapping	Legal, privacy and compliance staff, sometimes outside counsel	One-time for the initial map, then recurring as laws and contracts change. Drivers: number of customer contracts, partner agreements and jurisdictions with notice duties.
Notification template and process engineering	Incident response leads, legal reviewers, implementation partner if engaged	One-time build, then periodic revision. Drivers: number of distinct notice triggers, approval chains and notice recipients per incident type.
Notification tracking tooling	Vendor licenses for case management, or staff time to run a self-hosted tool	Licenses recur per seat or per module. Self-hosted open-source case tracking such as DFIR-IRIS (LGPL-3.0-or-later) can remove license spend, but hosting, patching and integration work remain. Confirm licensing terms with the project.
Exercise and tabletop time	Incident response, legal, communications and executive participants	Recurring, usually at least once a year per your own policy. Drivers: number of stakeholder groups and whether regulators and partners are included in exercises.
Evidence upkeep	Compliance staff who keep notice logs, approvals and timestamps current	Recurring with every incident and every review cycle. Drivers: incident volume and how cleanly case records are kept during response.
External legal or testing review	Outside counsel or specialist reviewers for wording and regulator-facing notices	Mostly one-time for template review, recurring when a live incident needs counsel. Ask whether review is per template, per hour or per incident.
Independent assessment sampling	Independent auditor or assessor, who sets the sample and fees	Recurring with each assessment cycle. Drivers: scope of notifications sampled and how quickly you can produce proof of approval and timing. Ask the auditor for the sample method in writing.

Who owns incident notification, what partners do and what auditors check

Your organization owns the outcome that RS.CO-02 describes: internal and external stakeholders are notified of incidents. That means deciding who must be told, when, and in what form. The decisions depend on your own legal, regulatory and contractual obligations, so they belong to leadership, legal counsel, privacy and the people who hold customer and partner contracts. NIST's Small Business Quick-Start Guide (SP 1300) describes the same split: notify customers, partners, law enforcement and regulators about a confirmed incident when laws, regulations, contracts or policies require it.

Decision authority: Name who approves external notifications and who can act while approval is pending, and record that in the response plan.
Obligation register: Maintain a current list of breach notification duties, contractual notice clauses and regulator reporting triggers, with owners and deadlines.
Notification criteria: Define the incident conditions that start each notification path, as the Implementation Examples for RS.CO-02 expect the response plan to do.
Legal review: Make counsel responsible for wording, privilege decisions and jurisdiction-specific timing.
Stakeholder records: Keep the contact details and notice addresses for customers, partners and regulators current.

Check that every notification duty you are subject to has a named owner, a trigger and a tested route to send it.

Where organizations miss RS.CO-02 and how to close the gap

RS.CO-02 asks whether internal and external stakeholders are notified of incidents, and the gaps that fail it are usually operational rather than technical. The cards below cover the places where notification obligations go unlisted, decisions go unrecorded, timing goes unproven and nobody owns the regulator clock.

No maintained list of notice clauses

Customer and partner contracts often contain their own notification windows, contact points and required content, and those terms rarely reach the people running incident response. Build a register that lists each contract with a notice obligation, the trigger it sets, the deadline, the named recipient and the clause reference. Review it when contracts renew and when new customers onboard. Ask counsel to confirm which clauses reach confirmed incidents and which reach suspected ones.

Notification decisions made informally

When the decision to notify a customer, regulator or law enforcement is made in a chat thread or hallway conversation, nobody can later show who approved it, what facts they had and why they chose that timing. RS.CO-02 implementation examples tie notification to response plan criteria and management approval. Write a decision record for each notification that captures the trigger, the approver, the information considered and the outcome, and store it in the case file.

Notices sent without timestamps

An assessor will ask when the organization first knew of an incident, when it decided to notify and when each notice left the building. If those times live only in email headers or memory, the timeline cannot be reconstructed. Record each event in the case timeline with a timestamp and time zone, and attach a copy of the sent notice with its recipient list. Ask your incident response tooling vendor to confirm how its audit trail records these entries.

Regulator reporting owned by nobody

Breach notification duties to regulators often run on short clocks and different thresholds across jurisdictions, yet many organizations never assign a single owner for them. Name an accountable role for each regulator, document who drafts the report, who reviews it for legal exposure and who signs it. Keep a current list of regulator contacts and report formats. Confirm with counsel which regulators apply to your sector and customer base, since that list changes with your footprint.

Notification steps never rehearsed

A notification plan that has never been run tends to fail on the first real event, usually because a contact is outdated, a template is missing or approval takes longer than the contract allows. Run a tabletop exercise that includes a customer notice, a partner notice and a regulator report, and time each step. Record what slowed the team down and update the plan, contact list and templates. Repeat the exercise after major organizational or contract changes.

Questions buyers ask about RS.CO-02 incident notification

How long does it take to set up RS.CO-02 incident notification?

No researched figure is available for duration, so treat any timeline as something to confirm in writing. The effort depends on how many notification obligations apply (customers, partners under contract, law enforcement, regulators), how many of them already have written procedures, and how many systems must be wired into the response workflow. Ask a partner to break the timeline into scope, design, build, testing and handover, and to name which of those steps depend on your legal review and management approval. A fixed-scope engagement gives you that breakdown before work starts.

Can our team meet RS.CO-02 without outside help?

Yes, an organization can meet RS.CO-02 with its own staff, because the outcome is a set of notification procedures that your organization owns and runs. Outside help is useful when the team lacks time, experience with incident response tooling, or a tested process for reaching regulators and customers. An implementation partner can prepare the case records, notification templates, escalation paths and evidence, but it cannot decide who gets notified or when. Those decisions stay with your management and legal function.

What does RS.CO-02 require from legal and operations teams?

Legal and operations teams own the decisions that RS.CO-02 depends on. Legal should identify which laws, regulations and contracts trigger notice, and what content and deadlines each one sets. Operations should maintain the response plan, the contact lists, and the criteria that determine when an incident is confirmed and escalated. NIST's Implementation Examples tie notification to response plan criteria and management approval, so decision rights must be written down before an incident occurs. Ask a partner to document these roles in the scope and to confirm that legal signs off on the templates.

Does NIST certify that our organization meets CSF 2.0?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. The CSF is a voluntary framework, so any claim of alignment is your organization's own statement, which a customer may ask you to support with evidence. Be cautious with any provider that offers a NIST CSF certificate. Independent assessors can test your controls, but they do not certify against the CSF on NIST's behalf.

How does RS.CO-02 relate to ISO 27001 clause 5.26 and SP 800-53 IR-6?

The NIST CSF 2.0 Reference Tool lists ISO/IEC 27001:2022 clause 7.4 and Annex A control 5.26 as informative references for RS.CO-02, and it lists SP 800-53 Rev. 5.2.0 control IR-6 alongside IR-4, IR-7, SR-3 and SR-8. These are mappings that help you reuse evidence, not proof that one framework satisfies another. Annex A control 5.26 concerns responding to information security incidents, and IR-6 concerns incident reporting. Confirm each mapping against the current standard text and your assessor's view before you rely on it in an audit.

What should we ask a partner to include in a quote?

Ask for a written scope before any price, because a quote follows from the agreed scope. DeployOpen does not publish a price list, and it does not issue reports or certifications. Request a list of the notification obligations in scope, the systems and tools to be configured, the deliverables (procedures, templates, case workflows, test records), who on your side must approve each item, and what happens if scope changes. Also ask which costs are one-time (design, build, testing) and which recur (support, retesting, updates when laws or contracts change), and whether the independent assessor's fees are excluded.

Can an open-source case management tool support RS.CO-02 notification records?

A case management platform can hold the records that show notification decisions were made and carried out. DFIR-IRIS, for example, keeps each case as one record of assets, IOCs, tasks and evidence with a full audit trail, and it builds a consolidated investigation timeline and generates reports from case data. Those features help you show when an incident was confirmed and what actions followed. The platform does not decide who must be notified, and it does not send notices for you. Confirm with your partner and your legal team which fields, approvals and report templates your notices require before you configure the tool.

How DeployOpen prepares incident notification evidence

DeployOpen works on RS.CO-02 as an implementation partner: we help your team build the notification procedures, decision records and tooling that show who was told what, when and why. Your organization owns the decisions about notifying customers, partners, law enforcement and regulators, and only your legal counsel and the relevant authorities can judge what a notice must contain.

How we scope

We agree the written scope for RS.CO-02 before work starts, naming the systems, stakeholder groups and notice types covered.
We confirm which laws, regulations and contracts your notification duties come from, with your legal and compliance owners.
We define the decision roles, such as who approves a notice and who has authority to contact regulators, as part of the scope.

How we build

We configure a self-hosted case platform such as DFIR-IRIS so each incident keeps one record with a full audit trail.
We build notification templates and checklists tied to the response plan criteria and management approval steps your team sets.
We set up a consolidated incident timeline so notification timestamps can be traced back to detection and confirmation events.

How we hand over

We document the notification procedures, decision logs and evidence locations in a handover pack your team can maintain.
We run a tabletop exercise against the notification workflow and record the results and follow-up actions in writing.
We provide a list of the evidence an independent auditor or assessor would ask to see, so your team can confirm it exists.

How we support

Ongoing support, upgrades and continuous testing of the notification tooling are available as a retainer agreed in writing.
We can review notification procedures after changes to laws, contracts or your response plan, at the scope you agree.
Assessment findings and the decision on certification or attestation remain with your organization and the independent assessor you choose.