ISO 27001 Annex A: All 93 Controls Explained

The Purpose of Annex A

Annex A serves a specific role in ISO 27001:

• It connects your risk assessment to concrete protective actions
• It ensures coverage across organisational, people, physical, and technological layers
• It provides an internationally recognised baseline of information security controls
• It gives auditors a consistent reference to test effectiveness and completeness

For SMEs, the practical value is that you don’t need to invent your own control framework. Annex A provides the catalogue; your job is to select, justify, implement, and maintain the controls that align with your risks.

How Annex A Connects to The Rest of ISO 27001

The Clauses define the mandatory requirements for implementing the ISMS (the governance, framework and guidelines necessary). The controls are more like the tuning controls on a mix console – the things you set the right levels for your business, and in some circumstances turn off altogether (if I’m not stretching the metaphor).

If you’re working through ISO 27001 in order, Annex A comes after Clause 6, not before. Trying to start with the controls is one of the most common implementation mistakes I see.

I emphasise to my clients the importance of ensuring that their controls align with their risk assessment.

So, for example, if in your risk assessment you talk about the importance of controlling GDPR data and the huge risk to your business, and then when you get to the ISO controls around PII, and you put in place something very basic, it won’t make sense to the auditor, who will say, “Over here you have assessed the risk on this as high, and on the controls, you’ve barely implemented anything. Why?”

How Annex A Is Organised

Annex A is split into four groups: Organisational, People, Physical and Technological. Each has a clear focus.

The four-theme structure makes implementation easier to manage and to delegate across a business. The themes/families map roughly to who in the organisation will own each family of controls: governance teams (e.g. your information security group) own Organisational, HR owns People, Facilities owns Physical, and IT/security owns Technological.

In a small business where the same one or two people own it all, the themes still help by separating control types, so you can tackle them in manageable chunks rather than as one undifferentiated list of 93. Certainly, when I’ve approached them, I’ve tended to do it in families, to make it easier to address them without having to do all 93 at once.

You’ll also note clusters of controls within families that share a similar theme, such as incident management or development controls. Again, you can utilise these to make it easier to deal with ‘bite-sized’ groups of controls, rather than doing it all at once.

Annex A and the Statement of Applicability

In a small section of the ISO 27001 standard, the requirement is laid out for creating a “Statement of Applicability”, listing the controls in Annex A, the justification for their inclusion or exclusion, and whether they are implemented.

This undersells the amount of effort required in my book. It’s a huge task for most organisations, but in effect, the Statement of Applicability (SoA) is a required document listing:

To be fair, the standard does not actually ask you to explain how you’ve implemented the control, but rather whether you have. This is a mistake in my book: if you’ve decided it should be included, it must be implemented, and I also think that describing how you’ve implemented the control is important (at a high level).

The SoA is the single most scrutinised document in an ISO 27001 audit (they can spend days on it). It must align with your risk assessment – every included control should trace back to a risk it treats, and every excluded control should trace to either a risk that doesn’t exist for your scope or an alternative control that treats the same risk.

I’ve written more about the SoA and how to go about it below.

Learn more about how to complete the Statement of Applicability →

How to Actually Use Annex A

Annex A is not a checklist you have to work through in order. The real flow looks like this:

How to Approach Annex A Controls: Minimal Viable Compliance

The single biggest mistake I see in SME ISO 27001 implementations is over-engineering both the selection of unnecessary controls and then over-responding to controls. Teams read an Annex A control, decide it sounds serious, and reach for an enterprise-grade tool or a 20-page policy. Six months later, they haven’t finished, they’re exhausted, the ISMS feels heavy, and half the controls aren’t actually being followed because they’re too complex to operate day-to-day.

The standard doesn’t ask for any of that. ISO 27001 is risk-based, and Annex A controls are meant to be implemented proportionately to your risks, your scope, and your size.

A 12-person software company doesn’t need the same control implementation as a 5,000-person bank.

The principle I work with clients on is “Minimal Viable Compliance”, which means meeting the intent of the control, keeping evidence that you’ve done it, and not adding complexity that the risk doesn’t justify. Simple now, improve later as risks and the business scale.

What MVC looks like in practice

Take control 8.2 “Privileged Access Rights” as an example. The control says: “The allocation and use of privileged access rights shall be restricted and managed.” That single sentence can drive an SME to consider buying a Privileged Access Management (PAM) platform costing tens of thousands of pounds a year.

It doesn’t have to.

The intent of the control is straightforward:

• Restrict who has powerful accounts (admin, root, super-user)
• Make sure approvals are in place before those accounts are issued
• Keep oversight on how they’re used

Here’s what an MVC implementation of a control like A.8.2 looks like for a small business:

1. Identify – list all privileged accounts in a spreadsheet
2. Assign responsibility – one named person owns the list
3. Approval – manager sign-off before granting privileged access, ideally after the user has completed appropriate training
4. Limit use – staff use normal accounts day-to-day; admin accounts only when required
5. Log usage – capture admin account activity where the platform supports it
6. Review – check the list every six or twelve months and remove anyone who no longer needs access

The evidence pack for audit is correspondingly simple: a spreadsheet or ticket history showing approvals, a short Access Control policy of a few paragraphs, and a record of the last review (an email, a meeting note, or a sign-off).

The control is met. The intent is satisfied. There’s evidence to show the auditor. No PAM platform required!

What MVC isn’t

MVC isn’t an excuse to do nothing or take shortcuts. There are three traps to avoid:

The MVC mindset

Every Annex A control can be approached this way. Read the control. Understand the intent. Ask what the smallest implementation would be that genuinely meets the intent and produces evidence. Build that. Then improve it over time as risks change, and the business grows.

For the SMEs I work with, this is usually the difference between an ISMS that’s certifiable in 90 days and one that’s still in flux at month nine. Heavy implementations rarely fail audit; they fail the business by being too cumbersome to maintain. My MVC approach keeps the ISMS proportionate to the organisation it’s protecting.

ISO 27002 and How It Relates to Annex A

If you haven’t met ISO 27002, now’s the time to get familiar with it, because it’s important to 27001.

ISO 27002 is the companion standard to ISO 27001. While Annex A of ISO 27001 lists the control titles and a brief statement of intent, ISO 27002 provides detailed implementation guidance for each control.

When you select a control from Annex A (for example, A.5.23 – Information Security for Use of Cloud Services), ISO 27002 tells you what good looks like for that control: the intent, recommended steps, and verification points.

Do you NEED 27002? No. Is it a good idea? Yes. Without it, you might misinterpret a control’s intent or scratch your head about what it actually means. 27002 can remove that ambiguity, but (and I stress this) it’s not gospel “you must do this..” rules, it’s recommendations and considerations.

I’ve written about each and every control in my guidance, so if money is short, start there. If you want more info on ISO 27002, check out my guide here.

Read more on ISO 27002 →