Obsolete the Day You Sign It: Australia Needs a Continuous ATO, and It Already Has the Missing Piece

The problem is what the text hands to a person. Continuity here rests on a system owner's judgement about whether a risk level "has been exceeded", and reassessment turns on whether a change is "significant" (Department of Home Affairs, 2026, Requirement 0090). What no Australian instrument requires is that the monitoring output arrive at the authorisation decision in a defined form, on a defined cadence, at a defined threshold, or that an entity demonstrate any competency before relying on that ongoing state. Australia does mandate automation elsewhere, as the ISM shows further down, which makes the omission harder to excuse rather than easier. The United States Department of Defense went the other way and made continuous authorisation a status: named, granted by a specific office, revocable, and conditional on three demonstrated competencies (McKeown, 2022). That is the real Australian gap. Not the words, the machinery under them.

We know what that omission costs, because the Auditor-General went and measured it. In September 2024 the Australian National Audit Office reported on the Department of Defence's management of its ICT systems security authorisations and found the arrangements only partly effective. Five per cent of the IT systems Defence's own inventory project had identified were recorded in its authorisation management system at all. Of the systems that were recorded, 47 per cent sat at "Expired" or "No accreditation", and of those marked "Active", 30 per cent had an authorisation expiry date that had already passed (Australian National Audit Office, 2024, paras 3.14, 3.17). Sit with that last one for a second. Active on the record and expired in fact is the exact gap this article is about, and it is not a hypothetical I am constructing to make a point. It is the Commonwealth's auditor describing the largest department in the country.

One caveat, so the citation stays honest. That audit ran against PSPF Policy 11 as it then stood, not Release 2026, and Defence's own framework rather than every entity's. It evidences the mechanism, not the current numbering, and Top Secret systems were outside its scope. I use it throughout for what it is: the best public Australian measurement of what happens when authorisation is ongoing on paper and nothing is watching it.

The good news sits at step two. The Australian Signals Directorate already publishes the ISM as an OSCAL catalog, so the hardest ingredient of a continuous model, a machine-readable national control baseline, is already on an Australian government server (Australian Signals Directorate, 2026b).

If continuity is a judgement your system owner makes with no required evidence base, no cadence and no competency test, what exactly is being continued?

The framework supplies its own stages, so I will use them. The ISM risk management framework has six steps: define the system, select controls, implement controls, assess controls, authorise the system, and monitor the system (Department of Home Affairs, 2026, s 13.1). Taken in order, here is where each goes stale.

Step One: Define the System

The boundary is drawn once, in prose, by people in a room. It fixes what sits inside the authorisation and what is somebody else's problem, and everything downstream inherits that line.

Then the system moves. Infrastructure as code redefines the environment on every merge, the provider ships changes nobody approved, and a firewall rule goes in at 2 am during an incident and never gets walked back. Two years on, the running estate can hold a swapped identity provider, an absorbed data feed and an inference service nobody put inside the original line.

The framework anticipates this. Requirement 0090 calls for reassessment on significant functionality or architectural change (Department of Home Affairs, 2026). The load is carried entirely by the word "significant", judged by the same people who would have to fund the reassessment. Nothing observes the boundary. A person remembers it.

What that looks like when somebody finally checks is worth reading. In two of the five systems the ANAO examined, the security documentation itself recorded connections to unauthorised systems, and neither the documentation nor the assessment worked out what those connections risked. One case-study system ran on an outsourced firewall and security monitoring service for which, in Defence's own words, there was "no overarching accreditation or endorsement … nor is there any formal risk acceptance". Another system's plan simply recorded the security posture of everything it connected to as "unknown" (Australian National Audit Office, 2024, para 3.81). The boundary had not been redrawn. It had been quietly conceded, in writing, and the authorisation was granted anyway.

This is the Einstellung effect wearing a lanyard: we reach for the accreditation pattern that suited a mainframe changing once a decade because it is the familiar move, and the familiarity of the tool is what stops us seeing it no longer fits (Luchins, 1942). I made the same argument about governance in Exempt by Design. The control did not keep pace because it was never built to move.

Step Two: Select the Controls

This is the step that already works, and the reason a sovereign continuous model is buildable now rather than after a policy cycle.

ASD publishes the ISM as an OSCAL catalog with resolved profiles for each classification, currently release v2026.06.18 against the June 2026 ISM under OSCAL 1.1.2 and CC BY 4.0 (Australian Signals Directorate, 2026b). Run the numbers on the catalog and 1,035 of its 1,150 items apply at PROTECTED, out of 1,101 controls and 49 principles. A sovereign continuous ATO can therefore run the same OSCAL machinery on our own ISM profiles under our own PSPF decision-makers, rather than importing American controls or American authorisation semantics.

One precision worth keeping: ASD's own word for the per-classification profiles is "illustrative" (Australian Signals Directorate, 2026b). The catalog is authoritative. The profiles are ASD's worked example of applicability, and an entity treating one as a compliance verdict has skipped its own tailoring step.

Because the baseline is real machine-readable data, you can run the inheritance maths straight on it. Authorise a platform once, and a system built on it inherits most of that PROTECTED baseline, implementing only its residual instead of the full set. One caveat, stated plainly: ASD publishes the catalog and the per-classification profiles, not the system security plans, so control state and inheritance live in the OSCAL SSP layer that each system fills in. Both the status and the inheritance are core OSCAL, the latter expressed through the SSP's leveraged-authorisation model, not anything ASD ships and not a US authorisation programme bolted on. The companion project has this as a live explorer on the real ISM baseline, alongside OSCAL component-definition fragments that show a single component declaring the control it satisfies as data rather than prose.

Reuse of assessment work is further along than the "we have nothing" story admits. PSPF Release 2026 stands up a Centralised Risk Sharing Capability, a central repository of risk assessments of products, applications and web services maintained by Home Affairs to remove duplicative and inconsistent effort, with Requirement 0222 in force from 1 July 2026 alongside a Commonwealth Technology Standard at Requirement 0221 (Department of Home Affairs, 2026, ss 13.5, 13.6). That is assess-once-share-many, and it is real. It also stops at the product layer. A shared product risk assessment does not authorise a system, and nothing in that capability carries evidence forward into an entity's own authorisation decision.

Step Three: Implement, and Declare What You Actually Run

Here is the objection I can hear from here. "Our existing systems have a Word document from 2019, if we are lucky, and a spreadsheet someone maintains by hand." Good. That is the normal starting condition.

The move is to digitise what exists into OSCAL rather than demand a rewrite. A control described in prose becomes a structured implementation statement, an architecture diagram becomes component definitions with declared control mappings, and a profile records what was selected and how it was tailored (National Institute of Standards and Technology, n.d.). Design constraints get promoted into policy rather than left as good intentions: "this system must not egress to the public internet" stops being a sentence in a PDF and becomes a rule something can evaluate.

What makes it honest is what happens where the documentation is silent, contradictory or aspirational. The gap does not get papered over. It becomes a Plan of Action and Milestones entry with an owner and a date.

Which is where Rumsfeld's taxonomy earns its keep, specifically the quadrant he left out. He gave us known knowns, known unknowns and unknown unknowns (Rumsfeld, 2011). Slavoj Žižek added the fourth term, the unknown knowns, and his sense of it is sharper than the usual gloss: not tacit knowledge, but "the disavowed beliefs, suppositions and obscene practices we pretend not to know about, even though they form the background of our public values" (Žižek, 2004). Aspirational accreditation paperwork is exactly that. The organisation knows the segmentation was never finished, and it is written down as though it were. Digitising to OSCAL drags that disavowal into a tracked item somebody has to own.

Step Four: Assess the Controls

The registered IRAP assessors who do this work hold the strongest objection to everything I am arguing, and it deserves to be stated in their own terms.

An assessor's job goes well beyond confirming a control exists. It is to exercise professional judgement about compensating controls, unusual system boundaries and residual risk that no rule set anticipated, and that judgement is exactly what a Rego policy was never written to reproduce. The PSPF names IRAP assessors as the security assessor for SECRET and below, requires cloud service providers to have completed an IRAP assessment within the previous 24 months, and applies the same rule to gateways (Department of Home Affairs, 2026, Requirements 0109 and 0114; Table 21, p. 66). Moving the control into a pipeline does not remove the need for an independent human check. It relocates the question one level up: who assesses whether the gate code does what it claims, and whether the pipeline's own supply chain can be trusted. If the answer is nobody, you have not removed accreditation risk. You have hidden it inside a file nobody audits.

I concede the whole of that, and I would go further than the profession usually does in public, because ASD already has. Under a heading "What IRAP does not do", ASD states that IRAP assessors "do not accredit, certify, endorse or register systems on behalf of ASD", that the scope of a security assessment "will generally not cover all ISM security controls", and that a completed assessment "does not inherently imply that a system is compliant with the tested security controls" (Australian Signals Directorate, 2025). Scope is negotiated per engagement. So the "file nobody audits" problem is not created by moving to a pipeline. It is the current condition, stated by the national authority, and the point-in-time model has been living with it for years.

The answer is more assessment, aimed at a wider object, and that is a smaller ask than it sounds, because the ISM already reaches into the build pipeline. ISM-2031 requires that compilers, interpreters and build tools, explicitly including pipelines, implement available security features. ISM-2032 requires that the build solution ensure all automated testing completes without warnings, alerts or errors before software artefacts are built. Read that second one again: in substance it is a mandated fail-closed build gate, applicable from NOT CLASSIFIED through TOP SECRET. Secret scanning on commit, signature verification, analysis of third-party artefacts and a software bill of materials each carry their own ISM controls (Australian Signals Directorate, 2026a, ISM-2027, ISM-2028, ISM-2030, ISM-2031, ISM-2032, ISM-2054).

What has no published assessment methodology in Australia is the policy-as-code ruleset itself as an object of assessment. A full-text search of the 170 pages of PSPF Release 2026 returns nothing for "pipeline", "DevSecOps", "policy as code" or "continuously monitor". So the honest claim is narrower than the one I would like to make, and stronger for it: assessors already work in this territory, the missing thing is a method for assessing gate logic, and writing that method is work the profession is well placed to do.

Step Five: Authorise the System

Now the decision itself. The authorising officer authorises each technology system to operate based on accepting its residual security risks, using the ISM's risk-based approach, and the entity keeps a register of authorised systems carrying the name and position of the authorising officer and the system owner, the date of authorisation, and any decisions to accept residual risk (Department of Home Affairs, 2026, Requirements 0086, 0087 and 0089; s 13.3).

Then comes the clause most commentary misses. Authorisation to operate is generally ongoing once the system is operational, and where a risk level has been exceeded the system owner must identify the mitigation required and whether the authorising officer needs to accept the risk or sign off on the proposed mitigations. Reauthorisation triggers are listed, and they are sensible ones: new or emerging cyber threats, discovery that controls are less effective than planned, a major cyber security incident, and major functionality or architectural change (Department of Home Affairs, 2026, s 13.3.1).

Read as text, that is continuous authorisation. Read as a design, it is a set of conditions with no instrumentation. Every trigger fires on a human noticing, and every threshold is a judgement about whether something counts as major, significant, or exceeded.

The ANAO measured what a trigger that depends on someone noticing actually delivers. Two of the five case-study systems were operational straight through both the September 2018 PSPF revision and the August 2020 update to Policy 11, and the documentation for those systems references neither (Australian National Audit Office, 2024, para 3.96). Commonwealth policy change was a listed re-authorisation trigger the whole time. It fired twice and nobody heard it. The timings around it tell the same story: authorisation requests took an average of 285 days to complete, records sitting at "New in progress" had gone untouched for an average of 388 days, and 68 per cent of systems recorded as being in re-authorisation had already passed their expiry date (paras 3.21, 3.24). Six of the seven Navy capabilities audited were released for operational use before their ICT systems were authorised at all (para 3.42).

My favourite detail in the whole report, and I mean favourite in the way you mean it at 11pm on a Sunday, is that Defence's ICT authorisation management system was itself sitting at "In re-accreditation" in August 2024, its own authorisation having expired in March 2023 (para 3.24). The system of record for whether things are authorised was not authorised. Nothing in the process noticed, because noticing was nobody's job.

Compare what the Americans built on the same idea. The DoD memo makes a continuous ATO a status the authorising official earns by demonstrating three competencies: ongoing visibility of key cybersecurity activities inside the system boundary with robust continuous monitoring of RMF controls, the ability to conduct active cyber defence in real time, and the adoption and use of an approved DevSecOps reference design (McKeown, 2022). The implementation guide that followed covers all three, plus platform, process and team practices, metrics and a readiness assessment method, and is candid that a cATO is a superset of the NIST RMF term ongoing authorisation, "which has existed for years but lacked the automation to make it effective across a broad community" (U.S. Department of Defense, 2024, p. 3). NIST had provided for ongoing authorisation since 2018 (National Institute of Standards and Technology, 2018). The automation is what made it real.

Two things about that model cut against the way this argument usually gets sold. First, a cATO is layered on an ATO rather than replacing it: systems seeking one must already hold an ATO and have entered the RMF monitor stage, and the determination "does not affect the underlying system ATO. Rather, it modifies requirements for re-authorizing that system's ATO" (McKeown, 2022; U.S. Department of Defense, 2024, p. 5). The certificate does not disappear. It stops being the whole control, and the pipeline becomes the thing that keeps it true. Second, the status is granted, revocable and competency-tested, and that is the part Australia has no equivalent of. We have the continuity language, and no named state an entity can be granted, held to, and lose.

Step Six: Monitor the System

Systems drift, and that is the default state of anything under continuous change rather than a failure mode. Config drifts as engineers make live fixes, model behaviour drifts as inputs shift and retraining lands, dependencies drift as the ecosystem moves. Left alone, every system marches away from the state it was assessed in, every day, for free.

The discipline that answers this has a name and a standard: Information Security Continuous Monitoring, maintaining ongoing awareness of security posture to support risk decisions (National Institute of Standards and Technology, 2011). What lifts it above a dashboard is a common evidence spine, and OSCAL is that spine. Catalog to profile to component definition to system security plan, then assessment results carrying what monitoring found and a POA&M carrying what is open. One connected data structure from control to evidence turns "is this system still meeting its baseline" into a query rather than a project.

Australian entities already monitor. What no Australian instrument requires is that the monitoring output arrive at the authorisation decision in a defined form, on a defined cadence, at a defined threshold. That join is missing, and it is where the lifecycle actually fails.

Some entities monitor less than the word suggests. The ANAO found that Defence's assessment and authorisation process "does not mandate any specific processes for ongoing monitoring of ICT systems after authorisation", that its guidance treats ongoing monitoring as optional and decided system by system, and that the Continuous Monitoring Plan template required by its own framework, released in May 2024, was still marked "under development" the following month (Australian National Audit Office, 2024, para 3.4 and n. 74). Defence stated the position more plainly than I would have dared to on its behalf: responsibility for monitoring re-authorisation triggers "rests largely with the System Owner's organisation via normal system and business management practices", there are "insufficient automated facilities" to help them do it, and there are "no automated checks to either assure control implementation or prompt System Owners to review" (para 3.31 and n. 77).

Then comes the part that should stop you, because it is the Australian counterfactual to the American story from the last section. Over there, automation is what turned ongoing authorisation from a term into a status. Over here, Defence scoped the automation and cut it. Integrated Continuous Assurance functionality was in the plan for the second tranche of its governance, risk and compliance programme, and it was de-scoped out of that tranche (para 3.31). The tranche still cost $5.06 million on top of the first tranche's $9.9 million, and a Control Owner report in May 2024 found the maturity of the relevant control had gone backwards, partly because the tool was not mature enough to support an enterprise view (nn. 87, 88). Fifteen million dollars of governance tooling, and the continuous assurance was the bit that got cut.

Rebuilding the Six Steps as One Pipeline

Everyone treats accreditation as bespoke. Every agency, every system, a fresh artisanal effort, which is why it is slow, expensive and impossible to keep current. The way out is the opposite instinct: one spine that never changes, and everything agency-specific as a plug-in part.

The spine runs the same six steps, instrumented, each stage with a defined input and output so the parts swap without touching it. A classification adapter maps the system to the right ISM-OSCAL profile. Monitoring plugs in through a SIEM adapter whether the agency runs Splunk, Sentinel or Elastic, and the build plugs in through a CI/CD adapter carrying SBOM and SLSA provenance. An agency picks its parts rather than rebuilding the pipeline. I have not laboured the full stage list here because the argument does not need it laboured; the companion project walks all ten stages with the adapter contracts and the OSCAL artefact each one emits.

The release gate is where this stops being observation and becomes a control, because it is the only point in the lifecycle where a rule can say no and be obeyed without a person choosing to comply. Policy as code means the rule is written once, in something like Rego for the Open Policy Agent, and evaluated on every release.

• Differentiate the thresholds by environment. A gate that fails closed everywhere grinds development to a halt and gets switched off inside a week, which is the shelfware death of a good control. A gate that only ever warns is decoration. Warn-only in development and test where the blast radius is nil, fail-closed in production where a critical finding must physically stop the release.

• Never relax the artefact baseline. Every environment requires a signed artefact and a present SBOM in SPDX or CycloneDX, with SLSA provenance attesting where it was built and from what source. What varies is whether a critical finding blocks or merely surfaces. ISM-2032 already sets the shape of this obligation (Australian Signals Directorate, 2026a).

• Carry cost on the same rails. Continuous authorisation and continuous cost management are the same shape: telemetry into gates and onto a dashboard, which is the case I made in Embedding FinOps: Achieving a Continuous Authority to Operate and still hold to (Hall, 2023). Budget thresholds and cost-anomaly checks run as policy-as-code, tiered like the security gates, and shared-platform cost gets tagged, allocated and shown back to the agencies consuming it so a common enclave is not a black hole (FinOps Foundation, 2026). The unit that matters is cost per authorisation decision.

This is the "accountability built in, not bolted on" argument from The Compliance Clock, and the declared-dependency discipline from The Undeclared Dependency, pointed at authorisation.

Where AI Helps, and Where It Must Not

AI earns its keep in narrow, checkable places inside this pipeline. Turning legacy prose documentation into structured OSCAL implementation statements is a language task and a good one: the model drafts, a human confirms. Suggesting which control a component most plausibly satisfies means an assessor edits rather than starting from a blank cell. Ranking drift alerts puts scarce attention on what matters first.

The limit is flat. AI assists and never decides, and the accountable authority's acceptance of residual risk is non-delegable. That is a legal and command responsibility belonging to a named person, and no confidence score substitutes for a signature. NIST is explicit that generative AI introduces failure modes that must be managed rather than assumed away, which is why its Generative AI Profile exists at all (National Institute of Standards and Technology, 2024). Use AI to prepare the decision, never to make it.

One honest disclosure about the companion project. I built it as a runnable concept so you can walk the whole lifecycle, but the AI pieces are stubbed demos, there is no live model in the loop, and all the data is synthetic. The point is to make the argument tangible, not to ship an accreditation engine.

Where It Actually Breaks

The lifecycle does not break at the certificate. Australia's authorisation is already ongoing by its own terms, and saying otherwise gets you corrected by anyone with the PSPF open.

It breaks at the join between step six and step five. Monitoring produces evidence, and nothing requires that evidence to reach the authorising officer in any format, on any cadence, or at any threshold beyond a system owner's sense that a risk level has been exceeded (Department of Home Affairs, 2026). Every other step inherits the weakness. The boundary at step one goes stale because nobody is required to observe it. The controls at step two sit in an authoritative machine-readable catalog that no instrument requires anyone to evaluate continuously. The assessment at step four is scoped by negotiation and, on ASD's own statement, accredits nothing (Australian Signals Directorate, 2025). Six steps, one missing wire.

Honesty requires me to widen that claim, because the ANAO's findings run broader than my argument does. Across the five systems it examined, mandatory security documentation was missing for every one, Defence could not substantiate that document reviews or control implementation assessments had taken place, and the peer review meant to catch that caught none of it (Australian National Audit Office, 2024, paras 3.78, 3.82, 3.85). In one case a required follow-up assessment was lost during a data migration between two authorisation tools, so the assessor who picked the system up years later had no idea it was outstanding, and the residual risk was downgraded from moderate to low without the assessment ever being done. Almost none of that is technical. It is people, process and paperwork, and a Rego policy evaluating a software bill of materials would not have caught a single one of them.

That lands squarely on the pipeline argument and I am not going to duck it. My answer is that it sharpens the case rather than softening it. The reason all six steps failed together is that the same missing wire runs through every one of them: nothing in the lifecycle was required to observe itself, so each failure stayed invisible until an auditor spent a year looking for it. A pipeline does not fix bad paperwork. What it fixes is the part where bad paperwork is only ever discovered by audit.

The fix does not need new legislation. It needs three pieces of engineering, and each can start on Monday. Make the ISM OSCAL catalog the evidence format for control state, so "does this still hold" is a query. Put the release gate in the pipeline so a control can refuse. Then define the missing status: a named, granted, revocable Australian continuous authorisation, with published competencies an entity must demonstrate, that modifies what reauthorisation requires.

On those competencies, take the American three and add a fourth. Theirs are continuous monitoring, real-time active cyber defence, and an approved DevSecOps reference design (McKeown, 2022). Ours should carry one more, because our evidence says so: security assessment expertise embedded from the initiation of an initiative rather than arriving at the end of it. The ANAO's failures were overwhelmingly procedural, the assessment team was reviewed as "operating above 100 per cent utilisation" with project engagement among the first things to suffer, and Navy told the auditors outright that it lacked the skillsets and capacity to start the process at all (Australian National Audit Office, 2024, paras 3.22, 3.39). The obligation, naturally, already exists. Defence's own control makes the security assessor responsible for advice and guidance "throughout all phases of system development" (para 2.85). Australia has the words for that one too. What it has never had is anyone resourced to make them true, and shifting assessors earlier only works once inheritance has collapsed the per-system burden enough to give them the room.

The Americans took two years to get from memo to implementation guide, and we would start with a better baseline than they had.

So this is the question I would put to any accountable authority in the country. Your authorisation is ongoing on paper already. When your system owner last decided that no risk level had been exceeded, what evidence was actually in front of them, and would you sign for it today?

Explore the runnable framework and interactives: /projects/sovereign-cato-pipeline

Thanks for reading.

The views expressed in this article are my own and do not represent those of my employer or any of my clients.

References

• Australian National Audit Office. (2024). Defence's management of ICT systems security authorisations (Auditor-General Report No. 2 2024–25). Commonwealth of Australia. https://www.anao.gov.au/work/performance-audit/defences-management-of-ict-systems-security-authorisations

• Australian Signals Directorate. (2025). Infosec Registered Assessors Program (IRAP). Australian Cyber Security Centre. https://www.cyber.gov.au

• Australian Signals Directorate. (2026a). Information Security Manual. Australian Cyber Security Centre. https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/ism

• Australian Signals Directorate. (2026b). Information Security Manual: OSCAL releases (v2026.06.18). Australian Cyber Security Centre. https://www.cyber.gov.au/ism/oscal

• Department of Home Affairs. (2026). Protective Security Policy Framework (Release 2026). Australian Government. https://www.protectivesecurity.gov.au/publications-library/pspf-annual-release-2026

• FinOps Foundation. (2026). The FinOps Framework. https://www.finops.org/framework/

• Hall, B. (2023, April 10). Embedding FinOps: Achieving a continuous Authority to Operate (cATO). LinkedIn. https://www.linkedin.com/pulse/embedding-finops-achieving-continuous-authority-operate-benjamin-hall

• Luchins, A. S. (1942). Mechanization in problem solving: The effect of Einstellung. Psychological Monographs, 54(6), i–95. https://doi.org/10.1037/h0093502

• McKeown, D. (2022, February 2). Continuous authorization to operate (cATO) [Memorandum]. U.S. Department of Defense, DoD Senior Information Security Officer. https://dodcio.defense.gov/Portals/0/Documents/Library/20220204-cATO-memo-Signed-Cleared.pdf

• National Institute of Standards and Technology. (n.d.). Open Security Controls Assessment Language (OSCAL). https://pages.nist.gov/OSCAL/

• National Institute of Standards and Technology. (2011). Information security continuous monitoring for federal information systems and organizations (SP 800-137). https://doi.org/10.6028/NIST.SP.800-137

• National Institute of Standards and Technology. (2018). Risk management framework for information systems and organizations (SP 800-37 Rev. 2). https://doi.org/10.6028/NIST.SP.800-37r2

• National Institute of Standards and Technology. (2024). Artificial intelligence risk management framework: Generative artificial intelligence profile (NIST AI 600-1). https://doi.org/10.6028/NIST.AI.600-1

• Rumsfeld, D. (2011). Known and unknown: A memoir. Sentinel.

• U.S. Department of Defense. (2024, March). DevSecOps continuous authorization implementation guide (Version 1.0). Office of the Chief Information Officer. https://dodcio.defense.gov

• Žižek, S. (2004, May 21). What Donald Rumsfeld doesn't know that he knows about torture and the Iraq war. In These Times. https://inthesetimes.com/article/what-rumsfeld-doesn-know-that-he-knows-about-abu-ghraib