If you’ve opened Annex A of the standard and felt your eyes glaze over at a list of 93 controls, you’re not alone. ISO 27001 controls explained in plain terms is exactly what most IT managers and compliance officers need before they can even start scoping an ISMS, let alone pass an audit. The control set looks intimidating on paper, but once you understand how it’s organised, it becomes a practical checklist rather than a wall of jargon.
This article breaks down the four control themes introduced in the 2022 revision, organisational, people, physical, and technological, and explains what each control number actually requires you to do. You’ll see how the numbering works, why certain controls matter more for specific industries, and how they connect to your risk treatment plan rather than sitting as a standalone tick-box exercise.
We’ll also cover how to map controls to real business processes, what auditors typically scrutinise first, and where organisations without in-house security expertise tend to fall short. Whether you’re preparing for certification or reviewing an existing ISMS, this guide gives you the working knowledge to implement Annex A properly rather than guess your way through it.
Why ISO 27001 controls matter for your business
Annex A isn’t a bureaucratic hoop to jump through. Each control exists because someone, somewhere, got breached in a way that a specific safeguard would have prevented. When you get ISO 27001 controls explained properly, you start to see them as a distilled list of everything that commonly goes wrong in information security, mapped to a fix. Skip the controls and you’re not just risking a failed audit, you’re leaving real gaps that attackers actively look for.
Controls translate risk into action
Getting your risk assessment right is only half the job. The other half is doing something about the risks you’ve identified, and that’s precisely where Annex A earns its place. A risk register that says "unauthorised access to customer data" is a high risk means nothing until you attach a control like access management or multi-factor authentication to it. Controls give your risk treatment plan teeth. Without them, you end up with a lovely spreadsheet and no actual reduction in exposure.
Annex A controls turn a risk register from a list of worries into a working defence plan.
Certification opens doors that stay shut otherwise
Procurement teams at larger organisations increasingly ask for ISO 27001 certification before they’ll even shortlist a supplier. Insurers ask similar questions before underwriting cyber cover, and many now price premiums directly against how well you can demonstrate control maturity. If you’re an SMB competing for contracts against bigger firms, having a certified ISMS with properly implemented controls can be the difference between winning the tender and never hearing back.
What weak controls actually cost
Gaps in Annex A implementation rarely stay theoretical for long. The table below shows how missing controls translate into real business impact:
| Missing control area | Typical consequence |
|---|---|
| Access control (A.5.15-A.5.18) | Former employees or contractors retain system access, leading to data leaks |
| Backup (A.8.13) | Ransomware recovery takes days instead of hours, or fails entirely |
| Supplier relationships (A.5.19-A.5.22) | Third-party breach exposes your data with no contractual recourse |
| Awareness training (A.6.3) | Staff fall for phishing, giving attackers an easy way in |
| Logging and monitoring (A.8.15-A.8.16) | Incidents go undetected for weeks, increasing damage and cost |
However the breach happens, the pattern is the same: the control that would have stopped it, or caught it early, was either missing or half-implemented.
Boards and clients want proof, not promises
Insurers, loss adjusters, and clients dealing with a live incident don’t want to hear that you "take security seriously". They want evidence: logs, patch records, access reviews, incident response documentation. Annex A controls, when implemented properly, generate exactly that evidence as a by-product of doing the work correctly. That’s a big part of why services like CyberSOS incident response lean so heavily on whether an organisation already has these controls in place before an incident happens, because recovery is faster and cheaper when the groundwork exists.
Regulators are watching more closely too
Under UK GDPR, the Information Commissioner’s Office expects organisations to have "appropriate technical and organisational measures" in place, language that maps almost directly onto Annex A’s structure. You can read the ICO’s own guidance on security outcomes on the ICO website. Demonstrating a mature control set doesn’t just help with certification audits, it also gives you a defensible position if a regulator ever comes asking questions after an incident.
How to select and implement Annex A controls
You don’t implement all 93 controls blindly. ISO 27001 works on a risk basis, so your Statement of Applicability (SoA) is the document that records which controls apply to you, which don’t, and why. Get the SoA wrong and auditors will spot it immediately, because it’s usually the first document they ask for.
Start from the risk assessment, not the control list
Work backwards from your risk register rather than forwards from Annex A. Every risk you’ve identified as needing treatment should point to one or more controls that reduce it. If a control in Annex A doesn’t map to any risk on your register, you can mark it as not applicable, provided you can justify that decision in writing. This is the part most SMBs get backwards, they try to implement controls in numerical order instead of letting risk drive the selection.
Select controls because they address a specific risk, not because they appear on a checklist.
A practical selection and implementation sequence
Use a structured process so nothing gets missed and the audit trail holds up under scrutiny:
- Complete or update your risk assessment covering assets, threats, and vulnerabilities specific to your business.
- Cross-reference each risk against the relevant Annex A control or controls.
- Draft the Statement of Applicability, marking each control as applicable, partially applicable, or excluded, with justification.
- Assign an owner to each applicable control, someone accountable for its implementation and ongoing operation.
- Implement in priority order, starting with controls that address your highest-rated risks or that regulators and clients specifically ask about, such as access control and backup.
- Document evidence as you go, policies, logs, screenshots, configuration records, rather than retrofitting proof before an audit.
- Review annually, or after any significant change to systems, suppliers, or business processes.
Don’t implement in isolation
Controls rarely work alone. Multi-factor authentication (A.8.5) supports access control (A.5.15), which in turn depends on a working asset inventory (A.5.9) so you actually know what you’re protecting. Treat implementation as building a connected system, not ticking off 93 separate boxes. Organisations that skip the asset inventory step often find their access control policy is technically compliant on paper but meaningless in practice, because nobody can say with certainty which systems hold sensitive data in the first place.
What the four control themes cover in practice
Annex A groups its 93 controls into four themes, and understanding what each one actually covers saves you hours of confusion when you’re building your Statement of Applicability. Organisational controls set the policies and governance structure. People controls deal with staff behaviour and responsibilities. Physical controls cover premises and equipment. Technological controls handle the systems and data itself. Knowing which theme a control sits under tells you who in your organisation should own it.
| Theme | Control count | Example control | Typical owner |
|---|---|---|---|
| Organisational | 37 | A.5.19 Supplier relationships | Compliance officer |
| People | 8 | A.6.3 Awareness training | HR / IT Manager |
| Physical | 14 | A.7.4 Physical security monitoring | Facilities manager |
| Technological | 34 | A.8.16 Monitoring activities | IT/Security team |
Organisational and people controls work together
Governance means little without people who understand it. Organisational controls like A.5.1 (policies for information security) only work if A.6.3 (awareness training) actually gets staff to follow them. Policies written and forgotten in a shared drive don’t stop anyone clicking a phishing link. Pair every organisational control with the people control that makes it real, otherwise you’re documenting intent rather than practice.
A policy nobody’s read is not a control, it’s paperwork.
Physical and technological controls close the gaps
Physical controls stop someone walking into your server room; technological controls stop someone walking into your network remotely. Both matter equally. A locked comms cabinet (A.7.4) is worthless if remote access (A.8.5) has no multi-factor authentication behind it, and encrypted data (A.8.24) doesn’t help if backup tapes sit in an unlocked cupboard. Attackers don’t care which theme your weakness falls under, they just look for the easiest door in.
Why the balance across themes matters
Businesses often over-invest in one theme and neglect the rest. IT teams gravitate toward technological controls because they’re familiar territory, while physical and people controls get treated as afterthoughts. A mature ISMS spreads attention across all four, because a single missing control in any theme can undermine everything else you’ve built. Reviewing your Statement of Applicability theme by theme, rather than control by control, is a quick way to spot where your coverage is thin.
Common mistakes when applying ISO 27001 controls
Most organisations don’t fail ISO 27001 audits because they lack effort. They fail because they repeat the same handful of mistakes that undermine an otherwise solid ISMS. Recognising these patterns early saves months of rework and stops auditors flagging nonconformities that were entirely avoidable.
Treating the Statement of Applicability as paperwork
A common trap is writing the Statement of Applicability after the fact, just to satisfy an auditor’s checklist, rather than using it to drive real decisions. When the SoA doesn’t trace back to actual risks, auditors notice immediately, because the justifications sound generic rather than specific to your business. Another version of this mistake is marking controls "not applicable" without a documented reason, which is one of the fastest ways to trigger a nonconformity.
An SoA without risk-based justification is the first thing an auditor will pull apart.
Implementing controls without ownership
Controls left without a named owner tend to decay within months. Someone configures multi-factor authentication during the initial project, then nobody reviews access lists again until the next audit cycle exposes a dozen stale accounts. Assign a person, not a department, to each control, and build review dates into their calendar rather than relying on memory.
Confusing documentation with implementation
Writing a policy is not the same as following it. Plenty of businesses have a beautifully worded incident response policy that nobody has actually tested. Auditors increasingly ask for evidence of operation, not just evidence of existence, so a policy with no logs, no drill records, and no sign-off history won’t hold up under scrutiny.
Ignoring supplier and third-party risk
Organisations often lock down their own systems tightly while giving almost no scrutiny to suppliers who hold or process the same data. Supplier relationship controls (A.5.19 to A.5.22) get skipped because chasing third parties for evidence feels harder than fixing internal systems. That gap is exactly where breaches involving outsourced payroll, IT support, or cloud storage tend to originate.
Treating certification as a one-off project
Finally, many businesses pour resources into the initial certification push and then let the ISMS stagnate. Controls need continuous review as systems, staff, and threats change. An ISMS frozen at its certification date drifts out of alignment with reality within a year, and surveillance audits will expose that drift quickly.
Making Annex A work for your organisation
Getting ISO 27001 controls explained clearly is only the starting point. The real work is mapping those 93 controls to genuine risks, assigning owners who actually maintain them, and treating your Statement of Applicability as a living decision record rather than a filing exercise. Do that consistently and Annex A stops feeling like a compliance burden and starts functioning as what it actually is: a tested framework for stopping the incidents that put businesses out of action.
Most organisations don’t lack the will to implement these controls properly, they lack the in-house time and specialist knowledge to do it without missing something an auditor or an attacker will find later. That’s where getting outside expertise pays for itself, whether you need help building your first risk register or want a second opinion on an existing ISMS before your next surveillance audit. Talk to TrustedIA about getting your Annex A controls right the first time.
