Threat Modelling Under APRA CPS 234: Evidence for the Design-Time Obligations

Something has gone wrong, and someone is asking how the affected system came to be protected the way it was.

It might be your supervisor, after a notification under paragraph 35 of CPS 234. It might be internal audit, running the review of control design and operating effectiveness that paragraph 32 requires. It might be an independent specialist brought in under a tripartite arrangement, or your own board on day three of an incident, wanting to know whether anyone saw this coming. The question is always a version of the same one: when this system was designed, who decided what would protect it, and against what?

"We applied our security baseline" is a weak answer. It is honest, it is often true, and it tells the person asking nothing about this system. A baseline is a set of controls chosen without reference to the thing in front of you, which is precisely the gap the question is probing.

"Here is the dated threat model the controls came from, the threats it enumerated, what we did about each one, and who signed it" is a strong answer. Not because it proves the design was right, but because it shows a decision was made on evidence, by named people, at the time it could still be changed cheaply.

What CPS 234 actually asks of system design

Read CPS 234 end to end and you will not find threat modelling. The words do not appear in the July 2019 standard, and they do not appear in CPG 234 either. Anyone selling you threat modelling as an APRA requirement is one search away from being contradicted, so start from what is genuinely there.

What is there is a cluster of obligations that design work is the natural way to satisfy.

Paragraph 15 requires an information security capability commensurate with the size and extent of threats to your information assets. Paragraph 20 requires you to classify your information assets, including those managed by related parties and third parties, by criticality and sensitivity. Paragraph 21 is the one that bites hardest at design time: controls must be implemented in a timely manner and must be commensurate with the vulnerabilities and threats to the information assets, their criticality and sensitivity, the stage at which they sit within their life-cycle, and the potential consequences of an incident. The standard's own footnote defines that life-cycle as the process from planning and design through to decommissioning and disposal. Design is inside the obligation, not adjacent to it.

Then paragraph 27 requires a systematic testing program whose nature and frequency track the rate at which vulnerabilities and threats change, and paragraph 31 requires you to review the sufficiency of that program at least annually or on material change to information assets or the business environment. Paragraph 17 says the same thing about capability itself: it must be actively maintained with respect to changes in vulnerabilities and threats, including changes to your own assets. Paragraph 13 puts the board at the top of all of it.

Notice the word that keeps recurring. Commensurate. It is a comparative test, and comparative tests require both sides to be visible. To show that a control is commensurate with a threat, you have to be able to point at the threat. A uniformly applied baseline gives you one side of that comparison and asks the assessor to take the other on trust.

CPG 234 is guidance rather than obligation, and says so plainly: prudential practice guides discuss statutory requirements but do not themselves create enforceable requirements. Read in that light, it is still the clearest signal of what APRA considers sound practice. It lists "vulnerability and threat management" and "secure design, architecture and consultation" among the specialised capabilities entities typically need. It notes that planning and design controls, as the first phases of the asset life-cycle, would typically ensure security is built into the asset. Its security principles name secure by design directly, and its software security attachment expects information security requirements to be identified as part of requirements definition and to address potential threats. None of that is a mandate. All of it describes work that threat modelling is a recognised way of doing.

Why threat modelling is the cleanest evidence

A threat model is not a compliance artefact by nature. It is a design activity that happens to leave behind exactly the record these obligations ask you to produce, which is a much better position than an artefact built to be shown.

The mapping is close to one to one. Drawing the system names its information assets as concrete data stores and flows, and each one can carry the criticality and sensitivity classification paragraph 20 requires, at the level of the system rather than the register. Enumerating threats by a stated method, usually STRIDE per element, gives coverage that can be argued about instead of asserted. Mapping each threat to a control, an accepted risk, or a documented exclusion is the paragraph 21 comparison written down. The unmitigated threats you counted rather than hid become the priority list for the paragraph 27 testing program, which is how testing gets aimed at something. And a baselined model with re-review triggers is what keeps the whole thing current in the sense paragraph 17 describes.

The assessor's real question was never "do you threat model". It is "show me why these controls and not others, for this system". A model answers that in the form of a record someone else can follow.

A process that fits a regulated entity

The method is the easy part. What makes threat modelling survive contact with a regulated environment is the process wrapped around it, and most of that wrapper is already implied by the standard.

Tier by criticality, using the classification you already have. Paragraph 20 makes you classify information assets by criticality and sensitivity, so use that as the input to depth rather than inventing a second scale nobody maintains. A change to a payments path and a change to an internal reporting tool should not receive the same treatment. Tiering sets depth, reviewer seniority, and turnaround. It does not decide whether the model happens.

Name the sign-offs, including the asset owner. Paragraph 14 requires clearly defined roles and responsibilities for decision-making, approval and oversight, and paragraph 13's board accountability is only real if it lands on named individuals further down. CPG 234 goes further and describes formal allocation of accountability for an asset's security to an information asset owner, typically located in the business function most dependent on it. That person should be on the model, because they are the only one who can genuinely accept a residual risk.

Draw the boundary at the edge of your control. Paragraphs 16, 21 and 22 all extend to information assets managed by related parties and third parties, and paragraph 22 asks you to evaluate the design of that party's controls. On a diagram, that is a trust boundary drawn where you stop being able to enforce anything, and the threats that cluster on it are the ones your third-party assurance has to actually answer.

Baseline the approved design, then watch it drift. You cannot demonstrate that capability was actively maintained against change unless there is a recorded state to compare against.

If you want the surrounding governance in more detail, that is the subject of what a security design review contains. If you want the analysis itself walked end to end on a real system, start with the step-by-step threat modelling guide.

CPS 230 gets the same analysis for free

CPS 230 commenced on 1 July 2025 and asks a different question: not whether information is protected, but whether the business keeps running. Paragraph 34 requires a register of critical operations and a credible continuity plan. Paragraph 38 requires tolerance levels for each critical operation: how long a disruption you would tolerate, how much data loss you would accept, and the minimum service levels you would hold during one. Paragraph 27 requires you to identify and document the processes and resources needed to deliver critical operations, including people, technology, information, facilities and service providers, and the interdependencies across them. Paragraph 40 wants the continuity plan to assess execution risks and key internal and external dependencies.

Look at what a threat model already contains. Every external entity on the diagram is a dependency. Every denial of service threat is a resilience question wearing a security hat. Every trust boundary with a provider on the other side is a service-provider relationship someone will have to document anyway. The analysis has been done; it is sitting in a security document because that is who ran the workshop.

Be honest about the limits. A threat model does not set tolerance levels: those are business decisions made by people who understand what an outage costs customers. It is not scenario analysis, which tests severe but plausible events end to end. What it does is stop the two programs from maintaining separate, quietly divergent pictures of the same system, which is what happens within about a year when security and resilience each keep their own diagrams.

Getting there

Two honest paths, and the first one is genuinely viable.

Stand the practice up yourself. The method is public and not difficult; the step-by-step guide will get a competent team through a real system. What is hard is the part after the first model: triggers people actually honour when a release is late, tiering that keeps the queue survivable, and records that outlive the engineer who wrote them. Budget your effort there, not on choosing a methodology.

Or bring help in. A threat modelling uplift engagement models your highest-priority systems with your engineers in the room and leaves behind the process and the threat library rather than a report. If the prior question is how wide the gap is across both prudential standards, a CPS 234 readiness assessment measures capability against each requirement and hands you the gap register. We prepare and evidence; we do not certify anyone's compliance, since that sits between the entity, its board and APRA.

Either way, the models need somewhere to live. That is what threat modelling in Alvor is for: models anchored to the architecture rather than filed next to it, controls that carry through from mapped mitigation to evidence, and sign-offs recorded on the model itself. The audit-ready record becomes a by-product of doing the work, which is the only version of compliance evidence that stays true.

Nobody gets credit for a threat model. What you get is a better answer to the question that arrives after something breaks: when this was designed, who decided what would protect it, and against what.