Azure ships built-in ISO/IEC 27001 initiative definitions that map many technical controls to policy definitions, but they are a baseline, not a finish line. Treat them as a starting point: map your required controls to the initiative, find the gaps, close them with custom policies or manual evidence, and test everything through policy-as-code before you enforce it.
TL;DR:
- Use the Controls tab to separate Microsoft, customer, and shared responsibilities, but treat compliant results as policy evaluations, not certification or complete audit coverage.
- Map each required ISO control to MCSB IDs, flag uncovered controls, then add custom policies for technical gaps and dated manual evidence for process gaps.
- Assign policies in a nonproduction scope with enforcement disabled, validate results through Azure Resource Graph or the Azure Policy SDK, then enable enforcement gradually.
- Prioritize identity, cryptography, and logging when resources are limited, and retain versioned policy files, assignment snapshots, remediation logs, and dated exports for audits.
Table of Contents
- Where to find the initiative and how the Controls tab works
- Who owns each control: Microsoft, you, or both
- What to do when built-in policies don’t cover a control
- Operationalizing the mapping with policy-as-code
- A checklist for assessing resources and preparing evidence
- Where I’d spend limited time
- Turn your mapping into a budgeted ISO 27001 plan
- FAQ
Where to find the initiative and how the Controls tab works
Start in Azure Policy, under Definitions, and filter by the Regulatory Compliance category. The ISO/IEC 27001 initiative is a built-in set of policy definitions grouped into controls and compliance domains. Microsoft publishes the built-in initiative list along with a GitHub commit history, so watch the Azure Policy repository for changes and note which initiative version you assigned.
Once assigned, Regulatory Compliance initiatives add a Controls tab to the compliance view. It shows each control’s compliance state, its ownership, and the policy definitions that feed it. Drilling in gives you three views:
- Overview: the control’s state and ownership summary.
- Policies: the list of policy definitions contributing to that control.
- Resource compliance: a per-resource view showing which resources pass or fail.
Read the state carefully. Azure Policy’s “Compliant” status reflects the evaluation of the underlying policy definitions, not an ISO 27001 certification, so use these dashboards to assess technical implementation rather than as a final audit report.
Who owns each control: Microsoft, you, or both
The Controls tab shows ownership information for controls. Use it as a starting point for identifying which evidence you may need to gather.
- Microsoft-responsible controls usually rest on third-party attestations. Pull the details from Azure’s ISO/IEC 27001 compliance offering and file them in your evidence pack.
- Customer-responsible controls need evidence from your own environment: configurations, logs, procedures, and records.
- Shared controls need both, so document the split.
The mapping is not one-to-one. Several policy definitions can feed one ISO control, and one policy can support several controls. The Azure Government ISO 27001 sample cautions that the mappings are partial: some controls are manual or disabled, and “Compliant” does not imply full coverage.
Azure’s own guidance is blunt: Azure Policy dashboards give only a partial view of ISO 27001 status, so internal audits must still cover non-technical controls. Plan for that from day one rather than discovering it during the audit.
For a deeper look at splitting duties, see our guide to ISO 27001 shared responsibility and Annex A mappings.
What to do when built-in policies don’t cover a control
Gaps are normal. Typical ones include non-technical controls such as HR screening and physical security, controls the Microsoft Cloud Security Benchmark (MCSB) doesn’t address, and controls that depend on environment-specific parameters. A gap analysis, like the one in this compliance gap analysis walkthrough, keeps the work orderly.
Follow this sequence, based on the Cloud Adoption Framework’s control-mapping guidance:
- Map each required ISO control to MCSB control IDs.
- Mark every control that MCSB or the initiative leaves uncovered.
- For technical gaps, write custom policy definitions or add them to a custom initiative.
- For process gaps, document manual evidence: policies, training records, review minutes.
- Record the decision per control so the reasoning survives staff turnover.
Practical mitigations include Guest Configuration policies for settings inside virtual machines, policies that validate backup retention, and dated process evidence for procedures and training.
Pro Tip: Give every manual-evidence control a named owner and a review date in your register, so an auditor sees a live process rather than a one-time upload.
Our article on types of evidence for ISO 27001 audits shows what auditors typically accept.
Operationalizing the mapping with policy-as-code
Policy-as-code turns your mapping into something repeatable and reviewable. Microsoft’s workflow guidance recommends a file structure of policy-v#.json, policyset-v#.json, and parameters files, all kept in version control so every change has a pull request and an author.
An assignment comes down to a few fields:
- policyDefinitionId: the definition or initiative being assigned.
- scope: the management group, subscription, or resource group.
- enforcementMode: whether the policy actually blocks or modifies resources.
- parameters: values specific to the environment, which the compliance offering page warns must be set correctly.
- resourceSelectors and exemptions: narrowing the rollout and recording approved exceptions.
Test in a non-production scope first with enforcementMode disabled. Validate results with the Azure Policy SDK or Azure Resource Graph queries, run remediation tasks, then enable enforcement progressively, moving to production only after validation. The commit history, assignment snapshots, and remediation logs double as audit evidence.
A checklist for assessing resources and preparing evidence
Work through these steps in order, and keep each output:
- Inventory your ISO controls and map each to initiative controls and MCSB IDs.
- Export the initiative definitions you assigned.
- Save assignment parameter snapshots for every scope.
- Export resource compliance results at a fixed date.
- Keep remediation task logs and exemption records.
- Link manual evidence to each customer-responsible control.
| Evidence item | Where it comes from | Control owner |
|---|---|---|
| Initiative definition export | Azure Policy Definitions | Customer |
| Assignment parameter snapshot | Azure Policy Assignments | Customer |
| Resource compliance export | Compliance, Resource compliance tab | Customer |
| Third-party audit report | Azure compliance offering | Microsoft |
Mapping data per control is easier when you structure it like this data-mapping approach: one record per item, with a source and an owner.
Where I’d spend limited time
If time or budget is tight, start with the controls tied to the highest business risk: identity, cryptography, and logging. A clean compliance percentage across low-risk controls impresses nobody if administrator access is loose. Use Azure Policy to enforce and monitor, but never let it stand in for organizational processes or the manual evidence they produce. And keep versioned policy files and assignment snapshots as a deliberate part of your evidence pack, because an auditor asking “what was assigned in March?” deserves a quick, dated answer.
— Martin
Turn your mapping into a budgeted ISO 27001 plan
Once your mapping shows the gaps, the next question is what closing them will cost and how long it will take. Our ISO 27001 Cost Calculator can help you explore costs based on your company size, industry, and security maturity.
If you want a quick snapshot first, take our free check. For a structured ISO 27001 readiness assessment, use our ISO 27001 Readiness Assessment. Both can help you assess your ISO 27001 readiness and planning needs.
FAQ
Does a “Compliant” status in Azure Policy mean we are ISO 27001 certified?
No. “Compliant” means the underlying policy definitions evaluated as passing, not that your organization is certified. Microsoft states this directly, so treat the dashboard as a technical assessment tool.
Do the built-in initiatives cover every ISO 27001 control?
No. Many controls need a mix of automated policies and manual evidence, and some controls are manual or disabled in the initiative. Plan to write custom policies or document process evidence where the built-ins stop.
How should we test a new policy initiative safely?
Assign it in a non-production scope with enforcementMode disabled, then validate results with Azure Resource Graph queries or the Azure Policy SDK. After remediation looks right, enable enforcement step by step.
Who provides evidence for Microsoft-responsible controls?
Microsoft does, through its audit reports and compliance documentation for Azure. You still need your own evidence for customer-responsible and shared controls.