--- title: "ATO packages from one hash-chained record" description: "SSP, SAR, POA&M, OSCAL 1.1.2 and eMASS XML generated from one implementation record in your tenant, regenerable to any date, verifiable by the assessor." url: https://policycortex.com/platform/ato-authorization sealed: 2026-09-02 amended: 2026-09-02 register: platform/ato-authorization records: 6 digest: sha3:88486cfbf9793fbc4aadf07134b631a312fab8f5c55567154a5c9912137b4ac5 --- # The package is a projection of the record. Register / Mechanism / ATO packaging An authorization decision is a claim about a system as of a date. PolicyCortex generates the SSP, SAR and POA&M from one implementation record kept on the hash chain in your tenant, exports the package as OSCAL 1.1.2 with eMASS XML and evidence indexes, and regenerates it to any timestamp inside retention, so the authorizing official can enumerate what changed. [Request verification](https://policycortex.com/contact) · [The federal record](https://policycortex.com/federal) ![The PolicyCortex continuous ATO workspace: authorization lifecycle, passing-control posture, open POA&Ms, evidence artifacts, and six live collections](https://policycortex.com/images/pcx-continuous-ato-workspace-1600.webp) Exhibit A-1 · the authorization workspace: lifecycle, posture, POA&Ms, and six live collections. Illustrative demo data; the interface is real. ## One implementation record, several shapes. The documents assessors ask for are projections of this record, not parallel artifacts maintained by hand. SSP, POA&M, and SAR generate from one implementation record, and the package exports as OSCAL 1.1.2. The same record ships in assessor handoff shape for the eMASS and C3PAO exchange, and in program-office shapes for federal environments. The document is never the source. The chain is. - **ssp**: The System Security Plan, in NIST SP 800-18 r1 structure, generated from the implementation record rather than authored beside it. - **sar**: The Security Assessment Report, per NIST SP 800-53A, generated from the same record. - **poam**: The Plan of Action and Milestones: open gaps by family and severity, each with an owner and a remediation path. - **oscal**: OSCAL 1.1.2 JSON, native. Machine readable by construction; the format FedRAMP 20x asks for. - **emass**: eMASS XML, the assessor handoff shape for the eMASS and C3PAO exchange. The OSCAL package is C3PAO-agnostic; it does not lock you to an assessor. - **conmon.record**: The continuous monitoring record: append-only JSONL, hash chained, seven-year retention, regenerable to any timestamp. - **evidence.index**: The index of evidence artifacts behind every control, each with its content hash and capture time. - **package**: One ZIP carrying all of the above: inventory, validations, POA&M, SSP, SAR. Hash chained, AES-256 protected. See also - [Proof of state, where the rows come from](https://policycortex.com/proof/state) - [The export surface in the architecture](https://policycortex.com/architecture#boundaries) ## Regenerable to the date the authorizing official signed. An authorization decision is a claim about a system as of a date. The record regenerates to any historical timestamp, so the package your authorizing official signed and the package you hold today differ only by rows you can enumerate. Chain verification tells both of you whether anything was edited after the fact. Continuous authorization records are the same rows in a different envelope. When a collector was down or a scope was unobserved, the package says so: a declared gap with interval and reason, never silently fewer rows. See also - [Proof of change, where edits become visible](https://policycortex.com/proof/change) - [Declared gaps](https://policycortex.com/architecture#gaps) ## From scope to 3PAO assessment. One authorization package, tracked from scope through 3PAO assessment. The rows below are where assessors expect to find what the record produces; the record is the product. - **NIST 800-53**: CA-7 continuous monitoring from point-in-time records; AU-9 and AU-10 from the chain itself; CM-3, AC-6, SI-4. SSP and SAR generated, not authored. - **NIST 800-171 / CMMC Level 2**: One evidence base for the 110 requirements, handed to the assessor as generated evidence with the raw payload attached. - **FedRAMP 20x**: Machine-readable by construction; exports as OSCAL 1.1.2 rather than as documents transcribed from screenshots. - **eMASS / C3PAO**: The handoff package: what the assessor receives and how they verify it by hash. ![A PolicyCortex ATO collection overview: passing controls, six-stage lifecycle from scope to 3PAO assessment, control family coverage, and package readiness](https://policycortex.com/images/pcx-ato-collection-overview-1600.webp) Exhibit A-2 · one authorization package from scope to 3PAO assessment: passing controls, family coverage, next action. Illustrative demo data; the interface is real. See also - [The eMASS and C3PAO handoff](https://policycortex.com/cmmc/emass-c3pao-handoff) - [The federal record](https://policycortex.com/federal) ## Which boundaries. AWS and Azure boundaries are supported for ATO packaging, including AWS GovCloud and Azure Government; the software also runs inside GCC High. GCP support covers governance, remediation, and control-linked evidence, not an ATO workflow. On-premises delivery for air-gapped environments is available. Where each component runs and what it can reach is stated in the [architecture](https://policycortex.com/architecture). ## Four questions program offices ask. **Q: What is in the package?** A: The SSP, the SAR, the POA&M, the OSCAL 1.1.2 JSON, the eMASS XML, and the evidence indexes, generated from one implementation record and shipped as one ZIP, hash chained and AES-256 protected. **Q: Which clouds are supported for ATO packaging?** A: AWS and Azure boundaries, including AWS GovCloud and Azure Government; the software also runs inside GCC High. GCP is observed for governance, remediation, and control-linked evidence, but an ATO workflow for GCP is not offered. **Q: Can the package be regenerated as of a past date?** A: Yes. Retention is seven years and the record regenerates to any historical timestamp inside it, so the package as of the day the authorizing official signed is a parameter you pass, not an archive you search. **Q: Does PolicyCortex authorize or certify the system?** A: No. The authorizing official remains the authority on what operates and the assessor remains the authority on what passes. PolicyCortex produces the records those decisions rest on, and no certification is guaranteed. ## What this page is not. **Stated limit.** PolicyCortex is not a C3PAO and does not certify anything. The assessor remains the authority on what passes, and the authorizing official remains the authority on what operates. The record makes verification cheaper; it does not guarantee any outcome. Hand the assessor a package built to be verified. [Request verification](https://policycortex.com/contact) ## Register colophon | Seq | Label | SHA3-256 | Prev | |---|---|---|---| | REC 0000 | ONE RECORD | 3d7b658e097a | 339a9a3d41df | | REC 0001 | AS OF | 89f39801be7f | 3d7b658e097a | | REC 0002 | LIFECYCLE | 8497825ad5a0 | 89f39801be7f | | REC 0003 | BOUNDARIES | d1d2cbd055a1 | 8497825ad5a0 | | REC 0004 | QUESTIONS | 7db58a5548ef | d1d2cbd055a1 | | REC 0005 | STATED LIMIT | 88486cfbf979 | 7db58a5548ef | Head sha3:88486cfbf9793fbc4aadf07134b631a312fab8f5c55567154a5c9912137b4ac5. Each digest is SHA3-256 over the previous digest, the register key, the record label, and the record copy; a second party can recompute it from this document.