Dependencies
Definition
Dependencies are the people, processes, technologies, services, and third parties that a system, business process, or control relies on to operate securely and meet objectives. In ISO/IEC 27001:2022, dependencies are surfaced when you define organizational context and interested parties (Clauses 4.1 and 4.2), determine scope (Clause 4.3), and perform risk assessment and treatment planning (Clause 6.1). They are also central to operational planning (Clause 8.1) and to resilience expectations such as ICT readiness for business continuity (Annex A 5.30), redundancy (Annex A 8.14), and supplier and ICT supply chain security (Annex A 5.19–5.21). Dependencies can be internal (e.g., identity and access management, logging, key management, network connectivity, staffing) or external (e.g., cloud hosting, telecoms, payment processing, managed security services, critical software libraries). Understanding upstream and downstream dependencies helps teams anticipate cascading failures, validate control effectiveness, prioritize remediation, and document evidence for audits. Effective dependency management typically includes maintaining a dependency register, mapping service-to-service relationships, defining ownership and SLAs/OLAs, assessing third-party and software supply chain risks (including transitive dependencies), and validating recovery requirements (RTO/RPO) through testing. Equivalent concepts appear in other assurance approaches as service mapping, criticality analysis, third-party risk, and supply chain security.
Real-World Examples
Startup SaaS critical service dependencies
A small SaaS provider maps dependencies on identity services, email delivery, DNS, and cloud hosting to ensure access controls and incident response still work during outages.
Microservices and shared platform dependencies
A scaleup documents how microservices depend on shared logging, message queues, and key management so a single platform issue does not silently break monitoring or encryption.
Third-party and supply chain dependencies
An enterprise evaluates dependencies on key suppliers and telecom providers, including contractual SLAs and contingency options, to reduce operational and compliance disruption risk.
Software and transitive dependency exposure
A security team inventories application libraries and their transitive dependencies to identify vulnerable components and prioritize patching based on business criticality.
Dependencies are the internal and external things your services and controls rely on, such as platforms, people, processes, suppliers, and software components that can introduce risk or enable resilience.
Dependency mapping documents how systems and processes rely on one another, helping teams prevent cascading failures, prove control coverage, prioritize remediation, and plan recovery during disruptions.
Start from critical business services, list required systems and suppliers, confirm RTO/RPO needs, validate single points of failure, and test scenarios to confirm which dependencies must be restored first.
A dependency is anything required for operation (including internal services), while a third party is an external organization; third parties are a subset of dependencies but not the only type.
Maintain a dependency register with owners, criticality, upstream/downstream links, SLAs/OLAs, security requirements, evidence sources, and recovery expectations, and keep it updated via change management.
Upstream dependencies are services you rely on (like identity or networking), while downstream dependencies are systems that rely on you; both matter for impact analysis and incident communications.
Libraries and components can introduce vulnerabilities, licensing obligations, and supply chain exposure; unmanaged dependencies can undermine patching, monitoring, and assurance evidence for key controls.
Transitive dependencies are indirect components pulled in by other packages; they are hard to manage because they are less visible, change frequently, and can introduce hidden vulnerabilities and incompatibilities.
An SBOM lists the components and versions in software, making dependencies more transparent so teams can assess exposure, track vulnerable libraries, and demonstrate supply chain due diligence.
Common approaches include service catalogs, architecture diagrams, CMDB relationships, runtime tracing and telemetry, network flow analysis, and structured dependency registers linked to risk and change records.
| Version | Date | Author | Description |
|---|---|---|---|
| 1.0.0 | 2026-02-26 | WatchDog Security GRC Wiki Team | Initial publication |
