RS.CO-03 Incident information sharing: requirements

What RS.CO-03 asks for and why sharing incidents is hard to get right

If you have been told to show that RS.CO-03 is met, the short answer is this: the Subcategory asks your organization to share incident information with designated internal and external stakeholders. It sits in the RESPOND Function under the Incident Response Reporting and Communication (RS.CO) Category of NIST CSF 2.0. The risk it addresses runs in two directions. Sharing too widely, or through the wrong channel, can expose sensitive details about an attack, a victim or an investigation. Sharing too late, or with the wrong people, leaves the people who need to act without the facts they need. The outcome above is our own paraphrase of NIST's wording in CSWP 29, not a quotation, so read the source itself before you write it into a policy.

The hard part is rarely the sending. It is deciding, before an incident, who the designated stakeholders are and keeping that list current. Those names usually span legal, communications, HR, executive leadership, key customers and suppliers, and sometimes an information sharing community. Each needs a defined trigger, a channel and a content rule, such as which indicators can leave the building and which cannot. Organizations also tend to confuse this Subcategory with RS.CO-02, which covers notifying affected parties and regulators. Those notification duties have their own legal and contractual triggers and are covered on the sibling page. RS.CO-03 is about the wider circle of sharing that the response plan designates.

The Subcategory carries forward CSF 1.1 RS.CO-3 at the same identifier and absorbs part or all of CSF 1.1 RS.CO-5, so a CSF 1.1 assessment mapped to it may need its evidence re-scoped. NIST publishes six Implementation Examples for RS.CO-03, covering secure sharing under response plans and sharing agreements, voluntary sharing of sanitized attacker tactics, techniques and procedures with an Information Sharing and Analysis Center, notifying HR of malicious insider activity, updating senior leadership on major incidents, and coordinating with critical suppliers. Use them as a checklist of decisions to document. Confirm current wording and mappings in NIST's CSF 2.0 Reference Tool export before relying on them in an assessment.

Which stakeholders, data and third parties fall inside RS.CO-03

RS.CO-03 asks whether the right information reaches the right people, inside or outside the organization. Each card below is a scoping decision that changes who receives incident content, what gets removed first, and which written agreement must exist before anything is sent. Settle these choices in the response plan before an incident, not during one.

Designated internal recipients

Name the internal roles that receive incident information and what each one needs: executive leadership needs status and business impact, legal needs facts relevant to notification duties, and the security operations team needs technical detail. Write this list into the response plan with named roles and deputies, not individuals. Check that the list is reachable out of hours, because a stale contact list is a common gap when an incident starts. Each role should map to one channel, such as a restricted incident room, so updates do not spread through informal email.

Insider activity routed to HR

When an incident points to malicious insider activity, content about the individual should not flow through general incident channels. Define a procedure in which the incident lead informs HR and legal, HR decides on employment steps, and the security team limits the case file to what HR needs. Confirm with counsel which records may be shared and how they are retained. This decision changes the work because it adds access restrictions, a separate case record and a point where investigators stop sharing.

Industry sharing with an ISAC

Decide whether attacker tactics, techniques and procedures will go to an Information Sharing and Analysis Center, and under which membership terms. Sharing is voluntary under the NIST example, so the organization must sanitize records first, removing customer data, internal hostnames and details that identify the victim. Confirm the ISAC's distribution rules and whether sharing groups limit who sees each item. Assign one owner to approve every outbound submission so sharing stays consistent.

Critical suppliers and third parties

Identify the suppliers whose services or data an incident could affect, such as hosting providers, managed security providers and payment processors, and decide what each one may receive. Coordination is a two-way channel, so record what the organization needs from the supplier, including logs and timelines, and what it will share back. Existing contracts often set notice periods and information duties, so check them before the incident. Where no contract exists, the sharing scope should be limited to the minimum needed for containment.

Law enforcement and regulators

Decide which authorities receive incident information and at what point, and whether the response plan calls for that contact. NIST's small business guidance frames notification to law enforcement and regulators around cases where laws, regulations, contracts or policies require it. Assign one person to make the contact so statements stay consistent with later notifications. Ask counsel which obligations trigger a report and which are optional. Keep a record of every disclosure, including what was shared and when.

Sharing agreements that govern each channel

Each recipient group needs a written basis for sharing, such as an employment policy for HR, a membership agreement for an ISAC, a non-disclosure agreement or contract clause for suppliers, and a legal basis for authorities. Map each channel to its agreement before an incident, and list the handling rules, such as marking, retention and onward disclosure limits. Without a mapped agreement, staff may share information the organization cannot defend later. Review the map after each exercise and after any change in membership or contracts.

How an assessor tests RS.CO-03 and which findings come up

This table compares four test activities an independent assessor may run for RS.CO-03, the evidence each one asks for, and the findings that appear most often. Read each row as a question the assessor will put to your team, and use the findings column to check your own records before an assessment begins. The organization owns the result, and only the independent assessor reaches a conclusion.

Test activity	Evidence requested	Common findings
Review the response plan and sharing procedures	Current incident response plan, communication procedures, named roles for internal and external sharing, approval records	Plan names no designated recipients, or the procedure is not linked to the incident process
Sample past incidents for recorded recipients	Incident tickets, distribution logs, copies of notices sent, timestamps of each sharing action	No record of who received information, or records show sharing that the plan does not allow
Check agreements with ISAC and suppliers	Signed sharing agreements, membership terms, supplier contract clauses on incident information, handling rules for sanitized indicators	Information shared with an ISAC or supplier without an agreement, or agreements that do not cover incident data
Interview leadership on update cadence	Executive briefing records, escalation thresholds, minutes of major incident updates, HR referral records for insider activity	Leadership updates are informal or undocumented, and HR referral for malicious insider activity has no defined trigger

How to implement RS.CO-03 in sequence

This sequence turns RS.CO-03 from a general intention into a documented process: who receives incident information, what each recipient gets, how external sharing is cleared, when leadership hears from the response team, and how the whole flow is tested before a real incident forces the question.

Define the designated stakeholder list
Start by listing every internal and external party that may need incident information: executive leadership, legal, communications, human resources, customers, critical suppliers, your Information Sharing and Analysis Center (ISAC) membership if you have one, law enforcement and regulators where obligations apply. For each entry, name the role that owns the relationship and the role that approves contact. Record this in a stakeholder matrix that your incident response plan references. The output is a signed-off matrix with named owners and a version date, which an assessor can compare against your response plan and your supplier and contract inventory. Confirm which parties your contracts and regulations require you to inform, because that list drives the rest of the sequence.
Set sharing rules for each recipient class
For each class in the matrix, document what may be shared, in what form, at what point in the response, and under which agreement. Internal recipients usually receive full case detail under confidentiality terms. Customers and partners typically receive scoped impact statements. Suppliers may need only the indicators or service dependencies relevant to them. Where a non-disclosure agreement, information sharing agreement or contract clause governs the exchange, cite it in the rule. The output is a sharing rules table, one row per recipient class, reviewed by legal and approved by the incident response owner. An assessor will look for evidence that sharing decisions follow written rules rather than individual judgment during a crisis.
Build the sanitization and approval gate
Before anything leaves the organization, route the material through a sanitization step that removes internal hostnames, IP addresses of internal systems, personal data, customer identifiers and privileged legal analysis. Attacker tactics, techniques and procedures (TTPs) and indicators shared with an ISAC should be converted into a neutral format, such as STIX or a plain indicator list, and reviewed for accidental disclosure. Assign an approver who is not the author. Keep a log of each release, including the recipient, the approver and the date. The output is an approved sharing template and a release log. Ask your ISAC or sharing community which formats and handling terms they expect, since these vary between communities.
Set senior leadership update triggers and cadence
Define the conditions under which the incident commander must brief executives, such as confirmed exfiltration, service outage above a threshold your business sets, regulatory notification duties or media interest. Set a cadence for updates during a major incident and assign the person who delivers each one. Include a standard brief covering scope, business impact, containment status, decisions needed and next update time. Where insider activity is suspected, add a trigger for notifying human resources and legal before any action against an individual. Your thresholds should be written by your own leadership, not copied from a template. The output is a leadership escalation procedure with a one-page brief template, which an assessor can match against the timeline of a real or exercised incident.
Test the process in a tabletop exercise
Run a tabletop exercise that includes at least one external sharing decision, one insider-related HR notification and one leadership briefing. Use a scenario written for your environment, and have the people named in the matrix take the roles they would hold in a real event. Record where the matrix was unclear, where a sharing rule was missing, and where the sanitization gate slowed the response. Assign each finding an owner and a closure date, then update the matrix, rules and templates. The output is a dated exercise record with findings and a closure log. Assessors typically ask for this record to confirm that the sharing process has been operated and improved, not only written down.

Which evidence shows RS.CO-03 is met and how to keep it current

RS.CO-03 is met when an organization can show who receives incident information, under what terms it is shared, and that the list and agreements were kept current. The cards below cover six artifacts an assessor is likely to ask for, along with the routine that keeps each one accurate between assessments. The organization owns these records; an independent assessor decides whether they are sufficient.

Designated stakeholder matrix

A matrix that names each internal and external recipient of incident information, the incident types that trigger notice, the role responsible for sending it, and the channel used. Include HR, senior leadership, critical suppliers, the ISAC and regulators where obligations apply. Review it on a fixed schedule, and after every reorganization, contract change or exercise that exposes a missing contact. Record the reviewer and date on each version so an assessor can see the list was maintained, not written once.

Sharing procedure in the response plan

The section of the incident response plan that sets the sequence for sharing: who approves release, what information may leave the organization, how sensitive details are removed, and which secure channels are used. Check that the procedure matches what people actually did in the last incident or exercise. A procedure that names a mailbox nobody monitors or an approver who left the company will not satisfy an assessor.

Executed sharing agreements

Signed agreements with an ISAC, customers, managed service providers or other suppliers that define permitted use, handling of shared data, confidentiality and retention. Keep a register showing each agreement's owner, signature date, renewal date and termination conditions. Confirm with counsel that each agreement covers the information the procedure says will be shared. An unsigned draft or an expired agreement is weak evidence even when the sharing actually happened.

Sanitized TTP sharing records

For each voluntary sharing of attacker tactics, techniques and procedures with an ISAC or peer group, keep the sanitized content as sent, the approval record, the recipient and the date. Each entry should trace back to the case that produced the indicators. Open-source platforms such as MISP can hold sharing groups and distribution settings, and OpenCTI can hold STIX-based records, but confirm the platform's export history meets your retention and approval rules before relying on it.

HR and leadership notification records

Records showing that HR was told about suspected malicious insider activity and that senior leadership received updates on major incidents. Keep the notification time, the content summary, the recipient and any decision taken. Exercises count as evidence only when their outputs are recorded and the gaps were fixed. Ask HR and legal to confirm how these records are stored, since they may contain personal data with its own access limits.

Review log of matrix and agreements

A dated log of each review of the stakeholder matrix, procedure and sharing agreements, with the change made, the approver and the reason. Tie each external disclosure to a case record in your incident platform, such as a DFIR-IRIS case with its timeline and audit trail, so every notice can be traced to a specific incident. Set the review interval in policy, then check the log against it between audits. Gaps in the log are the first thing an assessor will test.

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

This table lists each cost component of running RS.CO-03 sharing, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written scope and to check that every quote covers the same components.

Cost component	Type and who is paid	Main cost drivers	What to ask for in a quote
Tooling or licenses	One-time setup and recurring hosting. Open-source options such as DFIR-IRIS, MISP and OpenCTI carry no license fee, but the organization pays for hosting and staff time.	Number of tools deployed, hosting model, and whether sharing runs between several MISP instances	Itemized list of software, versions, hosting components and any commercial add-ons, with license terms stated for each
Engineering time for case and sharing workflows	One-time build, then recurring tuning. The organization or its implementation partner is paid for configuration of sharing groups, distribution levels and case templates.	Number of recipients, number of distinct sharing groups, and integrations with SIEM, EDR or ticketing sources	Named deliverables such as sharing-group design, distribution rules, case templates and an integration list, with a fixed-scope statement
Sharing agreements and legal review	One-time drafting, then recurring renewal. Paid to internal legal or outside counsel; DeployOpen does not draft legal agreements.	Number of external agreements, jurisdictions involved, and whether ISAC membership terms apply	Confirmation of who drafts, reviews and signs each agreement, and whether the scope includes agreement templates
External review of the response plan	One-time review, then recurring periodic review. Paid to an independent reviewer or internal assessor, depending on who signs off.	Size of the response plan, number of sharing paths it defines, and the review frequency chosen	Review scope, reviewer qualifications, number of review rounds included and the written findings format
Evidence upkeep	Recurring. Paid as staff time for keeping sharing logs, distribution records, agreement registers and exercise reports current.	Incident volume, number of recipients logged, and retention period set by the organization	Evidence list mapped to each sharing event, retention settings, and who maintains the register after handover
Exercises and tabletop testing	Recurring. Paid as staff time and, if external, facilitator fees.	Number of exercises run each year, number of stakeholder groups included, and whether an ISAC or supplier takes part	Exercise count, facilitator role, after-action report format and how follow-up actions are tracked
Auditor sampling and assessment support	Recurring at each assessment cycle. The organization pays the independent auditor or assessor; the implementation partner prepares evidence but does not issue reports.	Number of sharing events in the sample period, assessment framework chosen, and how many evidence requests the auditor raises	Confirmation that evidence preparation is separate from the auditor's fee, and the evidence retrieval support included
Operating staff for voluntary sharing	Recurring. Paid as analyst time for sanitizing indicators and tactics before sharing with an ISAC.	Volume of indicators or TTPs shared, sanitization rules, and how often the organization shares	Who sanitizes, the sanitization checklist, and the expected review step before any outbound release

Open-source tools that produce RS.CO-03 evidence

RS.CO-03 asks whether incident information reaches the stakeholders an organization has designated, through channels it controls. The three tools below cover different parts of that job: the case record, the sharing of threat indicators and the threat intelligence library. Each one produces artifacts an assessor can inspect, but none of them decides who should receive what.

DFIR-IRIS case records

DFIR-IRIS keeps each incident as one case with its assets, indicators of compromise, tasks and evidence, plus a full audit trail. For RS.CO-03, that record is the source of truth for what was shared, when, and with whom, so the case history should capture every outbound update to a stakeholder. Its reports are generated from case data, which lets a sharing summary be reproduced rather than rewritten from memory. Confirm the audit trail records who exported or sent each report. The software is licensed under LGPL-3.0-or-later, so review the license terms with your legal team before modifying or redistributing it.

MISP distribution controls

MISP synchronizes events between instances and applies granular distribution and sharing groups, which decide which partners can receive a given indicator set. This is the mechanism most relevant to sharing attacker TTPs with an ISAC or trusted peers, and it should be configured against a written sharing agreement. MISP also exports to STIX 1 and 2, CSV and Suricata, Snort and Zeek formats through its REST API, so exports can be tested against partner systems. Confirm the distribution level on every outbound event matches the agreement. MISP is licensed under AGPL-3.0-only, which carries network-use obligations for modified versions offered to users, so confirm them before deployment.

OpenCTI knowledge sharing

OpenCTI organizes threat intelligence as STIX-based entities, relationships and containers, and shares that knowledge through native feeds and exports. It is useful for packaging sanitized TTP descriptions into containers that can be handed to a designated recipient, and for recording where each piece of intelligence came from. Ingestion through connectors, TAXII, RSS, CSV and JSON feeds means the platform can also show which external sources informed a response. Confirm that outbound containers exclude internal identifiers and personal data. OpenCTI is licensed under Apache-2.0, a permissive license, but the connectors and integrations you add may carry their own terms.

Who owns RS.CO-03 in-house, with a partner and with the auditor

RS.CO-03 asks whether incident information reaches the right internal and external stakeholders. The organization decides who those stakeholders are, what they may receive, and when. Those decisions depend on contracts, sector rules, legal advice and the organization's risk appetite, so they cannot be handed to anyone else. The internal team also owns the final call on each sharing event, including what is withheld.

Stakeholder list: Name the internal leaders, customers, partners, regulators, ISAC members and law enforcement contacts who may receive incident information, and keep the list current.
Sharing agreements: Negotiate and sign non-disclosure, information sharing and contractual notice terms before an incident occurs.
Sharing decisions: Decide, case by case, what is shared, with whom, through which channel and on whose authority.
Leadership updates: Own the content and cadence of updates to senior leadership and the board during a major incident.
HR and legal triggers: Define when suspected insider activity goes to HR and legal, and who approves that step.

Confirm that these decisions are written into the response plan and that named roles, not job titles alone, hold each approval.

Where organizations fall short on RS.CO-03 and how to close each gap

RS.CO-03 asks that incident information reach the right internal and external stakeholders through channels they can rely on. The gaps below tend to appear together: lists that drifted, sharing without paperwork, and disclosures nobody recorded. Each fix names an artifact you can produce and show an assessor.

Stakeholder list missing HR and suppliers

Many stakeholder lists cover IT, legal and executives but omit HR, critical suppliers and managed service providers. RS.CO-03 expects sharing with designated internal and external stakeholders, so a list with these gaps fails the test in practice. Fix it with a named stakeholder register that lists role, contact path, backup contact and the trigger for each notification. Review it on a fixed schedule and after every staffing or supplier change, and check that each entry still resolves to a live contact.

Sharing without written agreements

Teams often exchange incident details with an ISAC, a supplier or a peer organization on the strength of a phone call or an informal email. Without a written agreement, nobody has settled what may be shared, how it must be protected, or how long it may be retained. Fix it by putting a sharing agreement in place before the first exchange, covering scope, handling markings, retention and who may approve disclosures. Keep signed copies with the response plan so the path is usable during an incident.

Attacker TTPs shared without sanitization

Sharing attacker tactics, techniques and procedures with an ISAC can expose customer data, internal hostnames or the details of an unpatched weakness if the material is not cleaned first. RS.CO-03 covers voluntary sharing of sanitized TTP information, so the sanitization step is the control. Fix it with a short sanitization checklist and an approval step signed off by legal or the incident lead. Record what was removed and who approved the release, so the sharing decision can be reviewed later.

No record of disclosures

When a disclosure is not logged against the incident, the organization cannot later show who received what, when, or under which authority. This makes it hard to answer regulators, customers or auditors and to avoid repeated or contradictory messages. Fix it with a disclosure log attached to the incident record. Each entry should hold recipient, channel, time, content reference, approver and the agreement that applied. Case management tools can keep this log alongside the incident timeline.

Informal leadership updates

Senior leaders often learn about major incidents through hallway conversations or chat threads, which leads to inconsistent facts and decisions taken without the full picture. RS.CO-03 includes updating senior leadership on major incidents, so these updates need a defined owner and rhythm. Fix it with a leadership brief template that states what is known, what is unknown, actions taken and decisions needed. Assign an owner for each update and file the briefs with the incident record.

Sharing path never exercised

A stakeholder list and agreements mean little if the sharing path has never been tested under time pressure. Gaps usually surface when a contact has left, an email bounces or an approval waits on someone on leave. Fix it by running a sharing exercise as part of the incident response test program, with a scenario that requires HR, a supplier and leadership updates within one simulated incident. Record the results and feed corrections back into the stakeholder register and agreements.

Questions buyers ask about RS.CO-03 cost, effort and outside help

How much effort does RS.CO-03 take to implement?

The effort depends mostly on how many stakeholder groups must receive incident information, how many sharing agreements already exist, and how mature the current incident response plan is. RS.CO-03 is a Subcategory of the RESPOND Function, so its evidence sits on top of work done for detection and incident management. Effort rises when sharing rules are undefined, when the team must write new agreements with suppliers or partners, or when legal and HR must agree on what can be disclosed and to whom. Effort falls when a response plan already names recipients, classifies information and records who approved each disclosure. Ask any provider to break the effort down by stakeholder group so you can see where the work actually sits.

How long does it take to prepare evidence for RS.CO-03?

No reliable duration can be given without a defined scope, because the time depends on your environment, the number of recipients and the state of your records. Preparing evidence usually means collecting the sharing procedures, sample notifications with timestamps, signed agreements, and records showing that sharing was approved and sanitized where needed. Teams with a working incident log can move faster than teams reconstructing past events from email threads. Ask for a timeline in a written scope that lists each deliverable, the dependencies on your staff, and the point at which the scope is considered complete.

Does NIST certify that an organization meets RS.CO-03 or the CSF?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. Any assessment of your CSF 2.0 alignment is therefore either a self-assessment you carry out or an independent assessment performed by a firm you engage. Be cautious with any offer that presents a NIST certificate, since none exists. If a customer or regulator asks for proof, agree in advance on what evidence will be accepted and who will review it.

What does RS.CO-03 need from our own team?

RS.CO-03 needs named owners rather than a shared mailbox. You should assign one owner for the sharing procedure, one for each external channel such as an ISAC membership or a supplier notice path, and one for HR coordination when insider activity is involved. Those owners need access to incident records, including the timeline, affected assets and the decisions taken. Leadership must set aside decision time to approve what is shared with senior management, regulators or partners, because delayed approvals are a common reason that notices go out late. Ask who on your side signs off each disclosure type before any outside party starts work.

Can we implement RS.CO-03 ourselves without an outside partner?

Yes, many organizations do this with internal staff, particularly when their incident response plan is already documented and their legal team can draft sharing terms. Internal teams often struggle with three things: keeping sharing decisions consistent under pressure, producing evidence that auditors or customers can trace, and maintaining the agreements over time. An implementation partner can prepare systems, workflows and records for those tasks, such as case records with audit trails, but the organization still owns the controls. Only an independent auditor or assessor issues a report or opinion on whether the control is met.

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

Ask for a written scope that names the stakeholder groups covered, the sharing channels in use, and the systems to be configured or documented. The quote should list each deliverable, such as sharing procedures, templates, configured case tooling and an evidence pack, along with the client tasks and the dates that depend on them. Confirm what is one-time work and what recurs, including support, upgrades and any retainer for ongoing testing. Also ask who performs the work, how changes to scope are priced, and which parts the partner will not do, such as issuing any assessment result. DeployOpen does not publish a price list, and a quote follows from the written scope.

How DeployOpen prepares RS.CO-03 evidence for self-hosted platforms

DeployOpen plans, implements and documents self-hosted open-source platforms that support RS.CO-03 Incident information sharing inside your own infrastructure. We prepare the systems, sharing workflows and evidence an assessor can review, while your organization keeps ownership of its controls, sharing agreements and decisions about what to disclose.

How we scope

Engagements are fixed-scope, with the sharing audiences, channels and platforms agreed in writing before work starts.
The written scope names which stakeholders receive information, such as ISAC contacts, HR, leadership and critical suppliers.
Scope also records which sharing agreements, marking rules and sanitization steps your own policies require before any release.

How we build

We configure case management and threat intelligence platforms so sharing permissions and distribution groups match the agreed scope.
Sanitization and export steps for attacker TTPs are set up so indicators leave the platform only in agreed formats.
We test sharing paths with sample, non-sensitive data to confirm access controls and audit trails behave as documented.

How we hand over

Handover includes configuration records, sharing runbooks and the audit trail settings that show who shared what and when.
Documentation maps each sharing workflow to the RS.CO-03 outcome and to the evidence an independent assessor would request.
Your team receives walkthroughs so staff can run sharing steps and explain them to an auditor without DeployOpen present.

How we support

Ongoing support, upgrades and continuous testing of the sharing platforms are available as retainers after handover.
Retainers can cover platform updates, sharing agreement changes and periodic checks that audit trails still record each disclosure.
DeployOpen prepares evidence for assessments, while independent auditors or certification bodies issue any reports or certificates.