Cloud Security Stack
Compliance and governance

Compliance

Mapping ISO 27001 controls to Microsoft Purview

Which Annex A controls Purview genuinely satisfies, which it only partly evidences, and the ones your auditor will still want to see you doing by hand.

15 min read · Reviewed 22 August 2026 · Written against ISO/IEC 27001:2022 Annex A and Microsoft's published Purview capabilities.

The mistake this guide exists to prevent

Buying Microsoft Purview does not make an organisation ISO 27001 certified, and no amount of licensing changes that. ISO 27001 certifies a management system: a documented scope, a risk assessment, a statement of applicability, internal audits and management review. Purview is a set of technical capabilities that can produce evidence for some of the controls inside that system.

The distinction matters because it decides where your effort goes. Organisations that treat Purview as the compliance project spend a year configuring labels and then fail the audit on documentation they never wrote.

How the 2022 revision changed the shape

ISO/IEC 27001:2022 reorganised Annex A from 114 controls into 93, grouped into four themes: organisational, people, physical and technological. Only the technological theme, and parts of the organisational one, are addressable by a tool at all. People and physical controls are not, whatever a vendor mapping document implies.

Where Purview genuinely helps
Purview coverage
A.5.12 Classification of information
A.5.13 Labelling of information
A.5.14 Information transfer
A.5.33 Protection of records
A.8.10 Information deletion
A.8.11 Data masking
A.8.12 Data leakage prevention
A.6.3 Security awareness and training
A.5.7 Threat intelligence
A.7.x Physical controls

Coverage means Purview can produce meaningful evidence for that control, not that configuring it satisfies the control on its own. Verify against your own statement of applicability.

The order to actually do this in

01

Write the scope and the statement of applicability first

Before touching a single label. The statement of applicability decides which controls apply to you, and configuring technology before you know that is how organisations end up with a beautifully labelled estate and a failed audit.

02

Run the data discovery, then design the taxonomy

Use content explorer to find out what you actually hold. Almost every taxonomy designed in a meeting before discovery has to be rebuilt afterwards.

03

Deploy labels in simulation before enforcement

Auto-labelling in simulation mode for at least a full business cycle. Enforcing a policy that has not been simulated is the fastest route to the business routing around your controls.

04

Build the evidence pipeline last

Decide what the auditor will be shown, how it is exported and who produces it on the day. An organisation that cannot produce evidence on demand does not benefit from having the control.

What you will still be doing manually

Risk assessment and treatment. Internal audit. Management review. Supplier assessments. Awareness training and its records. Incident post-mortems. Business continuity testing. None of these are tool problems, and all of them are audited.

Budget for this properly. In most first-time certifications the documentation and process work outweighs the technical configuration by a wide margin, and it is almost always the part that slips.

The verdict

Our pick

Use Purview for the technological controls, and only after the management system exists

It produces genuinely strong evidence for classification, labelling, DLP and records retention, which are otherwise painful to evidence manually.

Who should skip

Do not start here if you have no scope document, no risk assessment and no statement of applicability. Those come first, and no licence substitutes for them.

Disclosure. Some links on this site are affiliate links. Scoring weights are published before any programme is joined, and commission is never a ranking input. Full policy, and the method behind this guide.