Five Questions Every AO Needs to Answer

Continuous Authorization Under the Cybersecurity Risk Management Construct

Executive Summary

In September 2025, the Department of War (DoW) announced the Cybersecurity Risk Management Construct (CSRMC), which calls for automated, continuous risk management across a system’s life as the replacement for point-in-time cyber assessments (DoW Chief Information Officer [CIO], 2025). That fundamentally changes the authorizing official’s (AO’s) job. An AO used to judge a package once and then approve it. Under CSRMC, the AO has to continuously assess whether a system’s risk is acceptable for as long as that system is used.

That ongoing decision rests on five questions the AO must be able to answer at any point in a system’s lifecycle. A continuous authorization to operate (cATO) architecture can answer every one of them with live data instead of a security document. This paper shows how. It closes with a crawl-walk-run path that lets a program answer more of the five questions at each phase without pausing software delivery.

Why Authorizations Go Stale

An authorization to operate (ATO) describes a system at the time of approval. Program teams spend months assembling evidence for that signature, and software updates often sit frozen while they do. Meanwhile, a system that can’t be patched without reopening its authorization falls further behind every time the threat changes. The Department reached the same conclusion when it announced CSRMC, saying the previous framework leaned on static checklists and manual processes that slowed secure capabilities on their way to the field (DoW CIO, 2025). Its 2022 cATO memo had already noted that Risk Management Framework (RMF) implementation concentrated on getting systems authorized and fell short on monitoring them afterward (Department of Defense [DoD] CIO, 2022).

The deeper problem is how responsibility is divided. The National Institute of Standards and Technology’s (NIST’s) risk model splits it across three tiers: the organization sets governance at Tier 1, mission and business processes translate it at Tier 2, and individual systems implement it at Tier 3 (NIST, 2011a). In most traditional implementations, nothing carried the Tier 1 and Tier 2 rules down to Tier 3 in a form an engineer could build against. Governance documents lived in one place and technical configurations in another, so engineers built to their best reading of the requirement and hoped the assessor would read it the same way.

Often the assessor didn’t. The disagreement surfaced late, usually as findings and rework, while security packages dragged on because the engineering team and the governance team had spent months solving different problems. Nobody designed Tier 3 to be isolated. The traditional process just had nothing connecting it to the tiers above.

A cATO architecture closes that gap by having governance and engineering work from one shared source. The U.S. Government Accountability Office (GAO) describes continuous authorization the same way: it pairs the ATO with automation that produces real-time, continuous evidence of the system’s security posture (GAO, 2023, p. 17). Each of the five questions below is a point where the AO depends on that source being there.

1. What Am I Actually Authorizing?

An AO can only accept risk for what sits inside the boundary, so a cATO architecture works to keep that boundary small and its contents visible.

A cATO architecture makes inheritance the default, so a system no longer has to prove every control on its own, including controls it never implemented. It builds on common controls from boundaries that have already been assessed, such as Federal Risk and Authorization Management Program (FedRAMP) authorizations and DoW provisional authorizations issued under the Cloud Computing Security Requirements Guide (Defense Information Systems Agency, 2025). The inherited share can be large. Cloud.gov, for example, reports that agencies on its FedRAMP Moderate platform inherit more than 60 percent of NIST SP 800-53 controls (cloud.gov, n.d.). Physical security at the data center and encryption on the underlying network are handled upstream, and what remains for the program team is its own application logic and mission-specific configuration, the part where this system’s risk actually differs from its neighbor’s. Inherited controls are still verified. The time saved comes from not redoing work someone has already validated.

The contents come from the build. Every build produces a Software Bill of Materials (SBOM) listing each library and dependency, its version, and how the components relate. Federal SBOM expectations now follow the Cybersecurity and Infrastructure Security Agency’s (CISA’s) 2026 minimum elements, which replaced the National Telecommunications and Information Administration’s 2021 baseline (CISA, 2026a). Systems that include machine learning models also get an AI Bill of Materials recording model and dataset provenance, an area where CISA notes AI software may need elements beyond the baseline (CISA, 2026a) and where G7 cybersecurity agencies have published supplemental minimum elements (G7 Cybersecurity Working Group, 2026). Nobody writes these by hand because the build process is the only place with a complete, current picture of what went into an artifact.

2. Was It Built to the Policy I Approved?

This answer used to rest on a large security document and the AO’s trust in it. In a cATO architecture, it rests on code.

The team writes the policy behind the AO’s approval as code before application work starts, so the system has a known baseline from its first commit. From then on, the pipeline automatically moves code from one environment to the next, checking every change against that policy and refusing to promote anything that fails. Each rule traces to a control in the tailored NIST SP 800-53 baseline (NIST, 2020). Changes to the policy code go through the Information System Security Manager (ISSM) change control process, so the coded policy stays the one the AO approved.

That’s the practical fix for Tier 3 isolation. An engineer no longer has to read a governance document and guess what the enterprise wants. NIST’s DevSecOps guidance lists policy as code among the code types a cloud-native environment must manage and describes how it supports continuous authority to operate (NIST, 2022a).

Those checks happen at Policy Enforcement Points (PEPs), which sit between the stages of the pipeline. NIST uses the term for the enforcement components inside the running platform, where policy as code resides (NIST, 2021, 2022a); this paper applies it to the gates in the pipeline as well. A PEP inspects the artifact in front of it (the code, container, or file) and decides whether it can move on, rather than simply logging that a check ran. The pipeline works like an assembly line with inspection stations:

Station 1. A developer commits code. Before it can merge, a PEP checks it against security policy.

Station 2. Before a container is built, another PEP verifies the base image and dependencies.

Station 3. Before the artifact reaches staging, PEPs run it through dynamic testing and confirm that it meets every policy requirement that applies.

Station 4. At deployment, the production environment checks that the artifact is signed and approved before it will run it, so nothing that skipped the line reaches production.

When a check fails, the pipeline stops and tells the developer what failed and why, well before the change reaches a release candidate. When a gate must be overridden, the ISSM approves the exception, the override is logged, and it becomes a Plan of Action and Milestones (POA&M) item that appears on the AO dashboard alongside the system’s other open findings. Every artifact that reaches production carries a signed record of the checks it passed, so the AO can trace a running component back to the policy it was built against.

Because the PEPs are centrally managed, a policy change made once extends to every pipeline. NIST’s guidance on software supply chain security describes the same pattern of building assurance checks into CI/CD pipelines and maps it directly to the Secure Software Development Framework (NIST, 2024).

3. Is It Still the System I Approved?

The answer comes from watching for drift from the approved baseline, using evidence that machines collect continuously instead of people assembling it for an audit.

In a traditional shop, audit season starts with a team gathered around an email, slides, or an extensive spreadsheet all nodding their heads while waiting for a specific assignment to gather pieces of evidence. Several people then spend weeks pulling screenshots and logs using different tools, and a folder of PDFs finally goes out the door. By that point, the documents can already be out of date. A cATO architecture replaces that scramble with continuous collection: Assured Compliance Assessment Solution (ACAS) vulnerability findings, Security Content Automation Protocol (SCAP) Compliance Checker results, and Security Technical Implementation Guide (STIG) checklist results feed an integration layer as each scan completes, and that layer normalizes the output and updates the risk record.

Because the feeds are continuous, any drift between requirements and code shows up fast. Drift is the gap between the configuration that received the ATO and the one running today, and it builds up from unauthorized changes and temporary workarounds that could quietly become permanent. Each deviation from the approved baseline gets flagged. The persistent audit tracks whether the backlog of unresolved findings and deferred patches is shrinking or growing. NIST’s continuous monitoring guidance frames the goal as ongoing assurance that implemented controls stay aligned with organizational risk tolerance (NIST, 2011b).

The pipeline converts all of this into a machine-readable format, preferably NIST’s Open Security Controls Assessment Language (OSCAL), which gives security plans, assessment results, and POA&Ms a common structure (NIST, n.d.). A PDF of a security posture helps the person reading it. Software can validate an OSCAL file, compare it with the previous version, query it, and load it directly into eMASS or a governance, risk, and compliance platform without anyone having to retype it.

Security staff still review the data, but they spend their time deciding what the evidence means and what to prioritize instead of checking whether it was collected correctly.

4. How Fast Does the Team Fix What It Finds?

A cATO architecture finds vulnerabilities fast. The number an AO needs is how fast each one gets fixed.

Mean Time to Patch (MTTP) tracks the time from identification to remediation, by severity, and DoD Instruction 8531.01 already requires Components to compute it (DoD CIO, 2020). The cATO architecture escalates high-risk findings as they get closer to their deadline. For years, CISA’s BOD 19-02 gave civilian agencies fixed windows of 15 days for critical and 30 days for high vulnerabilities on internet-accessible systems (CISA, 2019), and BOD 22-01 added a two-week clock for most vulnerabilities in its Known Exploited Vulnerabilities catalog (CISA, 2021). In 2026, BOD 26-04 replaced those flat deadlines with timelines based on asset exposure, known exploitation, exploit automation, and technical impact, with the new timelines phasing in by December 2026 (CISA, 2026b). These directives apply to civilian agencies, so a DoW program works to the patch schedule its Component sets under DoD Instruction 8531.01 and to remediation orders from U.S. Cyber Command (DoD CIO, 2020). A cATO dashboard typically watches the distribution as well, since a 28-day average can hide a long tail of findings that have been open for 90 days.

Mean Time to Detect (MTTD) measures how quickly the team notices a problem, whether that’s a misconfigured firewall rule or an intruder.

Mean Time to Respond (MTTR) measures how quickly it contains the blast radius of the attack. A rising MTTD usually means visibility is slipping away. A rising MTTR is more worrying, because it suggests the response process is struggling under real conditions.

An unpatched internet-facing service might be manageable by itself, but paired with excessive privileges and weak logging, it becomes a different problem. That combination can be the start of a breach, and no static report shows the relationship between logging and privileges together. The AO dashboard surfaces these toxic combinations beside open POA&Ms ranked by age and exposure so that a mission owner sees a change in the context of operational risk rather than a finding ID.

Much of what a team fixes, it didn’t write in the first place. Consistent with NIST’s supply chain risk guidance (NIST, 2022b), every third-party component passes automated dependency scanning before it reaches production and is rechecked as new CVEs get published. Contracts matter as much as tooling. cATO SLA clauses hold suppliers to the same security posture as internal teams, so a vendor vulnerability triggers an agreed response instead of a negotiation.

Any given morning, an AO can log in and see three critical patches nearing their deadline and an overnight configuration change that opened yet another compliance gap. The decision rests on the system as it runs today, using the same data the operations team is working from.

5. Will Anyone Else Accept This Decision?

Another AO will accept this decision if they can check the evidence behind it. Reciprocity is one of CSRMC’s ten tenets (DoW CIO, 2025), and the first four questions are what make it possible.

When programs inherit controls and reuse one another’s assessment evidence, the same control does not have to be tested twice, and DoD reciprocity policy already treats that reuse as the expectation (DoD CIO, 2024b). Machine-readable evidence is cheaper to accept because an AO in another domain can validate an OSCAL package with software instead of reading it end to end.

FedRAMP is moving the same way. Its RFC-0024 proposed replacing Word and Excel authorization packages in the Rev5 process with machine-readable formats (Center for Cybersecurity Policy and Law, 2026). FedRAMP’s published outcome retires DOCX and XLSX, requires fully machine-readable packages for High (Class D) services, and phases the new formats in through 2027 (FedRAMP, 2026). A program whose authorization package and monitoring data can cross those boundaries doesn’t start over for every new domain or mission partner.

How the Questions Map to CSRMC and the cATO Memo

Each AO question lines up with specific CSRMC phases and tenets and with one of the three competencies the 2022 cATO memo requires.

Phases and tenets from DoW CIO (2025); competencies from DoD CIO (2022, 2024a). The mapping is ACC3’s reading of the construct, not an official Department crosswalk.

From Crawl to Run

A security program that slows delivery to a crawl gets bypassed and eventually gets cut in a budget cycle. As Question 3 described, much of the effort in a traditional compliance cycle goes into collecting and formatting evidence. Automating that collection hands that effort back to engineering every time a report comes due. The bigger payoff is that the system can keep its authorization current without halting software delivery to do it.

Programs usually get there in three phases. Crawl gives the AO answers to Questions 1 and 3, Walk adds Question 2 and sharpens Question 3, and Run adds Questions 4 and 5.

• Crawl. Work with the AO to tailor a NIST SP 800-53 Rev. 5 baseline to the system’s mission and risk tolerance. Write down the rationale for every tailoring decision because someone will ask. Put vulnerability scanning on an automated schedule that feeds a system the team can query.

• Walk. Move security into the pipeline with automated gates and give the AO a live dashboard in place of the quarterly briefing.

• Run. Add remediation triggered by events and schedules, continuous SBOM validation that treats a stale bill of materials as a finding, and reciprocity across defense domains.

Programs that jump straight to Run usually end up with a lot of tooling the AO doesn’t trust yet. The ones that crawl carefully often get there sooner than they expected because each phase gives the AO a reason to believe the next one.

Continue the Conversation

Most programs can answer some of these five questions only some of the time. ACC3 International welcomes conversations with program offices and AOs working out where their systems stand and what it would take to answer all five.

References

Center for Cybersecurity Policy and Law. (2026, January 16). FedRAMP signals acceleration of requirements for machine-readable packages in the Rev5 process. https://www.centerforcybersecuritypolicy.org/insights-and-research/fedramp-signals-acceleration-of-requirements-for-machine-readable-packages-in-the-rev5-process

cloud.gov. (n.d.). Compliance and controls. https://docs.cloud.gov/platform/compliance/

Cybersecurity and Infrastructure Security Agency. (2019). Binding Operational Directive 19-02: Vulnerability remediation requirements for internet-accessible systems (Revoked June 10, 2026, by BOD 26-04). https://cisa.gov/binding-operational-directive-19-02

Cybersecurity and Infrastructure Security Agency. (2021). Binding Operational Directive 22-01: Reducing the significant risk of known exploited vulnerabilities (Revoked June 10, 2026, by BOD 26-04). https://cisa.gov/binding-operational-directive-22-01

Cybersecurity and Infrastructure Security Agency. (2026a, July 29). 2026 minimum elements for a software bill of materials (SBOM) [Joint guidance with NSA, FBI, and international partners]. https://www.cisa.gov/sites/default/files/2026-07/2026_cisa_sbom_minimum_elements_508c.pdf

Cybersecurity and Infrastructure Security Agency. (2026b, June 10). Binding Operational Directive 26-04: Prioritizing security updates based on risk. https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk

Defense Information Systems Agency. (2025, January 30). Cloud service provider (CSP) security requirements guide (SRG) (Version 1, Release 2). https://public.cyber.mil/dccs/dccs-documents/

Department of Defense Chief Information Officer. (2020). DoD vulnerability management (DoD Instruction 8531.01). https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/853101p.pdf

Department of Defense Chief Information Officer. (2022). Continuous authorization to operate (cATO) [Memorandum]. https://dodcio.defense.gov/Portals/0/Documents/Library/20220204-cATO-memo-Signed-Cleared.pdf

Department of Defense Chief Information Officer. (2024a). DevSecOps continuous authorization implementation guide. https://dodcio.defense.gov/Portals/0/Documents/Library/DoDCIO-ContinuousAuthorizationImplementationGuide.pdf

Department of Defense Chief Information Officer. (2024b). DoD cybersecurity reciprocity playbook. https://dodcio.defense.gov/Portals/0/Documents/Library/(U)%202024-01-02%20DoD%20Cybersecurity%20Reciprocity%20Playbook.pdf

Department of War Chief Information Officer. (2025, September 24). Department of War announces new Cybersecurity Risk Management Construct. https://dowcio.war.gov/In-the-News/Article/4367432/department-of-war-announces-new-cybersecurity-risk-management-construct/

Federal Risk and Authorization Management Program. (2026, March 25). Initial outcome from RFC-0024 Rev5 machine-readable packages (Public Notice NTC-0009). https://www.fedramp.gov/notices/0009/

G7 Cybersecurity Working Group. (2026, May 12). Software bill of materials for AI: Minimum elements. Federal Office for Information Security (BSI). https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/SBOM-for-AI_minimum-elements.pdf?__blob=publicationFile&v=4

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

National Institute of Standards and Technology. (2011a). Managing information security risk: Organization, mission, and information system view (NIST SP 800-39). https://csrc.nist.gov/pubs/sp/800/39/final

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

National Institute of Standards and Technology. (2020). Security and privacy controls for information systems and organizations (NIST SP 800-53 Rev. 5, Release 5.2.0, August 2025). https://doi.org/10.6028/NIST.SP.800-53r5

National Institute of Standards and Technology. (2021). Attribute-based access control for microservices-based applications using a service mesh (NIST SP 800-204B). https://doi.org/10.6028/NIST.SP.800-204B

National Institute of Standards and Technology. (2022a). Implementation of DevSecOps for a microservices-based application with service mesh (NIST SP 800-204C). https://doi.org/10.6028/NIST.SP.800-204C

National Institute of Standards and Technology. (2022b). Cybersecurity supply chain risk management practices for systems and organizations (NIST SP 800-161 Rev. 1, Update 1, November 2024). https://doi.org/10.6028/NIST.SP.800-161r1-upd1

National Institute of Standards and Technology. (2024). Strategies for the integration of software supply chain security in DevSecOps CI/CD pipelines (NIST SP 800-204D). https://doi.org/10.6028/NIST.SP.800-204D

U.S. Government Accountability Office. (2023). Software acquisition: Additional actions needed to help DOD implement future modernization efforts (GAO-23-105611). https://www.gao.gov/products/gao-23-105611