---
title: "Azure Governance Evidence, GCC High Included"
description: "Azure commercial, Government, and GCC High: Azure Policy, Defender, Entra ID, and Resource Graph as hash-chained evidence for CMMC, NIST 800-171, FedRAMP."
url: https://policycortex.com/solutions/azure
sealed: 2026-09-02
amended: 2026-09-05
register: solutions/azure
records: 6
digest: sha3:e02bf31ff32581c8ee5a916a752d948b18ecc51eff6e65b18afaa72c8f034300
---

# Azure-native. Commercial through GCC High.

Azure Policy / Defender for Cloud / Entra ID / GCC High

PolicyCortex was built Azure-first and runs inside your subscriptions in commercial Azure, Azure Government, and GCC High. It reads Azure Policy, Defender for Cloud, Entra ID, and Resource Graph, records what the estate was, what changed it, and what machines were allowed to do, and every remediation handler ships with matched captureState and restoreState so rollback is a contract.

[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 Azure estate must prove

Azure Policy reports compliance for now; Defender for Cloud recommends for now; the activity log records that something changed. The assessor's questions are about then: what was this storage account's encryption setting, this Key Vault's network rule, this Conditional Access policy, as of the date they name, who or what changed it and under what authority, and what was any automated fix permitted to do before it ran.

Government tenants add a boundary question: which subscriptions under which management group sit inside the CUI enclave, and whether what is outside it was unobserved or simply not connected.

- **azure.scope**: Management group through subscription to resource, scoped with Resource Graph (KQL). The declared boundary is a field on every record.
- **azure.clouds**: Commercial Azure, Azure Government, GCC, and GCC High. GCC High is a first-class deployment target.
- **azure.sources**: Azure Policy initiatives and compliance results, Defender for Cloud recommendations, Entra ID and PIM, Resource Graph. Reader at management-group scope for read-only onboarding.
- **azure.frameworks**: CMMC Level 2, NIST 800-171, NIST 800-53, FedRAMP. Azure boundaries are supported for ATO packaging.

## The evidence produced from your subscriptions

Azure Policy is the execution layer. The record is what Azure Policy does not ship: state as of any date, the authority behind each change, and the envelope around each action. Where each proof files:

- **Azure Policy · Defender**: Proof of state: compliance results and recommendations captured as point-in-time records with the raw ARM response attached, content hashed, regenerable to any date.
- **Activity log · Entra ID**: Proof of change: who or what altered a resource, under what authority, with before and after hashes and a rollback identifier. PIM elevation is part of the authority on the record.
- **ARM remediation**: Proof of agency: every remediation runs through native ARM operations, no agent required, inside an envelope and in the trust mode you set; GATED, a named human approving each action, is the default. Matched captureState and restoreState pairs make rollback a contract.
- **Conditional Access · PIM**: Identity posture as evidence: which policies bound which principals as of a date, with MFA and PIM state carried on the record.
- **Frameworks**: One control mapping per record: a storage encryption setting evidences NIST 800-171 3.13.16, 800-53 SC-28, and CMMC SC.L2-3.13.16 at once, written down, not implied.

## How the record is verified across management groups

Across a management group the recomputation covers every connected subscription as one chain, and PIM elevation on a change is part of what the digest commits to, so authority cannot be revised after the fact.

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 in an Azure tenant

After access is reviewed and scope is agreed, read-only onboarding uses a service principal holding Reader at management-group scope. Azure Policy results, Defender recommendations, Entra ID, and Resource Graph are read, nothing is written, and Contributor is not needed for this read-only mode.

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.

The standard engagement scope is a CMMC Level 2 package in one primary environment; Azure Government and GCC High are in scope.

- **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 GCC High supported?**
A: Yes. PolicyCortex deploys in commercial Azure, Azure Government, GCC, and GCC High. The platform is Azure-first, so GCC High is a first-class deployment target.

**Q: Does this replace Azure Policy?**
A: No. Azure Policy is the execution layer. PolicyCortex authors initiatives, deploys them at scope, and records the compliance results, then adds what Azure Policy does not ship: cross-framework mapping, gated remediation with a rollback contract, and a hash-chained record of state as of any date.

**Q: How does Defender for Cloud fit?**
A: Defender recommendations are consumed and recorded. A high-severity recommendation gets a remediation proposed with a published confidence figure, gated for a named human's approval by default, applied through ARM with a rollback identifier armed first, and verified against the pinned target state.

**Q: What service principal permissions are needed?**
A: Reader at the management-group scope for read-only onboarding. Contributor at the resource scope only where remediation is enabled. PIM-aware: just-in-time elevation is supported and is recorded as part of the authority behind each change.

**Q: Where does the data live?**
A: In your own tenant. There is no telemetry pipeline to PolicyCortex servers and no egress of evidence.

**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.

Request access to review your Azure scope and onboarding needs. [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 | dc50cced6248 | 14ac4ab0f4d5 |
| REC 0001 | EVIDENCE | 69b378b4d34c | dc50cced6248 |
| REC 0002 | VERIFICATION | ce3ba82c4d02 | 69b378b4d34c |
| REC 0003 | EVALUATION | 19c0df903bf0 | ce3ba82c4d02 |
| REC 0004 | DELIVERY | 8ef29e0a939d | 19c0df903bf0 |
| REC 0005 | QUESTIONS | e02bf31ff325 | 8ef29e0a939d |

Head sha3:e02bf31ff32581c8ee5a916a752d948b18ecc51eff6e65b18afaa72c8f034300. 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.
