APRA CPG 235 turns data governance into a resilience issue

At a glance

What this is: This is an analysis of how APRA's CPG 235 pushes Australian financial services to treat data governance as a resilience and trust control, not just a compliance exercise.

Why it matters: It matters because data lifecycle oversight, access governance, and automation increasingly shape both regulatory alignment and the security posture of identity-linked financial data.

By the numbers:

• In the first half of 2025, the OAIC recorded 532 data breach notifications.
• The financial services industry accounted for 14% of incidents recorded by the OAIC in the first half of 2025.

Context

Australian financial services firms are being asked to govern data as a lifecycle asset, which means treating capture, access, retention, publication, and disposal as controlled stages rather than isolated IT tasks. That shift matters because governance failures now show up as resilience problems, compliance gaps, and trust erosion, not just administrative inefficiency.

CPG 235 is relevant here because it links data governance to risk ownership, lineage, assurance, and operational control. For practitioners, the key issue is whether the organisation can prove who owns data decisions, how controls follow the data, and whether access and retention rules are enforced consistently across systems and business units.

Key questions

Q: How should organisations govern data across its lifecycle?

A: Organisations should treat governance as a chain of controls across acquisition, storage, transfer, retention, and disposal. Each stage needs an owner, a policy, and a way to flag violations back to the source. Without stage-level accountability, lifecycle governance becomes a set of disconnected documents instead of an operational control model.

Q: What are the signs that data governance is failing in a financial services environment?

A: Common signs include duplicate and derivative data spreading across systems, inconsistent classification, incomplete inventories, overexposed records, and data moving without clear controls. If teams cannot reliably map sensitive data before cloud migration or quantify where regulated information is stored, governance is already operating with blind spots. Those gaps usually show up later as audit friction, remediation delays, or avoidable exposure.

Q: What are the signs that data governance is not keeping pace with APRA expectations?

A: Common signs include unclear ownership, manual exception handling, inconsistent retention rules, weak lineage visibility, and access approvals that are not tied to the data lifecycle. If teams cannot explain where critical data sits, who controls it, and how decisions are evidenced, the governance model is already drifting from operational reality.

Q: What should governance teams do when agent access, data sensitivity, and compliance obligations conflict?

A: Prioritise the strictest data handling requirement and make the agent inherit that constraint through policy, not through manual exception handling. Where access, sensitivity, and regulatory context do not align, the safe default is to restrict retrieval and disclosure until the combined risk is resolved. That approach is closer to enforceable governance than post-hoc review.

Technical breakdown

Why data lifecycle governance fails when ownership is fragmented

A data management framework only works when ownership is explicit. If data owners, custodians, and stewards are unclear, governance becomes a series of disconnected approvals instead of a consistent control model. That fragmentation is especially risky in financial services, where data flows across core banking, analytics, reporting, and customer-facing systems. CPG 235 effectively requires organisations to connect policy, accountability, and operational enforcement so controls are visible at each stage of the data lifecycle. Without that structure, lifecycle oversight turns into exception handling and audit recovery rather than proactive governance. See the NIST SP 800-53 Guide.

Practical implication: Define ownership by lifecycle stage and make each role accountable for a specific control decision, not just a general governance title.

How data lineage and assurance support regulatory control

Lineage is the ability to trace where data came from, how it changed, and where it is used. Assurance adds the evidence that those paths are controlled and reviewed. Together, they let a financial organisation show that critical data is not only stored correctly but also processed and shared under governed conditions. That matters under CPG 235 because a control that cannot be traced or evidenced is hard to defend in an audit or incident review. In practice, lineage diagrams and metadata repositories become governance infrastructure, not documentation extras.

Practical implication: Use lineage and assurance evidence to test whether access, retention, and publication controls still hold after data moves between systems.

Why automation changes the economics of data governance

Manual governance does not scale cleanly across hybrid environments. As data volumes grow, people end up relying on sampling, exception queues, and delayed reviews, which leaves too much control drift between policy and enforcement. Automation changes that by making classification, retention, and access decisions repeatable at the point of action. In financial services, that matters because data governance is intertwined with regulated records, sensitive customer data, and privileged access to models and treasury information. Automation does not replace accountability, but it does reduce the amount of governance that depends on memory and spreadsheet control.

Practical implication: Automate classification, retention, and access control enforcement where policy decisions need to hold across multiple systems and business units.

Threat narrative

Attacker objective: The practical objective is to reach valuable financial and personal data with enough access and ambiguity to use it, move it, or expose it without immediate detection.

1. Entry occurs through broad, poorly governed access to distributed data stores, analytics platforms, or operational repositories rather than through a single perimeter failure.
2. Privilege is escalated when access approvals, retention exceptions, or data-owner decisions are not tied to enforceable lifecycle controls.
3. Impact follows when data exposure, misuse, or poor traceability undermines regulatory compliance, operational resilience, and customer trust.

Breaches seen in the wild

• Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.

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

Data governance is now a control plane, not a records function. CPG 235 shows that financial organisations cannot treat governance as documentation layered on top of operations. The real issue is whether data decisions are enforced at the point of use across capture, processing, retention, publication, and disposal. That makes governance a live control surface rather than a back-office policy exercise. Practitioners should manage it as part of the security architecture.

Lifecycle control is the named concept that separates compliance from resilience. If an organisation can classify, trace, retain, and dispose of data consistently, it can defend both regulatory intent and operational behaviour. If it cannot, then audit findings are likely to reflect a deeper control gap, not a paperwork problem. This is where data breach notification checklist discipline becomes relevant because uncontrolled lifecycle decisions quickly become reporting and response problems. Practitioners should close the lifecycle gap before it becomes an incident narrative.

Financial services data governance and identity governance now intersect at access decisions. The article repeatedly ties data controls to approvals, segregation of duties, and role accountability, which means identity controls are no longer separate from data risk management. When access to credit risk models, treasury data, or customer records is governed inconsistently, identity and data failures reinforce each other. That makes privileged access oversight a data governance issue as much as an IAM issue. Practitioners should align identity controls with the data lifecycle they are meant to protect.

Automation is becoming the only realistic way to keep governance consistent at scale. Hybrid estates create too many control touchpoints for manual review to remain reliable on its own. The article's core signal is that classification, retention, and access enforcement must happen continuously if governance is to remain credible. That does not reduce the need for accountability; it makes accountability measurable. Practitioners should use automation to make governance repeatable, evidence-based, and operationally enforceable.

Read next: NIST SP 800-53 Guide

What this signals

APRA-style data governance is converging with identity governance. Once access, lineage, and retention all become part of the same control story, IAM teams can no longer treat data governance as a separate discipline. The practical consequence is that access review, privileged access, and lifecycle enforcement need to be evaluated against the data they protect, not only against the account or role.

Data lifecycle drift is the governance gap many programmes miss. Policies often exist, but they fail when classification, retention, and disposal are not enforced consistently across hybrid environments. The programme-level risk is not only non-compliance. It is the loss of confidence that critical data can be traced, controlled, and defended when conditions change.

Automation will increasingly determine whether governance scales or decays. Manual review can still support exceptions, but it cannot be the primary mechanism for a large financial data estate. The programmes that sustain control will be the ones that embed enforcement into operational workflows rather than relying on periodic after-the-fact checks.

For practitioners

• Define lifecycle ownership for critical data Assign named owners, custodians, and stewards to capture, processing, retention, publication, and disposal decisions so governance has accountable control points.
• Map lineage for regulated data sets Build traceability for where critical data originates, how it changes, and which systems consume it so assurance can follow the data path.
• Automate classification and retention enforcement Apply policy controls automatically across hybrid repositories so sensitive data is tagged, retained, and disposed of consistently.
• Tie high-risk access to segregation of duties Require workflow controls for access to treasury, risk, and customer data so approvals and exceptions are visible and reviewable.
• Use assurance reviews to test control durability Schedule recurring checks that compare policy intent with actual enforcement across systems, then remediate drift before it becomes an audit issue.

Key takeaways

• Data governance in financial services now carries resilience and trust implications, not just compliance obligations.
• The article's evidence points to a control problem at the lifecycle level, where ownership, lineage, and enforcement must stay aligned.
• Automation and explicit accountability are the practical levers that keep policy from drifting away from operational reality.

Related NHI Mgmt Group resources: Data Breach Notification Checklist · NIST SP 800-53 Guide · Financial Services Identity Security Guide

Key terms

• Data Lifecycle Management: The governance of data from creation through use, retention, publication, and disposal. In regulated environments, it is not just storage administration. It is the set of controls that decides how data moves, who can touch it, and when it must be removed or archived.
• Data Lineage: The record of how data moves across systems, applications, and workflows. In security operations, lineage shows where sensitive data propagates, which identities touch it, and how a compromise could spread across connected environments.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Governance Automation: Governance automation is the use of software-driven workflows to perform recurring compliance and access control tasks with less manual effort. In ERP and cloud environments, it helps standardise reviews, reporting, and exception handling while preserving oversight, evidence, and accountability for decisions.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, secrets management, and workload identity. It helps practitioners connect identity controls to the wider security programmes that data governance now depends on.