Join our Newsletter — 33% off our NHI Course

What breaks when a bank cannot map critical dependencies for OR-2?

The bank loses the ability to prove which services are essential, how disruption spreads, and where containment should begin. That makes resilience evidence weak even if policies and playbooks exist. In practice, the failure is not just technical blind spots, but governance blind spots that stop leaders from showing regulators how important business services stay available under stress.

Why OR-2 Fails When Critical Dependencies Cannot Be Mapped

OR-2 is fundamentally an evidence problem, not just a documentation problem. If a bank cannot map the dependencies behind a critical business service, it cannot prove which upstream systems, suppliers, applications, or recovery paths matter most. That breaks the chain from business service to operational resilience evidence, so leaders are left with assertions instead of demonstrable dependency control.

The practical consequence is that the bank cannot show where stress will propagate or which functions must be contained first. For resilience work, that means the organisation may know its processes on paper but still be unable to demonstrate how those processes behave when real infrastructure, data, or third-party dependencies fail.

What Governance Gaps Appear Behind the Technical Blind Spot

The bigger failure is governance. Dependency mapping is what turns a list of systems into an accountable view of important business services, ownership, and exposure. When that map is missing, risk decisions become abstract, because the bank cannot tie resilience statements to named services, control owners, or measurable dependency chains.

This is why the issue often survives normal policy reviews. Policies can say resilience exists, but without dependency evidence there is no reliable way to test whether the bank can isolate a fault domain, prioritise restoration, or explain why one service is more critical than another under disruption.

The gap also makes supervisory conversations harder. A regulator usually wants to see how the bank knows what it must protect first, how it validates that knowledge, and how it keeps the evidence current as systems and vendors change.

What Breaks in Recovery, Containment, and Assurance

When dependency mapping is absent, recovery planning becomes guesswork. Teams may still have playbooks, but they cannot confidently decide which systems to restore first, which shared services create blast radius, or which downstream services will fail if one dependency is lost. That weakens containment, prolongs recovery, and increases the chance of restoring the wrong things in the wrong order.

It also undermines assurance across NIST Cybersecurity Framework 2.0, because identification, protection, and recovery all depend on knowing the service relationship set. The same logic aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially control families that require asset, access, and contingency discipline. For banks that rely heavily on connected applications and external platforms, the dependency view should also be tested against CISA cyber threat advisories and broader sector threat patterns, because shared services are often where disruption spreads fastest.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
NIST CSF 2.0 GV.SC-01 — Supply Chain Risk Management Critical dependency mapping includes supplier and shared-service exposure.
ID.AM-01 — Identities and Assets are inventoried Dependency mapping relies on knowing the systems that support critical services.
RC.RP-01 — Recovery Plan Execution OR-2 evidence depends on proving restoration order and service recovery assumptions.
Recommendation — Map critical suppliers and shared dependencies to recovery priorities and containment decisions. Inventory the assets and service relationships that underpin each important business service. Test restoration order against documented dependencies and recovery objectives.
NIST SP 800-53 Rev 5 CP-2 — Contingency Plan Dependency mapping is needed to make contingency planning credible.
RA-3 — Risk Assessment Missing dependency maps create unmanaged resilience and propagation risk.
SA-9 — External System Services Many critical dependencies are third-party or shared external services.
Recommendation — Tie contingency plans to the services and dependencies that determine restoration order. Assess disruption propagation across dependent systems and services. Document external dependencies and verify their impact on critical service availability.
ISO/IEC 27001:2022 A.5.29 — Information security during disruption OR-2 is about proving services remain available under disruption.
A.5.23 — Information security for use of cloud services Cloud dependencies often drive resilience and containment blind spots.
Recommendation — Align disruption planning to the dependencies that protect essential service availability. Record cloud service dependencies and test their effect on recovery sequencing.

Practitioner Guidance

What to prioritise: Treat dependency mapping as a resilience control, not a modelling exercise. The first question is whether the bank can name the dependencies that would stop an important business service from operating within its tolerance for disruption.

What to verify: Check that each critical service has an owner, a dependency chain, and a current recovery sequence. If the bank cannot show those three things together, the OR-2 evidence is incomplete even if the underlying systems are monitored.

Decision rule: If a dependency is shared, outsourced, or cross-domain, assume its failure can widen impact until the bank proves otherwise with tested recovery evidence. The safest default is to contain from the most connected shared dependency outward, not from the loudest business complaint inward.

Practitioner takeaway: OR-2 fails when resilience is described in policy language but not proven through service-to-dependency evidence; the bank must be able to show, not merely claim, how disruption moves and where containment starts.