How to support cATO in Azure with automated evidence

1. Define cATO and the decision your evidence supports

Continuous authorization to operate (cATO) supports ongoing authorization through sustained visibility into security posture, repeatable testing, and a process for responding to changes and risk. In Azure, that can connect policy evaluation, infrastructure deployment, application security testing, operational monitoring, and accountable review. Azure does not have a resource setting that turns cATO on.

Microsoft’s mapping of DoD Zero Trust activities 3.5.1 and 3.5.2 connects cATO to standardized control monitoring, deviation detection, DevSecOps testing, incident-response integration, and analytics for authorizing officials. Those capabilities require an operating process and evidence beyond infrastructure configuration. The applicable program and authorizing official establish the authorization criteria, acceptable change boundaries, required evidence, and response thresholds.

FedRAMP provider status, an agency application ATO, and a DoD cATO process have related but distinct scopes and decision authorities. Select the cloud and provider offering required by your agency, then map inherited, shared, and customer responsibilities. Azure Government service availability does not establish that every feature, region, or tool is covered by your approved boundary.

2. Define an evidence contract for each control implementation

Before writing a collector, identify the required security outcome, covered resources, implementation owner, verification method, evidence source, allowed result states, freshness window, and escalation path. Version this mapping with the architecture. Set freshness and review intervals from the applicable program’s requirements rather than an invented universal cATO cadence.

A storage policy result can support boundary-protection evidence such as an applicable SC-7 implementation. It does not prove every network path, private DNS setting, data-flow restriction, or cryptographic requirement. Record “this check supports this part of the implementation,” not “this resource passes SC-7.”

3. Build the Azure evidence workflow

Use an approved CI/CD runner and cloud-correct authentication. Keep the deployment identity, evidence-reading identity, archive-writing identity, and human review roles distinct where practical. A collector usually does not need permission to change production infrastructure. A deployIfNotExists remediation identity has different permissions and should not be treated as the evidence reader.

Store sanitized evidence in an approved repository or object store inside the documented boundary. Use per-run paths, access controls, integrity manifests, and the applicable retention requirements. Review any use of a SaaS CI artifact store before placing regulated system details there. Terraform plans/state, subscription/resource identifiers, policy exceptions, logs, and deployment outputs can be sensitive even without access tokens.

4. Use Azure Policy to observe and constrain configuration

Create a reviewed initiative or a small set of definitions matched to the supported services. Record assignment scope, parameters, exclusions, exemptions, enforcement mode, and the actual definition versions evaluated. An initiative’s display name is not a stable evidence identifier, and assigning a regulatory initiative does not prove complete baseline coverage.

Start in a controlled audit/evaluation rollout, test known compliant and noncompliant resources, and then introduce enforcement where approved. Distinguish Audit from Deny and from Modify/deployIfNotExists. A deny effect can reject a future noncompliant create/update; it does not automatically repair an existing resource. Remediation requires its own identity, permissions, task, and verification.

Policy evaluation has timing and coverage limits. Microsoft documents a standard reevaluation cycle once every 24 hours plus event-driven and on-demand evaluation. Completion time varies, and not every resource provider supports the same triggers. Record evaluation timestamps; do not treat the time a collector ran as the time Azure evaluated each resource.

Continue with the Azure Policy evidence automation how-to for a concrete rule, evaluation/collection commands, pagination, exemption handling, and result validation.

5. Connect Terraform or Bicep/ARM to the evidence record

Keep policy definitions, assignments, deployment modules, and control-map revisions in version control. In Terraform, preserve the reviewed plan and apply result with provider/CLI versions and the dependency lockfile. With Bicep, compile to ARM JSON and preserve the reviewed what-if, template/parameter references, deployment operation results, and resulting resource IDs.

Neither a plan nor what-if is a compliance assessment. A plan describes proposed changes; what-if has documented analysis limits. After a successful deployment, export the live configuration and gather fresh supporting policy and runtime results. When a later manual change alters a setting, retain both the original release record and the new drift finding.

Continue with the Terraform and Bicep/ARM evidence-pipeline how-to for equivalent audit-policy examples, predeployment stages, exit-code handling, and postdeployment collection.

6. Operate the loop between releases

Collect evidence after relevant deployments and on a scheduled cadence appropriate to the requirement. Combine periodic collection with change and security signals from approved monitoring. Azure Activity Log can help explain configuration changes; application and data-plane activity may need additional diagnostic sources. Include vulnerability management, identity reviews, application tests, incident response, and organizational evidence where applicable.

Represent at least these conditions separately: verified technical check; noncompliant result; approved exception; not applicable with a reason; stale or missing evidence; and collection/tool failure. Unknown, an empty response, or an unreachable API must not become a passing control. Alert on expired exceptions, unsupported evaluation, missing expected resources, and silent collection failures.

Route findings to the implementation owner and the program’s review process. Record a remediation or rollback decision, retest the actual affected behavior, and retain closure evidence. Define which changes remain within the approved authorization conditions and which changes require further review. A new data flow, region, external service, or privilege model may change more than a policy dashboard can see.

7. Start with a bounded, testable pilot

1. Choose one workload and an approved control implementation, such as private storage access or required logging.
2. Identify every expected resource and assign the configuration, runtime-test, evidence, and review owners.
3. Deploy the reviewed policy and IaC in a test scope; demonstrate both a compliant and a deliberately noncompliant fixture.
4. Preserve the reviewed change, observed configuration, policy results, runtime tests, and exception records in a single traceable release package.
5. Exercise stale results, an empty API response, missing permissions, an expired waiver, and an out-of-band change. Confirm each produces the intended alert or review gate.
6. Document acceptance criteria and operational handover before expanding to another service or control.

Use the existing FedRAMP compliance automation workflow guide for the broader control-to-evidence pattern. Apply service-specific runtime tests from the Foundry guides and Data Factory guides where those services are in scope.

Common cATO questions

Does Azure Policy provide cATO automatically?

No. It provides supported configuration checks and enforcement capabilities. cATO also requires the applicable authorization process, operational monitoring, evidence review, response capabilities, and accountable risk decisions.

Is cATO the same as continuous monitoring?

Continuous monitoring supplies observations. A continuous authorization approach also needs a process that uses those observations to evaluate changes, respond to deviations, and support authorization decisions under the program’s conditions.

Should we use Terraform or Bicep for Azure cATO?

Choose the tool your team can operate and review reliably. Both can version policy assignments and deployments. Terraform adds a state and dependency-lockfile workflow; Bicep compiles to ARM and uses Azure deployment/what-if operations. Both need runtime evidence.

Does a compliant policy result prove FedRAMP compliance?

No. Microsoft describes Azure Policy compliance as a partial view of overall compliance. Scope, inherited responsibilities, supported checks, manual evidence, and assessment decisions still matter.

Sources and technical review

Public documentation reviewed October 13, 2026. Recheck the applicable program requirements and the selected Azure cloud, API, and tool versions before implementation.

• Microsoft mapping of DoD cATO activities 3.5.1 and 3.5.2
• Azure Policy overview and supported evaluation modes
• FedRAMP shared responsibilities and the limits of Policy compliance
• Policy evaluation timing and compliance data

The examples illustrate an engineering workflow. No Azure deployment, provider authorization-package review, agency risk acceptance, or cATO approval was performed for this guide.