--- title: "Multi-Framework Governance Evidence" description: "One implementation record projected into CMMC, NIST 800-171 and 800-53, FedRAMP, SOC 2, PCI DSS 4.0, ISO 27001, and HIPAA: one control mapping per row." url: https://policycortex.com/solutions/governance sealed: 2026-09-02 amended: 2026-09-02 register: solutions/governance records: 5 digest: sha3:36218b0add80968e1db1b8a3402c759a30f19ca3cada4cc514093ebf9443150a --- # One record. Every framework that matters. CMMC / NIST 800-171 and 800-53 / FedRAMP / SOC 2 / PCI DSS / ISO 27001 / HIPAA Defense contractors carry CMMC, NIST 800-171, NIST 800-53, FedRAMP, and DFARS at once; commercial enterprises stack SOC 2, PCI DSS 4.0, ISO 27001, and HIPAA. PolicyCortex keeps one hash-chained implementation record and writes the control mapping on every row, so one encryption setting evidences every framework that cites it and the evidence for all of them can be recomputed. [Request verification](https://policycortex.com/contact) · [Book a call](https://policycortex.com/book) Read only. Fourteen days. No sales call required. ## What overlapping frameworks ask you to prove Every framework asks for the same environment through a different vocabulary. CMMC AC.L2-3.1.1, NIST 800-53 AC-3, FedRAMP AC-3, SOC 2 CC6.1, PCI DSS requirement 7, ISO 27001 A.5.15, and HIPAA 164.312(a) are all, in the end, a question about who can reach what. Answering each separately means collecting the same evidence several times and keeping several narratives in step by hand. The obligation that matters is that the mappings be explicit. An assessor who asks why this row satisfies that control needs to see the mapping written on the record, not inferred by a tool at report time. - **gov.frameworks**: CMMC Level 2, NIST 800-171 and 800-53, FedRAMP, DFARS, SOC 2, PCI DSS 4.0, ISO 27001, HIPAA, ITAR, CIS benchmarks, MITRE ATT&CK and ATLAS. - **gov.mapping**: Bidirectional control map: the 110 CMMC Level 2 requirements cross-walked to NIST 800-53 and onward. The mapping is stored on the record, not implied. - **gov.policy**: Policy evaluation runs inside your tenant; custom rules are first-class beside framework controls and produce the same evidence. - **gov.rollout**: Policy changes roll out in phases under the trust mode you set; a regression against the compliance baseline rolls back to the prior phase, and the rollback is a row. ## One implementation record, every framework One implementation record, many envelopes. Where each proof files: - **Access (AC · CC6 · A.5.15 · req. 7)**: Proof of state: who could reach what as of any date, one record, with every framework's control identifier written on it. - **Change (CM · CC8 · A.8.32 · req. 6)**: Proof of change: who or what altered the estate, under what authority, with before and after hashes and a rollback identifier, filed once against every framework that cites it. - **Audit (AU · CC7 · A.8.15 · req. 10)**: The chain itself: an audit record that cannot be edited without detection, with declared gaps, serving every logging and monitoring control at once. - **Machine actions (AC-6 · SI-4 · ATLAS)**: Proof of agency: the envelope, the action, and the counterfactual for every autonomous act, with MITRE ATT&CK and ATLAS techniques annotated. - **Documents (SSP · POA&M · SAR)**: Generated from the one record and exported as OSCAL 1.1.2 where the framework wants it. The document is never the source. ![The PolicyCortex control implementation table: CMMC Level 2 controls by family with implementation status and evidence counts](https://policycortex.com/images/pcx-system-control-collections-1600.webp) Exhibit SB-9 · the requirement table where evidence files, control by control, with implementation status and artifact counts. Illustrative demo data; the interface is real. ## How one record is verified for many frameworks For overlapping frameworks the recomputation is done once: the control mapping is a field on the row, so an assessor for any framework recomputes the same digest and reads the mapping written on 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. ## How you evaluate it across your frameworks The fourteen days capture every row with its mappings written on, so by the end one encryption setting already evidences every framework you selected and none of that evidence needs re-collecting. Connect read only for fourteen days, in 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. At the end of the fourteen days you hold the records and can recompute the chain yourself. - **eval.mode**: SHADOW. Watch only; nothing executes. - **eval.duration**: Fourteen days. - **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. ## Questions assessors and buyers ask **Q: How does cross-framework mapping work?** A: A curated bidirectional control map: the 110 CMMC Level 2 requirements cross-walked to NIST 800-53 and, through it, to the other frameworks. Each row carries its mappings as a field, so one piece of evidence satisfies the matched controls in adjacent frameworks and the reason is written down. **Q: Custom internal policies?** A: Yes. Custom rules are first-class beside the framework controls: same evidence model, same gating, same record. **Q: Why several policy engines under one layer?** A: OPA for in-tree rules, Steampipe for live cloud queries, Cloud Custodian for resource lifecycle. The router picks the engine per control; the evidence is the same shape whichever ran. **Q: How is a regression detected during a phased rollout?** A: Each phase runs against the compliance baseline. Promotion to the next phase requires the same or a better result. A drop rolls back to the prior phase, and the rollback is a row in proof of change. **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. **Q: What happens when a collector is down?** A: The chain carries a declared gap: the stream, the interval, the reason, and when it was declared. Evidence never silently has fewer rows. One record. Every mapping written down. [Request verification](https://policycortex.com/contact) · [Book a call](https://policycortex.com/book) ## Register colophon | Seq | Label | SHA3-256 | Prev | |---|---|---|---| | REC 0000 | OBLIGATION | 5be7c23a408d | 9b4405416504 | | REC 0001 | EVIDENCE | 5927addc2b51 | 5be7c23a408d | | REC 0002 | VERIFICATION | 9abaf56b2902 | 5927addc2b51 | | REC 0003 | EVALUATION | fbbc5f2e2747 | 9abaf56b2902 | | REC 0004 | QUESTIONS | 36218b0add80 | fbbc5f2e2747 | Head sha3:36218b0add80968e1db1b8a3402c759a30f19ca3cada4cc514093ebf9443150a. 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.