This is the build, not the argument. The companion article, Obsolete the Day You Sign It, makes a narrower case than the usual one: Australia has already written continued authorisation down. PSPF Release 2026 carries a section headed "Continued Authorisation" and says authorisation to operate is generally ongoing once a system is operational (s 13.3.1.1). What is missing is the machinery under those words, an evidence plane on a defined cadence at a defined threshold, and a named cATO status an entity can be granted, held to and lose. This page is the machinery half, walked stage by stage: a standard, plug-and-play continuous Authority to Operate (cATO) pipeline for Australian national-security, intelligence and enforcement agencies. The interactive above is the whole framework in one view. Hit Explode and watch the swappable adapters dock into a fixed spine.
One line of thesis, then the guts of it: the spine is constant, the parts swap, and it re-applies across agencies at any classification. An agency at OFFICIAL and an agency at TOP SECRET run the same ten stages. What changes is the profile, the tooling and the strictness of the gates, not the shape of the lifecycle.
Before you read another word: all data here is synthetic, the AI is stubbed, and this is a concept build, not a product. It exists to make a design tangible and to argue that this is buildable in Australia today. It is portfolio proof, not something you would point at a live enclave.
The Maturity Path
No agency lands at continuous authorisation on day one, and pretending otherwise is how programmes stall. The spine is a ten-stage lifecycle that does not budge between agencies. The maturity path is how an agency climbs from an ongoing authorisation nothing evidences to one that is re-evidenced on a cadence, in four phases:
Current state. Existing systems, documentation ranging from mature to missing, and an authorisation that is ongoing on paper and re-examined only when a system owner judges that a risk level has been exceeded. The certificate is not the defect. The absence of anything watching it is.
Digitise and baseline. Convert the existing documents into OSCAL. Select the profile for the classification. Raise a Plan of Action and Milestones (POA&M) for every gap so the picture is honest.
Instrument. Stand up continuous monitoring and the policy-as-code gates. Evidence starts flowing on its own instead of being assembled the week before an audit.
Continuous authorisation, drift-bounded. Authorisation becomes a live state, re-verified every refresh interval, so the gap between authorised and actual is bounded to one interval's worth of change rather than years of it.
The through-line that makes every stage talk to the next is OSCAL, the Open Security Controls Assessment Language, which carries a control from its definition to its live assessment without a human retyping it at each seam. Read that precisely, because it is the thing people get wrong about OSCAL. It is the interchange format and the archive, not the runtime. Nothing in a real stack runs OSCAL: Splunk emits Splunk events, ServiceNow holds ServiceNow records, OPA returns Rego decisions, and every one of them needs an adapter that generates OSCAL on the way out and resolves it on the way in. What OSCAL buys you is that the conversion happens once per seam, in a declared place, instead of in a person's head every time somebody asks whether a control still holds. Each stage below names what you implement, the OSCAL artefact it emits, and the thing that will bite you if you get it wrong.
The sim below makes the consequence concrete before we open the toolbox. Move its phase control from 0 to 3 and watch the undocumented controls convert to continuously evidenced ones. Then leave it refreshing only at the point of signing and advance the clock: the record stays reassuringly green while the real posture quietly ages to amber and red. Flip it to continuous and the gap snaps back inside its bounds at every refresh. That gap is the entire reason the rest of this build exists.
The Evidence Spine
Every stage below emits into the same evidence chain, so it is worth naming the chain before we start filling it. OSCAL gives you seven interlocking models, and the whole framework is the discipline of keeping them in sync: the catalog (the controls themselves), the profile (the tailored baseline for a classification), the component-definition (what each adapter claims to satisfy), the SSP (the system as designed), the assessment-plan (how the controls will be checked), the assessment-results (what monitoring actually found), and the POA&M (what is not yet met and when it will be). When those artefacts are machine-readable, the question "is this system still meeting its baseline" becomes a query you run on a quiet Tuesday, not a project you stand up every few years.
The sovereign point is the one that matters most, because it decides whether any of this waits on a policy cycle. ASD already publishes the Information Security Manual in OSCAL, so the Australian control baseline is machine-readable today. Two precisions to keep, because both are easy to overstate. ASD ships the catalog and the per-classification profiles, not the System Security Plans, so the parts of the chain that describe a specific system are the parts each system writes for itself. And ASD's own word for those per-classification profiles is "illustrative": the catalog is the authoritative object, the profiles are a worked example of applicability, and an entity that treats one as a compliance verdict has skipped its own tailoring. The two pieces of overseas lineage worth naming honestly are OSCAL itself, the data format the ISM is published in, and NIST's Risk Management Framework notion of ongoing authorisation, which is where the cATO idea came from. Nothing else is imported.
Three Clocks the Evidence Plane Has to Watch
A machine-readable baseline solves one problem and creates another, and the second one is where most of these builds quietly rot. Three things version independently, and none of them waits for the others.
The ISM release. ASD updates the ISM quarterly, and each release changes controls. An assessment made against the June 2026 ISM is an assessment against a different baseline than one made three months later.
The OSCAL schema. The vendored release here is OSCAL 1.1.2. The format itself versions, and a pipeline pinned to one minor version will either break or, far worse, silently misread on the next.
The tool-native model. Every adapter converts. The SIEM's schema, the ITSM's record shape and the scanner's finding format all move on their vendors' release cycles, not on ASD's.
The consequence of leaving those unmanaged is not theoretical. The Auditor-General found that the control library inside Defence's ICT authorisation management system held ISM controls from various versions of the ISM between April 2013 and September 2021, and that the Essential Eight annex wired into its live assessment process reflected the December 2022 ISM while the ISM itself was shipping quarterly (ANAO, 2024, nn. 71, 88). Eight years of baseline versions coexisting in one tool, with nothing on the record saying which assessment was made against which. A control marked satisfied is close to meaningless if you cannot say satisfied against what.
So the framework treats version as evidence, not metadata:
Stamp provenance on every artefact. Each assessment-result carries the ISM release it was evaluated against and the OSCAL version it was serialised in. A control's state is a claim about a specific baseline at a specific time, and it should be impossible to record one without the other.
Make re-baselining a trigger in its own right. When ASD ships a release, compute the profile delta and re-evaluate only the controls whose text or applicability actually moved. This is the machine version of the "Commonwealth or Defence policy changes" re-authorisation trigger, which the ANAO found nobody actioned: two of the five systems it examined ran straight through two PSPF revisions with no reference to either in their documentation.
Put the version in the adapter contract. The slot contract is not "emits OSCAL". It is "emits valid OSCAL 1.1.2 carrying a baseline identifier", so a version mismatch fails at the seam rather than surfacing as a wrong answer years later.
The encouraging part is that ASD has already done the hard half. Every control in the published ISM OSCAL catalog carries revision and updated properties, so a version-aware evidence plane is buildable on data that is on an Australian government server today.
Inheritance Is Not Just Technical
The inheritance most OSCAL writing talks about runs on one axis: a platform is authorised, a system built on it inherits controls, and the system implements only its residual. That axis is real and it is Phase 1's whole economic argument. It is also not the axis that breaks agencies.
The other axis runs down a policy hierarchy, and Defence's own document tree is the clearest published example of it:
Legislation and whole-of-government policy (PSPF)
→ Accountable Authority Instructions (Secretary)
→ Defence Instructions (Secretary and CDF)
→ Defence policies and manuals (DSPF)
→ Service instructions, SOPs, templates (Army, Navy, Air Force)
Five layers, each authored by a different officer, each versioned on its own schedule, and nothing anywhere computing the difference between a layer and its parent. The ANAO found divergence at every seam. Changes to PSPF Policies 10 and 11 made between August 2020 and February 2022, including the Essential Eight and the ISM six-step process, did not reach the DSPF until 10 May 2024, a 46-month inheritance lag, during which key authorisation roles sat undefined for 13 of the 14 Services and Groups. Below that, Army guidance offered a "streamlined security assessment" in lieu of formal certification, which the parent framework does not permit. Navy's risk scale did not align with the DSPF's, and for Extreme-risk systems the Chief of Navy was both System Owner and Authorising Officer, which the DSPF's independence requirement forbids. Air Force allowed systems to be force assigned "without or with partial certification", and its June 2024 instruction permitted officers below SES 1 to authorise moderate and low risk systems a month after the updated DSPF required SES 1 (ANAO, 2024, paras 2.17, 2.28, 2.32, 2.34, 2.38).
Every one of those was discoverable only by a human reading two documents side by side. It took a performance audit to find them.
The mechanism to fix this already exists in OSCAL and almost nobody uses it this way. A profile can import a catalog or another profile, and apply include, exclude and modify. That is an inheritance-with-declared-deviation operator. ASD uses it once, to tailor the ISM per classification. Chain it instead:
ISM catalog ASD, authoritative
└─ whole-of-government profile
└─ entity profile declares its deviations from the parent
└─ Group/Service profile declares its deviations from the entity
└─ system profile declares its residual tailoring
Two things that currently need an Auditor-General then become queries. A layer that drops a control its parent mandates shows up as an exclude with no authority to exclude, catchable when the profile is authored rather than four years later. And when a parent changes, every child profile importing it is flagged stale, so a 46-month lag becomes a build failure on the day ASD publishes.
The four kinds of constraint an agency actually carries are not the same kind of object, and the design has to say so rather than flatten them:
Organisational and governance policy. Who may authorise, at what level, and whether the roles must be independent. These are not ISM controls at all: they constrain the process, not the system. They live in an entity-authored catalog that the profile chain imports, which is legitimate OSCAL and worth stating plainly as an extension beyond anything ASD publishes.
Technical control policy. Native profile territory, and the easy case.
Design principles. "This system must not egress to the public internet" is promoted at Stage 1 from a sentence in a PDF into an evaluable rule. It belongs in the chain as an entity-level added control, not as a good intention in an architecture document.
Agency-specific constraints. An air-gapped enclave cannot run a cloud-hosted SIEM, and a deployed platform cannot phone home. These are applicability constraints, and they are the honest reason a Service instruction diverges from its parent in the first place.
That last one carries the whole design philosophy, so it is worth being blunt about it. The failure at Defence was not that Navy diverged. Navy had real constraints and a genuine capacity problem. The failure was that Navy diverged undeclared. The job of an open architecture is not to stop agencies differing from the centre, which is neither possible nor desirable at this spread of classifications and missions. It is to make every divergence declared, justified, and inherited from a named parent, so that the difference between a considered exception and a quiet drift is a field in a file rather than a matter of opinion.
Phase 0: Context and the Current State
You do not start from a blank page. You start with a real system carrying an authorisation nobody has re-evidenced since signing, documentation ranging from thorough to contradictory to absent, and a boundary nobody has looked at closely in a while. Phase 0 is one stage, and it is the one everything else inherits.
Stage 1, context and authorisation boundary. Name the mission, the classification, the architectural constraints, and the design principles you are treating as policy. Set the boundary: what is in the system and what is not. Name the people who carry the risk, the Authorising Officer (AO) and the Information System Security Officer (ISSO), because a control with no owner is a wish.
What you implement: the boundary definition and the risk-ownership record that seed the SSP. A design principle like "this system must not egress to the public internet" gets promoted here from a sentence in a PDF into a rule the pipeline can later evaluate, not left as a good intention.
The artefact it emits: the opening entries of the OSCAL SSP, the system characteristics and the authorisation boundary.
The gotcha: everything downstream inherits this stage's decisions, so a boundary drawn loosely here quietly widens the blast radius of every later stage. Measure twice, cut once. Get the boundary and the owners right before you write a line of pipeline.
Phase 1: Digitise and Baseline
This is where the paper you already have becomes data, and where the economics of the whole thing change. Three stages.
Stage 2, baseline selection. Pick the control baseline for the classification: an ISM-OSCAL profile per classification level, paired with an Essential Eight maturity target (ML1, ML2 or ML3 as the consequence rises). The baseline arrives as data, not a PDF.
What you implement: the classification-to-profile choice, wired so the SSP resolves against the right profile.
The artefact it emits: the selected OSCAL
profile, which tailors thecatalogfor the classification.The gotcha: lead with the ISM's own control numbering. If you reach for a NIST SP 800-53 mapping, keep it a hedged aside, conceptually mappable at most, and never imply a crosswalk ASD has not published.
Stage 3, documentation ingestion and digitisation. Ingest what exists, convert it to OSCAL, and where there is a gap, do not paper over it.
What you implement: the ingestion path that turns prose into structured OSCAL implementation statements, and the gap-tracking that raises a POA&M for anything silent, contradictory or aspirational.
The artefact it emits: draft
component-definitionand SSP content, plus aPOA&Mentry per gap, dated and owned.The gotcha: the temptation is to make the picture look finished. Resist it. A tracked gap is an asset; a hidden one is a liability that surfaces on the worst morning of the year. This is where AI genuinely helps, drafting the crosswalk from a legacy document, with a human confirming, never deciding.
Stage 4, system and component definition. Produce the SSP as an OSCAL artefact. Each adapter in the catalogue ships its own OSCAL component-definition, so plugging in a SIEM or an identity provider brings its control claims with it rather than leaving you to hand-write them. A component-definition is smaller than people expect. Here is an illustrative one for the SIEM adapter, claiming the controls it satisfies:
{
"component-definition": {
"uuid": "11111111-1111-4111-8111-111111111111",
"metadata": {
"title": "Illustrative SIEM telemetry adapter",
"last-modified": "2026-07-18T00:00:00Z",
"version": "0.1.0",
"oscal-version": "1.1.2"
},
"components": [
{
"uuid": "22222222-2222-4222-8222-222222222222",
"type": "software",
"title": "SIEM telemetry adapter (example)",
"control-implementations": [
{
"uuid": "33333333-3333-4333-8333-333333333333",
"source": "ism-oscal-profile://protected",
"description": "Continuous monitoring feed",
"implemented-requirements": [
{ "uuid": "44444444-4444-4444-8444-444444444444", "control-id": "au-6", "description": "Emits assessment-results on a fixed cadence." },
{ "uuid": "55555555-5555-4555-8555-555555555555", "control-id": "si-4", "description": "Drift and anomaly signals folded into POA&M." }
]
}
]
}
]
}
}
The control identifiers here (au-6, si-4) are illustrative and NIST SP 800-53-style, since OSCAL component-definitions commonly reference the 800-53 catalog. An ISM profile would carry the ISM's own numbering. The uuid and metadata fields are the ones the schema actually requires, so this validates rather than just reads well.
What you implement: the SSP that ties components to the controls they satisfy, and the per-adapter component-definitions that make that reusable.
The artefact it emits: the OSCAL
system-security-planand acomponent-definitionper adapter.The gotcha: this is where authorisation is really won, and it turns on two fields. The first is state: the
implementation-statusNIST defines, being implemented, partial, planned, alternative or not-applicable. The second is inheritance: whether the system implements a control itself, inherits it from a platform that already carries it, or shares it, expressed through the SSP'sleveraged-authorizationassembly and itsprovided,inheritedandsatisfiedstatements. Both are core OSCAL, neither is something ASD publishes, and neither imports a US authorisation programme. They live in the SSP each system writes.
Inheritance is the part that changes the economics. A platform is authorised once. Its SSP exports the controls it provides, each with the responsibility it hands down. A system built on that platform declares a leveraged authorisation, marks those controls as inherited against the platform's exported ids, and implements only its residual: the controls that are genuinely system-specific. Do that across a fleet and the marginal work of authorising the next system collapses.
The numbers make it concrete. The June 2026 ISM OSCAL release carries 1,150 items, being 1,101 controls and 49 principles, and the PROTECTED profile applies 1,035 of the 1,150 items in the ISM OSCAL catalog. Authorise a platform that legitimately provides two-thirds of those and a new system on it implements a few hundred residual controls instead of the full 1,035. The baseline did not shrink. The work each new system has to repeat did. The Australian analogue is real, if prose-based rather than schema-mandated: ASD's Cloud Assessment and Authorisation guidance and the IRAP Common Assessment Framework already run on shared-responsibility control inheritance. The interactive below runs the maths on the real ISM baseline: set a classification, authorise the platform, and watch the residual each system owns collapse.
That usually gets sold as a cost argument, which undersells it. It is a throughput argument, and the Auditor-General has now put public numbers on why throughput is the thing that matters. Between 2012 and 2023 Defence authorised systems at an average of 0.2 per cent of its identified IT estate per year, reaching 0.3 per cent in 2023 even after a 744 per cent increase on its 2012 figure. Five per cent of its IT systems had been recorded in its authorisation management system at all, 47 per cent of those recorded sat at expired or no accreditation, and a request took an average of 285 days to complete. Its own Control Owner report in May 2024 assessed the maturity of the relevant principle as "developing" and concluded that "the volume of Defence ICT systems outweighs available resources for assessment and authorisation activities" (ANAO, 2024, paras 3.14, 3.16, 3.17, 3.21, 3.61). The Auditor-General drew the same line I am drawing here, putting that resourcing finding directly alongside the 0.2 per cent. Per-system artisanal assessment cannot close a gap that is growing faster than it is. That is division, not opinion.
So the unit of assessment has to move up. Rather than assessing each system as a fresh object, you assess the environment that produces systems: the platform, the pipeline, the control plane, and the people and process wrapped around them. A system built inside that environment inherits the great majority of its controls, including the procedural ones, and carries only its declared residual. This is not a new mechanism. It is the leveraged-authorization model generalised from "the platform provides the infrastructure controls" to "the production environment provides most controls, including the ones about people".
What keeps that honest is a declared conformance envelope: the shapes of system the environment is authorised to emit, expressed as data classifications, connection types, deployment topologies and component categories. Inside the envelope, inherit. Step outside it, with a new classification, an external connection nobody has assessed, or a component type the environment has never produced, and you assess the delta, because that is genuinely new risk and no prior authorisation reaches it. The difference from the re-authorisation triggers in the DSPF, which the ANAO found fire only when a person happens to notice, is that an envelope violation is computable at deploy time.
Three things this deliberately does not claim:
It does not remove the per-system authorisation. PSPF Policy 11 requires the residual risk of a specific system to be accepted by an accountable person, and you cannot accept in advance the residual risk of a system that does not exist yet. What changes is the size of the decision: not "I accept this system's residual risk on this evidence" but "I accept it, given that it sits inside envelope X authorised on this evidence, plus this declared delta".
It concentrates risk, and that has to be priced. A defect in the environment's control set propagates to everything built on it at once, so an environment-level authorisation warrants higher assurance and a shorter re-verification cadence than any single system on it. Inheritance without that is just a bigger blast radius with better paperwork.
It needs an authorising office Australia does not have. Nobody in the Commonwealth can currently authorise a production environment as such. That is a policy artefact rather than an engineering one, and it is the same gap the companion article is about, arriving from a different direction.
Phase 2: Instrument
Now the evidence starts flowing on its own. Four stages turn a described system into a monitored one with a gate that can actually say no.
Stage 5, secure build and supply chain. Hermetic builds, a Software Bill of Materials (SBOM), SLSA provenance, signed artefacts and hardened base images. This is the stage where you can prove what is in the thing you are about to run, and where it came from. Here is the CI shape: build, generate the SBOM, sign, attest the SBOM and the provenance, verify both against a pinned identity, then gate.
steps:
- name: build
run: make build IMAGE=$IMG
- name: sbom
run: syft $IMG -o cyclonedx-json > sbom.json
- name: sign
run: cosign sign --yes $IMG
- name: attest
run: |
cosign attest --yes --predicate sbom.json --type cyclonedx $IMG
cosign attest --yes --predicate provenance.json --type slsaprovenance $IMG
- name: verify
run: |
# keyless verify needs BOTH the identity and the issuer; a wildcard identity
# would accept a signature from anyone, so pin it to your CI's OIDC subject.
cosign verify $IMG \
--certificate-identity-regexp "^https://github.com/org/repo/" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com"
cosign verify-attestation $IMG --type slsaprovenance \
--certificate-identity-regexp "^https://github.com/org/repo/" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" > attest.json
- name: gate
run: |
opa eval --format pretty \
--data policy/release.rego \
--input evidence.json \
'data.cato.release.allow'
What you implement: the hardened build pipeline and the attestations it produces.
The artefact it emits: an SBOM, a SLSA provenance attestation, and a cosign signature the gate can verify.
The gotcha: the verify step is load-bearing. Pin the certificate identity to your CI's OIDC subject. A wildcard identity accepts a signature from anyone, which quietly defeats the whole supply-chain claim.
Stage 6, policy-as-code gates and release. Encode the release rules as policy-as-code (OPA/Rego is the worked example here). Lower environments warn; production fails closed. Ship through GitOps, and route change and release through the agency's ITSM so the paper trail is automatic.
package cato.release
# Lower environments warn; production fails closed.
default allow := false
allow if {
input.env != "prod" # lower env: advisory only
}
allow if {
input.env == "prod"
input.build.signed # from a verified cosign signature, not a self-reported flag
input.build.slsa_level >= 3 # from a verified provenance attestation, not a self-reported field
not critical_cve
control_plane_enforcing # this gate must not be the only thing standing there
}
critical_cve if {
some v in input.sbom.vulnerabilities
v.severity == "critical"
}
# The gate asserts that the ENFORCING policy exists, is in deny mode, is scoped to
# this boundary, and was observed recently. Checking only the artefact leaves the
# whole control open to anyone who does not come through the pipeline.
control_plane_enforcing if {
some p in input.control_plane.policies
p.control_id == "egress-deny-public-internet"
p.mode == "deny" # not "audit", not "warn"
p.scope == input.boundary_id
input.now_ns - time.parse_rfc3339_ns(p.observed_at) < 86400000000000 # seen in the last 24h
}
What you implement: the executable gate, evaluated against the profile, with differentiated thresholds by environment.
The artefact it emits: a pass or fail decision recorded as OSCAL
assessment-results.The gotcha: teams get this wrong in both directions. A gate that fails closed on every environment grinds development to a halt and gets switched off within a week, which is the shelfware death of a good control. A gate that only ever warns is decoration. Warn in the lower environments, fail closed in production, and never relax the baseline of a signed artefact with a present SBOM. The deeper trap is the one in the code above: a release gate only sees what the pipeline chose to tell it, and only runs at all if you come through the pipeline. Console access, an out-of-band deployment, an emergency change or a break-glass credential walks straight past it, and the assessment-results keep reporting green because nothing observed the bypass. That is why the gate asserts the state of the control plane rather than only the state of the artefact, and why the next section exists.
Stage 7, continuous monitoring. Pipe SIEM and telemetry into OSCAL assessment-results, and run drift detection so you can see the authorised posture and the actual posture pulling apart the moment they do.
What you implement: the monitoring feed, emitted through the SIEM adapter, and the drift detection that compares live posture to the SSP.
The artefact it emits: streaming OSCAL
assessment-results, with drift and anomaly signals folded back into thePOA&M.The gotcha: a pipeline that observes but never stops anything is a very expensive smoke alarm. Monitoring only earns its keep because Stage 6 can act on what it finds.
Stage 8, active cyber defence. Detect and respond, with a penetration-test cadence that matches the classification. Monitoring tells you something moved; active defence does something about it.
What you implement: the detect-and-respond capability and a pen-test cadence tiered to the consequence.
The artefact it emits: findings that fold into
assessment-resultsand, where they are not yet closed, thePOA&M.The gotcha: this is not passive logging that someone reads after the breach. If it cannot act while the adversary is still on the wire, it belongs in Stage 7, not here.
Assurance Depth: One Control, More Than One Check
Infrastructure as code and policy as code are the easy part of this build, and treating them as the answer is how you end up owned with a green dashboard. The principle the rest of Phase 2 hangs on is narrow and worth stating on its own: a control is only evidenced if something independent of the enforcement path observed it.
The Auditor-General's findings are that failure at the paper layer, over and over. Systems were force assigned without certification. Six of the seven Navy capabilities audited went into operational use before their ICT systems were authorised. Thirty per cent of the systems recorded as having an active authorisation had already passed their expiry date. And the largest bypass of the lot: 89 per cent of the IT systems in Defence's own inventory had no recorded authorisation status at all, having never entered the process. Defence noted that its "operational environment limits its ability to provide a dedicated testing regime to check compliance" (ANAO, 2024, paras 3.10, 3.17, 3.42, n. 80). None of those were caught by the process that was supposed to catch them, because in each case the only thing looking was the thing being walked around.
So each control in the profile declares which tiers of check apply to it, and what evidence each tier emits. The tiers have to fail independently or you have one check wearing three hats:
Preventive, at declaration time. The policy-as-code gate over infrastructure as code and the release artefact. Cheap, fast, and it catches honest mistakes before they exist. It fails open to anyone who does not use the pipeline.
Enforcing, at the control plane. Admission control, cloud policy, identity conditional access: something that refuses the action at the point of effect regardless of how it was initiated. This is the tier the Stage 6 gate asserts rather than assumes, and note the recursion, because it is the whole point. The pipeline check is not "this resource is compliant". It is "the enforcing policy is installed, in deny mode, scoped to this boundary, and seen recently".
Detective, over observed state. Independent reconciliation of what is actually running against what the SSP says, over a telemetry path that depends on neither of the tiers above. This is the only tier that can catch a bypass, because it is the only one that is not standing on the path being bypassed.
Then the rule that ties this back to the drift argument the whole build is about: an expected signal that stops arriving is a finding, not silence. If the detective tier goes quiet for a control, that ages the authorisation exactly as a failed check would. Reading absence as compliance is precisely how a record comes to say "Active" while the expiry date sits in the past.
Two honest limits on the novelty here, because this is the part of the design I would most expect to be argued with:
The components are all off-the-shelf. Kyverno, Gatekeeper, cloud-native policy engines and posture management tools already do tiers two and three. NIST SP 800-53A has graded assessment methods as examine, interview and test for years. Nothing in the tiers themselves is an invention.
What is missing is the per-control declaration. No published Australian baseline says, control by control, which tiers apply and what each emits, so a control backed only by a pipeline check looks identical on a dashboard to one backed by all three. Declaring assurance depth as a property makes that difference visible, and it makes it computable across a profile: how much of the PROTECTED baseline is enforceable at the control plane, how much is merely declared, and how much is procedural and can only ever be evidenced by a human attesting to it.
That last number is one I have deliberately not published, and the reason matters. A great many ISM controls are people and process controls rather than technically enforceable states, which is consistent with what the ANAO found, where essentially every one of the five case-study failures was procedural rather than technical: missing documentation, reviews that could not be substantiated, a peer review that caught none of it, and a required follow-up assessment lost in a data migration between two tools. But the ISM OSCAL catalog carries no property marking a control enforceable or procedural, so any such split would be my classification rather than ASD's, and this repository vendors a curated 50-control sample rather than the full 1,101. Computing a real census means classifying the whole catalog and publishing the method so it can be argued with. That is the obvious next piece of work on this build, and until it is done I am not going to quote a proportion I have not actually counted.
Phase 3: Continuous Authorisation, Drift-Bounded
The pointy end. Two stages turn a monitored system into a living authorisation.
Stage 9, ongoing assessment and authorisation. OSCAL assessment-plan, assessment-results and POA&M feed the AO's live risk decision. Authorisation stops being an ongoing assertion nobody re-tests and becomes a live state: authorised right now, on today's evidence, or not.
What you implement: the assessment-plan that says how controls are checked, and the dashboard that puts the current posture, the open POA&M items and the drift in front of the AO.
The artefact it emits: the OSCAL
assessment-plan, and a live authorisation decision recomputed from currentassessment-results.The gotcha: continuous authorisation does not remove the human. It gives the AO a current picture instead of a two-year-old one. Same accountability, honest evidence.
Be precise about what this stage can and cannot supply, because it is the seam the companion article turns on. The pipeline can produce the evidence, the cadence and the threshold that PSPF Release 2026 leaves to a system owner's judgement. It cannot create the thing Australia has no equivalent of: a named continuous authorisation status, granted by a specific office, revocable, and conditional on competencies an entity has to demonstrate. That is a policy artefact, not an engineering one. What the build does is make such a status assessable, because competencies like continuous monitoring, active cyber defence and an approved DevSecOps design are exactly what Stages 5 to 8 emit evidence for.
Stage 10, govern and improve. Audit, report, and feed what you learned back into Stage 1. The loop closes here and starts again.
What you implement: the governance loop that turns exceptions and lessons into updated baselines and boundaries.
The artefact it emits: the reporting and the fed-back changes to the profile and the SSP.
The gotcha: a loop that never actually changes Stage 1 is a report, not governance. If nothing upstream moves, the improvement is theatre.
The part most accreditation conversations skip is whether any of this survives contact with a budget. Continuous authorisation and continuous cost management are the same telemetry-and-gates pattern, so cost rides the same rails: a monitored signal on the same dashboard as control status, budget and anomaly thresholds tiered from development to production, and cost per authorisation decision as the unit economic that ties spend to the mission. I argue the full case in Embedding FinOps: Achieving a Continuous Authority to Operate.
The model below puts a number on it. Pick an assessor pay grade, set the classification, choose point-in-time or continuous, and move the AI-assist lever. That lever is where AI earns its keep and where its limit sits: it does the unglamorous drafting, the crosswalks, the evidence summaries and the first cut of a POA&M, taking manual hours off the human, and it never makes the authorisation decision.
How the rate is derived, so you can argue with it. The pay grades are real and citable: the ASD Non-SES Salary Scales effective 1 September 2025, at Annex C of the ASD Terms and Conditions of Employment (non-SES) Determination 2024. Everything after that is my sampling, not ASD's. The model takes one representative salary point per grade, loads it at 1.7 times base to cover the 15.4% APS employer superannuation contribution plus on-costs and overhead, and divides by roughly 1,800 productive hours a year. That lands ASD Level 6 near $100 an hour and Executive Level 1 near $123. Both the multiplier and the hours are assumptions I picked, and a defensible loaded multiplier runs anywhere from 1.5 to 2.0, so the absolute dollars move a long way if you disagree with me. The effort figures the rate is multiplied by are synthetic outright. This is a synthetic model over one real input, and no agency's actual cost of assurance is in it or inferable from it. What survives a change to the assumptions is the ratio: continuous authorisation and AI-assisted drafting both lower cost per authorisation decision, by removing human hours from evidence assembly rather than from the decision itself.
The Adapter Contracts
This is what makes the build reusable rather than a one-off. The framework does not tell an agency which SIEM to buy. It fixes the slot and the OSCAL contract for that slot, and lets the agency bring whatever it already runs. Nine slots, each with the contract and an example of what might dock into it:
Deployment topology: the stage band and the enclave boundary the SSP asserts. Hybrid cloud, on-prem, cloud-native, or an air-gapped enclave.
Classification to ISM-OSCAL profile: the profile that tailors the baseline and tightens the gates. An ISM-OSCAL profile per level, paired with an Essential Eight ML1, ML2 or ML3 target.
Identity and ABAC: a component-definition for identity and attribute-based access control. Entra ID, Okta, on-prem Active Directory.
SIEM and telemetry: a monitoring feed emitted as OSCAL assessment-results. Splunk, Microsoft Sentinel, Elastic.
ITSM change and release: change and release records tied to the release gate. ServiceNow, Jira, Azure DevOps.
CI/CD and supply chain: the SBOM format and the SLSA provenance level carried on the build artefact. GitHub Actions, GitLab CI, Azure DevOps.
Policy-as-code: the gate decision, evaluated against the profile. OPA/Rego, Kyverno, Gatekeeper.
GRC and OSCAL consumer: reads the SSP, the assessment-results and the POA&M. Any OSCAL-aware GRC tool.
Vulnerability scanner: findings folded into assessment-results and the POA&M. Any scanner emitting SBOM-aligned findings.
The framework defines the slot and the OSCAL contract. The agency owns the choice. That is the whole trick: standardise the seam, not the supplier. An agency can beg, borrow or build whatever fills the slot, and as long as it speaks the contract, the next agency can make a different call without touching the frame. The three competencies the US Department of Defense requires an authorising official to demonstrate before granting a cATO map cleanly onto this spine: an approved DevSecOps design lives in Phase 2's build and gate stages, continuous monitoring is Stage 7, and active cyber defence is Stage 8. That is the lineage, not the frame. The frame is Australian, fed by the ISM.
AI Is Optional by Construction
The AI-assist lever in the model above has a zero position, and that position is a first-class configuration rather than the degraded case. This is a design constraint, not a disclaimer.
A continuous ATO is a deterministic system. Controls resolve against a profile, evidence either arrives on cadence or it does not, gates evaluate rules, and the authorisation decision belongs to a named human. Nothing in that chain requires a model. So the rule the build holds itself to is stronger than "AI assists and never decides": the pipeline must be fully functional and fully compliant with AI entirely absent, and that has to be a testable property rather than a claim. Where AI is switched off, the same work gets done by a person at lower throughput, and the artefact that comes out is identical in kind.
The reasons are the ones this audience will recognise on sight:
Availability. An air-gapped enclave or a high-side network may have no model available at all, and certainly none authorised to that classification. A pipeline that degrades to useless without one is a pipeline that does not work in the places that need it most.
Aggregation. Control implementation statements describe how a system is defended. Feeding them to a model is a data exposure decision in its own right, and at some classifications it is the wrong one regardless of where the model runs.
Failure mode. The characteristic failure here is a confident wrong control mapping that reads perfectly and is not true, which is the hardest kind for a reviewer to catch.
Recursion. If AI is load-bearing in the authorisation pipeline, the model becomes an in-boundary component that itself requires authorising, assessed by the pipeline it is part of.
Where AI does earn its keep is narrow, checkable and additive: drafting OSCAL implementation statements from legacy prose, proposing a control mapping an assessor edits rather than composes, and ranking drift alerts so scarce attention lands on the right one first. A human confirms before any of it becomes evidence. None of it is on the critical path, and none of it touches the decision.
Framing this as a limit on sovereign AI gets it backwards. A sovereign capability that knows where models do not belong is a more credible one, and the authorisation path of a TOP SECRET enclave is a good place to demonstrate that.
What This Is Not
Being candid, because the national-intelligence governance gap is exactly the wrong place to oversell a demo. This is a concept build to argue a design, not a deployable system:
The data is synthetic, with two real inputs I have named. Every drift curve, every effort estimate and every adapter claim is hand-authored to teach a point, and none of it reflects a real agency's numbers or posture. The exceptions are the ISM OSCAL baseline counts, which come from the vendored ASD release, and the ASD Non-SES salary scales behind the cost model. Both are real; everything the model does with them is mine.
The AI is stubbed. Where a real pipeline would run models, this runs deterministic lookups. There is no live inference anywhere in it. On the supply-chain thread that the undeclared-dependency piece pulls on, the same rule holds: the framework can prove what it can prove, and nothing more.
It is a teaching model, not a product. It makes a design legible. It does not run your enclave, and it never claims a capability or a client relationship.
The Australian evidence I lean on has a stated scope. The ANAO findings cited throughout are from a performance audit of one department, conducted against PSPF Policy 11 as it then stood rather than Release 2026, and Top Secret systems were outside its scope. They evidence the mechanism, not every entity, and not the current numbering. The claim that the spine runs unchanged from OFFICIAL to TOP SECRET is a design assertion of mine, and no public audit reaches the top of that range to test it.
The one line worth carrying away: the accountable authority's decision is never delegated to a model. The pipeline gathers the evidence, computes the posture and shows the AO the gap in real time. It does not make the call. Stage 9 is a human with the standing to say yes or no, on today's evidence, and own it. Automate the evidence, not the accountability.