ISO 27001 Annex A contains 93 information security controls that organizations can use as a reference when determining how to treat information security risks.
But Annex A is often misunderstood.
The 93 controls are not a checklist that every organization must implement. They are not the entirety of ISO 27001. And implementing all 93 controls does not, by itself, mean an organization has implemented ISO 27001.
The controls are part of a larger risk-driven management system.
A better way to understand their role is:
Business requirements and risks → risk treatment → necessary controls → comparison with Annex A → Statement of Applicability → implementation → evidence → evaluation
That sequence matters.
ISO 27001 expects organizations to determine the controls they need based on their risks and requirements, then compare those controls with Annex A to make sure necessary controls have not been overlooked.
This guide explains how the 93 ISO 27001 controls fit into that process, how Annex A is structured, and what it means to actually implement a control.
What Are ISO 27001 Annex A Controls?
Annex A is the reference set of information security controls included in ISO/IEC 27001:2022.
There are 93 controls organized into four themes:
| Theme | Controls | Number of Controls |
|---|---|---|
| Organizational | A.5 | 37 |
| People | A.6 | 8 |
| Physical | A.7 | 14 |
| Technological | A.8 | 34 |
| Total | 93 |
These controls address a broad range of information security concerns.
Some deal with governance and organizational processes. Others address employees, physical environments, or technology.
Examples include areas such as:
- information security policies;
- roles and responsibilities;
- segregation of duties;
- threat intelligence;
- asset management;
- acceptable use;
- information classification;
- access control;
- identity management;
- supplier security;
- incident management;
- business continuity;
- legal and regulatory requirements;
- security awareness;
- physical security;
- endpoint devices;
- privileged access;
- authentication;
- malware protection;
- vulnerability management;
- configuration management;
- backups;
- logging and monitoring;
- network security;
- cryptography;
- secure development;
- change management.
The breadth of Annex A reflects an important principle: information security is not solely a technology problem.
An organization can have strong technical security and still experience serious information security failures because of poor governance, inadequate employee practices, weak supplier management, or physical security problems.
Are All 93 ISO 27001 Controls Mandatory?
No.
This is probably the single most important thing to understand about Annex A.
ISO 27001 does not require every organization to implement all 93 Annex A controls.
The organization’s control decisions should be driven by its information security risks, requirements, and chosen risk treatment.
The organization determines the controls necessary to implement its risk treatment decisions. It then compares those controls with Annex A to verify that necessary controls have not been inadvertently omitted.
That means the process should not begin with:
“Here are 93 controls. Which ones should we implement?”
It should begin with:
“What risks and requirements do we need to address, and what controls are necessary to address them?”
Annex A then provides an important reference point.
This is one reason ISO 27001 is fundamentally a risk-based management system rather than a fixed security checklist.
Our What Is ISO 27001? Requirements, Controls & Certification Explained guide provides a broader explanation of how Annex A fits into the standard.
How Control Selection Should Work
A practical control selection process starts before Annex A.
Suppose an organization identifies the following risk scenario:
Compromised administrator credentials could allow unauthorized access to production systems, resulting in customer data exposure and service disruption.
The organization evaluates that risk and determines that additional treatment is necessary.
It might determine that appropriate controls include:
- restricting privileged accounts;
- implementing multifactor authentication;
- periodically reviewing privileged access;
- logging administrative activity;
- monitoring suspicious activity;
- establishing procedures for granting and removing privileged access.
Those control decisions came from the risk.
The organization can then compare its necessary controls against Annex A and determine how the relevant Annex A reference controls relate to its treatment.
The sequence is:
Risk → treatment decision → necessary controls → Annex A comparison
Not:
Annex A control → implementation → find a risk to justify it
That difference may appear subtle, but it changes how an ISMS is designed.
One approach uses controls to manage organizational risk.
The other can turn ISO 27001 into a compliance checklist.
Can You Use Controls That Are Not in Annex A?
Yes.
Annex A is a reference set, not a limit on which controls an organization can use.
An organization may determine that it needs controls that are not explicitly represented in Annex A.
Those controls might come from:
- regulatory requirements;
- customer contracts;
- another security framework;
- industry standards;
- internal security requirements;
- technology-specific requirements;
- organizational risk treatment decisions.
For example, an organization might use controls from another framework because customers expect them or because they provide more detailed requirements for a particular technology environment.
The important question isn’t:
“Is this control in Annex A?”
It is:
“Is this control necessary for our organization?”
If the answer is yes, the control may be part of the ISMS regardless of where it originated.
The Four ISO 27001 Control Themes
The 2022 edition reorganized Annex A into four broad themes.
Understanding these themes makes the control set easier to navigate.
A.5 Organizational Controls
The 37 organizational controls cover many of the governance and management activities needed to support information security.
They address areas such as:
- information security policies;
- security roles and responsibilities;
- segregation of duties;
- management responsibilities;
- contact with authorities;
- threat intelligence;
- security in project management;
- information and asset management;
- acceptable use;
- information classification;
- information transfer;
- access control;
- identity management;
- authentication information;
- access rights;
- supplier relationships;
- cloud services;
- incident management;
- information security during disruption;
- legal, regulatory, and contractual requirements;
- privacy and protection of personally identifiable information;
- independent review;
- compliance with security policies;
- operating procedures.
These controls demonstrate why ISO 27001 cannot be delegated entirely to the IT department.
Many organizational controls require involvement from security, legal, procurement, HR, business leadership, risk management, and other functions.
A.6 People Controls
The 8 people controls address information security risks associated with employees and other personnel.
They cover areas including:
- screening;
- terms and conditions of employment;
- information security awareness, education, and training;
- disciplinary processes;
- responsibilities after termination or change of employment;
- confidentiality agreements;
- remote working;
- information security event reporting.
Technology alone cannot manage all information security risk.
People need to understand their responsibilities, know what is expected of them, and know how to respond when something goes wrong.
A.7 Physical Controls
The 14 physical controls address protection of physical locations, equipment, and information.
They include areas such as:
- physical security perimeters;
- physical entry;
- securing offices and facilities;
- physical security monitoring;
- environmental and physical threats;
- working in secure areas;
- clear desk and clear screen practices;
- equipment placement and protection;
- assets used off-premises;
- storage media;
- supporting utilities;
- cabling security;
- equipment maintenance;
- secure disposal or reuse of equipment.
Physical security can sometimes receive less attention in technology-focused security programs.
ISO 27001 treats it as part of the same information security system.
A server protected by sophisticated authentication controls can still be exposed if unauthorized people can physically access it.
A.8 Technological Controls
The 34 technological controls cover many of the technical safeguards commonly associated with cybersecurity.
They address areas including:
- endpoint devices;
- privileged access;
- access restrictions;
- source code access;
- secure authentication;
- capacity management;
- malware protection;
- vulnerability management;
- configuration management;
- information deletion;
- data masking;
- data leakage prevention;
- backups;
- redundancy;
- logging;
- monitoring;
- clock synchronization;
- privileged utility programs;
- software installation;
- network security;
- network services;
- network segregation;
- web filtering;
- cryptography;
- secure development;
- application security;
- secure architecture;
- secure coding;
- security testing;
- outsourced development;
- separation of development, test, and production environments;
- change management;
- test information;
- protection during audit testing.
These controls often involve security and IT teams, but governance still matters.
A vulnerability management tool, for example, doesn’t automatically create an effective vulnerability management control.
The organization still needs expectations for scanning, prioritization, remediation, exceptions, ownership, monitoring, and escalation.
A Control Is More Than a Control Title
One of the most useful distinctions when implementing Annex A is the difference between selecting a control and designing a control.
Suppose an organization determines that access reviews are necessary.
Writing:
“Access rights will be reviewed periodically.”
doesn’t provide enough information to operate the control consistently.
A useful control design should answer questions such as:
| Control Element | Question |
|---|---|
| Objective | What is the control intended to accomplish? |
| Scope | What systems, users, or processes does it cover? |
| Owner | Who is responsible for the control? |
| Activity | What actually happens? |
| Frequency | When or how often does it occur? |
| Evidence | What demonstrates that it happened? |
| Exceptions | What happens when a problem is identified? |
| Escalation | When does an issue require additional attention? |
For example:
Control objective: Prevent inappropriate continued access to sensitive systems.
Control activity: System owners review privileged user access quarterly and confirm whether each user’s access remains appropriate.
Evidence: Completed review record showing users reviewed, reviewer, date, decisions, identified exceptions, and resulting actions.
Exception handling: Access identified as inappropriate is removed or formally escalated according to the access management process.
Now the organization has something that can actually operate and be evaluated.
Control Design, Implementation, and Operation Are Different
Another useful distinction is between three different questions:
Is the control appropriately designed?
Does the control, if operated as intended, reasonably address the risk or requirement?
Has the control been implemented?
Has the organization actually put the control into place?
Is the control operating?
Is the control being performed as intended over time?
These are not the same assertion.
Consider quarterly access reviews.
A procedure might be well designed.
The organization might have assigned an owner and established a review process.
But if the reviews haven’t occurred for the last two quarters, the control isn’t operating as intended.
Similarly, a technical control might be deployed but incorrectly configured.
That is why simply marking a control as “implemented” can hide important information.
What Is Control Evidence?
Evidence helps demonstrate that a control is operating.
The appropriate evidence depends on the control.
Examples might include:
| Control | Possible Evidence |
|---|---|
| Access reviews | Completed review records and resulting actions |
| Security awareness | Training records and completion reports |
| Vulnerability management | Scan results, remediation records, exceptions |
| Supplier security | Assessments, approvals, risk decisions |
| Backups | Backup logs, monitoring records, restoration tests |
| Incident management | Incident records and investigation documentation |
| Change management | Change requests, approvals, testing records |
| User provisioning | Access requests and approvals |
| Logging | Log configuration and monitoring records |
| Physical access | Access records and review results |
Evidence should be a natural output of the process whenever possible.
If an organization waits until an audit to ask what evidence exists, that may reveal a larger problem.
The control may have been documented without sufficient thought about how its operation would be demonstrated.
What Is the Statement of Applicability?
The Statement of Applicability, commonly called the SoA, is one of the central documents connecting risk treatment to the ISO 27001 control environment.
The SoA identifies the controls the organization has determined are necessary, provides justification for their inclusion, indicates whether they are implemented, and provides justification for excluding Annex A reference controls.
This creates traceability between the organization’s risk decisions and its control environment.
A weak SoA might simply say:
A.5.X: Applicable
A more useful SoA helps explain why the control is necessary and how it relates to the organization.
For example:
Included because the organization relies on third-party service providers that can affect the confidentiality and availability of customer information.
That gives the reader information about the reason behind the control decision.
The SoA should not become an exercise in inventing generic justifications for 93 controls after implementation is already complete.
It should reflect the organization’s actual control determination process.
We’ll cover this in detail in our upcoming Statement of Applicability: A Practical ISO 27001 Guide.
What Does “Not Applicable” Mean?
Organizations sometimes become uncomfortable excluding Annex A controls because they assume certification requires implementing all 93.
It doesn’t.
An Annex A reference control may be excluded when the organization determines that it is not necessary.
The key is that the exclusion needs to be justifiable.
A decision should make sense in the context of the organization’s scope, risks, requirements, technology, and operating environment.
For example, a control addressing a particular type of development activity may not be necessary if the organization does not perform that activity within the relevant ISMS context.
But exclusions shouldn’t be used simply because a control is difficult or inconvenient to implement.
The question is whether the control is necessary, not whether the organization would prefer to avoid it.
Who Should Own ISO 27001 Controls?
Control ownership should reflect how the organization actually operates.
The security or GRC team does not need to own every control.
Different controls may naturally belong to different functions.
| Function | Examples of Potential Control Responsibilities |
|---|---|
| Information Security | Security monitoring, incident management, security governance |
| IT | Backups, configuration, identity administration, infrastructure controls |
| HR | Screening, employment lifecycle, awareness activities |
| Procurement | Supplier onboarding and contractual processes |
| Legal | Legal and contractual requirements |
| Facilities | Physical access and environmental safeguards |
| Engineering | Secure development and application security |
| Business Owners | Access approvals and risk decisions |
A GRC team may coordinate the control framework, monitor status, collect evidence, and support assurance activities without actually performing every control.
This distinction becomes increasingly important as an ISMS grows.
Central governance does not require centralized control ownership.
How Should ISO 27001 Controls Be Documented?
There is no need to create unnecessary documentation for the sake of documentation.
But an organization should be able to understand how important controls are expected to operate.
Depending on the environment, useful control documentation might include:
- control identifier;
- control objective;
- control description;
- control owner;
- frequency;
- systems or processes in scope;
- related risks;
- related requirements;
- evidence expectations;
- monitoring method;
- exception process;
- implementation status.
Some of this information may exist in policies or procedures.
Some may exist in a GRC platform or control register.
Some may be embedded directly into operational workflows.
The format matters less than whether people can understand and operate the control consistently.
How Do You Know Whether a Control Is Effective?
A control existing does not necessarily mean it is effective.
Control effectiveness asks whether the control is producing the intended result.
Suppose an organization performs quarterly access reviews exactly as documented.
Every quarter, the review identifies dozens of terminated employees who retained access long after leaving the company.
Technically, the review control may be operating.
But the results indicate a problem elsewhere in the access lifecycle.
An effective ISMS should recognize that pattern and ask:
Why isn’t access being removed promptly?
Is the termination process failing?
Is HR notifying IT consistently?
Are some systems excluded from automated deprovisioning?
Does ownership need to change?
Should additional controls be implemented?
This is where control monitoring becomes part of continual improvement.
The goal isn’t merely to prove that a control happened.
The goal is to understand whether the organization’s control environment is managing risk as intended.
Common Mistakes With ISO 27001 Controls
Treating Annex A as a Checklist
Starting with 93 controls and mechanically implementing them reverses the intended risk-driven process.
Start with context, requirements, and risk.
Assuming Every Control Is Mandatory
The organization determines necessary controls and justifies its decisions.
Not every organization needs exactly the same control environment.
Assuming Annex A Contains Every Possible Control
It doesn’t.
Organizations can determine that additional controls are necessary.
Confusing Policies With Controls
A policy may establish an expectation, but it doesn’t necessarily demonstrate that the expected activity occurs.
Assigning Every Control to Security
Many controls naturally belong to IT, HR, procurement, engineering, facilities, legal, and business teams.
Defining Controls Too Vaguely
Statements such as “access is periodically reviewed” leave important operational questions unanswered.
Who reviews it? What access? How frequently? What evidence is retained? What happens when inappropriate access is found?
Collecting Evidence Only Before an Audit
Evidence should normally result from operating the control.
Last-minute evidence collection often exposes controls that were documented but not consistently performed.
Measuring Implementation but Not Effectiveness
A control can exist and still fail to manage the intended risk.
Implementation is only one part of the question.
ISO 27001 Controls Frequently Asked Questions
How many controls are in ISO 27001:2022?
There are 93 reference controls in Annex A of ISO/IEC 27001:2022.
What are the four Annex A control themes?
The controls are organized into four themes: organizational, people, physical, and technological.
Do I need to implement all 93 ISO 27001 controls?
No. Organizations determine the controls necessary based on risk treatment and other requirements, then compare those controls against Annex A to make sure necessary controls have not been omitted.
Can I use controls that aren’t in Annex A?
Yes. Organizations can use additional controls from other frameworks, regulatory requirements, contractual requirements, internal standards, or other sources when necessary.
What is the difference between ISO 27001 and ISO 27002?
ISO 27001 defines requirements for an information security management system and includes the Annex A reference controls. ISO 27002 provides additional guidance related to information security controls.
What is the Statement of Applicability?
The Statement of Applicability documents the organization’s necessary controls, why they are included, whether they are implemented, and the justification for excluding Annex A reference controls.
Does implementing the 93 controls make you ISO 27001 compliant?
Not by itself. ISO 27001 includes management system requirements beyond Annex A, including context, leadership, planning, support, operation, performance evaluation, and improvement.
What is a control owner?
A control owner is the person or function responsible for ensuring that a control is appropriately managed. The exact responsibilities should be defined by the organization.
What is control evidence?
Control evidence is information demonstrating that a control has operated or that a particular security activity occurred. Examples include completed reviews, system records, approvals, logs, reports, assessments, and remediation records.
The Most Important Thing to Remember About Annex A
Annex A is extremely important to ISO 27001.
But Annex A is not ISO 27001.
The 93 controls exist within a larger information security management system.
The strongest control environments maintain a clear chain:
Risk and requirements → necessary controls → control design → ownership → operation → evidence → evaluation → improvement
When that chain is visible, Annex A becomes what it is intended to be: a powerful reference set for building an information security control environment appropriate to the organization.
When the chain is missing, Annex A can easily become just another compliance checklist.
If you’re building your broader management system, start with our What Is an ISMS? How an Information Security Management System Actually Works guide.
For the complete implementation sequence, see our ISO 27001 Implementation Guide: A Practical Roadmap for Building Your ISMS.
