Information is shared with designated internal and external stakeholders
During an incident, information asymmetry creates risk. When security knows the full scope of an attack but business stakeholders do not, decisions get made without the context needed to make them well. When partner organizations or sector peers are not informed of a threat, they remain exposed to attacks that you have already survived. Systematic information sharing, both internally across business functions and externally to trusted partners and sector groups, multiplies the value of hard-won incident intelligence.
Implementation steps
- 1
Establish a single source of truth for incident status during active incidents
Create a central incident status page or document that is updated continuously during an active incident: current assessment of scope and impact, timeline of key events, status of containment and remediation actions, and open questions. Share this with all internal stakeholders so that everyone is operating from the same information, rather than receiving siloed updates from different responders with different pieces of the picture.
confluencenotionstatuspageslack - 2
Define information sharing agreements with key external parties
Identify the external parties with whom you would share incident information and under what conditions: sector ISAC (Information Sharing and Analysis Center) for industry threat information, CERT/CISA for significant incidents, key technology partners and SaaS vendors who may be affected, and law enforcement for criminal incidents. Establish these relationships before an incident so that the channels and agreements exist when you need them.
confluence - 3
Classify information before sharing it externally
Not all incident information should be shared externally. Define a classification process for incident information: what can be shared with sector peers (typically sanitized IOCs and TTPs without identifying information about your organization), what is confidential to the organization, and what is under legal hold and should not be shared. Use TLP (Traffic Light Protocol) markings when sharing with external parties to communicate handling expectations.
confluence
Evidence required
Incident communication processes
Documentation of how incident information is shared internally and externally.
- · Incident response plan section on information sharing responsibilities
- · ISAC membership records and participation evidence
- · Incident status communication template or Slack channel convention
Information sharing records
Evidence that incident information was shared appropriately during past incidents.
- · IOC sharing records submitted to an ISAC or CISA
- · Incident status page or communication log from a past significant incident
- · TLP-marked threat intelligence shared with sector partners
Related controls
Internal and external stakeholders are notified of incidents in a timely manner
Incident Response Reporting and Communication
Internal and external stakeholders are understood, and their needs and expectations regarding cybersecurity risk management are understood and considered
Organizational Context
Critical objectives, capabilities, and services that external stakeholders depend on or expect from the organization are understood and communicated
Organizational Context
Cyber threat intelligence is received from information sharing forums and sources
Risk Assessment