APJ regulators want evidence that critical services can recover, not simply confirmation that backups exist.
Something has shifted in the conversations I have with financial institution technology leaders across APJ. It’s subtle, but it matters.
The question used to be: Does our backup work?
Now the question is: Can we prove that our critical service would recover within tolerance, and can we show that to a regulator, auditor, or a risk committee?
Those are not the same question. And the gap between them is where I see a lot of institutions becoming unexpectedly exposed.
Backup, disaster recovery and business continuity remain essential. But a successful restore does not prove that a critical financial service can stay within its tolerance for disruption. Regulators increasingly expect evidence that critical operations can continue through severe disruption, including tested recovery times, reliable recovery records, and clear accountability across risk, audit, and regulatory stakeholders.
For infrastructure, security, platform, and operations teams, operational resilience is no longer just a technology-stack challenge. It is a technical evidence problem. The questions technology leaders are asking now are whether their organisation can:
- Recover the complete service, rather than an isolated workload?
- Achieve the expected recovery time under conditions resembling a real incident?
- Demonstrate what was recovered, what changed, and why the restored data should be trusted?
- Identify the people, systems or AI agents that accessed or changed sensitive data?
- Produce supporting evidence when risk, audit or a regulator requests it?
The operational requirement is no longer simply to run recovery. It is to make recovery repeatable, observable and defensible.
A successful restore does not prove that a critical service stayed within tolerance
Backup teams have traditionally measured success through tool-level outcomes: A virtual machine boots, a database connects, or a file is restored. Those outcomes still matter, but operational resilience asks a larger question: Did the complete critical service recover within the institution’s defined tolerance, and can the team prove it?
That service may depend on a legacy core, cloud services, SaaS applications, identity systems, and data distributed across multiple operating environments. Restoring one component does not establish that the end-to-end service is available or that it meets the institution’s defined tolerance.
This changes the unit of measurement. The question is no longer only whether each platform met its own recovery time objective (RTO) and recovery point objective (RPO). It is whether the combined recovery sequence restored the critical operation within tolerance, and whether evidence demonstrates that it did.
APJ requirements differ by market, but they converge on demonstrable and accountable resilience
Across the region, specific frameworks differ, but the direction is consistent: Resilience must be demonstrable, current, and accountable.
- Hong Kong: Financial institutions were expected to achieve full operational resilience by May 31, 2026, under the Hong Kong Monetary Authority’s Supervisory Policy Manual module OR-2.
- Australia: The Australian Prudential Regulation Authority’s CPS 230 sets operational-risk-management expectations, including board oversight and requirements related to material service providers and concentration risk.
- Singapore: The Monetary Authority of Singapore has consulted on updated Guidelines on Operational Risk Management, including expectations for financial institutions to define their operational-risk appetite and tolerance.
- New Zealand: The Reserve Bank of New Zealand’s BS11 requires large banks to demonstrate that they can continue operating if a parent organization or significant outsourcing provider fails. The Reserve Bank has also identified advanced AI as a factor regulated entities should consider in cyber-resilience planning.
- India: The Reserve Bank of India’s cybersecurity and operational-resilience requirements reinforce board-level accountability, incident reporting, and oversight of access to sensitive data.
The practical consequence for technical, security, infrastructure, and operations teams is clear: The controls you build and the recovery records you generate must support evidence that can travel up through the institution’s governance structures, not just satisfy a technical audit.
Tested recovery times carry more weight than estimated RTOs
Regulators and auditors increasingly want tested recovery times rather than estimates, along with logs showing that recovery worked under realistic conditions. That places greater importance on the evidence generated during recovery exercises.
In practice, a resilience test should enable an institution to establish: When the disruption began, when recovery actions occurred, whether dependencies were available, when the service became operational, whether the result stayed within tolerance, what exceptions occurred, and who accepted the outcome. These are evidence categories rather than a universal checklist. The principle is that claims about resilience need to be supported by testing, recovery records, and a defensible accountability chain, not asserted from memory.
In many financial institutions, security and recovery operations still hold two incomplete views of the same risk. Security teams understand data sensitivity and access exposure, but may lack direct visibility into recoverability. Backup and infrastructure teams, on the other hand, understand restore status, but may lack context about sensitivity, business importance, and regulatory relevance.
If those views are joined only during an incident or an audit, the institution may struggle to explain whether its most important data was correctly protected, whether the right recovery point was selected, and whether the restored state can be trusted. Operational resilience depends on connecting data classification, access visibility, and recovery evidence before an incident, not reconstructing that relationship when there’s a regulator in the room.
Human and AI activity are creating different accountability chains
One question I am seeing emerge, specifically in audits, is whether an action was performed by a person or an AI agent operating autonomously. Those two scenarios create different accountability chains. Auditors want to understand which applies and where responsibility sits.
For security and platform teams, provenance is now part of recoverability. Logs need to show not only that data changed but also who or what made the change and how responsibility is assigned. This is especially important when AI systems interact with sensitive data through training inputs, prompts, outputs, and generated logs. Automated systems can alter large volumes of data quickly: An agent may reclassify records, a pipeline may rewrite a dataset, or a model may update its training inputs without human approval.
Treating AI governance as a separate audit trail creates a parallel process that is disconnected from the controls the institution already uses for its other data. In my view, the more defensible approach is to extend existing recovery and accountability disciplines to this new surface, rather than building a separate standard that sits alongside it but never quite integrates with the rest.
Third-party and concentration risk must be accounted for in recovery design
Australia’s CPS 230 includes board-level expectations on third-party and concentration risk. New Zealand’s BS11 addresses whether large banks can continue operating if a parent organisation or major outsourcing provider fails. These requirements make supplier dependency a recovery issue, not just a procurement one.
Technical teams should be able to explain whether the institution can continue or recover if a provider responsible for a critical component becomes unavailable. That includes understanding whether recovery knowledge, administrative control, data access, or protected copies are concentrated with a provider that cannot be readily replaced.
Technical teams will define whether resilience is defensible
Operational resilience may be owned by risk committees and overseen by boards, but it is delivered through the daily decisions of infrastructure, security, platform, and operations teams. The best-prepared organizations will connect service dependencies, recovery validation, security controls, AI governance, and third-party risk in a repeatable, evidence-based resilience program, before an incident or audit exposes the gaps.
The question is no longer simply: “Can we recover?” Instead, the question is: “Can we prove that critical services will recover within tolerance when regulators, auditors, or risk committees ask us to demonstrate it?”
The answer will increasingly determine whether an institution can demonstrate resilience with evidence, or is left asserting it as a claim.
Download the new e-Book, Transforming Data Resilience for APJ Financial Services in the Age of AI, to see how leading financial institutions are strengthening data resilience across hybrid, SaaS, and AI environments while building the proof their risk committees now expect.
