ISO 27001 on Azure: Annex A controls, mapped and evidenced

What ISO 27001 actually requires of an architecture

Clauses 4 to 10 define the management system: scope, risk methodology, objectives, competence, internal audit, management review, corrective action. That half is documentation and governance, and it is not ours to write.

Annex A is the other half. The 2022 revision restructured it into 93 controls across four themes: 37 organizational, 8 people, 14 physical, 34 technological. Your statement of applicability declares which apply, and the certification body samples against it. Physical controls for the data center are Microsoft’s under the shared responsibility model. The technological theme is almost entirely yours, and it is architecture.

The controls that decide a cloud stage 2 audit are consistent:

A.5.15 to A.5.18 and A.8.2 to A.8.5, the access control family: identity lifecycle, privileged access, information access restriction, secure authentication.
A.8.9 configuration management, new as a named control in 2022. The auditor asks for your configuration baseline and for how you detect deviation from it.
A.8.15 logging and A.8.16 monitoring activities, the second also new. Logging without monitoring is a half-implemented control and gets recorded as such.
A.8.20 network security and A.8.22 segregation of networks. Topology is what a technical auditor examines first, because it is hard to fake.
A.8.24 use of cryptography. Note the wording: a policy on the use of cryptography, naming algorithms, key lengths and key lifetimes. Encryption being switched on is not the control.
A.8.10 information deletion and A.8.11 data masking, both new, and the weakest area in most cloud estates: non-production environments holding a copy of production data nobody can delete on request.
A.8.32 change management and A.8.28 secure coding, which the pipeline answers or does not.
A.5.23 information security for use of cloud services, which is a question about how subscriptions are provisioned, governed and eventually withdrawn.
A.5.30 ICT readiness for business continuity, tested rather than asserted.

What we design and enforce in Azure

A policy initiative shaped by your statement of applicability. We do not deploy a generic baseline and call it compliance. Each applicable control that has a technical expression gets an Azure Policy assignment at the management group level, and each assignment is annotated with the control reference so the mapping survives staff turnover.

Identity as the access control family. Microsoft Entra ID with Conditional Access, Privileged Identity Management so privileged rights are activated rather than held, scheduled access reviews producing dated records, and workload identities with federated credentials instead of long-lived secrets.

Infrastructure as code as the configuration baseline. Terraform or Bicep in a repository with branch protection and required reviewers. The baseline is the repository, deviation is detectable by a scheduled drift check, and A.8.9 and A.8.32 stop being narrative. This is the same foundation described on the Azure landing zone page.

Segmentation that maps to A.8.20 and A.8.22. Hub-and-spoke, Azure Firewall or an NVA, network security groups with a documented rationale, private endpoints on data services, and private DNS zones. The diagram is the evidence.

Logging and monitoring as two controls, not one. Diagnostic settings to Log Analytics with a stated retention, Microsoft Sentinel analytics rules and an on-call path for A.8.16, Microsoft Defender for Cloud for vulnerability management under A.8.8, and threat intelligence feeding detections for A.5.7.

A cryptographic policy, written and enforced. Key Vault or Managed HSM, named algorithms and key lifetimes, rotation schedules, and Azure Policy denying resources that do not use the keys the policy names.

Deletion and masking, taken seriously. Storage lifecycle rules, retention set per data category, de-identified datasets for non-production, and a tested deletion path. A.8.10 is where we find the most surprises, and where most remediation time is actually spent.

Continuity that has been tested. Backup policies as code, recovery objectives written down, restore tests scheduled and recorded, and failover runbooks that somebody has executed.

What the evidence pipeline produces

Your statement of applicability with a column per control naming the Azure assignment that implements it and the query that evidences it.
Azure Policy compliance state per assignment, exportable per control reference.
Defender for Cloud regulatory compliance assessment for the ISO 27001 initiative, tracked across the surveillance cycle rather than captured the week before the audit.
Access review outcomes, PIM activation history and Conditional Access reporting.
Pull request and deployment history as the change management record under A.8.32.
Vulnerability findings with remediation dates against your stated service levels.
Restore and failover test records for A.5.30 and A.8.13.
Drift alerts and their resolution, which feed clause 10 corrective action records with real content instead of invented ones.

What you keep

The statement of applicability to Azure mapping, maintained as a file in your repository rather than a spreadsheet on somebody’s laptop.
The policy initiative as code, annotated with control references.
A written cryptographic policy and the key lifecycle it describes.
The evidence query pack and the runbook naming who runs which export.
Continuity test records and a schedule that continues after we leave.
A risk register aligned to your clause 6.1 methodology, including the risks you accepted and why.

Who this is for

Organizations whose European or enterprise customer made the certificate a contract condition. Companies already certified on an on-premise scope whose surveillance audit now reaches into Azure. Teams that moved to the 2022 revision and have not yet addressed the controls it added. Firms holding SOC 2 who want the second framework without paying for a second build.

Who this is not for

If you want the ISMS documentation written, we are the wrong firm: we do the architecture half, and you need a lead auditor or an ISMS consultant for the management system. If you want a certificate in eight weeks, the stage 1 and stage 2 sequence does not compress that far. And if nobody is actually asking for ISO 27001, check whether SOC 2 satisfies the customer first, because it usually costs less to reach.

Compliance architecture, the engagement that delivers this.
SOC 2 on Azure, the overlapping control set.
GDPR and HDS, where ISO 27001 is a prerequisite rather than an option.
Azure landing zone, where the policy initiative is enforced.
Compliance, the pillar.

Questions we get

Are you ISO 27001 certified?

No, and we will not imply otherwise. Our security architecture is led by certified security architects and we build to the standard, but Entrazure does not hold an ISO 27001 certificate. Ask any vendor claiming one for the certificate number and the accredited body that issued it.

Can you certify us?

No. Certificates are issued by certification bodies accredited for the scheme, after a stage 1 documentation review and a stage 2 implementation audit. We build the system they audit. A firm that both remediates and certifies is not offering you an independent certificate.

Do we need ISO 27001 or SOC 2?

Ask the customer who is blocking the deal. European and enterprise procurement usually names ISO 27001. North American enterprise security teams usually name SOC 2. The underlying Azure work overlaps heavily, so the second one is mostly mapping and evidence rather than new engineering.

How much of the standard is architecture?

Annex A of the 2022 revision has 93 controls across four themes. The 34 technological controls are almost entirely architecture, and a good share of the 37 organizational controls need architectural evidence. The management system clauses, scope, risk method, internal audit and management review, are not ours to write.

What did the 2022 revision change for a cloud estate?

It named things that were previously implied. Configuration management, monitoring activities, information deletion, data masking, data leakage prevention, secure coding, threat intelligence and information security for use of cloud services all became explicit controls. Infrastructure as code answers configuration management better than any document can.

We are already certified. Why revisit the Azure estate?

Because certificates are scoped, and cloud estates drift. The common pattern is a certificate written when the estate was on-premise, a surveillance audit that now asks about Azure, and no policy set behind the answer. Fixing that before the surveillance visit is cheaper than a nonconformity.

Have a question about this work?

Three fields. An architect reads it and answers within one business day.