ISO 27001 Annex A is the reference set of 93 information security controls in ISO/IEC 27001:2022. Organisations use it to check that their risk treatment has not missed necessary controls across organisational, people, physical, and technological themes.
It is not only for technical teams, and it is not a checklist that every organisation implements in the same way.
Annex A covers how an organisation governs security, manages people, protects physical environments, and uses technology. Many of the decisions behind those controls belong to business leaders, even when specialists carry out the work.
For a business leader, the important question is not “How do we complete Annex A?”
It is “Which controls are necessary for our risks and requirements, who owns them, and how will we know they are working?”
What is ISO 27001 Annex A?
Annex A is the reference control set included in ISO/IEC 27001:2022.
It contains 93 controls grouped into four themes:
| Theme | Number of controls | What it broadly covers |
|---|---|---|
| Organisational | 37 | Governance, policies, suppliers, incidents, continuity, legal requirements, and operating responsibilities |
| People | 8 | Screening, employment responsibilities, awareness, remote working, and reporting security events |
| Physical | 14 | Premises, equipment, secure areas, environmental protection, and physical access |
| Technological | 34 | Identity, access, encryption, backups, logging, networks, development, configuration, and technical resilience |
The official ISO overview of ISO/IEC 27001 describes the standard as a framework for establishing, implementing, maintaining, and continually improving an information security management system, or ISMS.
Annex A supports that management system. It is not the whole standard.
What Annex A is not
Annex A is not:
- A complete security programme by itself.
- A list that every organisation implements without question.
- A technical configuration manual.
- Proof that a control is operating effectively.
- A shortcut to ISO 27001 certification.
- A replacement for risk assessment and risk treatment.
This distinction matters because teams sometimes begin with all 93 controls and try to mark each one complete.
That reverses the logic.
An organisation should understand its context, scope, risks, and requirements, determine the controls needed to treat those risks, and then compare those controls with Annex A so that necessary controls have not been overlooked.
Why business leaders should care about Annex A
Most Annex A controls require more than a tool setting.
They require decisions about:
- Risk appetite.
- Business priorities.
- Roles and accountability.
- Budget and resources.
- Supplier expectations.
- Acceptable exceptions.
- Legal and contractual obligations.
- How security performance is reviewed.
For example, an IT administrator can enable multi-factor authentication. Leadership still needs to decide which systems are in scope, whether exceptions are allowed, who approves them, and what happens when a business-critical supplier cannot meet the requirement.
That is why Annex A is a management topic as well as a security topic.
How Annex A connects to business risk
The controls make more sense when they are connected to a risk.
Consider this risk:
An unauthorised person gains privileged access to a customer-facing system, leading to data exposure or service disruption.
Relevant treatment may include:
- Strong identity and authentication controls.
- Privileged access restrictions.
- Access approval and removal processes.
- Logging and monitoring.
- Periodic access reviews.
- Incident response procedures.
Annex A helps the organisation check whether its chosen treatment covers the control areas that matter.
The control decision should then be recorded and connected to an owner, policy, operating process, and evidence.
See How to Link Security Risks to Controls, Policies, and Evidence for the full traceability chain.
What is the Statement of Applicability?
The Statement of Applicability, usually called the SoA, records the organisation’s control decisions.
It should make clear:
- Which Annex A controls are applicable.
- Which controls are not applicable.
- Why each decision is justified.
- Whether applicable controls are implemented.
- Where relevant policies, processes, or control references can be found.
The SoA is not a scorecard where more applicable controls automatically means better security.
Its purpose is to make control decisions clear and defensible.
An applicable control can still have an implementation gap. A control should not be marked not applicable merely because it is difficult, expensive, or unfinished.
For a deeper explanation, read What Control Applicability Really Means in ISO 27001.
The four ISO 27001 Annex A control themes in plain English
Organisational controls
These controls define how security is directed and managed.
Business leaders should ask:
- Are security responsibilities clear?
- Do policies reflect how the company actually operates?
- Are supplier and cloud-service risks understood?
- Can the organisation manage and learn from incidents?
- Are legal, regulatory, and contractual requirements tracked?
- Is security included in projects and change decisions?
These are governance questions before they are documentation questions.
People controls
People controls address responsibilities before, during, and after employment or engagement.
Leaders should ask:
- Are security expectations clear during onboarding?
- Is training relevant to people’s roles?
- Are confidentiality and acceptable-use responsibilities understood?
- Is there a reliable joiner, mover, and leaver process?
- Can people report suspected security events without confusion?
The aim is not to treat employees as the problem. It is to give people clear responsibilities and workable processes.
Physical controls
Physical controls protect locations, equipment, and information from unauthorised access, damage, or interference.
Even cloud-first and remote companies should consider:
- Home-working environments.
- Company laptops and removable equipment.
- Secure disposal.
- Visitor access.
- Office or shared-workspace arrangements.
- Environmental and utility dependencies.
The exact controls depend on the ISMS scope and operating model.
Technological controls
Technological controls cover the systems and configurations many people associate with cybersecurity.
They include areas such as:
- Identity and access management.
- Authentication.
- Malware protection.
- Vulnerability management.
- Backups.
- Logging and monitoring.
- Network security.
- Secure development.
- Change and configuration management.
- Data deletion and masking.
Leadership does not need to configure every control. It does need confidence that responsibilities, priorities, exceptions, and evidence are clear.
What decisions should leadership make?
A practical leadership review of Annex A should answer six questions.
1. What is in scope?
Define the products, services, teams, locations, systems, suppliers, and information covered by the ISMS.
Without a clear scope, control decisions become inconsistent.
2. What risks and requirements matter?
Consider business risks alongside legal, regulatory, contractual, and customer requirements.
3. Which controls are necessary?
Determine controls through risk treatment, then compare that set with Annex A.
4. Who is accountable?
Each control needs one accountable owner, even when several teams contribute.
See ISO 27001 Control Ownership: How to Assign Accountability Without Confusion.
5. What does implementation mean?
Agree how the organisation will distinguish planned, partially implemented, implemented, operating, and verified controls.
6. How will progress and effectiveness be reviewed?
Use evidence, monitoring, testing, internal audit, management review, incidents, and corrective actions to understand whether the ISMS is working.
A simple Annex A example for a growing business
Imagine a growing software company that:
- Stores customer information in cloud services.
- Uses remote employees and contractors.
- Depends on several important suppliers.
- Develops a customer-facing application.
- Receives customer security questionnaires.
Its Annex A work may identify priorities around access control, secure development, logging, supplier security, incident response, backups, employee responsibilities, and business continuity.
The company still needs to decide:
- Which specific risks each control treats.
- How the control fits existing workflows.
- Who owns it.
- What policies and procedures support it.
- What evidence is produced.
- Which gaps need a roadmap.
Annex A gives structure. The organisation must provide the context and implementation.
What Annex A does not prove
Selecting a control does not prove it is implemented.
Writing a policy does not prove people follow it.
Collecting one screenshot does not prove a control operates consistently.
And completing an internal control list does not mean the organisation is certified.
ISO 27001 certification, when pursued, assesses the ISMS against the standard through an independent certification process. Annex A is one important part of that wider system.
Where Aneo Framework Pro fits
Aneo Framework Pro helps small and growing businesses work through questionnaire-based framework and control decisions, then generate tailored, editable security policy drafts and supporting readiness documents.
It provides a structured starting point for ISO 27001 work without treating Annex A as a generic template library.
The outputs still require human review, approval, implementation, and evidence. Framework Pro does not certify an organisation, complete control implementation, replace legal advice, or replace auditor judgement.
Quick FAQ
How many controls are in ISO 27001 Annex A?
ISO/IEC 27001:2022 Annex A contains 93 controls grouped into organisational, people, physical, and technological themes.
Does every Annex A control have to be implemented?
No. An organisation determines the controls necessary for its risks and requirements, compares them with Annex A, and justifies applicability decisions in the Statement of Applicability. A difficult or unfinished control cannot be excluded only for convenience.
Is Annex A the same as ISO 27001?
No. ISO 27001 defines requirements for an information security management system. Annex A is the standard’s reference set of information security controls.
What is the difference between ISO 27001 and ISO 27002?
ISO 27001 contains certifiable ISMS requirements and the Annex A reference controls. ISO 27002 provides more detailed guidance for information security controls, but it is not itself a certifiable management-system standard.
Is Annex A only for IT teams?
No. Annex A includes governance, people, physical, supplier, legal, continuity, incident, and technological controls. Many decisions require leadership and cross-functional ownership.
Does completing Annex A mean a company is ISO 27001 certified?
No. Control selection and implementation are parts of a wider ISMS. Certification requires an independent assessment of the management system against ISO/IEC 27001 requirements.
Final thought
Annex A is easier to understand when leaders stop treating it as a technical checklist.
It is a reference set that helps an organisation test the completeness of its risk treatment decisions.
Start with business context and risk. Determine the controls you need. Compare them with Annex A. Assign accountable owners. Implement the controls in real workflows. Keep evidence. Review whether the system is working.
That is the business value behind the list of 93 controls.