Outcomes, capabilities, and services that the organization depends on are understood and communicated
Organizations rarely operate entirely on their own infrastructure. Cloud providers, SaaS tools, payment processors, and third-party APIs all underpin critical business functions, and a failure in any one of them can cascade into a major incident. Mapping the internal dependencies on external capabilities helps you identify single points of failure, inform vendor risk management, and build realistic continuity plans that account for third-party outages.
Implementation steps
- 1
Map internal dependencies on external services and capabilities
Work with engineering and operations teams to identify every external service the organization relies on: cloud infrastructure (AWS, Azure, GCP), SaaS applications, payment processors, DNS providers, CDNs, and identity providers. Note what internal functions depend on each.
confluencemirogoogle-sheetslucidchart - 2
Assess criticality and failure impact for each dependency
For each identified dependency, document what happens if it becomes unavailable or is compromised. Rate each by business impact and categorize dependencies as critical, important, or supporting. This feeds business continuity planning and vendor risk assessments.
confluencegoogle-sheetsjira - 3
Communicate dependency risks internally and keep the map current
Share the dependency map with leadership, engineering leads, and the incident response team. Assign an owner to update the map when new services are adopted or deprecated. Review the map at least annually and after significant architecture changes.
confluenceslackgoogle-docs
Evidence required
Internal dependency map or register
A documented inventory of external services and capabilities that the organization depends on, with associated business functions and impact assessments.
- · Architecture diagram annotated with external service dependencies
- · Vendor/service inventory spreadsheet with criticality ratings
- · Business continuity plan section covering third-party dependencies
Evidence of communication and awareness
Proof that the dependency map has been shared with relevant stakeholders and is incorporated into planning processes.
- · Incident response playbook referencing critical third-party services
- · Risk register entries for high-criticality external dependencies
- · Architecture review documentation acknowledging dependency risks
Related controls
Critical objectives, capabilities, and services that external stakeholders depend on or expect from the organization are understood and communicated
Organizational Context
The organizational mission is understood and informs cybersecurity risk management
Organizational Context
Internal and external stakeholders are understood, and their needs and expectations regarding cybersecurity risk management are understood and considered
Organizational Context
Legal, regulatory, and contractual requirements regarding cybersecurity, including privacy and civil liberties obligations, are understood and managed
Organizational Context