Continuous ATO Is a Data Problem

Every DoD software factory has been told to move to continuous authorization, and the policy behind it is settled: the memos are signed, and the Army, Air Force, and Space Force have all committed to timelines. Yet most programs that actually try to execute cATO end up somewhere between a spreadsheet and a stalled pilot. After seventeen years in federal cyber I have watched this pattern enough times to be confident about the cause, which is that cATO does not stall on policy so much as it stalls on data.

The three things that never live in one place

To make an authorization decision continuously instead of once every three years, an Authorizing Official needs three things to be true at the same moment.

• Real-time asset state: what is actually on the network right now, rather than what the inventory said last quarter.
• Continuous control evidence in the system of record: eMASS, Xacta, or your GRC tool, refreshed from live technical state instead of re-keyed by hand.
• Automated control assessment: the system mapping a scanner finding or a configuration to whether an 800-53 control is satisfied, so the human reviews rather than assembles.

The reason cATO is hard is that no traditional tool holds all three together. The scanner knows about vulnerabilities but not the control, the GRC platform knows the control catalog but not the live host, and the CMDB knows the asset but not whether its crypto is in FIPS mode or its EDR is actually running. The ISSM ends up as the integration layer, and that integration layer is a person downloading ACAS XMLs and uploading them to eMASS by hand.

Your SSP is a snapshot, your scans are uploaded by hand, and your control status is quarterly; so the gap between what is true right now and what your authorization package says is exactly where the risk lives.

Why "continuous" is really a data-integrity requirement

The word "continuous" tends to get read as "faster," but it actually means something stricter: the authorization artifact has to be a live function of the environment rather than a periodic transcription of it, which makes it a data problem before it is a workflow problem. Getting there means three things have to change.

1. One authoritative asset truth

The same host shows up in EDR, the cloud console, two scanners, and an identity provider, each under a different name and with a different risk picture, and until those records reconcile into one, every control assessment downstream inherits the disagreement. You cannot assess "the system" if you cannot first agree on what is in it. A unified asset graph that relates assets, identities, exposures, and the controls that apply to them is the precondition rather than a nice-to-have.

2. Evidence as a byproduct of operations

The expensive way to do compliance is to run it as an assessment project gathering evidence, writing narratives, and assembling a package on a deadline. The continuous way is to let the evidence fall out of the system that is already running, so that when a scanner finding, an SBOM inventory, or a STIG result maps to its control automatically, the package becomes a query rather than a quarter of work. The honest version of this still shows where each piece of evidence came from, so an assessor can actually trust it.

3. Machine-readable artifacts

The systems on the receiving end of your authorization package want OSCAL, not a PDF: eMASS, RegScale, and Xacta, along with the tooling an AO or 3PAO uses to review it. Generating the SSP, the assessment results, and the POA&M as OSCAL directly from the live graph is what turns authorization into a real pipeline; the moment an artifact becomes a document a human typed, you are back to quarterly.

The part vendors get wrong

I will say the unglamorous thing plainly: continuous authorization is not push-button ATO, and you should be wary of anyone who sells it that way. The data can be continuous and the control-state computation can be automated, but control assessment still involves judgment and risk acceptance remains a decision an AO owns and signs, so the goal is never to remove the human but to stop making the human the data bus. What automation should buy you is an ISSM who no longer spends the week re-keying scan results, an AO who no longer authorizes on a quarterly snapshot, and a package that reflects what is actually deployed on the day it is read.

The control-plane framing

There is a second reason to care about getting the data layer right, and it reaches well past compliance. Zero Trust architectures put a Policy Decision Point at the center, and every allow, deny, or quarantine decision that PDP makes inherits the quality of the asset and identity data underneath it, so garbage in becomes quarantine out. The same authoritative trust-data layer that makes cATO continuous is the layer a PDP needs to make good decisions, which means compliance and enforcement turn out to be the same data problem wearing two different hats.

That is the bet we made in building SafeHarbor: fix the asset-truth layer first, generate the compliance artifacts and the trust signals from it, and continuous authorization stops being a heroic quarterly effort and starts being a property of the system. cATO is achievable, but you reach it by treating it as a data-integrity problem first and a paperwork problem second.