APRA CPS 234 doesn't care how many security tools you bought. When an auditor sits down with your AWS environment, they want three things: that you've classified your information assets, that your controls map to that classification, and that you can produce the evidence on demand. Most AWS environments handle the first two and fall over on the third.
This is the practitioner mapping I wish existed when I started: each CPS 234 requirement, the AWS service that addresses it, the specific AWS Config rule or Security Hub control that proves it's working, and the evidence artifact an auditor will actually accept. (CPS 234 now pairs with CPS 230, the operational-risk standard live since 1 July 2025.)
This is practitioner guidance to accelerate your control mapping — not legal or audit advice. Validate against the current APRA CPS 234 text and your own environment before relying on it.
Start with the foundations, not the controls
Before mapping a single clause, stand up the baseline. Almost every control below lights up from it:
- AWS Security Hub with the AWS Foundational Security Best Practices (FSBP) and CIS AWS Foundations standards enabled.
- AWS Config turned on in every account and every region — not just the ones you remember.
- GuardDuty centralised via an Organizations delegated administrator.
- AWS Audit Manager with a custom CPS 234 framework, so evidence collects continuously instead of in a panic the week before the audit.
If you skip this and try to satisfy CPS 234 control-by-control, you'll rebuild the same plumbing ten times.
The mapping
CPS 234's requirements group into a handful of themes. Here's the practitioner view.
Roles & responsibilities (Para 13–14)
The Board is ultimately accountable, and roles must be clearly defined. On AWS this is Organizations + IAM Identity Center + Service Control Policies — your org structure is the documentary evidence of who can do what. The Config rule iam-policy-no-statements-with-admin-access catches the most common failure: over-broad admin policies that make "clearly defined responsibilities" a fiction.
Implementation of controls (Para 21–22)
This is the bulk of the work, and it splits four ways:
| Control area | AWS services | Proves it with |
|---|---|---|
| Identity | IAM, Identity Center | iam-root-access-key-check, root-account-mfa-enabled, mfa-enabled-for-iam-console-access, access-keys-rotated |
| Data protection | KMS, S3, EBS, RDS | s3-bucket-server-side-encryption-enabled, s3-bucket-public-read-prohibited, encrypted-volumes, rds-storage-encrypted |
| Network | VPC, Security Groups, WAF | restricted-ssh, restricted-common-ports, vpc-flow-logs-enabled |
| Patching | Systems Manager, Inspector | ec2-managedinstance-patch-compliance-status-check |
The evidence is the per-resource Config compliance timeline plus your Security Hub CIS score export. An auditor doesn't want to hear "we encrypt everything" — they want the timeline showing the rule was compliant across the period.
Incident management & logging (Para 23–26)
Detection is GuardDuty + Security Hub + EventBridge; the logging that makes incidents investigable is CloudTrail + CloudWatch Logs. The rules that matter here — multi-region-cloud-trail-enabled, cloud-trail-log-file-validation-enabled, cloud-trail-encryption-enabled — are exactly the ones that get quietly disabled in dev accounts and then forgotten. Log file validation is the one auditors specifically look for, because it proves your logs weren't tampered with.
Testing control effectiveness (Para 27–30)
CPS 234 requires systematic testing, not an annual scramble. This is where open-source Prowler earns its place alongside Security Hub: continuous scanning, and — when you get a finding — a remediation that's tracked, not just noted. Config auto-remediation (SSM Automation bound to non-compliant rules) is how you show APRA that gaps get closed, with a remediation execution history to prove it.
APRA notification (Para 35–36)
You have 72 hours to notify APRA of a material incident. That's an EventBridge rule on GuardDuty/Security Hub severity firing into SNS, plus a documented runbook. The evidence is the EventBridge → SNS delivery logs showing the path works — test it before you need it.
Where almost everyone fails: evidence on demand
Engineers build the controls. What they skip is making the evidence exportable and current. When the auditor asks "show me that S3 encryption was enforced across Q2," a screenshot of today's console is worthless — they want the Config compliance timeline for the period. The teams that pass quickly are the ones who treated Audit Manager as the evidence collector from day one, not the ones with the most tools.
Get the full mapping
The complete table — every clause mapped to AWS services, Config rules, and evidence artifacts — is in the free CPS 234 → AWS Controls cheatsheet. It's the reference I hand to every engineering team I work with.
If you'd rather have someone run this against your estate and hand you a board-ready evidence pack, that's exactly what a CPS 234 on AWS readiness assessment is.