The AO receives evidence. Not a description of evidence.
Authorization packages built from current system state, not from memory.
The authorization package fails when documentation lags reality.
NIST SP 800-37 Rev 2 defines the Risk Management Framework as a six-step lifecycle: Categorize, Select, Implement, Assess, Authorize, Monitor. The Authorize step requires the Authorizing Official to review the authorization package and make a formal risk acceptance decision.
Source: NIST SP 800-37 Rev 2
The authorization package consists of: the System Security Plan, the Security Assessment Report, the Plan of Action and Milestones, and supporting evidence artifacts. The quality of the AO's risk decision is bounded by the quality of the package.
The most common authorization failure mode is not a poorly implemented control. It is the inability to demonstrate implementation on demand. An ISSO who has implemented AC-2 correctly but has no evidence that the account management process was followed produces a gap the assessor cannot close.
The second most common failure mode is documentation lag. Between the time the SSP was written and the time the AO reviews it, the system has changed. New services deployed. Infrastructure reconfigured. Personnel changed. The AO is reviewing historical documentation. The 3PAO is testing the current system. When they diverge, the assessment produces findings that could have been identified and addressed earlier.
Documentation that is out of date before it is signed.
A traditional ATO package is a point-in-time snapshot. An ISSO writes the SSP describing system state as of a given date. The AO reviews it months later. The system has changed multiple times since then. The package describes a system that no longer exists. The 3PAO tests the system as it exists now. They diverge.
Evidence that is always current.
REAEGIS generates the SSP from current system state. Every control narrative is derived from real evidence. The OSCAL package reflects what is deployed right now. When the AO opens the package, it describes the system as it exists — not as it was described months ago. The 3PAO tests the same system the package describes.
Continuous ATO: the DoD authorization model.
The DoD has formalized Continuous Authorization to Operate as an authorization model where real-time monitoring and continuous evidence generation replace the periodic assessment cycle. The DoD CIO has identified three foundational cATO competencies:
- CONMONContinuous monitoring
- ACDActive cyber defense
- DevSecOpsDevSecOps with a secure software supply chain
A program that satisfies these three competencies can maintain an ongoing authorization rather than pursuing periodic re-authorization. The AO maintains confidence in the security posture through continuous visibility rather than periodic assessment.
REAEGIS measures each cATO competency independently: continuous monitoring is measured by evaluation frequency, finding age, and ConMon package delivery; active cyber defense is measured by finding-to-remediation cycle time and gate pass rates; DevSecOps posture is measured by pipeline integration depth and signed artifact coverage. The combined measure is the cATO Readiness score — a composite indicator the AO can use to evaluate whether the program has achieved the maturity required for continuous authorization.
Authorization is not a destination.
It is a system property.
REAEGIS is the infrastructure that maintains it — converting every commit, scan, and approval into evidence your Authorizing Official can act on.