The CPS 230 Deadline: Is Your Legacy Software Compliant?

Your aging on-premises systems are no longer merely inefficient, they are now a material operational risk under CPS 230. With the July 2025 deadline for APRA’s CPS 230 fast approaching, Australian organizations must prove their critical operations are resilient, not just functional.

Introduction

For CIOs and IT Managers in Australia’s finance and critical infrastructure sectors, the Prudential Standard CPS 230 Operational Risk Management represents a fundamental shift. It moves the goalposts from "disaster recovery" to "operational resilience."

This standard applies to all APRA-regulated entities, including banks, insurers, superannuation funds, and RSE licensees. Unlike modern cloud-native applications designed for redundancy, legacy systems are often brittle, hard to recover, and opaque. Crucially, APRA places ultimate accountability for operational risk management on Boards and Senior Management, meaning technology stability is now a governance issue.

This article explores why legacy modernization is no longer optional under CPS 230 and outlines a practical framework to secure your compliance before the deadline.

Section 1: The Regulatory Ticking Clock (Why This Matters Now)

On 1 July 2025, APRA’s CPS 230 comes into full effect. The standard mandates that regulated entities must maintain the operation of critical functions within approved tolerance levels, even during severe disruptions.

The Definition of Critical Operations

A "critical operation" is any process where a disruption would have a material adverse impact on depositors, policyholders, or the stability of the financial system. APRA requires entities to identify these operations and set Board-approved tolerance levels for disruption. These tolerances must be "credible, measurable, and regularly tested" (CPS 230, paras 27-33).

If your core banking ledger, claims processing engine, or payment switch runs on end-of-life (EOL) hardware, you are carrying a high-severity operational risk.

Why Legacy Systems Fail Compliance

Legacy infrastructure often fails to meet the strict regulatory requirements because of the hidden costs and technical debt that accumulate over time:

• Slow Recovery: Monolithic architectures can take days to rebuild, breaching the 4-8 hour tolerance windows often set for critical services.
• Scenario Testing Gaps: APRA expects disruptive but plausible scenarios to be tested annually (para 42). Legacy systems often cannot support these simulations without actual risk of catastrophic failure.
• Lack of Observability: You cannot report on what you cannot see. Black-box legacy apps often lack the telemetry needed for the proactive risk management APRA demands.
• Service Provider Dependency Risk: CPS 230 explicitly covers your supply chain. If legacy systems rely on unsupported vendors, you cannot demonstrate that the service provider meets required operational and security controls. Entities must ensure third-party contracts enforce these resilience capabilities.

Section 2: Common Mistakes / Wrong Approaches

As the deadline looms, we see organizations making panic-driven decisions that fail to address the root cause.

1. The "Paperwork Compliance" Trap
   Updating your Business Continuity Plan (BCP) without testing the underlying technology is dangerous and fails to meet APRA's requirement for "evidence-based assurance." If your BCP says you can recover in 4 hours but your tape restore takes 12, you are non-compliant.

2. Lift-and-Shift Without Refactoring
   Simply moving a fragile on-premises application to a cloud Virtual Machine (VM) ("Rehosting") does not automatically improve resilience. As we explored in the cloud migration reality, cloud-lifted legacy systems often inherit the same single points of failure, recovery challenges, and poor observability unless modernized.

3. Ignoring Data Integrity
   Resilience isn't just about uptime; it's about data. CPS 230 expects entities to "minimize data loss in disruption scenarios," typically requiring near-real-time replication for critical operations to meet stringent Recovery Point Objectives (RPO). Reliance on nightly batch backups often falls short of this requirement.

Section 3: Hrishi Digital’s Practical Framework

We use a four-step framework to transition legacy environments into CPS 230-compliant assets.

1. Assess (Criticality Mapping)

We map failure scenarios specifically to your Board-approved tolerance levels (RTO/RPO), not just identify single points of failure (SPOFs). We identify which legacy components threaten your defined critical operations.

2. Stabilise (Immediate Risk Reduction)

We implement interim risk controls while long-term modernization occurs. This often involves introducing immutable backups and automated failover mechanisms to shore up immediate vulnerabilities.

3. Modernise (Cloud-Native Resilience)

We move from monolithic structures to decoupled architectures. While microservices are a common pattern, many APRA-regulated entities benefit from domain-driven modularization to separate critical failure domains. This ensures that the failure of a non-critical component does not take down a critical one.

4. Optimise (Continuous Monitoring)

We deploy modern observability tools to provide real-time dashboards of system health, facilitating continuous control monitoring and Board-level reporting on operational risk profiles.

Code Examples: Implementing Resilience as Code

To meet CPS 230's requirement for verifiable recovery, we recommend defining your infrastructure recovery policies as code. Below is an example of an Azure Bicep configuration that enforces Geo-Redundant Storage (GRS).

Note: While this example uses Azure Bicep, the same 'Compliance as Code' principles can be applied using Terraform or AWS CloudFormation.

// Bicep template to ensure Critical Operation data is Geo-Redundant
// This supports the 'Data Preservation' requirement of CPS 230

param location string = resourceGroup().location
param vaultName string = 'rsv-critical-ops-prod-001'

resource recoveryServicesVault 'Microsoft.RecoveryServices/vaults@2023-01-01' = {
  name: vaultName
  location: location
  sku: {
    name: 'RS0'
    tier: 'Standard'
  }
  properties: {
    // CRITICAL: Ensure Geo-Redundancy is enabled for compliance
    redundancySettings: {
      standardTierStorageRedundancy: 'GeoRedundant'
      crossRegionRestore: 'Enabled'
    }
    securitySettings: {
      // Protect against ransomware (operational risk)
      softDeleteSettings: {
        softDeleteState: 'Enabled'
        softDeleteRetentionPeriodInDays: 14
      }
    }
  }
}

output vaultId string = recoveryServicesVault.id
output redundancyMode string = recoveryServicesVault.properties.redundancySettings.standardTierStorageRedundancy

Section 4: Local / Strategic Advantage

For Australian organizations, particularly in the NT and national critical infrastructure sectors, Hrishi Digital offers a strategic partnership:

• Sovereign Data Focus: We design architectures that align with PROTECTED controls, ASD guidance, and APRA’s expectation for data residency, ensuring your data remains compliant with Australian sovereignty requirements.
• Legacy .NET & SQL Specialists: We specialize in the difficult work of modernizing .NET and SQL legacy bases that others find "too risky" to touch. Our ASP.NET Core migration roadmap provides a proven framework for these transformations.
• Darwin-Based Support: We operate in your timezone, providing local expertise for Northern Australia's unique business landscape.

Section 5: Case Study Snapshot

Scenario: A regional credit union (APRA-regulated) used a 12-year-old on-premises SQL cluster for core transaction processing.

• The Risk: The disaster recovery process relied on manual tape transport, with an estimated recovery time of 24+ hours, well outside their new 4-hour tolerance.
• The Solution: Hrishi Digital migrated the database to Azure SQL Managed Instance (Business Critical Tier) with auto-failover groups enabled.
• The Result:
  • RTO: Reduced from 24 hours to < 1 hour.
  • RPO: Reduced from 24 hours to < 5 seconds.
  • Governance: The credit union’s Board used the new resilience metrics to meet CPS 230 annual testing and reporting obligations.

Best Practices for CPS 230 Compliance

• Test Failures Regularly: Don't wait for a disaster. Run "Chaos Engineering" drills to prove your systems recover as expected.
• Automate Documentation: Use tools that automatically generate topology maps and recovery logs to provide evidence to auditors.
• Decouple Critical Services: Isolate your critical operations from non-critical noise to reduce the "blast radius" of any failure.
• Enforce Service Provider Contracts: Ensure critical service providers including software vendors, cloud platforms, and datacentre partners have contractual obligations to maintain resilience capabilities and provide evidence during audits.

Conclusion

The CPS 230 deadline is non-negotiable. Beyond compliance, the ultimate goal of CPS 230 is protecting customers and maintaining financial stability. Modernizing legacy systems is no longer just about performance or features; it is a condition of your license to operate. By assessing, stabilizing, and modernizing your stack now, you turn a regulatory burden into a competitive advantage of reliability. Learn how our legacy system modernization services can help you meet compliance deadlines.

Ready to secure your critical operations?

Primary CTA: Book a Free CPS 230 Legacy Assessment – Let’s review your critical systems and map out a modernization path before the deadline.