Policy attestations, recording manual evidence in Azure

Regulated businesses often blend automated and manual controls. Automated checks are easy to verify. Manual controls, such as a quarterly access review or a signed incident response procedure, are harder to track. Azure Policy Attestations fill this gap by letting you record evidence, choose a compliance state, and set an expiry so your team reconfirms on schedule. Attestations are first‑class resources that sit alongside your policy assignments and show up in your compliance views.

Why attest

Frameworks such as System and Organisation Controls 2 (SOC 2), International Organisation for Standardisation 27001 (ISO 27001) and the Health Insurance Portability and Accountability Act (HIPAA) all require manual controls. These might include approving a runbook, training staff or reviewing a third-party certificate. Azure has a policy effect called manual that marks a control as needing a human decision. You then create an attestation which sets the state of that manual control to Compliant, NonCompliant or Unknown, and you can attach evidence and an expiry date. Use this when the platform cannot prove the control automatically. Typical examples include an incident response runbook approval, a quarterly privileged access review or confirmation that staff have completed training

How attestations relate to policy assignments and compliance state.

An attestation is a separate resource under the provider Microsoft.PolicyInsights. It links to the specific policy assignment that represents your manual control. If you assigned an initiative, you can optionally point to a single member definition by supplying the policyDefinitionReferenceId.

Attestations set the compliance state for the targeted resource or scope. You choose Compliant, NonCompliant or Unknown. You can also set expiresOn to a date when the attested state should lapse so the default state applies again. This keeps stale approvals out of your reports.

Because attestations are their own resource they have their own lifecycle. You can create, read, update and delete them through the API, CLI or PowerShell. Removing the related assignment removes the attestation automatically.Attestations are not the same as the Microsoft Azure Attestation service, which is for attesting trusted computing modules in confidential computing. That service has its own built-in policies and uses a different resource type. When we talk about policy attestations here, we are referring to the Microsoft.PolicyInsights/attestations resource that records a manual compliance decision.ations exist and when to use them

Creating and updating attestations, API, CLI, PowerShell

You can also use Azure CLI or PowerShell. Azure CLI offers `az policy attestation create`, `update`, `show`, `list` and `delete`. PowerShell provides New-AzPolicyAttestation, Set-AzPolicyAttestation and Get-AzPolicyAttestation. These tools let you script attestation creation and updates, so you can integrate them with deployment pipelines.

Below is an example using the Azure CLI to create an attestation at resource group scope for a manual policy inside an i

# Variables

SUB_ID="00000000-0000-0000-0000-000000000000"

RG="rg-app1"

ATT_NAME="q4-access-review-2025"

ASSIGNMENT_ID="/subscriptions/$SUB_ID/providers/Microsoft.Authorization/policyAssignments/pa-manual-access-reviews"

DEF_REF_ID="access-review-policy-ref"

# Create the attestation

az policy attestation create \

--resource-group "$RG" \

--attestation-name "$ATT_NAME" \

--policy-assignment "$ASSIGNMENT_ID" \

--definition-reference-id "$DEF_REF_ID" \

--compliance-state Compliant \

--assessment-date 2025-12-31T00:00:00Z \

--evidence source-uri=https://contoso.sharepoint.com/sites/GRC/Docs/Access-Review-Q4.pdf description="Signed Q4 access review" \

--expires-on 2026-03-31T00:00:00Z \

Linking evidence and expiry, keeping audits tidy

Evidence is a simple list of items, each with a description and a sourceUri. Link to a durable, access-controlled location, for example a private SharePoint library or a storage account with appropriate permissions. Use assessmentDate to record when the evidence was checked, owner to capture responsibility, and expiresOn to force a re-attestation before your next audit window.

A tidy approach helps. Use a consistent naming scheme for attestation names, include the control identifier and period, and tag metadata with fields like department or system name.

Governance tips for large estates and initiatives

Design manual policies to target the right boundary. If teams own resource groups, assign manual policies at the resource group level so you only need one attestation per team rather than per resource. If the process is subscription‑wide, assign the policy at subscription scope. This keeps the number of attestations manageable.

For initiatives, use the policyDefinitionReferenceId property in your attestation to point at a single member control. That keeps evidence focused and avoids claiming compliance for the whole initiative.

Operationally, keep an inventory. List attestations at subscription or resource group scope and filter by PolicyAssignmentId when you report quarterly. Both CLI and REST APIs support filters and paging.

Fallback: when a control cannot be met, use a Policy Exemption instead of creating a misleading Compliant attestation. Exemptions mark resources as Exempt with optional expiry and a reason like Waiver or Mitigated. They remain auditable and are safer than claiming compliance without evidence.

Next steps

1. Identify two or three manual controls that are high value for audits. Draft manual policy definitions and assign at the correct scope.

2. Create a secure evidence library and a naming pattern.

3. Pilot with az policy attestation create. Include owner, assessmentDate, and a sensible expiresOn date.

4. Build a simple report using az policy attestation list with a filter on PolicyAssignmentId. Export results into your audit pack.

5. Read our GRC explainer, then book a Policy as Code review if you want help designing manual policies that scale. Internal links: /blog/grc-and-azure-policy and /services/policy-as-code-review.

Glossary

API stands for Application Programming Interface. It is a set of rules that allow programs to communicate.

ARM means Azure Resource Manager, the deployment and management service in Azure.

CLI is the Command Line Interface, a text based tool for managing Azure resources.

RBAC stands for Role‑Based Access Control, Azure's way of granting permissions to users and services.