APRA CPS 234 Evidence Requirements — What Regulated Entities Need

What CPS 234 is and who it applies to

Prudential Standard CPS 234 Information Security is a binding prudential standard issued by the Australian Prudential Regulation Authority (APRA). It came into effect on 1 July 2019 and applies to all APRA-regulated entities, including:

•Authorised deposit-taking institutions (banks, building societies, credit unions)

•General insurers and life insurers

•Private health insurers

•Registrable superannuation entity licensees (superannuation funds)

•Authorised non-operating holding companies

CPS 234 also applies, by extension, to the third parties and service providers that APRA-regulated entities rely on for information security functions. If an APRA-regulated entity outsources its IT security to a managed service provider, the obligations under CPS 234 extend to that arrangement.

The standard is principles-based, not prescriptive. It does not dictate specific technologies, specific configurations, or specific technical controls. Instead, it requires entities to maintain information security capabilities that are "commensurate with the size and extent of threats to their information assets" and to be able to demonstrate those capabilities.

This principles-based approach is both a strength and a challenge. The strength is that flexible entities can implement controls appropriate to their size, complexity, and risk profile. The challenge is ambiguity because CPS 234 does not specify exactly what evidence is required, entities must determine what constitutes sufficient evidence of compliance. This guide addresses that challenge.

The core requirements of CPS 234

CPS 234 is a relatively short standard approximately 2,500 words across 36 paragraphs. But within those paragraphs are requirements that have significant operational implications. The key requirement areas are:

Roles and responsibilities (paragraphs 14–15)

The board of an APRA-regulated entity is ultimately responsible for the entity's information security. CPS 234 requires the board to ensure that the entity maintains information security commensurate with the size and extent of threats, and that it has clearly defined information security roles and responsibilities. The board must be informed of material information security incidents.

This means information security is not just an IT concern it is a board-level governance obligation. The evidence of compliance starts at the board level: board minutes reflecting information security discussions, board-approved information security policies, and board reporting on information security posture.

Information security capability (paragraph 16)

The entity must maintain an information security capability commensurate with the size and extent of threats to its information assets, "which enables the continued sound operation of the entity." This is the central requirement of CPS 234 and the one that generates the most questions about evidence.

"Commensurate with the size and extent of threats" is deliberately non-prescriptive. APRA does not tell entities which controls to implement. Instead, the entity must assess its threat landscape, determine what capabilities are appropriate, implement those capabilities, and be able to demonstrate that they are functioning.

The evidence required here is multifaceted: threat and risk assessments, control frameworks (such as Essential Eight, ISO 27001, or NIST CSF) that the entity has adopted, evidence that the controls defined in those frameworks are implemented and functioning, and evidence that the capability is reviewed and updated as threats evolve.

Policy framework (paragraph 17)

The entity must maintain an information security policy framework that is commensurate with its exposures to vulnerabilities and threats. The policy framework must be reviewed at least annually.

The evidence: documented information security policies, evidence of annual review (version history, review dates, approver records), evidence of policy dissemination to relevant staff, and evidence that policies are consistent with the entity's risk profile and threat assessment.

Information asset identification and classification (paragraph 18)

The entity must classify its information assets, including those managed by related parties and third parties, by criticality and sensitivity. This classification must include information assets that support financial reporting.

The evidence: an information asset register, classification scheme, evidence of classification reviews, and evidence that the classification covers third-party managed assets.

Implementation of controls (paragraphs 19–23)

The entity must implement controls that protect information assets commensurate with the criticality and sensitivity of those assets, and that are "adjusted on a timely basis when there are material changes to vulnerabilities or threats." Controls must be tested through a systematic testing program.

The evidence: control implementation records, configuration evidence from technical systems, testing program documentation, test results, remediation records for identified gaps, and evidence that controls are adjusted when threats change.

This is the area where automated evidence collection has the most significant impact. Technical controls, such as MFA configuration, endpoint protection status, patch levels, backup status, access management, and encryption settings, can be evidenced automatically from the source systems. Governance controls policies, training, contracts, and risk assessments require documentary evidence that is typically not automatable.

Incident management (paragraph 24)

The entity must have mechanisms to detect and respond to information security incidents in a timely manner. The entity must have an information security incident management plan and must review it annually.

The evidence: incident management plan, evidence of annual review, incident response testing records, and incident logs demonstrating timely detection and response.

Testing (paragraphs 25–27)

The entity must test the effectiveness of information security controls through a systematic testing program. The testing must be conducted by appropriately skilled and functionally independent specialists. Tests must be escalated and remediated in a timely manner.

The evidence: testing program documentation, test schedules, test results, assessor qualifications, remediation Attesting, and evidence that testing covers controls proportional to the rate of change of vulnerabilities and threats, the criticality of information assets, the consequences of a breach, risks associated with exposure to environments and parties outside the entity's control, and the materiality and frequency of changes to information assets.

Internal audit (paragraph 28)

The entity's internal audit function must include a review of the design and operating effectiveness of information security controls, including those maintained by related parties and third parties.

The evidence: internal audit plans, audit reports, audit findings, and remediation Attesting.

Notification to APRA (paragraphs 29–36)

The entity must notify APRA of material information security incidents and material control weaknesses that the entity expects it will not be able to remediate in a timely manner. Notification must occur within 72 hours for incidents and within 10 business days for control weaknesses.

The evidence: notification records, incident classification criteria, escalation procedures, and evidence that notification timelines were met.

The evidence challenge for regulated entities

The breadth of CPS 234 creates a significant evidence challenge. The standard touches virtually every aspect of an entity's information security program from board governance to technical controls to incident response to third-party management.

Most regulated entities approach CPS 234 evidence in one of three ways, each with limitations.

Approach 1: Annual assessment by external consultants.

Many entities engage external consultants (often their auditor or a specialised cybersecurity firm) to perform an annual CPS 234 assessment. The consultant reviews policies, interviews staff, examines technical configurations, and produces a report with findings and recommendations.

This approach produces a point-in-time assessment. It is valuable for identifying gaps and providing remediation guidance. But it captures a snapshot, typically over a two to four week engagement period and says nothing about the other 48 to 50 weeks of the year. If a control degrades after the assessment, the entity has no evidence of the degradation until the next assessment cycle.

The cost is also high. A comprehensive CPS 234 assessment by a qualified firm can cost tens of thousands of dollars annually. For smaller regulated entities, such as small insurers, credit unions, and smaller super funds, this cost is disproportionate.

Approach 2: Internal self-assessment against the standard.

Some entities perform their own assessment, mapping their controls to CPS 234 requirements and documenting the results. This is less expensive than external assessment but suffers from the same point-in-time limitation. It also introduces the self-assessment bias problem: the people assessing the controls are often the same people responsible for implementing them.

Approach 3: Relying on framework compliance as a proxy.

Some entities argue that compliance with ISO 27001, the Essential Eight, or another control framework satisfies CPS 234 because the frameworks address the same security domains. This is partially true there is significant overlap but CPS 234 has specific requirements (board governance, APRA notification, testing by functionally independent specialists) that generic frameworks do not address.

The common limitation across all three approaches is the evidence gap between assessments. CPS 234 requires entities to maintain capabilities, not just demonstrate them annually. An entity that passes a CPS 234 assessment in March but has degraded controls in September is not compliant in September, regardless of the March assessment.

What APRA actually looks at

APRA's supervisory approach to CPS 234 focuses on several areas that regulated entities should understand:

Capability, not compliance. APRA assesses whether the entity has the capability to protect its information assets, not whether it has ticked every box on a checklist. An entity with strong controls but incomplete documentation is in a different position from an entity with comprehensive documentation but weak controls. APRA is interested in the substance, not just the form.

Board awareness and governance. APRA expects the board to be genuinely informed about information security, not just to receive a quarterly slide pack. Board minutes should reflect meaningful discussion of information security risks, incidents, and posture changes. Board-approved policies should be current and reviewed annually.

Third-party risk management. APRA has been particularly focused on how entities manage information security risks arising from third-party arrangements including cloud providers, MSPs, and outsourced IT. CPS 234 requires entities to assess whether third-party controls are commensurate with the consequences of an information security incident affecting the information assets managed by the third party.

Testing programs. APRA expects systematic testing, not ad hoc checks. The testing program should be risk-based, cover critical systems and controls, be performed by appropriately skilled and functionally independent specialists, and produce results that are Attested and remediated.

Incident response readiness. APRA expects entities to have tested their incident management plans not just documented them. Table-top exercises, simulation exercises, and lessons-learned reviews from actual incidents are all relevant evidence.

Continuous improvement. APRA expects entities to evolve their information security capabilities as threats change. Evidence of continuous improvement includes: updated threat assessments, control adjustments in response to new threats, adoption of new security technologies, and trending of control effectiveness over time.

Building an evidence program for CPS 234

A practical CPS 234 evidence program combines automated technical evidence with governance documentation. Neither alone is sufficient.

Technical evidence (automatable):

The following types of evidence can be collected automatically from source systems on a recurring schedule:

Access control and identity management — MFA configuration and enrollment status across all users, privileged account inventory and role assignments, password policies, Conditional Access or equivalent policy configuration, and last logon records.

Endpoint security — endpoint protection deployment status, health and policy compliance across all devices, detection and response capability, and device inventory.

Patch management — operating system and application patch levels, time-to-patch metrics, vulnerability scan results, and end-of-life software inventory.

Backup and recovery — backup job status, retention configuration, success and failure history, and backup isolation configuration.

Cloud security posture — cloud platform security configuration, encryption settings, logging and monitoring status, and IAM posture.

Network and perimeter — firewall and security gateway configuration evidence where exposed through management APIs.

All of this evidence can be collected directly from Microsoft 365, Active Directory, AWS, Azure, Google Cloud, CIS scanners, endpoint protection platforms, and backup software, the same systems the entity already operates. When committed to immutable, hash-chained storage, this evidence is verifiable, continuous, and auditable.

Governance evidence (requires manual input or attestation):

The following types of evidence cannot be collected automatically from technical systems. They require governance documentation, attestation, or manual input:

Board governance — board-approved information security policies, board minutes reflecting security discussions, board reporting on information security posture.

Policy framework — documented policies, annual review records, policy version history, evidence of policy dissemination.

Information asset register — asset classification, sensitivity mapping, criticality assessment.

Risk assessment — threat assessments, risk treatment plans, residual risk acceptance records.

Third-party management — third-party security assessments, contractual security requirements, monitoring arrangements.

Incident management — incident management plans, testing records, lessons-learned documentation.

Training — security awareness training records, completion Attesting, content review records.

Testing program — testing methodology, test schedules, assessor qualifications, test results, remediation Attesting.

The critical distinction:

An evidence platform should clearly distinguish between technical evidence (collected automatically and verifiable) and governance evidence (documented and attested). Where a CPS 234 requirement depends on governance evidence that the platform cannot collect automatically, the platform should report this as "insufficient evidence" — not as a pass.

This honest reporting is essential for CPS 234 because APRA assesses substance over form. An entity that presents a compliance report showing 100% pass across all requirements including requirements that depend on board governance, policies, and training is either genuinely comprehensive or dishonestly overreporting. APRA's supervisors know the difference.

An entity that presents a report showing strong technical evidence (90%+ pass) with clear identification of governance areas requiring manual attestation is demonstrating maturity an understanding of what is automatable, what requires human governance, and where the gaps are. This is the kind of honest, substance-over-form reporting that APRA respects.

Mapping CPS 234 to automated evidence

For regulated entities considering automated evidence collection for CPS 234, here is a practical mapping of which CPS 234 requirement areas can be supported by automated evidence and which require governance documentation:

Substantially automatable:

Information security capability (paragraph 16) — technical control evidence demonstrating capability: MFA, patching, endpoint protection, backup, encryption, access management, cloud security posture.

Implementation of controls (paragraphs 19–23) — configuration evidence and control-state evidence collected from source systems.

Incident detection mechanisms (paragraph 24, partially) — evidence of monitoring capability, detection tool health, and alert configuration.

Control testing (paragraphs 25–27, partially) — automated vulnerability scanning, benchmark testing, and continuous control-state monitoring as supplementary evidence to formal testing programs.

Requires governance documentation:

Roles and responsibilities (paragraphs 14–15) — board minutes, role descriptions, delegation records.

Policy framework (paragraph 17) — documented policies, review records.

Information asset identification (paragraph 18) — asset register, classification scheme.

Incident management plan (paragraph 24, partially) — plan documentation, testing records, lessons learned.

Testing by independent specialists (paragraph 26) — assessor qualifications, formal test methodology, engagement records.

Internal audit (paragraph 28) — audit plans, reports, findings.

APRA notification (paragraphs 29–36) — notification records, escalation procedures.

The practical approach:

Automate what can be automated, technical control, and evidence collected continuously from source systems. Document what requires governance policies, board minutes, asset registers, and testing programs. Attest to where required risk acceptance, governance approvals, and manual control confirmations.

A well-designed evidence platform handles the first category automatically, provides workflows for the second and third categories (governance attestation with immutable recording), and clearly labels which evidence type supports each CPS 234 requirement.

The relationship between CPS 234 and other frameworks

CPS 234 does not exist in isolation. Most APRA-regulated entities also engage with other compliance frameworks, and understanding the relationships between them is practical for efficient evidence management.

Essential Eight: The ACSC Essential Eight covers a subset of the technical controls relevant to CPS 234. An entity with strong Essential Eight coverage at L2 or L3 has significant evidence that its technical controls are commensurate with common threats. Essential Eight evidence feeds directly into CPS 234 evidence for implementation of controls (paragraphs 19–23).

ISO/IEC 27001:2022: ISO 27001 provides a comprehensive information security management system framework. An entity with ISO 27001 certification has a structured policy framework, risk assessment process, and control implementation program all relevant to CPS 234. However, ISO 27001 certification alone does not satisfy CPS 234, because CPS 234 has specific requirements (board governance, APRA notification, third-party management) that ISO 27001 does not mandate.

NIST CSF 2.0: The NIST Cybersecurity Framework provides a function-based structure (Govern, Identify, Protect, Detect, Respond, Recover) that maps well to CPS 234 requirement areas. Entities with NIST CSF alignment can map their CSF evidence to CPS 234 requirements.

The key insight is that evidence collected once can satisfy multiple framework requirements. An automated evidence platform that maintains universal controls mapped to multiple frameworks eliminates the duplication of effort that occurs when entities assess against each framework independently.

Practical steps for APRA-regulated entities

If your entity is regulated by APRA and you want to strengthen your CPS 234 evidence posture, consider these steps:

Step 1: Map your current evidence against CPS 234 requirements. For each requirement area, document what evidence you currently have. You will likely find that technical evidence is scattered across multiple systems, governance evidence is in various documents and email chains, and significant gaps exist, particularly in continuous monitoring and testing evidence.

Step 2: Identify which evidence can be automated. Review your current technology environment. If you use Microsoft 365, Active Directory, a major cloud platform, endpoint protection, and backup software, which most regulated entities do automated evidence collection is compatible with your environment.

Step 3: Establish a governance evidence workflow. For requirements that cannot be automated, board governance, policy management, asset classification, risk assessment, and testing programs establish a structured workflow that captures governance actions as formal, dated, attested records rather than informal documents and emails.

Step 4: Connect automated evidence to your CPS 234 mapping. When automated evidence collection is in place, map the collected evidence to specific CPS 234 paragraphs. This creates a living evidence register that is always current, not a point-in-time snapshot compiled before an APRA review.

Step 5: Prepare for APRA supervisory engagement. When APRA supervisors request evidence of CPS 234 compliance, the entity that can produce verified, continuous, mapped evidence with clear identification of what is proven by technical evidence and what is supported by governance documentation demonstrates a mature, substance-over-form approach to information security.

Platforms like APEXLyn Attest are designed for this purpose: automating technical evidence collection across all major system types, committing evidence to tamper-proof storage with cryptographic chaining, mapping evidence to CPS 234 and other frameworks (Essential Eight, ISO 27001, NIST CSF), and generating reports that distinguish between verified technical evidence and areas requiring governance attestation.