ISO 27001 Annex A: from controls to concrete measures

ISO 27001 Annex A (2022 version) lists 93 controls across four themes: organisational, people, physical and technological. On paper it is a list of requirements. In practice, many of them translate into precise settings on your endpoints. The point is not to cover everything at once, but to match each technological control to a verifiable measure, and then keep the evidence. It is this concrete mapping we detail here, in a Microsoft 365 environment with Intune. The goal is to move from an abstract checklist to a set of settings you can point to, measure, and prove at any moment.

From controls to endpoint settings

Several technological Annex A controls have a direct translation on devices. Here are the most common mappings you will find in a Microsoft 365 environment with Intune.

• Protection against malware (A.8.7): Microsoft Defender with real-time and cloud protection.
• Management of technical vulnerabilities (A.8.8): OS and application updates enforced by policy.
• Encryption (A.8.24): BitLocker on Windows, FileVault on macOS, with key escrow.
• Authentication (A.8.5): MFA and Conditional Access for all access.
• Logging (A.8.15): collection of sign-in and administrative events.
• User endpoint devices (A.8.1): automatic lock, strong passcode, device compliance.

An end-to-end example: encryption

Take control A.8.24. It is not enough to write 'disks are encrypted' in a policy. In practice, you configure an Intune policy enforcing BitLocker on Windows, assign it to the relevant device groups, enable escrow of the recovery keys, then check the rate of devices actually encrypted. The evidence you show the auditor is not the sentence in the policy, but the compliance report showing the percentage of covered devices at a given date.

A second example: technical vulnerabilities

Control A.8.8 works the same way. You define an Intune update policy that imposes a maximum delay for applying security patches to the operating system and key applications, assign it to the right device groups, then monitor how many devices meet that window. The auditor does not want to hear that updates are 'managed'; they want to see the share of the estate patched within the defined delay, at a dated point in time. The same configure-assign-verify loop applies to almost every technological control, which is what makes the whole approach repeatable and, crucially, defensible in front of an auditor who probes beyond the paperwork.

Do not confuse policy with evidence

An ISO 27001 auditor is not satisfied with intent. They expect a documented policy, a technical implementation, and evidence that the measure is genuinely applied across the estate. A control marked 'covered' on a spreadsheet but missing from the Intune configuration will not pass. Consistency between the document and technical reality is the heart of the audit.

1. 1Write a short policy per domain (encryption, access, updates).
2. 2Translate it into Intune policies assigned to the right groups.
3. 3Check the actual device compliance rate.
4. 4Keep dated evidence for the audit.

Steering coverage

The hardest part is keeping the big picture: which controls are covered, partially covered, or missing. Without a map you work blind and discover the gaps at audit time, under pressure. A consolidated view, by contrast, lets you focus effort on the gaps that matter. It also turns compliance into a shared conversation: management sees a single coverage figure, while the technical team sees exactly which policy or assignment is responsible for a partial control.

A control is only truly covered once the policy is applied, assigned and verified across the estate.

Maintaining coverage over time

This logic also applies over time. An estate evolves: new devices, new users, temporary exceptions. A control judged compliant at certification can degrade silently if no one watches the actual compliance rate. Regular review is an integral part of the ISO 27001 approach, just as much as the initial setup. A dashboard that recomputes coverage continuously beats a one-off audit once a year.

Common mistakes to avoid

• Ticking a control on a spreadsheet without checking the matching Intune policy exists and applies.
• Confusing 'policy created' with 'policy assigned': a policy with no scope protects no device.
• Neglecting organisational and people controls, assuming technology alone earns certification.
• Forgetting to date the evidence, which makes it unusable on audit day.
• Letting temporary exceptions become permanent without review.

Prioritise high-impact controls

Not all controls deliver the same security gain for the same effort. Faced with a list of 93 controls, starting with those that most reduce the attack surface avoids spreading yourself thin and makes progress visible from the first weeks.

1. 1Tackle encryption and strong authentication first, high-impact and quick to deploy.
2. 2Move on to updates and anti-malware protection, which cover the most common threats.
3. 3Add logging, essential to detect and document an incident.
4. 4Finish with organisational controls, which require management involvement.

An organisation with a hundred devices starts from a 70% encryption rate. By assigning a BitLocker policy to the uncovered groups and enabling key escrow, it reaches 98% in two weeks. Control A.8.24 then moves from partial to covered, backed by a dated report. The same pattern, repeated control by control, turns an abstract list into a measurable trajectory that holds up in front of an auditor.

How AuPoint helps

AuPoint builds this mapping automatically: each deployed protection is linked to the relevant ISO 27001 controls, and the platform computes a coverage score per framework. You get a dated, exportable compliance report ready to show an auditor, without maintaining a spreadsheet by hand. You see at a glance what is covered, partial or missing, and prioritise with full knowledge of the facts. Because the mapping is recalculated from your real configuration, the report stays in step with the estate instead of drifting away from it.

Frequently asked questions

Is covering technical controls enough to be certified?

No. Certification remains a formal process that requires an information security management system, including organisational and people controls. Endpoint measures are an essential building block but replace neither governance nor the official audit.

How many Annex A controls concern endpoints?

There is no official figure, but a significant share of the technological controls has a direct translation on devices: encryption, anti-malware, updates, authentication, logging, endpoint configuration. That is often where the technical implementation effort is concentrated.

How often should the evidence be regenerated?

Ideally continuously, and at least before each audit or management review. A recent report, reflecting the current state of the estate, inspires far more confidence than a document several months old that may have drifted from reality.

Should controls deemed non-applicable be documented?

Yes. The ISO 27001 approach expects a statement of applicability that justifies, for each control, its inclusion or exclusion. A control that is set aside must be so knowingly, with a traceable justification, not through simple oversight.

Can a single setting cover several controls?

Often, yes. Disk encryption, for example, contributes to both data protection and endpoint security. Mapping your settings once, then linking them to every relevant control, avoids duplicating the evidence work.

Linking Annex A controls to verifiable Intune measures turns an abstract list into a concrete, steerable practice. With AuPoint, each protection is mapped to the relevant controls, and the platform generates a dated compliance report exportable to PDF, with a coverage score per framework. One caveat: this report documents your technical measures and does not replace a formal certification or legal advice.