HKMA OR-2 compliance depends on visibility and containment

At a glance

What this is: This is a banking resilience analysis of HKMA OR-2 that argues visibility, containment, and continuous testing are the core compliance requirements.

Why it matters: It matters because resilience programmes now have to prove operational control across interconnected systems, including identity-mediated access paths and third-party dependencies, not just document intent.

👉 Read Illumio’s analysis of HKMA OR-2 compliance and banking resilience

Context

Operational resilience is the ability to keep critical services running through severe disruption, not just to detect risk after the fact. In banking, that shifts attention from isolated controls to mapped interdependencies, blast radius, and recovery readiness across hybrid environments, third parties, and business services.

HKMA OR-2 raises that bar for Hong Kong banks by requiring evidence that important business services are understood, protected, and testable under stress. The identity angle is indirect but real: the systems that create, route, and authorize access are part of the dependency chain, so access governance and containment become part of resilience rather than a separate compliance track.

Key questions

Q: What breaks when banking resilience programmes cannot see critical dependencies?

A: When banks cannot see critical dependencies, they cannot predict how a disruption will spread or which service to contain first. That turns recovery into guesswork and often leaves business continuity plans detached from reality. The result is longer outages, poor escalation choices, and weaker evidence for regulators that critical services can survive severe disruption.

Q: Why do hybrid banking environments make operational resilience harder to prove?

A: Hybrid environments combine legacy systems, cloud services, and third-party links, which increases the number of hidden dependencies that can fail together. That makes it harder to demonstrate service continuity under stress because the bank must control and evidence many more interconnection points than in a simpler estate.

Q: What do security teams get wrong about containment during incidents?

A: They assume containment can be improvised quickly under pressure. In practice, manual coordination across teams is slow and error-prone, especially when cloud, on-premises, and machine identities are all involved. Containment has to be pre-enforced through policy and access design, or the environment will remain too open when crisis hits.

Q: Who is accountable when an operational disruption exceeds impact tolerance?

A: Accountability sits with the business service owner, the risk function, and the technical teams that manage dependencies and recovery execution. Regulators expect those roles to be clear before an incident occurs, because impact tolerances only mean something when ownership for containment, communication, and restoration is already defined.

Technical breakdown

Why visibility is the first resilience control

OR-2 style resilience programmes fail when teams cannot trace how applications, infrastructure, data flows, and operational dependencies connect. Visibility is not a dashboard requirement alone. It is the control that lets banks identify critical business services, spot hidden couplings, and understand where a disruption can spread. In hybrid banking estates, that often means correlating legacy systems, cloud workloads, third-party links, and internal support processes into a single operational picture. Without that map, recovery plans remain theoretical because nobody can see which systems must be isolated first or which dependencies make a service fragile.

Practical implication: build service-to-dependency mapping that supports blast-radius analysis before you try to certify resilience.

How containment reduces operational blast radius

Containment is the practical counterpart to visibility. Once a disruption begins, segmentation and isolation limit how far it can move across workloads, business units, and supplier connections. That matters in banking because the same dependency chains that support efficiency also allow ransomware, system failure, or data theft to cascade quickly. Containment does not remove the initial event, but it reduces the chance that one compromised system turns into a market-facing outage. In identity terms, any access path that can traverse multiple services without strong scoping becomes part of the blast radius problem.

Practical implication: pre-stage segmentation and isolation controls around critical services so response teams can contain spread without improvising.

Why scenario testing has to reflect real failure paths

Scenario-based testing only works when it reflects the actual ways services fail. OR-2 expects banks to test disruptions, supplier collapse, and cyberattack propagation, not generic tabletop discussions. That means testing whether teams can maintain customer communication, evidence recovery decisions, and restore essential services within agreed tolerances. The strongest programmes treat testing as proof of control design, not a compliance ceremony. They also use test outcomes to refine dependencies, escalation paths, and decision authority across operations, risk, and technology.

Practical implication: run exercises that combine technical failure, operational decision-making, and reporting obligations, then remediate gaps immediately.

Threat narrative

Attacker objective: The objective was to disrupt banking operations, pressure recovery capability, and expose sensitive data while amplifying the operational and reputational cost.

1. Entry occurred through ransomware impact on ICBC’s U.S. broker-dealer operations, which disrupted core transaction processing and forced manual workarounds.
2. Escalation followed as the disruption rippled into operational dependency chains, exposing how tightly linked systems, people, and recovery processes were across the banking environment.
3. Impact was measured in delayed Treasury trades, exfiltrated sensitive data from the London branch, and broader confidence damage across the financial ecosystem.

NHI Mgmt Group analysis

Operational resilience has become an access-governance problem as much as a continuity problem. Banks do not fail only because systems go down. They fail when access paths, supplier links, and recovery dependencies create a blast radius larger than the organisation can contain. OR-2 therefore pushes resilience thinking into the same space as segmentation, privileged access reduction, and service scoping. The control question is not just whether recovery exists, but whether the environment can be constrained fast enough for recovery to matter.

Visibility debt is the hidden failure mode behind many resilience programmes. Organisations often have policies, but they lack a current, decision-useful map of what depends on what. That gap turns every incident into discovery under pressure, which is precisely when operational mistakes multiply. In banking, where critical services span legacy infrastructure, cloud, and third parties, the inability to see dependency chains is itself a resilience defect. Practitioners should treat that defect as measurable governance debt, not a tooling inconvenience.

Containment is the resilience control that converts testing into proof. Scenario exercises only become meaningful when teams can show how a disruption is isolated, which services stay live, and what fallback decisions are taken in sequence. That makes containment the bridge between technical controls and board-level resilience claims. For banks, the strongest compliance posture is one that can demonstrate bounded failure, not just recovery intent.

OR-2 validates a broader market shift toward operational control evidence instead of document-heavy assurance. Regulators are moving beyond statement-of-policy compliance and asking whether institutions can demonstrate service continuity under stress. That trend will pressure banks to align resilience reporting with actual runtime visibility, dependency management, and recovery performance. Practitioners should assume evidence quality will matter as much as policy quality.

Resilience programmes will increasingly be judged by their ability to govern third-party and cross-domain dependencies. The article’s emphasis on interconnections reflects a reality many teams still understate: a critical service can be undermined by systems outside the immediate control of the bank. That makes supplier oversight, service mapping, and access boundary clarity part of resilience governance. Practitioners should expect audits to ask where control actually stops.

What this signals

Visibility debt will increasingly be audited as a control weakness, not a reporting gap. Banking resilience programmes that cannot evidence dependency mapping will struggle to prove they can isolate disruption before it becomes systemic. The practical shift is toward service-level observability, where access boundaries and recovery paths are mapped as part of resilience design, not left to incident response.

The identity dimension matters because many resilience failures are amplified by standing access, broad vendor pathways, and poor offboarding discipline. If a disrupted service can still propagate through unmanaged access paths, containment claims are weak even when the technology stack looks robust. Programmes should align resilience work with identity and access governance so blast-radius control becomes measurable.

Resilience evidence will also need to move closer to runtime proof. Boards and regulators will increasingly expect banks to show how controls behave during failure, not just how they are described in policy. That makes exercises, segmentation data, and dependency inventory quality part of the governance record.

For practitioners

• Map critical business services to live dependencies Create a service map that shows applications, data flows, support teams, and third-party connections for each important business service. Use that map to identify where a single failure can cascade across banking operations and where isolation must happen first.
• Predefine isolation paths for high-value services Document how to segment or isolate critical systems without waiting for a crisis decision. Include the access boundaries, escalation owners, and recovery dependencies that must be preserved while limiting blast radius.
• Test resilience with realistic disruption scenarios Run exercises that combine ransomware, supplier failure, and service degradation, then verify customer communication, regulator reporting, and restoration sequencing. Treat each exercise as evidence that your containment design works under pressure.
• Review privileged and third-party access boundaries Check whether any administrative or vendor access path can move too broadly across critical services. Tighten those paths so a compromise in one zone does not become an enterprise-wide outage.

Key takeaways

• HKMA OR-2 pushes banks to prove operational resilience through visibility, containment, and testing, not through policy statements alone.
• The ICBC incidents show how one disruption can cascade across trading, data exposure, and customer trust when dependency chains are not controlled.
• Banks that can map services, isolate failures, and rehearse realistic scenarios will be better positioned to satisfy resilience expectations and limit business impact.

Key terms

• Operational resilience: The ability to deliver critical services through severe disruption and recover within acceptable limits. In practice, it combines dependency mapping, containment, recovery planning, and testing so the organisation can prove continuity rather than only describe it.
• Blast radius: The amount of business, technical, or operational damage that an incident can spread before it is contained. In banking, blast radius is shaped by interconnections, segmentation quality, privileged access paths, and how quickly teams can isolate affected services.
• 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.
• Scenario-based testing: A resilience validation method that simulates realistic disruptions to check whether people, processes, and systems can maintain or restore critical services. It is most useful when it includes technical failure, decision-making, communication, and regulator reporting, not just tabletop discussion.

What's in the full article

Illumio's full blog covers the operational detail this post intentionally leaves for the source:

• The article’s step-by-step explanation of HKMA OR-2 expectations for critical business services and impact tolerances.
• The vendor’s description of how its visibility model maps cloud, data centre, and endpoint communications without traditional network scans.
• The segmentation workflow it describes for isolating threats and limiting blast radius during ransomware or other disruption.
• The reporting and testing practices it says banks can use to demonstrate preparedness to regulators and boards.

👉 Illumio’s full post covers the ICBC examples, containment approach, and resilience testing expectations.

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 build the governance foundations that support wider resilience and access-control programmes.