Critical objectives, capabilities, and services that external stakeholders depend on or expect from the organization are understood and communicated
When a security incident disrupts services that external parties rely on, the damage extends beyond the technical impact to include broken trust, contractual penalties, and reputational harm. Understanding exactly which of your outputs and capabilities matter most to customers, partners, and regulators allows you to apply the highest level of protection where it counts. This knowledge also enables faster, more targeted incident response when disruptions occur.
Implementation steps
- 1
Identify services and capabilities that external stakeholders depend on
Interview product, customer success, and sales teams to understand which services, APIs, data feeds, or capabilities are contractually committed or operationally critical to external parties. Cross-reference customer contracts and SLAs to identify formal obligations.
confluencenotiongoogle-docs - 2
Document dependencies and their security implications
For each external-facing service or capability, record who depends on it, what the expected availability and integrity requirements are, and what the impact of disruption would be. This feeds directly into business impact analysis and prioritized recovery planning.
confluencemirogoogle-docsjira - 3
Communicate critical service expectations internally
Share this information with engineering, operations, and security teams so that protection and recovery priorities are aligned with external commitments. Include critical services in tabletop exercises and continuity planning scenarios.
confluenceslackgoogle-docs
Evidence required
External dependency and critical services register
A documented list of services, capabilities, or outputs that external stakeholders depend on, with associated availability expectations and impact assessments.
- · Customer-facing SLA document listing uptime commitments and covered services
- · Business impact analysis identifying externally depended-on systems
- · Confluence page mapping external stakeholders to the services they rely on
Evidence of internal communication
Documentation showing that critical external dependency information has been shared with relevant internal teams.
- · Architecture review meeting notes referencing external service commitments
- · Incident response plan section prioritizing externally critical systems
- · Security roadmap or risk register entries flagging customer-facing services
Related controls
Internal and external stakeholders are understood, and their needs and expectations regarding cybersecurity risk management are understood and considered
Organizational Context
Outcomes, capabilities, and services that the organization depends on are understood and communicated
Organizational Context
The organizational mission is understood and informs cybersecurity risk management
Organizational Context
Legal, regulatory, and contractual requirements regarding cybersecurity, including privacy and civil liberties obligations, are understood and managed
Organizational Context