How to Prove Your Information Security Capability to APRA: A Practical Case Study for CPS 234 and CPS 230 Compliance

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

If you are asking, “How do I prove my information security capability to APRA?”, the answer is simple in principle and demanding in practice: show evidence that your controls are designed, operating, tested, monitored, and improved. APRA does not need a polished narrative; it needs a traceable proof chain from risk to control to test to remediation to governance. For APRA-regulated entities, that proof usually centres on CPS 234, and where operational resilience and service provider oversight matter, CPS 230. The organisations that fare better are the ones that can produce current records, not retrospective claims.

In practice, APRA reviewers will often compare what you say in your board paper, what your policies require, and what your logs, tickets, exceptions, and assurance reports actually show. That is why many institutions now align their evidence packs to CPS 234, the ACSC Essential Eight, and, where relevant, ISO/IEC 27001 and NIST Cybersecurity Framework (CSF) control families. A capability statement that cannot be traced to operating evidence is not capability; it is marketing.

What APRA Actually Means by “Capability”

APRA’s perspective is less about how good your security program sounds and more about whether it behaves like a live operating system. In other words, can you show that information security is embedded into business activity, not parked in a policy folder until the next review cycle?

That distinction matters in Australian financial services, healthcare, and government-adjacent environments. For example:

• A superannuation trustee may have strong policies but still fail a prudential review if privileged access reviews are overdue and exceptions are not risk-accepted.
• A private health insurer may have a mature incident response plan, but if ransomware playbooks have never been exercised against production-like conditions, capability is unproven.
• A government service provider may have Essential Eight uplift targets, yet still struggle if patching evidence, logging retention, and backup restoration tests are fragmented across teams.

In this case study, we follow a mid-sized APRA-regulated organisation that discovered this the hard way when it started preparing for a prudential review.

The organisation began with a familiar posture: approved policies, a recent risk assessment, and a board paper that said security was “under control.” That story felt complete until the team tried to assemble evidence for APRA and realised the documents did not connect to operational records. The patch report lived in one system, incident notes in another, supplier assurance in a third, and board reporting in slide decks with no direct link to remediation. The gap was not the absence of effort; it was the absence of proof that the effort produced durable control. APRA-ready capability is therefore not a slogan, but an evidence discipline.

Which standards mattered in the case

For this organisation, CPS 234 was the primary standard because it governs information security for APRA-regulated entities. CPS 230 also became relevant because some of the organisation’s most important services depended on external providers, internal continuity planning, and operational risk management. That meant the security conversation could not stop at endpoints and passwords; it had to include service availability, third-party oversight, and business impact.

The organisation also benchmarked its uplift against the ACSC Essential Eight because APRA reviewers increasingly expect security controls to be mapped to real-world mitigation measures, not just policy statements. In parallel, the team used ISO/IEC 27001 for control structure and NIST CSF for maturity language, because those frameworks make it easier to show a repeatable pattern of Identify, Protect, Detect, Respond, and Recover.

The team first mapped the standards to their obligations so they could avoid collecting evidence that looked busy but proved little. That mapping step became the anchor for everything else.

A compact way to think about the difference is this:

| Standard / Framework | What APRA or the assessor is looking for | Evidence that helps | |---|---|---| | CPS 234 | Information security capability, control effectiveness, incident handling, and materiality-based protection | Policies, control framework, testing results, incident records, vulnerability management, board oversight | | CPS 230 | Operational risk management, service provider oversight, and business continuity | Supplier assurance, critical service mapping, incident response, continuity plans, remediation tracking | | ACSC Essential Eight | Practical attack-surface reduction and recovery maturity | Patch reporting, MFA enforcement, application control, backup restore tests, privileged access management | | ISO/IEC 27001 | Governance, risk treatment, and auditable control management | Statement of Applicability, control register, internal audit findings, corrective actions | | NIST CSF | Organised security lifecycle and improvement | Risk assessment, detection metrics, response playbooks, recovery evidence |

The case study team used this distinction to avoid a common trap: treating all security evidence as interchangeable. APRA does not review a cloud assurance pack in the same way it reviews an incident root cause analysis, and it does not treat executive dashboards as substitutes for control testing. The lesson was blunt but useful: if you cannot name the obligation, you will probably collect the wrong proof. That is where many confident compliance narratives begin to fray.

Policies describe intent. Evidence shows whether the intent survives contact with operations.

How the Baseline Was Built Without Guesswork

The first practical step was to define the current state as it really was, not as the organisation hoped it to be. The team inventoried governance documents, security standards, procedures, control owners, exception registers, and reporting packs. They also compared those artefacts with system-level records, such as access reviews, vulnerability scans, incident tickets, and supplier assurance files. That exercise exposed a wide gap between documentation and execution. It was not a failure of policy; it was a failure of traceability.

This is where BCyber’s platform data became particularly relevant. Across the BCyber environment, the active inventory includes 23 policies, 9 processes, 50 courses (2 enrollments), 960 published articles, 549 knowledge hub entries, 11 clients, and 14 fact-find assessments. Those artefacts are useful because they show how mature programs move from isolated documentation to operationalised compliance. In APRA reviews, that matters: a policy library is not enough unless it connects to processes, training, and evidence.

The team then mapped security capability to the organisation’s material risks and business services. That meant identifying which systems supported customer operations, payment processing, core administration, and regulated reporting, then deciding which controls deserved the most scrutiny. This is where “capability” becomes measurable: a control is not important because it exists, but because it protects something the business cannot absorb losing. The team used that logic to prioritise identity and access management, vulnerability management, logging, incident response, and third-party oversight. In practice, they stopped trying to prove everything and started proving the controls that mattered most.

The evidence artefacts that established the baseline

The baseline package was intentionally boring, because boring evidence is often the most credible. It included an enterprise security risk assessment, an asset and data classification register, a control framework mapped to CPS 234, CPS 230, and the Essential Eight, and a responsibility model showing who owned each control. It also included a policy and standards inventory with version dates, approval records, and exception notes. That combination helped the team answer a question APRA often asks implicitly: if a control fails, who knows, who acts, and who signs off the risk? Without that clarity, capability remains abstract.

The organisation also defined scope and boundaries with unusual care. Shared services, cloud platforms, managed security providers, and outsourced operational functions were all included where they affected regulated operations. That prevented the dangerous assumption that a service was “someone else’s problem” simply because it was outsourced. APRA does not view outsourced risk as outsourced accountability, and neither should the control owner. The team’s scoping work created a clean line from regulated service to dependent technology to responsible party, which made later evidence collection far easier.

How the Control Framework Was Made APRA-Ready

The organisation’s next task was to translate standards into concrete controls that could be tested. Rather than writing broad statements like “security is managed in accordance with policy,” the team defined each control with an owner, frequency, purpose, evidence source, and expected outcome. That made the control library useful for operations instead of merely decorative for audit season. The result was a living control matrix that could be read from either direction: from risk to control, or from control back to the evidence that proves it. That kind of traceability is what turns a framework into a defensible operating model.

The control domains were unsurprising, but the discipline applied to them was the difference. Identity and access management covered joiner-mover-leaver processes, privileged access, and periodic access review. Vulnerability and patch management included scanning cadence, risk-based remediation timeframes, and exception handling. Logging and monitoring covered event collection, alert tuning, and analyst response. Incident response, third-party oversight, encryption, secure change management, and security awareness were all given similar treatment. The team did not try to over-engineer the model; it simply ensured that each control could be observed, measured, and challenged.

Where the organisation made the framework proportionate

Materiality shaped the final design. The organisation did not apply the same level of control intensity to every system, because APRA expects proportionate effort, not identical effort everywhere. Critical services received tighter patch windows, more frequent review, and stronger oversight. Lower-risk systems still had controls, but they were matched to the business impact and the data they held. That distinction matters because a control framework that ignores materiality is usually too blunt to be useful and too vague to defend.

Ownership also became more explicit. Each control had an accountable business owner, not just a technical team. Security leadership managed the framework, risk management reviewed exceptions, operations handled execution, and internal audit provided independent challenge. The board’s role was not to run the controls, but to understand the risk story well enough to question it properly. That governance chain was documented in a RACI matrix, which proved far more useful than a generic organisational chart.

The control artefacts that strengthened the case

The organisation built a compact but complete set of artefacts to support the framework. These included a board-approved security strategy, a control framework mapped to CPS 234, CPS 230, Essential Eight, ISO 27001, and NIST CSF, a RACI matrix, a control library with testing frequency, and an exception and risk acceptance process. Each artefact was version-controlled and linked to an owner. The result was not just a control framework, but a control framework with a memory. That memory mattered when APRA asked how a decision made six months earlier had been tracked through to remediation.

This is also where BCyber’s product ecosystem can support evidence discipline:

• GRACE Portal acts as a unified cyber resilience platform, bringing together single-dashboard visibility, cross-product analytics, executive reporting, compliance tracking, and real-time monitoring.
• Paradigm helps automate GRC activities through policy automation, compliance mapping, and risk quantification.
• Profiler adds behavioural intelligence for insider threat detection, access pattern monitoring, and user activity analytics.
• CyberTriage supports AI-powered incident response with 4-minute triage, automated response, and forensic analysis.
• Perfect Storm can be used for scenario modelling, impact analysis, and resilience testing.
• Privacy in Depth supports privacy obligations under the Australian Privacy Act where APRA-regulated entities also manage personal information.

The team also identified a subtle but important question: who owns the intelligence your security spend generates — you, or a vendor renting it back to you? That question pushed them to keep their evidence internal, traceable, and reusable across risk, operations, and governance. They wanted a system that learned from each control failure rather than forgetting it in the next cycle. That is the difference between compliance theatre and operative intelligence. One resets after each review; the other compounds.

How the Organisation Proved Controls Were Actually Working

Once the framework existed, the organisation had to show that controls were operating effectively, not merely designed well. This is where many APRA submissions become fragile, because the evidence stops at policy approval and never reaches operational behaviour. The team therefore collected records from the actual performance of controls: completed access reviews, vulnerability reports, patch compliance logs, incident tickets, and monitoring outputs. They treated each record as a point on a chain, not as a standalone artifact. That chain showed not only that a control existed, but that it produced an observable result.

Testing and assurance were central to this stage. Internal testing validated whether controls were applied consistently, while independent assurance reviewed whether they were functioning as intended. In some cases, the organisation used automated checks, such as access recertification reports and vulnerability scans, because automation reduced ambiguity and improved consistency. In other cases, manual review was still necessary, especially for exception handling and executive sign-off. The team did not pretend that a single test type was enough; instead, it used a mix of checks that together gave APRA a stronger picture.

How vulnerability and incident evidence was presented

Vulnerability management became one of the clearest proofs of capability. The organisation showed how vulnerabilities were identified, prioritised, assigned, and closed according to severity and business context. Where remediation could not happen within target timeframes, the exception register showed who approved the deferral, why it was accepted, and when it would be revisited. That record mattered because unresolved issues are not always evidence of failure, but unexplained unresolved issues usually are. APRA’s interest is not perfection; it is disciplined management of risk.

A practical example: in a financial services environment, a critical internet-facing system with delayed patching may be acceptable only if compensating controls are documented, tested, and time-bound. In healthcare, that same delay could be more serious if it affects clinical systems or protected health information. In government, the priority may shift again depending on public-facing service availability and identity assurance. The evidence must reflect context, not just technical severity.

Incident response evidence followed a similar pattern. The organisation retained incident logs, escalation notes, root cause analyses, and post-incident reviews. It also showed how lessons learned flowed into remediation actions, control updates, and staff awareness activities. Where incidents required reporting beyond the organisation, those records were linked to internal governance and, where relevant, APRA-facing obligations. That linkage mattered because a response process that cannot show learning is just a stopwatch. A response process that changes the control environment is evidence of capability.

Logging, monitoring, and alerting were also demonstrated through actual operational outputs. The team showed event retention settings, alert tuning reviews, and analyst response workflows. Where a SIEM or equivalent platform existed, the evidence included dashboards and sample tickets that proved alerts were being reviewed and triaged. Supplier assurance was then added to the picture through security clauses, attestations, remediation follow-up, and risk review notes. This was especially important under CPS 230, where material service providers and continuity dependencies are not optional background details. They are part of the control environment.

For capability uplift, the organisation also aligned training to role-specific needs. Security leaders completed BCyber courses that mapped to governance, risk, and operational execution. For example, awareness content supported policy comprehension, while operational staff used role-based learning to understand patching, incident escalation, and evidence handling. This mattered because APRA capability is not only technical; it is behavioural and procedural. Training that is not role-linked rarely changes control performance.

How Governance Became Part of the Proof, Not Just the Cover Page

The organisation’s board had previously received security reporting, but the material was too high-level to prove capability. The new approach changed that by linking governance papers to the operational evidence underneath them. Board packs now included current risks, major incidents, unresolved vulnerabilities, remediation status, and supplier issues, with clear decision points and explicit accountability. Minutes showed not just receipt of information, but challenge, discussion, and sign-off. That difference is subtle in wording and significant in regulatory practice.

Executive accountability was also sharpened. Senior leaders were assigned delivery responsibility for key remediation items, and those accountabilities appeared in management reporting rather than sitting in a side register. Security performance became part of operational rhythm, not a separate compliance ritual. That shift helped the organisation answer a question APRA would reasonably ask: if something goes wrong, who is actually responsible for fixing it? The answer was no longer implied; it was documented and tracked.

What the board evidence pack contained

The board and committee pack included governance artefacts that were current, approved, and aligned to operational reality. It contained a risk appetite statement, board papers, committee minutes, executive dashboards, and policy approvals. It also showed evidence of challenge, such as questions about overdue remediation, supplier risk, and exceptions to standard controls. The point was not to make the board look perfect; it was to show informed oversight. APRA generally trusts governance more when it can see that leaders ask hard questions and receive direct answers.

The organisation learned an important lesson here: governance is not a substitute for operational evidence. A strong board pack cannot rescue weak control performance, and a strong control framework cannot stand alone without oversight. The two have to reinforce each other. That interplay is what makes the proof chain credible. If one side is missing, the story loses depth.

What Went into the APRA Evidence Pack

The final evidence pack was built to be readable, traceable, and complete without being bloated. It started with the current information security framework and policies, then moved through risk assessment, control mapping, operational performance evidence, independent assurance, incident and vulnerability records, and governance artefacts. Each item was version-controlled, dated, and tied to an owner. The pack also included remediation tracking so APRA could see not only what had been found, but what had been done about it. This sequencing mattered because it allowed the reviewer to move from control design to operating effectiveness without jumping between disconnected folders.

The strongest part of the pack was the chain itself. Risk led to control, control led to testing, testing led to issues, issues led to remediation, and remediation led back to governance. That chain made the organisation’s security posture explainable without requiring a separate narrative to stitch the pieces together. In practice, that is what makes a submission efficient for both sides. The reviewer does not have to guess how the organisation thinks, because the evidence shows the thinking.

Mistakes the team deliberately avoided

The team avoided several common errors that often weaken APRA submissions. It did not submit outdated policies, even when they were neatly formatted. It did not rely on a polished narrative without supporting records. It did not use board reporting as a proxy for control testing. It did not ignore third-party risk, and it did not leave remediation actions floating without dates or owners. Those are simple mistakes, but they can create serious doubt when a regulator asks for proof rather than description.

The pack also used version control aggressively. Every artefact had a date, owner, and approval status, which reduced the risk of contradictions between documents. This mattered because one outdated statement can undermine an otherwise strong submission. APRA reviewers are trained to notice inconsistencies, especially where the story changes between policy, report, and operational record. A current, coherent pack is not just cleaner; it is more defensible.

How the Organisation Kept Capability Alive After the Review

The final phase of the case study was not about passing a point-in-time review. It was about making sure the organisation did not have to reinvent its evidence chain every time a regulator, board, or auditor asked for proof. The team built recurring cycles for monitoring, testing, reporting, and remediation. That created a continuous readiness model where compliance became a by-product of normal operations rather than a crisis response. In practice, the organisation moved from “prove it now” to “prove it anytime.”

Continuous improvement was built into the operating rhythm. Incidents fed back into control updates, assurance findings fed into remediation plans, and remediation plans fed into re-testing. The organisation also tracked a small number of practical indicators, such as patch SLA performance, unresolved vulnerability age, incident response timing, test pass rates, remediation closure, and supplier assurance completion. These measures did not guarantee safety, and they were never treated as such. They simply made improvement visible, which is often the first requirement for sustained maturity.

The lasting lesson for APRA-regulated entities

The organisation’s real achievement was not a neat submission. It was the creation of a security capability that could show its work at any moment. That is what APRA is ultimately trying to understand: whether information security is a living discipline or a staged performance. The answer becomes much easier to demonstrate when security is embedded into risk management, change management, project governance, and executive reporting. At that point, the evidence pack is not assembled for the regulator; it is produced naturally by the business.

If your evidence disappears when the review ends, your capability may not be as mature as it appears.

BCyber’s Role in Evidence-Driven Compliance

BCyber’s approach is designed to help regulated organisations build this kind of living proof chain. The GRACE Portal provides unified cyber resilience visibility through a single dashboard, cross-product analytics, executive reporting, compliance tracking, and real-time monitoring. Paradigm supports GRC automation with policy automation, compliance mapping, and risk quantification. Profiler helps identify behavioural anomalies that can indicate insider threat or access misuse. CyberTriage accelerates incident response through AI-powered 4-minute triage. Perfect Storm supports scenario modelling and resilience testing, while Privacy in Depth helps organisations manage privacy obligations under the Australian Privacy Act.

BCyber is also recognised in the market, with Karen Stephens, Co-Founder & CEO, named a 2025 Finalist for Cybersecurity Professional of the Year, and BCyber named a 2025 GRC Provider of the Year finalist and 2025 AI Innovator - Cyber Security finalist. These recognitions do not replace evidence, but they do reflect the organisation’s focus on practical, audit-ready capability.

Sources and Further Reading

For readers building their own APRA evidence pack, these are the most relevant authoritative references:

• APRA CPS 234 Information Security

• APRA CPS 230 Operational Risk Management

• APRA Information Security Guide

• ACSC Essential Eight Maturity Model

• NIST Cybersecurity Framework (CSF)

• ISO/IEC 27001 overview

• ACSC Strategies to Mitigate Cyber Security Incidents

Conclusion

This case study shows that proving information security capability to APRA is not about producing more documents; it is about producing a credible chain of evidence. The organisation in the story succeeded by moving from policy-based compliance to evidence-based capability, with clear links between risk, control, testing, remediation, and governance. It treated CPS 234 as an operating standard and CPS 230 as a resilience and supplier oversight lens where relevant. It also used the Essential Eight, ISO 27001, and NIST CSF to make the capability easier to operationalise and verify.

The practical lesson is straightforward. If you cannot show what you protect, how you protect it, how you test it, and who owns the outcome, APRA will not be able to see your capability clearly. A strong evidence pack is not an audit trick; it is a reflection of disciplined operations. The organisations that do this well are not necessarily louder about compliance, but they are easier to trust because their records line up with reality.

Key Takeaways

• APRA wants proof, not presentation. Policies matter, but only when supported by current operational evidence.
• CPS 234 is the core standard, and CPS 230 becomes important where service providers, resilience, and continuity are in scope.
• The evidence chain matters most. Risk, control, testing, remediation, and governance should connect cleanly.
• Board oversight is part of the proof, but it must complement, not replace, control performance records.
• Continuous readiness beats point-in-time preparation. The best evidence pack is the one your organisation can keep current every week, not only before a review.
• Use recognised frameworks to strengthen your case. Mapping evidence to the Essential Eight, ISO 27001, and NIST CSF helps APRA reviewers understand maturity faster.

Verification note: BCyber platform inventory figures and product capabilities in this article are based on internal BCyber real platform data provided for editorial use. Any organisation-specific outcomes in the case study are presented as a composite, de-identified example to protect client confidentiality.

If you want, I can also turn this into a client-ready PDF-style case study, a shorter website version, or an SEO landing page with APRA-focused FAQs.