TL;DR: HKMA OR-2 pushes banks to prove they can see critical dependencies, contain disruptions, and recover through severe but plausible scenarios, with ICBC’s ransomware and data theft incidents showing how operational fragility can cascade across markets and geographies, according to Illumio. The compliance challenge is less about policy volume than about demonstrable visibility, segmentation, and rehearsal.
At a glance
What this is: HKMA OR-2 frames banking resilience as the ability to map dependencies, contain disruption, and keep critical operations running under severe but plausible scenarios.
Why it matters: For IAM, PAM, NHI, and broader security teams, OR-2 is a reminder that governance evidence must show how access paths, system links, and third-party dependencies are controlled when incidents spread.
By the numbers:
- ICBC’s 2023 ransomware attack disrupted its U.S. broker-dealer operations.
Context
HKMA OR-2 is an operational resilience requirement, not a narrow security policy. It pushes banks to show they understand critical business services, their dependencies, and how disruption will be contained and recovered from across hybrid environments, third parties, and interconnected processes.
The governance problem is that many institutions can document controls without being able to prove they have the visibility needed to execute them under stress. In banking, that gap matters because a local failure can become a market, customer, and regulatory problem very quickly, especially when access paths and system interdependencies are opaque.
Key questions
Q: What breaks when a bank cannot map critical dependencies for OR-2?
A: 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.
Q: Why do hidden dependencies increase operational resilience risk in banking?
A: Hidden dependencies turn small incidents into service-wide outages because teams cannot predict which processes, vendors, or workarounds will fail together. When the dependency map is incomplete, the organisation may recover one system while another critical service still collapses. OR-2 makes that a governance problem, not just an architecture problem.
Q: How do banks know whether containment controls are actually working?
A: They know it by testing whether a disruption can be isolated without taking down connected critical services. Effective containment shows up as limited blast radius, preserved availability for unaffected systems, and clear recovery paths during realistic scenarios. If an exercise only proves the team can restore systems after the fact, it has not proven containment.
Q: What should banks do when OR-2 resilience testing exposes manual workarounds?
A: Treat the workaround as a control signal, not an operational inconvenience. If staff must rely on alternate channels or ad hoc procedures to keep trading, servicing, or reporting alive, the bank should review the dependency, the access path, and the containment boundary that failed. The goal is to eliminate ungoverned recovery habits before they become normal practice.
Technical breakdown
Operational resilience depends on dependency mapping, not policy volume
OR-2 is fundamentally about whether a bank can identify the systems, teams, vendors, and data flows that keep important business services running. That means mapping dependencies across cloud, data centre, endpoint, and third-party connections, then understanding which links would fail first under stress. In practice, the hard part is not writing resilience documents. It is keeping the map accurate enough to support real decisions when an incident unfolds. Practical implication: banks need live visibility into service dependencies, not static diagrams that drift out of date.
Practical implication: banks need live visibility into service dependencies, not static diagrams that drift out of date.
Containment is the control that limits blast radius
Containment in OR-2 terms is the ability to stop a disruption from spreading beyond the affected business service. In cyber incidents, that often means restricting lateral movement, isolating compromised segments, and preserving the availability of unaffected systems while investigation continues. This is where segmentation becomes operationally meaningful, because resilience is not only about restoration speed. It is also about preventing one compromised path from taking down connected services, counterparties, or reporting processes. Practical implication: resilience testing should prove that critical services can be isolated without collapsing the rest of the environment.
Practical implication: resilience testing should prove that critical services can be isolated without collapsing the rest of the environment.
Scenario testing has to reflect real banking failure modes
HKMA’s expectations go beyond tabletop discussion and into scenario-based testing that resembles real disruption. That includes cyberattacks that spread quickly, vendor failure, system outage, and operational workarounds that pressure manual processes. A realistic test should show whether teams can detect the issue, preserve critical operations, communicate with customers, and report to regulators without improvising every step. The point is continuous improvement, not theatrical rehearsal. Practical implication: banks should validate recovery playbooks against end-to-end disruption paths, not isolated technical events.
Practical implication: banks should validate recovery playbooks against end-to-end disruption paths, not isolated technical events.
Threat narrative
Attacker objective: The practical objective was to disrupt banking operations, degrade trust, and extract sensitive data from a globally interconnected financial institution.
- Entry began with ransomware disrupting ICBC’s U.S. broker-dealer operations, which showed how quickly a cyber event can move from technical compromise to operational interruption.
- Escalation followed as business workarounds replaced normal transaction processing, including use of USB drives and Gmail, which signalled process degradation after core systems were affected.
- Impact extended into financial and data consequences, including almost US$9 billion in unsettled Treasury trades and the later exfiltration of 6.6 terabytes from the London branch.
Breaches seen in the wild
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Visibility is the first governance control OR-2 really tests: banks cannot prove resilience if they cannot see how services, systems, vendors, and manual workarounds connect. Documentation without dependency clarity creates an assurance gap that only appears when disruption hits. The control issue is not theoretical mapping, it is whether the institution can explain its own operational topology under stress.
Blast-radius control is now a board-level resilience requirement: the article shows why containment must be treated as a business continuity capability, not just a network technique. In banking, the point is to preserve critical services while isolating the failure domain, especially where hybrid environments and third-party links widen the exposure surface. Practitioners should treat segmentation as a resilience enabler, not only an attack-prevention tool.
HKMA OR-2 exposes a governance assumption gap: many programmes assume that if controls exist on paper, critical services will survive disruption in practice. The ICBC examples show the opposite, where hidden dependencies and weak containment turn cyber events into operational crises. The named concept here is resilience evidence debt, meaning the accumulated gap between documented control intent and demonstrable end-to-end recovery capability. Practitioners should close that gap with evidence, not assurances.
Identity and access governance still sits inside this resilience story: when banks rely on manual workarounds, uncontrolled access paths and emergency operating methods become part of the attack surface. That means IAM, PAM, and NHI governance are not separate from operational resilience, because service continuity depends on who and what can still act safely during disruption. Practitioners should ensure emergency access, service accounts, and third-party paths are visible and containable.
OR-2 is pushing resilience from policy compliance into operational proof: the likely market effect is a stronger demand for evidence that critical services can be mapped, segmented, and recovered under pressure. That shifts attention from governance artefacts to runtime control and rehearsal quality. Practitioners should expect regulators to care more about demonstrable containment and recovery than about the volume of documentation.
What this signals
Resilience evidence debt: many banks can describe operational resilience in policy terms but still cannot demonstrate how critical services behave when systems, third parties, and manual processes fail together. OR-2 is effectively demanding proof that the organisation can contain disruption and keep operating, which shifts the burden from documentation to live control.
For identity and access teams, the practical signal is that emergency access, service accounts, and third-party pathways must be part of resilience design. When incidents force manual workarounds, the question becomes whether those paths are visible, bounded, and reversible before they become the new normal.
For practitioners
- Map critical service dependencies end to end Build and maintain a live view of how business services, data flows, third parties, and manual workarounds connect so OR-2 evidence reflects the current operating model.
- Prove containment with disruption scenarios Run exercises that show how a compromised segment, failed vendor, or cyber event can be isolated while unaffected services continue to operate.
- Test recovery through realistic banking failure modes Include customer communication, regulator reporting, and manual processing fallbacks in scenarios that mirror the bank’s actual interdependencies.
- Review emergency access and workaround paths Check whether privileged access, service accounts, and third-party links remain visible and governable when normal systems are unavailable.
Key takeaways
- HKMA OR-2 is less about writing resilience policies and more about proving that critical business services can still operate when disruption spreads.
- The ICBC examples show how quickly banking incidents can move from local compromise to market disruption and large-scale data exposure.
- Banks need live dependency visibility, tested containment, and realistic recovery exercises if they want to demonstrate OR-2 readiness.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | OR-2 depends on knowing and constraining access paths across critical services and workarounds. |
| RS.MI-01 — Incidents are contained | The article’s containment focus aligns with limiting incident spread across banking operations. | |
| RC.RP-01 — Recovery plan is executed during or after an incident | OR-2 requires banks to prove they can recover critical operations after severe disruptions. | |
| Recommendation — Review access permissions across critical services so resilience scenarios can be contained and recovered predictably. Design response playbooks to contain disruptions before they affect adjacent services or third parties. Test recovery plans against realistic banking disruptions and validate end-to-end continuity evidence. | ||
| CIS Controls v8 | CIS-5 — Account Management | Emergency access and operational workarounds depend on disciplined account governance during disruption. |
| Recommendation — Audit account governance so emergency and workaround access remains controlled during resilience events. | ||
| MITRE ATT&CK | TA0008;TA0040 — Lateral Movement; Impact | The ICBC examples show movement from operational disruption to wider impact across banking services. |
| Recommendation — Map disruptive banking incidents to lateral movement and impact tactics to prioritise containment controls. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged Access Rights | Privileged access and emergency operations become critical when banks need to contain and recover fast. |
| Recommendation — Restrict privileged access rights so emergency operations stay bounded during resilience testing and incidents. | ||
Key terms
- Operational Resilience: Operational resilience is the ability to keep critical services running or recover them quickly after disruption. In identity-led environments, that depends on authentication services, privilege management, and recovery procedures that can be tested under realistic failure conditions.
- Containment: The phase of incident response that stops an incident from spreading while preserving the evidence needed to investigate it. In cloud environments, containment often starts with identity revocation, isolation of workloads, and protection of logs before any system is terminated or cleaned up.
- Impact tolerance: The maximum acceptable level of disruption to a business service before the organisation is no longer operating within acceptable bounds. It is a governance measure, not a technical metric, and it only works when ownership, evidence, and testing are defined in advance.
- Dependency Mapping: Dependency mapping is the process of identifying which systems, services, and workflows rely on a given identity or secret. It is critical for NHI rotation because teams need to know what will fail before they change credentials. Without it, security teams often delay remediation to avoid outages.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps identity and security practitioners connect resilience, access control, and operational continuity across the programme.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org