CPS 234 is a mandatory APRA standard for banks, insurers, superannuation funds, and other regulated entities.
It makes the board responsible for protecting information assets and keeping the entity operating through a security incident.
However, a policy pack alone will not meet it. Your team must know what it holds, decide what needs the strongest protection, test those protections, and report serious incidents or weaknesses before APRA’s deadlines pass.
The test is whether your team can show what it protects, how it tested the controls, and who acts when the clock starts. Let’s pull it apart.
What Is APRA CPS 234?
APRA CPS 234 Information Security is the mandatory information-security standard for organisations APRA regulates.
It requires them to keep the systems and data they rely on from being exposed, altered, or unavailable.
That includes hardware, software, and information held by a related party or supplier.
The standard tells you what must be protected; your cybersecurity compliance records show how each control works, when it was tested, and what happened when it fell short.
Why APRA Introduced CPS 234
APRA introduced CPS 234 because a security failure at a bank, insurer, or superannuation fund can interrupt services and harm the people who rely on them.
Protecting data and keeping services available helps these entities keep their promises to customers.
CPS 234 vs CPG 234
CPS 234 states what regulated entities must do, while the CPG 234 shows practices that APRA considers sound.
However, the guide does not create enforceable duties by itself. When you turn its guidance into tasks, trace each task back to the standard.
Who Must Comply With CPS 234?
CPS 234 binds the entities that APRA regulates, including authorised deposit-taking institutions such as banks, and registrable superannuation entity licensees that operate super funds.
A supplier is usually outside that direct scope, but its contract may still require many of the same controls because it handles the client’s assets.
Which Entities Are in Scope
CPS 234 directly covers authorised deposit-taking institutions, general insurers, life companies, private health insurers, and registrable superannuation entity licensees.
It also reaches specified non-operating holding companies, group heads, and the Australian branches of certain foreign entities.
Who Is Accountable for CPS 234 Compliance
The board remains responsible for the entity’s information security.
It may delegate tasks, so the entity must state who makes decisions, approves changes, runs controls, tests them, and raises problems.
Moving a system or security function to a supplier does not move that responsibility.
What Are the Key Requirements of CPS 234?
CPS 234 requires more than a policy or an annual test, because you need:
- People who can protect your systems
- Rules they can follow
- A current view of the assets at risk.
From there:
- You set and operate controls
- Respond to incidents
- Test the controls
- Ask internal audit to check the work
- Notify APRA when a serious issue meets its reporting threshold.
You cannot test or report what you have not first identified. The assets in your register shape the controls you put around them.
Testing can then expose a gap, internal audit can check the evidence, and a serious issue may need to go to APRA.
For evaluation, a vulnerability assessment helps uncover weaknesses, but a scan cannot tell you whether the wider set of controls works.
That takes people who know the systems, the skills to protect them, and tools that can keep up.
Information Security Capability
Your team needs enough people, skills, tools, and controls for the threats its assets face.
Keep that capability current as systems, threats, or suppliers change.
If a supplier manages an asset, check that it can protect the asset to the required standard.
Information Security Policy Framework
Set security rules that match the threats your assets face, then turn them into procedures people can follow. Record approved exceptions and their expiry dates.
Staff, contractors, customers, and suppliers should know which rules apply to them.
Information Asset Identification and Classification
List every asset, including those suppliers manage.
Rate the impact if it becomes unavailable, which APRA calls criticality, and if its data are exposed or altered, which APRA calls sensitivity.
Use those ratings to assign an owner, choose controls, and set the test frequency.
Implementation of Information Security Controls
Use the asset rating to choose controls. They must address current threats, the asset’s lifecycle from design to disposal, and the harm an incident could cause.
If a supplier manages the asset, the regulated entity must check how that supplier designed its controls.
Incident Management
Controls reduce risk, but they do not prevent every incident. Detect incidents early and respond without delay.
Plan for events that could realistically occur, from the first alert through to the review after recovery.
Also, name the escalation route, test the plan every year, and complete the fixes it exposes.
Testing Control Effectiveness
Test whether each control works in practice, not merely whether it was configured.
Test more often when threats, assets, exposure, or systems change.
Use skilled specialists who do not run the controls.
Raise weaknesses your team cannot fix promptly, and review the testing program annually or after a material change.
Internal Audit
Internal audit then checks how controls were designed and whether they work, including controls run by suppliers.
If it relies on a supplier report, it must check who did the work, what it covered, and whether the report is reliable enough to use.
APRA Notification
Testing and internal audit can uncover an issue that needs to go beyond the organisation. When an incident or weakness meets APRA’s reporting test, notify APRA on time.
Name who decides whether the threshold has been met and who sends the notice. They must act before every fact is known.
What Information Security Controls Does CPS 234 Expect?
CPS 234 does not prescribe a product list because it expects controls that fit the asset, the data it holds, its lifecycle, and the harm an incident could cause.
In practice, that means managing vulnerabilities, access, system changes, data, physical assets, and suppliers.
Start by finding weaknesses and active threats, because that tells you which assets need attention first.
Vulnerability and Threat Management Controls
Keep the asset list current, scan for weaknesses, and compare findings with active threats.
Give each fix to a named person, track its due date, and retest it after completion.
This shows what your team found, fixed, and still has open between formal tests.
Access and Identity Controls
Once you know which systems need attention, control who can reach them.
Give people only the access they need, and protect high-risk accounts with strong authentication.
Also, change or remove access when someone joins, moves roles, or leaves.
Log administrator activity. MFA suits many high-risk paths, but apply it according to the asset rating and threat.
Change and Lifecycle Management Controls
Access can be correct today and still fail when a system changes. Check security before you buy, build, release, change, or retire an asset.
After a material change, update the asset register and retest affected controls. Replace unsupported technology, and remove old data and access safely at end of life.
Data Protection and Cryptographic Controls
System changes can also move or expose data. Track sensitive data while your team stores, sends, uses, and disposes of it. Encrypt it and manage the keys where needed.
Thus, using a data loss prevention system can help you see where information moves and when someone handles it outside the rules.
Physical and Environmental Controls
Not every information asset sits in the cloud. Control who can enter facilities or handle devices, paper records, and backup media. Keep access logs.
Protect equipment from power loss, heat, water, fire, and other hazards that could stop it working or damage its information.
Third-Party and Related Party Controls
The same protection standard applies when a supplier runs an asset for you. Before it does, check its people, skills, and control design.
Review what its test reports cover instead of accepting a certificate at face value.
The contract should set incident deadlines, record and audit access, fix timeframes, subcontractor rules, and a safe exit.
When Must APRA Be Notified Under CPS 234?
CPS 234 sets two notification deadlines: 72 hours after the entity becomes aware of a material information security incident, and 10 business days after it becomes aware of a material control weakness it cannot fix promptly.
Meeting either deadline depends on finding, assessing, and escalating the issue quickly.
A practised data breach process can help, but CPS 234 also covers damaged data, unavailable systems, and potential compromises that do not involve personal information.
The 72-Hour Incident Notification Rule
Notify APRA as soon as possible and no later than 72 hours after the entity becomes aware of an incident that materially affected, or could materially affect, the entity or its customers.
The harm can be financial or non-financial.
The same deadline applies when the incident has been reported to another Australian or overseas regulator.
Please, do not wait for every detail before notifying APRA.
Also, always record what happened, what may be affected, the action taken so far, and when the entity became aware of it.
The 10-Business-Day Control Weakness Rule
Notify APRA as soon as possible and no later than 10 business days after finding a material control weakness that the entity does not expect to fix promptly.
This does not cover every open finding. Record when the team recognised the weakness, why it is material, what assets it affects, who owns the fix, and when the entity expects to remediate it.
How to Comply With CPS 234 Step by Step
To comply with CPS 234, always treat it as a working cycle. Too many businesses focus on CPS 234 as a document they complete once.
Start by recording the assets you hold and who owns them. That record tells you which controls to set, what suppliers must show, what testing to run, and when an issue may need to go to APRA.
Build and Maintain the Information Asset Register
Record what each asset does, who owns it, where it sits, and what data it handles. Then, add the supplier and other systems it depends on.
Rate its criticality and sensitivity, note its lifecycle stage, and link the evidence that its controls work.
Update the record after a major release, supplier change, or retirement. If the register falls behind, the controls and test plan will soon follow it.
Set Control Standards Against Asset Criticality
Set controls according to each asset’s criticality and sensitivity, so higher-impact systems receive stronger protection and more frequent testing.
Let’s say a customer platform holding sensitive data may need stronger login controls, logging, encryption, recovery, and testing than a low-impact internal tool.
When you accept an exception, record the substitute control, its owner, and its expiry date.
This gives the team a clear reason for the decision and a date to revisit it.
Document the Third-Party Assurance Position
For every supplier-managed asset, record what the supplier runs, which controls it uses, and what evidence it provides.
Link the supplier’s contract and test reports to the systems they actually cover.
Record findings, fixes, incident contacts, subcontractors, and notice periods. If evidence is missing, record the gap, the risk it creates, and who will reduce or accept it.
Run a Testing and Internal Audit Cycle
Run testing and internal audit on a cycle that shows whether controls work and whether the evidence is reliable.
Use asset and supplier records to decide what to test and how often.
Pair control reviews and vulnerability assessments with recovery and incident-response exercises.
Also, consider using penetration testing to check realistic attack paths.
Keep independent testers and internal audits separate from the people who run the controls.
Retest completed fixes, then escalate anything that remains open and cannot be resolved promptly.
Prepare the APRA Notification Playbook
Your APRA notification playbook must state who starts the clock, judges the impact, approves the notice, contacts APRA, and saves the records.
Make those decisions before an incident or material weakness appears.
Practise the 72-hour path with incomplete facts. Suppliers must also warn you early enough for the regulated entity to assess the issue and meet its own deadline.
What CPS 234 Means for Australian SMBs That Supply Regulated Entities
For Australian SMBs that supply regulated entities, CPS 234 usually means contractual security obligations rather than direct APRA regulation.
To keep the work, you may need to meet the client’s control, incident-notice, testing, and evidence requirements.
How CPS 234 Flows Down Through Supplier Contracts
CPS 234 flows down through supplier contracts as requirements for security controls, incident notice, audit access, and testing.
The contract may also set deadlines for fixes, rules for data handling and subcontractors, and a safe exit when the service ends.
Please note that CPS 230 has a broader role in material service-provider and fourth-party risk. CPS 234 remains focused on protecting the information assets in your care.
What Evidence a Regulated Client Will Ask You For
A regulated client will ask for records that show how you protect its systems or data and how quickly you can report a problem.
The evidence should match the service and data you handle, such as:
- A list of the assets you manage and where the data moves;
- Security rules and the people who own each control;
- Access reviews, MFA coverage, and system logs;
- Vulnerability findings, completed fixes, and retest results;
- Independent test reports that state which systems they covered, including what a penetration testing report typically documents;
- Incident and continuity plans, along with exercise results; and
- Notification contacts, notice periods, data locations, and subcontractors.
Many suppliers already collect some of these records for Essential Eight or SMB1001.
Thus, map what you already have before creating new documents under another label.
How CPS 234 Lines Up With the Essential Eight and SMB1001
Essential Eight and SMB1001 can support CPS 234, but neither framework makes an entity CPS 234-compliant by itself.
They can provide controls and evidence that a regulated entity or supplier can reuse.
Meanwhile CPS 234 adds duties around asset classification, supplier oversight, testing, internal audit, and APRA notification.
That difference matters when a regulated client asks for proof. Use the following comparison to separate the records you can reuse from the CPS 234 obligations the regulated entity must still manage:
| Framework | What you can reuse | What CPS 234 still asks for |
|---|---|---|
| Essential Eight | Controls that block common attack paths, measured through maturity levels | Board ownership, asset ratings, supplier checks, risk-based testing, internal audit, and APRA reporting |
| SMB1001 | Security rules, control owners, and staged records suited to an SMB | Controls tied to the regulated client’s assets, plus the client’s own decisions on impact, testing, and reporting |
Reuse the record, not the conclusion. The same MFA report may support all three frameworks, but the regulated client must still decide whether the control matches the asset and satisfies CPS 234.
CPS 234, Cyber Insurance and the Cost of Non-Compliance
Keeping CPS 234 records current can support a cyber insurance application and a later claim response, but compliance does not guarantee cover or payment.
Insurers use the evidence to assess risk and policy conditions, while APRA uses it to assess whether the entity meets its information-security duties.
Because both reviews depend on current evidence, keep records for:
- MFA coverage, privileged access, and access reviews
- Backups, recovery tests, and the people responsible for them
- The systems and data that could be affected by an incident
- Security tests, including their scope, date, provider, findings, and retest results
- Remediation work, accepted risks, and the reasons for those decisions
- Incident plans, exercise results, and the actions taken during a real event.
When those records are missing, the cost is usually operational before it becomes financial. Your team may need to:
- Rebuild the change history and identify affected systems during an incident
- Rush through fixes, testing, and evidence collection while services are disrupted
- Ask senior decision-makers to accept risk without a clear record of the exposure and
- Provide extra information before an insurer, client, or regulator can complete its review.
And, always keep the evidence as part of normal security work, not as something rebuilt for an audit or claim.
Current records help the insurer assess the policy, help APRA assess CPS 234 obligations, and give your team a clearer starting point when pressure arrives.
Meet Your CPS 234 Information Security Obligations With Redscale
If your asset register, supplier records, and test results are out of date, a renewal or supplier approval can turn into a manual chase.
That work gets harder when the 72-hour or 10-business-day clock has started.
You still need to identify the affected asset, find the right supplier record, assign the fix, and explain what changed.
That is where Redscale joins the process: it connects the work that keeps your evidence current.
At Redscale, we do that through three connected services.
Our managed security services watch the environment and routes alerts, so your team can record what it saw and how it responded.
Redscale vulnerability management takes known weaknesses from finding to named owner, completed fix, and retest.
Our penetration testing service will test agreed attack paths through Redscale’s OSCP- and CREST-certified testers, when your client, insurer, or board needs more than a scan.
Book a free discussion session with a Redscale expert to see what needs attention before the next evidence request.
