How Do I Comply with APRA CPS 234? A Practical Guide to Information Security, Evidence, and Ongoing Assurance

By BCyber Security Team | CISSP, CISM Last updated: 14 October 2026

If you work in an APRA-regulated entity, CPS 234 compliance starts with a practical question: can you prove that your information security capability keeps pace with your information assets, material risks, and third-party dependencies?

That is not the same as having a policy pack in SharePoint, a green dashboard, or an annual audit report. In APRA reviews we have seen the same pattern across banking, superannuation, and insurance environments: organisations often believe they are compliant until they are asked to show current evidence of asset classification, control testing, vendor assurance, and incident readiness.

The organisations that do this well treat security as an operating discipline. In BCyber engagements, we see that disciplined teams usually have a live control map, clear ownership, and evidence that can be traced from board oversight all the way to technical validation. Our own platform inventory reflects that this is not a theoretical exercise: BCyber maintains 23 policies, 9 processes, 50 courses, 992 published articles, 563 knowledge hub entries, 11 clients, and 15 fact-find assessments across its CyberSuite environment.

Verification note: BCyber platform data and counts cited in this article were verified against internal platform inventory records at time of publication. Client examples are described in anonymised or sector-level terms to protect confidentiality.

What does APRA CPS 234 actually require?

CPS 234 is APRA’s prudential standard for information security. It applies to APRA-regulated entities across banking, insurance, superannuation, and related sectors. It also extends beyond your perimeter, because you must account for information assets managed by third parties and other service providers.

In practice, CPS 234 means your compliance position is shaped not only by internal controls, but also by the security posture of cloud providers, managed service providers, software vendors, and business partners who touch material information.

The standard is risk-based and proportional. Your security capability must be commensurate with:

• the size and nature of your entity
• the threats you face
• the criticality and sensitivity of the information assets you hold
• the reliance you place on internal teams and external providers

APRA expects judgement backed by evidence. That means:

• known assets
• documented risk decisions
• tested controls
• measured remediation
• board visibility
• timely incident escalation

CPS 234 is also ongoing. Compliance is not “we passed once”; it is “can we still prove this now?”

What APRA and related frameworks expect in practice

A mature CPS 234 program usually aligns with:

• APRA CPS 234 for information security governance and assurance
• ASD Essential Eight for baseline mitigation and hardening
• NIST Cybersecurity Framework (CSF) for control lifecycle structure
• ISO/IEC 27001 for policy, risk, and ISMS discipline
• NIST SP 800-53 for control catalog depth where needed

A common mistake is assuming ISO 27001 certification or an annual penetration test equals APRA compliance. It does not. Those inputs help, but they do not replace asset scoping, control-to-risk mapping, testing, and evidence retention.

For reference:

• APRA CPS 234: https://www.apra.gov.au/cps-234-information-security
• APRA prudential standards hub: https://www.apra.gov.au/prudential-standards
• ASD Essential Eight: https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight
• ACSC/ASD guidance: https://www.cyber.gov.au/
• NIST CSF: https://www.nist.gov/cyberframework
• ISO/IEC 27001 overview: https://www.iso.org/isoiec-27001-information-security.html

How should governance and accountability be arranged?

CPS 234 works best when accountability is explicit and operational.

The board should not be buried in technical detail, but it must still be able to see:

• the security posture
• material risks
• incidents
• testing outcomes
• remediation progress
• third-party exposure

Executives need clear ownership for decisions that cross technology, risk, legal, procurement, privacy, and operations. Information security leadership then turns that ownership into repeatable control activity, while internal audit and compliance provide independent challenge.

At BCyber, this is the point where many organisations benefit from GRACE Portal, the unified cyber resilience platform. GRACE Portal centralises single-dashboard visibility, cross-product analytics, executive reporting, compliance tracking, and real-time monitoring across the CyberSuite ecosystem. That matters because CPS 234 evidence is rarely in one place; the control story has to be stitched together.

What good board oversight looks like

Board reporting becomes meaningful when it links security activity to business risk. A strong board paper should explain:

• what changed
• why it matters
• what has been remediated
• what remains outside tolerance
• who owns the action
• when it will be closed

Useful evidence includes:

• board and committee papers
• security governance charters
• risk appetite statements
• RACI matrices
• executive reporting packs
• accepted risk records
• exception approvals

Practical scenario: banking

A mid-tier Australian bank may have a strong vulnerability management program but weak board visibility into exceptions for legacy payment systems. In a CPS 234 review, the issue is rarely “do you scan?” It is “can you show which critical assets are exposed, who accepted the risk, what interim controls were applied, and when the exposure is due to close?”

This is where Paradigm, BCyber’s AI Self-Learning GRC platform, is useful. Paradigm supports GRC automation, risk quantification, policy automation, and compliance mapping through the Synapse AI Engine. That kind of structured mapping helps translate technical evidence into board-ready assurance.

How do you identify and protect the information assets that matter?

You cannot defend what you cannot see.

CPS 234 assumes you know where your information assets live, including:

• applications
• cloud workloads
• endpoints
• servers and infrastructure
• backups
• paper records where relevant
• third-party systems
• data moving between environments

A living inventory is better than a perfect spreadsheet nobody updates.

Classification that actually drives control design

Assets should be classified using criteria that reflect:

• confidentiality
• integrity
• availability
• regulatory impact
• business criticality

In financial services, a claims processing platform may be more availability-sensitive than an archival records system. In healthcare, patient management systems can carry confidentiality and availability risk simultaneously. In government, citizen identity stores often require stronger identity assurance, logging, and segmentation because compromise can cascade into fraud or privacy harm.

When classification is done well, it becomes a control selector.

High-criticality systems typically require:

• stronger identity controls
• MFA and privileged access management
• encryption in transit and at rest
• tighter logging and SIEM correlation
• stronger backup and recovery
• more frequent control testing
• stricter vendor oversight

Lower-risk assets still need a baseline, but not every system deserves the same treatment.

Practical inventory approach

1. identify every system and repository that holds or processes information
2. assign an owner and business purpose
3. classify the system/data by sensitivity and criticality
4. map dependencies, including cloud and outsourced services
5. align controls to classification
6. review after changes, migrations, mergers, or vendor transitions

In BCyber terms, this is where GRACE Portal and Profiler often work together. Profiler is a behavioural intelligence platform focused on user profiling, access pattern monitoring, risk scoring, and insider threat detection. For CPS 234, that combination helps identify where access behaviour deviates from the expected norm—especially useful in finance and government environments where privileged misuse or access anomalies are material risks.

Practical scenario: healthcare

An Australian private hospital group might classify electronic health record systems as critical due to patient safety, privacy, and continuity of care. In that context, control gaps in admin access, backup restoration, or identity lifecycle management are not just IT issues. They are operational and clinical continuity issues, and they should be treated as such.

Practical scenario: government contractor

A government services provider handling identity documents and citizen correspondence may need stronger segregation, audit logging, and retention controls. The challenge is not only protecting data; it is being able to prove chain-of-custody, access restriction, and incident containment if a records system is compromised.

What controls and testing evidence satisfy CPS 234?

CPS 234 does not ask whether controls exist in theory. It asks whether controls are appropriately designed, operating effectively, and tested often enough for the risk they protect.

A sound control framework usually covers:

• identity and access management
• privileged access management
• vulnerability and patch management
• endpoint protection
• network security and segmentation
• secure change management
• encryption
• logging and monitoring
• backup and recovery
• incident response

Where controls are compensating rather than ideal, document:

• the reason
• the limitation
• the residual risk
• the review date
• the owner

Testing should be risk-based, not ceremonial

Testing should include a combination of:

• design review
• operating effectiveness testing
• technical validation
• scenario-based exercises
• restore testing
• access recertification
• retesting after remediation

This is where many programs fail. For example:

• a backup job completes, but restore time exceeds tolerance
• a privileged account review occurs, but inactive admin access remains
• a scan is performed, but critical vulnerabilities are accepted without expiry dates
• a patch policy exists, but internet-facing assets remain outside SLA

Essential Eight example

One of the clearest Australian examples is the ASD Essential Eight. A CPS 234-aligned program should not treat Essential Eight maturity as a separate compliance island. It should use the Essential Eight as a baseline set of hardening and recovery controls, then overlay CPS 234 requirements for governance, asset scoping, vendor risk, and evidence.

For example:

• application control supports reduced malware execution risk
• patching and vulnerability management reduce exposure windows
• MFA reduces credential-based compromise
• regular backups and restoration testing support resilience against ransomware

Relevant BCyber support

BCyber’s 50 courses include structured learning relevant to these control areas, and course completion can be mapped into compliance education and awareness records. Depending on the audience, organisations often align learning to:

• governance and assurance
• privileged access hygiene
• incident response
• privacy and records handling
• secure change and patch management

BCyber’s GRACE Portal is commonly used to consolidate compliance tracking and executive reporting, while CyberTriage supports incident response readiness with AI-powered triage, automated response, threat containment, forensic analysis, and incident playbooks. In a CPS 234 context, rapid triage matters because delay increases both containment risk and reporting complexity.

Evidence you should retain

• vulnerability scan reports and closure logs
• access review records
• penetration test outputs
• recovery test results
• change records and approvals
• incident exercises and after-action reviews
• remediation plans with owners and due dates

How do third-party dependencies fit into compliance?

Third-party risk is not a side issue under CPS 234.

If a managed service provider, cloud platform, SaaS vendor, or outsourced operation handles information assets on your behalf, APRA still expects you to understand and manage the risk.

Due diligence should happen before onboarding. It should assess:

• security maturity
• incident notification practices
• subcontracting arrangements
• data residency and hosting
• logical access controls
• encryption and key management
• recovery capability
• assurance reporting
• exit and transition support

Contracting and assurance

Contracts should carry security requirements forward, including:

• breach notification timelines
• evidence request rights
• minimum control requirements
• subcontractor obligations
• logging and monitoring expectations
• data handling requirements
• termination and exit obligations

If a vendor cannot meet those terms, the risk should be explicitly accepted or the provider replaced.

Practical scenario: superannuation fund

A superannuation trustee may rely on multiple processors, a CRM platform, identity services, and cloud hosting. A common CPS 234 issue is fragmented assurance: each vendor provides a report, but no one consolidates the risk story. In that setting, BCyber’s GRACE Portal can help centralise compliance tracking, while Paradigm can map third-party obligations to controls and evidence.

Keeping assurance live

Vendor assurance should be risk-tiered:

• low-risk providers: periodic confirmation
• material providers: scheduled evidence review
• critical providers: deeper testing, escalation paths, and exit planning

Useful evidence includes:

• due diligence questionnaires
• contracts and security addenda
• audit reports
• access approval records
• incident correspondence
• periodic risk reviews
• fallback or exit plans

What should incident response and APRA notification readiness look like?

Incident response under CPS 234 starts before the incident.

The hard part is not just containment; it is deciding quickly whether the event is material and whether APRA notification is required. That means your triage process needs to be documented, rehearsed, and understood by:

• security
• legal
• privacy
• communications
• business owners
• executive decision-makers
• vendor contacts

A practical response model

A strong incident response model usually includes:

• detection
• triage
• containment
• eradication
• recovery
• communications
• post-incident review

It should also define:

• who makes the materiality decision
• escalation thresholds
• APRA notification workflow
• evidence preservation steps
• legal sign-off points
• communications approval paths

Scenario planning matters

For APRA-regulated entities, tabletop exercises should include:

• ransomware affecting a material service
• privilege escalation or admin credential compromise
• vendor outage with unclear cause
• data exposure with uncertain scope
• malicious insider activity
• cloud configuration drift leading to unintended exposure

In BCyber’s Perfect Storm scenario intelligence platform, scenario modelling and war-gaming can help stress-test these events before they happen. That is particularly relevant for organisations with complex service chains or multi-cloud dependencies.

Practical scenario: financial services

A payments provider experiences abnormal outbound traffic from an admin workstation. The technical team isolates the endpoint, but the incident manager still has to decide whether the event indicates broader credential compromise, whether customer data may have been exposed, and whether APRA notification thresholds have been crossed. In that moment, speed matters—but so does disciplined evidence collection.

What to test before a real incident

• APRA notification decision-making
• executive escalation under time pressure
• legal and privacy review points
• evidence preservation
• containment playbooks
• customer communication drafts
• vendor coordination
• recovery time objectives against business tolerance

Good incident readiness evidence includes:

• incident response plans
• escalation matrices
• APRA notification playbooks
• tabletop records
• after-action reviews
• corrective action logs
• communications templates

The fastest organisations are not the ones with the longest playbooks; they are the ones with the clearest decisions and the best evidence trail.

What evidence does APRA expect to see?

Evidence is the backbone of CPS 234 compliance.

APRA expects entities to demonstrate capability when asked. That means your evidence should tell a coherent story:

• governance was established
• assets were identified
• controls were designed
• controls were tested
• gaps were remediated
• vendors were managed
• incidents were learned from

A practical evidence map

| CPS 234 expectation | Typical evidence | Review rhythm | |---|---|---| | Governance and oversight | Board papers, committee minutes, charters | Quarterly or as governed | | Asset classification | Asset register, data classification records | On change and periodic review | | Control effectiveness | Test reports, scan results, access reviews | Risk-based | | Third-party security | Due diligence, contracts, assurance reports | Onboarding and periodic | | Incident readiness | Playbooks, tabletop records, incident logs | Regular exercise cycle | | Remediation | Action plans, closure evidence, risk acceptance | Until closed |

A strong evidence library is current, dated, approved, and traceable to the CPS 234 requirement it supports.

BCyber authority and operating context

BCyber’s ecosystem is designed around this evidence challenge:

• GRACE Portal for unified visibility and compliance tracking
• Paradigm for policy automation, compliance mapping, and GRC workflow
• Profiler for behavioural risk and access anomaly analysis
• CyberTriage for rapid incident triage and response
• Perfect Storm for resilience testing and scenario modelling
• TopSpin for storage forecasting, capacity planning, and trend analysis
• Privacy in Depth for privacy governance and Australian Privacy Act-aligned obligations

BCyber was recognised in 2025 as:

• Finalist Cybersecurity Professional Of The Year — Karen Stephens, Co-Founder & CEO
• 2025 GRC Provider of the Year — Finalist
• 2025 AI Innovator - Cyber Security — Finalist

These recognitions are relevant because CPS 234 success increasingly depends on automation, evidence integrity, and rapid operational visibility, not just policy documentation.

What not to rely on

Do not rely solely on:

• a certificate
• a policy register
• a static spreadsheet
• an annual audit
• a one-off gap assessment

Those items help, but they are not the same as a live assurance system.

What are the practical first steps if you are starting now?

If you are approaching CPS 234 for the first time, do not start with a grand redesign.

Start with a gap assessment against the core obligations:

• governance
• asset inventory and classification
• control design and testing
• third-party assurance
• incident readiness
• evidence and reporting

Then create a remediation plan that the board and executives can actually monitor.

A sensible order of operations

1. confirm governance ownership and reporting lines
2. refresh the asset inventory and classification model
3. identify material controls for critical assets
4. test the controls that matter most
5. tighten vendor assurance
6. rehearse incident response and APRA escalation
7. centralise evidence and compliance mapping

If your environment is already using frameworks like ISO 27001, NIST CSF, or Essential Eight, build on that rather than replacing it. The key is making sure those frameworks are mapped to APRA requirements and evidenced in the operating model.

Key Takeaways

APRA CPS 234 is about proving that information security capability is aligned to risk, not merely claiming that it is.

The strongest compliance programs connect:

• governance
• asset classification
• control testing
• third-party oversight
• incident readiness
• evidence management

If you cannot show how controls were chosen, how they were tested, and how issues were remediated, your organisation will struggle to defend its position during APRA review.

A living evidence base, maintained as operations change, is far more useful than a static policy archive.

Frequently asked questions

Does ISO 27001 automatically make us CPS 234 compliant?

No. ISO 27001 can support your security program, but CPS 234 is an APRA prudential standard with specific expectations around governance, asset classification, testing, third-party management, incident readiness, and evidence. You still need to map the standard to your operating environment.

Do we need board involvement for CPS 234?

Yes. APRA expects the board and senior management to have oversight of information security. The board does not need technical detail, but it does need visibility into material risks, incidents, testing outcomes, and remediation progress.

How often should controls be tested?

Regularly, with frequency and depth driven by risk. Higher-criticality controls should be tested more often and more meaningfully than low-risk ones. If the business, threat, or technology changes, the test rhythm should change too.

What should we do first if our evidence is scattered?

Create a CPS 234 mapping document and an evidence register. That will show which requirement each artefact supports, who owns it, and when it was last reviewed. Then prioritise governance, material assets, control testing, vendor assurance, and incident readiness.

When should we escalate to APRA after an incident?

Verify timing and thresholds against the current APRA source and your internal criteria. The safest practice is early internal escalation, a documented materiality assessment, and prompt regulatory decision-making where required. Where doubt remains, resolve it quickly rather than letting uncertainty linger.

Conclusion

Complying with APRA CPS 234 is less about producing security artefacts and more about proving that security is governed, tested, and continuously improved.

The organisations that do this well usually share the same traits:

• they know their assets
• they understand dependencies
• they test what matters
• they keep evidence close to the work
• they learn from incidents and vendor events

If you need a practical way to operationalise that model, BCyber’s GRACE Portal, Paradigm, Profiler, CyberTriage, Perfect Storm, and Privacy in Depth form a connected ecosystem for governance, resilience, and assurance. That ecosystem is designed to support regulated organisations that must show not just policy intent, but working control evidence.

For Australian APRA entities, the real compliance question is simple: if a regulator asked tomorrow, could you prove it?