--- title: "FedRAMP Continuous Authorization Evidence" description: "FedRAMP Moderate and High as continuous authorization: NIST 800-53 Rev 5 controls as hash-chained records; SSP, POA&M, SAR generated; OSCAL 1.1.2 export." url: https://policycortex.com/solutions/fedramp sealed: 2026-09-02 amended: 2026-09-05 register: solutions/fedramp records: 6 digest: sha3:d72ececdcbf9c96b942a83cdd865bb629755f33c3bd391e89e7863e358d59e44 --- # FedRAMP Moderate and High, as continuous authorization. FedRAMP Rev 5 / NIST SP 800-53 Rev 5 / OSCAL 1.1.2 FedRAMP Rev 5 has been the baseline since May 2023. PolicyCortex records the NIST SP 800-53 Rev 5 controls at the impact level you target as hash-chained evidence inside your boundary, generates the SSP, POA&M, and SAR from that one record, and exports OSCAL 1.1.2, so an authorization is a state you can regenerate to any date, not an event. [Request Access](https://app.policycortex.com/auth?mode=request-access) · [Book a call](https://policycortex.com/book) Access is reviewed. Scope and onboarding are agreed with your team. ## What an authorization asks you to prove An authorization decision is a claim about a system as of a date. FedRAMP asks for the NIST SP 800-53 Rev 5 baseline at Moderate or High, the SSP that describes how each control is implemented, the SAR that records what the assessor found, the POA&M that tracks what remains, and continuous monitoring after the decision: POA&M updates, scans, and significant change documentation when the boundary moves. FedRAMP 20x asks for the same facts as machine-readable records rather than documents. The difficulty is drift between the package and the system. The package your authorizing official signed and the package you hold today should differ only by rows you can enumerate. - **fedramp.baseline**: NIST SP 800-53 Rev 5, Moderate or High, with the impact-level overlays. - **fedramp.package**: SSP, SAR, POA&M, and evidence indexes. Exported as OSCAL 1.1.2 and in eMASS shape. - **fedramp.conmon**: Continuous monitoring after the decision: POA&M updates, on-event change capture, significant change documentation. - **fedramp.sponsor**: JAB or agency sponsorship. The evidence package supports either path; we do not pick it. - **fedramp.boundary**: AWS and Azure boundaries are supported for ATO packaging, including AWS GovCloud and Azure Government. ## The evidence produced for the 800-53 baseline Everything in the package is a projection of three records. Where each proof files under 800-53: - **CA-7 · CA-2**: Proof of state: continuous monitoring grounded in point-in-time records of every control implementation, regenerable to the date the assessor or authorizing official names. - **AU-9 · AU-10**: The chain itself: records protected from modification and non-repudiable, because each digest commits to the record before it. - **CM-3 · CM-6**: Proof of change: configuration change control as a record of who or what altered the boundary, under what authority, with a rollback identifier. A significant change is a row, not a memory. - **AC-6 · SI-4**: Proof of agency: least privilege and monitoring for machine actors. What an autonomous action was permitted to do before it ran, and what it did. - **SSP · SAR · POA&M**: Generated from the one implementation record and exported as OSCAL 1.1.2. The document is never the source; the chain is. ![The PolicyCortex continuous ATO workspace: passing-control posture, open POA&Ms, evidence artifacts, and live collections](https://policycortex.com/images/pcx-continuous-ato-workspace-1600.webp) Exhibit SB-8 · the authorization lifecycle as a workspace: passing-control posture, open POA&M items, evidence artifacts, live collections. Illustrative demo data; the interface is real. ## How the authorizing official verifies the record For an authorization the recomputation answers one question: the package the authorizing official signed and the package you hold today differ only by rows you can enumerate, because every row after the signing date carries the digest of the one before it. Every record PolicyCortex writes for this obligation is content hashed with SHA3-256 and carries the digest of the record before it, so each line commits to the entire history above it. The log is append only: a correction is a new record, never an edit. Verification is a recomputation, not an assertion. Run the chain from the first record forward and it returns one of two answers: intact, or the sequence number of the first record that breaks. A second party can do that recomputation without our help. The records, the digests, and the chain rule are everything required: no PolicyCortex account, no API of ours in the loop. When a collector was down or a scope was unobserved, the chain carries a declared gap with the interval and the reason, never silently fewer rows. Absence is declared, not inferred. **Stated limit.** PolicyCortex is not an assessor and does not certify anything. It produces the records a compliance decision rests on; the assessor, the authorizing official, or the accountable official makes the determination. What is not connected is not observed, and the record says so. Control identifiers cite NIST SP 800-53 Rev 5, NIST SP 800-171 Rev 2, PCI DSS 4.0, SOC 2 TSC, ISO/IEC 27001:2022 and 45 CFR 164 as published. ## Access and onboarding inside an authorization boundary We agree on your AWS or Azure boundary and target impact level, Moderate or High, before onboarding. Read-only captures within that scope supply evidence for the OSCAL package. Request access so we can review your environment, evidence needs, and onboarding scope. After access is approved, read-only onboarding uses SHADOW mode inside your own tenant. Nothing executes. Policy evaluation, evidence collection, and action gating run where your data already is; there is no telemetry pipeline to PolicyCortex servers and no egress of evidence. You hold the records and can recompute the chain yourself. - **eval.mode**: SHADOW. Watch only; nothing executes. - **eval.onboarding**: Access is reviewed. Scope and onboarding are agreed with your team. - **eval.location**: Your tenant. Azure, AWS, and GCP are observed clouds, including AWS GovCloud, Azure Government, and GCC High. - **eval.egress**: None. No telemetry pipeline to PolicyCortex servers; no evidence leaves the tenant. - **eval.after**: You keep the records. Licensing is annual and the tenant owns the evidence; a delivery engagement is optional. ## Delivery, if you want the record stood up for you Licensing does not depend on it, but a fixed-scope delivery engagement is available: thirty days, one agreed primary cloud environment, an evidence package built and defended through assessor review. The independent assessor makes the certification decision. No certification is guaranteed. FedRAMP work is scoped separately from the standard CMMC Level 2 engagement. - **engagement.scope**: Thirty days. One agreed primary cloud environment. - **engagement.outcome**: An evidence package built and defended through assessor review. - **engagement.limit**: The independent assessor decides. No certification is guaranteed. [Every term of the engagement, on its own page.](https://policycortex.com/engagement) ## Questions assessors and buyers ask **Q: Is PolicyCortex itself FedRAMP authorized?** A: No. PolicyCortex is not a FedRAMP-authorized cloud service; it runs inside your tenant and boundary rather than as a service outside it. For customers pursuing FedRAMP, it generates the artifacts inside that boundary. JAB and agency sponsorship are both supported. **Q: Rev 4 or Rev 5?** A: Rev 5 has been the FedRAMP baseline since May 2023. PolicyCortex records Rev 5 by default; Rev 4 evidence cross-walks are supported for legacy systems. **Q: JAB or agency sponsorship?** A: Both. We do not pick the path. The evidence package supports either sponsorship model. **Q: How does continuous monitoring work?** A: Evidence is captured on schedule and on change. The POA&M and SAR are regenerated from the record rather than edited by hand, and a significant change is a row in proof of change with a rollback identifier. Your continuous authorization status rests on records the authorizing official can recompute. **Q: What about FedRAMP 20x?** A: FedRAMP 20x asks for machine-readable evidence rather than documents. The record is machine-readable by construction: state and control mappings export as OSCAL 1.1.2 rather than as documents transcribed from screenshots. **Q: Does PolicyCortex make us compliant?** A: No. It produces the records compliance decisions rest on. The authorizing official, the C3PAO, or the accountable official makes the determination; PolicyCortex hands them evidence they can recompute instead of a narrative they have to believe. Bring your authorizing official. We speak OSCAL. [Request Access](https://app.policycortex.com/auth?mode=request-access) · [Book a call](https://policycortex.com/book) ## Register colophon | Seq | Label | SHA3-256 | Prev | |---|---|---|---| | REC 0000 | OBLIGATION | 9ffbe659a7a7 | 932e954494bf | | REC 0001 | EVIDENCE | 4dafb4d09532 | 9ffbe659a7a7 | | REC 0002 | VERIFICATION | fa1a7e13f905 | 4dafb4d09532 | | REC 0003 | EVALUATION | 2d7b0ab2b1b2 | fa1a7e13f905 | | REC 0004 | DELIVERY | 39c575149550 | 2d7b0ab2b1b2 | | REC 0005 | QUESTIONS | d72ececdcbf9 | 39c575149550 | Head sha3:d72ececdcbf9c96b942a83cdd865bb629755f33c3bd391e89e7863e358d59e44. 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.