Essential Eight & APRA CPS 234 uplift for Australian teams on AWS.

What you get

Proof

The Essential Eight, translated to AWS

The ACSC publishes the Essential Eight as a set of mitigation strategies, not as a cloud implementation guide. That gap is where most Australian teams stall: the strategies were written with a Windows fleet in mind, and mapping them onto containers, managed services and infrastructure-as-code takes interpretation. Here is how each one lands on AWS in practice.

Maturity levels: what the jump actually costs

Organisations routinely tell me they are "targeting Maturity Level 2" without having priced what that means. The levels are not a percentage score — each one describes the adversary it is meant to stop, and the step between them is uneven.

Level 1 is aimed at commodity, opportunistic attacks using widely available tooling. Most teams with competent AWS hygiene are closer to this than they expect, and the remaining gaps are usually patch cadence and standing admin access.

Level 2 assumes an adversary willing to invest time and to use better tooling against a specific target. This is where the cost lands, because it demands consistency and evidence rather than capability — logs centralised and retained, privileged access reviewed on a defined cycle, patch windows met every time rather than usually. The engineering is rarely hard; the operational discipline is.

Level 3 assumes an adaptive adversary who will adjust to your controls. Very few organisations outside government or critical infrastructure genuinely need it, and pursuing it without a mandate is an expensive way to feel secure. I will tell you if I think you are aiming too high.

The practical sequence is to measure honestly against every strategy first — including the ones you expect to fail — then close the cheapest gaps that move whole strategies up a level, rather than polishing the strategies you are already good at.

APRA CPS 234, specifically

If you are an APRA-regulated entity, CPS 234 is not optional and it is not satisfied by the Essential Eight alone. The prudential standard has been in force since July 2019 and imposes obligations the Essential Eight does not cover.

Four things it asks for that teams commonly miss. First, clearly defined roles and responsibilities — the board retains ultimate responsibility, and that has to be documented, not assumed. Second, information security capability commensurate with the threat, which means your controls have to be justified against your actual risk profile rather than copied from a template. Third, systematic control testing on a defined program, with the results reviewed by internal audit — testing you can show, not testing you assert. Fourth, and most operationally sharp, notification timeframes: material information security incidents must be reported to APRA within 72 hours, and material control weaknesses within 10 business days.

That notification clock is the reason incident response and detection tooling belong in a CPS 234 engagement rather than being treated as a later phase. You cannot notify within 72 hours if it takes you a week to establish what happened. GuardDuty, Security Hub and CloudTrail wired to an actual response runbook is what makes the obligation achievable.

CPS 234 also extends to third parties: you remain responsible for information assets managed by service providers, which means your AWS shared-responsibility boundary needs to be written down and your vendors assessed.

IRAP, data residency and the ISM

IRAP is the Australian Signals Directorate's assessor program, and an IRAP assessment measures an environment against the Information Security Manual rather than against the Essential Eight. The two overlap but are not interchangeable — the ISM is considerably broader.

AWS operates IRAP-assessed infrastructure in Australia, and the Sydney and Melbourne regions give you genuine in-country data residency for workloads that require it. What the assessment does not do is cover your side of the shared responsibility model: the region being assessed says nothing about whether your VPC design, key management or access controls would survive review. Preparing for IRAP means getting your own configuration into a state an assessor can evaluate, with the ISM control mapping documented before they arrive.

If you handle personal information, the Privacy Act and the Notifiable Data Breaches scheme sit alongside all of this, with their own assessment and notification duties. These obligations stack rather than substitute, which is the argument for building one control set and mapping it outward instead of running a separate project per framework.

One control set, several frameworks

The reason I push clients toward a single implemented control set is arithmetic. Essential Eight strategy 5 (restrict administrative privileges), ISO 27001 Annex A access-control requirements, CPS 234's capability obligation and the ISM's privileged-access guidance are all satisfied by the same underlying implementation: just-in-time privileged access, no standing admin, complete CloudTrail coverage, and a documented review cycle. Implement it once, evidence it once, map it four ways.

The mapping is where the effort actually goes, and it is worth doing deliberately. AWS Config rules generate continuous compliance evidence, Security Hub aggregates against standards, and Terraform keeps the configuration from drifting between audits — which matters because the most common way an organisation fails a re-assessment is not a missing control but a control that quietly stopped applying eleven months ago.

Related engagements: ISO 27001 implementation, fractional CISO for the governance and board-reporting side, and secure cloud landing zone if you are starting from a greenfield AWS footprint. For the underlying platform work see AWS DevOps consulting.

Lift your security posture — with evidence.

Free 30-minute call — tell me your target maturity and timeline.