APRA CPS 234 Checklist: Requirements for Regulated Entities and Their Service Providers

Short answer: A CPS 234 checklist confirms that the board owns information security, that capability matches the threats you face, that information assets are classified by criticality and sensitivity, that controls are implemented and systematically tested, that incidents are managed, and that APRA hears about material incidents within 72 hours. Service providers holding regulated data inherit most of these expectations by contract.

Related guides:

• The Ultimate ISO 27001 Guide
• Vendor Tiering Model
• Essential Eight Maturity

Key takeaways

• CPS 234 has been in force since 1 July 2019 and applies to every APRA-regulated entity, including banks, insurers, private health insurers and superannuation trustees.
• The board is ultimately responsible for information security, even when a third party manages the systems or data.
• APRA must be notified within 72 hours of becoming aware of a material information security incident, and within 10 business days of identifying a material control weakness that cannot be remediated in a timely manner.
• SaaS vendors, including SMB and HealthTech providers serving insurers and health funds, routinely receive CPS 234 clauses in contracts and security questionnaires.
• Existing ISO 27001 or SOC 2 evidence covers much of what CPS 234 asks for, but not the APRA notification and board reporting pieces.

---

What is APRA CPS 234 and who does it apply to?

Prudential Standard CPS 234 Information Security is a binding standard from the Australian Prudential Regulation Authority that requires regulated entities to maintain information security that protects against compromise of information assets.

It applies to authorised deposit-taking institutions, general insurers, life insurers, private health insurers, registrable superannuation entity licensees and certain groups. APRA also publishes Prudential Practice Guide CPG 234, which explains how APRA expects the standard to be met.

The standard does not apply directly to your SaaS company unless you are regulated by APRA. In practice, though, regulated entities are accountable for information assets managed by third parties, so they push equivalent obligations into supplier contracts.

How CPS 230 fits in: Prudential Standard CPS 230 Operational Risk Management took effect on 1 July 2025. It sets expectations for managing material service providers, business continuity and operational resilience, replacing the earlier outsourcing and business continuity standards. CPS 234 remains the information security standard.

Governance: who is accountable under CPS 234?

The board of the regulated entity is ultimately responsible for information security, and every other role flows from that accountability.

Use this checklist to test the governance layer:

• Roles and responsibilities for information security are defined for the board, senior management, governing bodies and individuals.
• The board receives regular reporting on information security posture, incidents and control weaknesses.
• Information security capability is commensurate with the size and extent of threats to information assets, and that assessment is refreshed as threats change.
• Capability covers assets managed by related parties and third parties, not only internal systems.
• An information security policy framework exists, is approved at an appropriate level and reflects the entity's obligations.
• The policy framework sets direction for all parties with responsibility for information security, including suppliers.

"Commensurate" is the key word. APRA does not prescribe a fixed control set, so a threat assessment and a documented rationale for your control choices matter more than a long list of tools.

Asset classification and control implementation checklist

CPS 234 requires information assets to be classified by criticality and sensitivity, and controls to be implemented in proportion to that classification.

Classification drives everything downstream, so do it first:

1. Build the inventory. Include information and the technology that stores or processes it: applications, databases, cloud accounts, endpoints and SaaS tools. Assets managed by third parties belong in the register too.
2. Rate criticality. How much would loss of availability or integrity hurt the business or customers?
3. Rate sensitivity. How much harm would unauthorised access or disclosure cause? Health claims data and member records will sit at the top.
4. Assign owners. Each asset needs an accountable person who approves access and accepts residual risk.
5. Link controls to classification. Higher-rated assets get stronger controls and more frequent testing.

Then confirm implementation:

• Controls protect assets across their full life cycle, from planning and acquisition through to decommissioning and disposal.
• Controls reflect the vulnerabilities and threats to each asset, the classification, and the potential consequences of an incident.
• Identity and access management, encryption, logging and monitoring, vulnerability management and secure change management are in place for critical and sensitive assets.

How should incident management and control testing work?

You need documented mechanisms to detect and respond to incidents in a timely way, plus a systematic testing program that proves controls actually work.

Incident management

• Plausible incident scenarios are identified and response plans exist for them.
• Response plans cover detection, escalation, containment, recovery and communication, including escalation to the board where needed.
• Plans are reviewed and tested at least annually, and updated after real incidents.
• Criteria for deciding whether an incident is "material" are written down, so the 72-hour clock is not lost to debate.
• Contracts require third parties to notify you of incidents affecting your information assets.

A good starting point is a structured incident response plan template that you adapt to your own scenarios and escalation paths.

Control testing and assurance

• A systematic testing program covers the design and operating effectiveness of controls.
• Testing frequency and depth reflect the rate of change of threats and assets, the asset classification, and the consequences of a failure.
• Testing is performed by appropriately skilled and functionally independent people.
• Controls operated by third parties are included, either through direct testing or reliable third-party assurance.
• Deficiencies that cannot be remediated in a timely manner are escalated to the board or senior management.
• Internal audit reviews the design and operating effectiveness of information security controls, including those maintained by third parties.

When do you have to notify APRA?

APRA must be notified no later than 72 hours after the entity becomes aware of a material information security incident, and no later than 10 business days after it becomes aware of a material control weakness it does not expect to remediate in a timely manner.

Trigger	Deadline	Who reports
Material information security incident that materially affected, or could materially affect, the entity or the interests of depositors, policyholders, beneficiaries or other customers	Within 72 hours of becoming aware	The regulated entity
Material information security incident that has been notified to other regulators, in Australia or elsewhere	Within 72 hours of becoming aware	The regulated entity
Material information security control weakness that cannot be remediated in a timely manner	Within 10 business days of becoming aware	The regulated entity

The clock starts when the regulated entity becomes aware, which is why its suppliers matter so much. If your platform suffers an incident and you take four days to tell your insurer customer, you have put them at risk of missing their own notification deadline. Expect contracts to set supplier notification windows well inside 72 hours. APRA notification is also separate from other obligations, such as the Notifiable Data Breaches scheme under the Privacy Act, which has its own assessment and reporting rules.

Can ISO 27001 or SOC 2 evidence satisfy CPS 234?

Largely yes for the control and testing requirements, but neither framework covers APRA notification or the specific board accountability CPS 234 places on regulated entities.

CPS 234 area	Reusable ISO 27001 evidence	Reusable SOC 2 evidence	Gap to close
Roles and responsibilities	Leadership commitment, ISMS roles, management review records	Control environment criteria, org charts, board or committee oversight	Board-level accountability and reporting cadence specific to APRA
Capability commensurate with threats	Risk assessment and treatment plan, threat intelligence control	Risk assessment criteria, fraud and change risk analysis	Documented link between threat environment and capability
Policy framework	Information security policy and topic-specific policies	Policies supporting common criteria	Explicit direction for third parties
Asset identification and classification	Asset inventory, classification scheme, acceptable use	System description, asset inventory, data classification	Criticality and sensitivity ratings on third-party assets
Implementation of controls	Statement of Applicability, Annex A control evidence	Logical access, change management and system operations controls	Mapping controls back to asset classification
Incident management	Incident management procedures and logs	Incident response criteria and test records	Materiality criteria and 72-hour APRA path
Testing control effectiveness	Internal audit reports, certification audit results	Type 2 report covering an observation period	Testing frequency tied to asset rating and change
Third-party managed assets	Supplier relationship controls, supplier reviews	Vendor management controls, subservice organisation review	Assessment of supplier capability against CPS 234 expectations

If you already hold certification, reading ISO 27001 third-party risk management requirements alongside this table shows how much of the supplier work you have already done.

CPS 234 for service providers: the vendor-side checklist

If you are a SaaS provider to an APRA-regulated customer, your job is to make it easy for that customer to show APRA that your controls meet its standard.

Regulated entities must assess a third party's information security capability in proportion to the potential consequences of an incident affecting the assets that party manages. How deeply you are assessed usually depends on how your customer tiers you, so expect heavier scrutiny if you hold member health data or support a critical business service.

Before the questionnaire arrives

• Know which customer data you hold and classify it by criticality and sensitivity, using terms the customer will recognise.
• Hold current independent assurance, such as an ISO 27001 certificate with its Statement of Applicability or a SOC 2 Type 2 report.
• Prepare a CPS 234 mapping document that cross-references your controls to each requirement area above.
• Document data location, including any offshore processing or support access.
• Maintain your own supplier register, since your subprocessors are fourth parties to your customer.

Contract and incident readiness

• Agree an incident notification window that leaves your customer time to meet its 72-hour deadline.
• Name a contact and escalation path for security incidents, reachable outside business hours.
• Be ready to support customer testing: penetration test summaries, right-to-audit clauses or independent reports in lieu of on-site audits.
• Commit to notifying the customer of material control weaknesses you cannot remediate quickly.
• Review CPS 230 clauses too, especially business continuity, exit planning and subcontracting notice.

How SecureSlate helps

SecureSlate gives you a single control library mapped across frameworks, so you can map CPS 234 requirement areas to the ISO 27001 and SOC 2 controls you already operate and track the gaps in one place. Automated evidence collection from your cloud and SaaS stack keeps access reviews, logging and change records current, while the risk register ties controls back to your asset classifications and policy templates give you a starting point for the policy framework.

For vendors, SecureSlate's vendor risk management helps you run the same discipline on your own subprocessors, and the trust center plus audit-ready exports let you answer CPS 234 questionnaires from insurers and health funds with current, consistent evidence.

Start your free SecureSlate trial

FAQ

Does CPS 234 apply to SaaS companies that are not regulated by APRA?

Not directly. CPS 234 binds APRA-regulated entities, but those entities remain responsible for information assets managed by third parties. They pass the obligations to suppliers through contracts, security schedules and questionnaires, so in practice many vendors must meet them.

What is the difference between CPS 234 and CPS 230?

CPS 234 focuses on information security: protecting information assets and notifying APRA of material incidents. CPS 230, effective 1 July 2025, covers operational risk more broadly, including critical operations, business continuity and the management of material service providers. Vendors often see both in the same contract.

Is an ISO 27001 certificate enough to prove CPS 234 compliance?

It is strong supporting evidence but rarely enough by itself. Customers usually want to see your Statement of Applicability, incident notification commitments, data location details and a mapping showing how your controls address each CPS 234 area.

How quickly must a vendor report an incident to an APRA-regulated customer?

CPS 234 does not set a supplier deadline directly. Your customer must notify APRA within 72 hours of becoming aware of a material incident, so contracts typically require vendors to notify much sooner. Check the specific window in your agreement.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.