ISO 27001:2022 · ANNEX A · 93 CONTROLS
ISO 27001 controls list: all 93 Annex A controls in four themes
The full Annex A control set from ISO/IEC 27001:2022, in one table you can read without buying the standard. Then the part nobody puts on a list page: which controls you actually have to implement, and how they get evidenced.
From $79/mo · Prices published · No sales call · Monthly billing
Audit readiness
0 %
Built for teams of 5 to 200
What the ISO 27001 controls are
ISO 27001 controls are the 93 information security controls listed in Annex A of ISO/IEC 27001:2022, grouped into four themes: 37 organizational controls (A.5.1 to A.5.37), 8 people controls (A.6.1 to A.6.8), 14 physical controls (A.7.1 to A.7.14) and 34 technological controls (A.8.1 to A.8.34). The 2013 edition listed 114 controls across 14 domains; the 2022 edition merged overlapping controls and added 11 genuinely new ones, which is why the number fell without the protection falling with it. The eleven additions are threat intelligence (A.5.7), information security for use of cloud services (A.5.23), ICT readiness for business continuity (A.5.30), physical security monitoring (A.7.4), configuration management (A.8.9), information deletion (A.8.10), data masking (A.8.11), data leakage prevention (A.8.12), monitoring activities (A.8.16), web filtering (A.8.23) and secure coding (A.8.28). The single most misunderstood point: you do not have to implement all 93. Annex A is a reference set you check your risk treatment against, not a mandatory checklist. You run a risk assessment, decide which controls apply, and record every include-or-exclude decision with its justification in your Statement of Applicability, which is the document the certification auditor reads first. Clauses 4 to 10 of the standard, the management system requirements, are the part that is genuinely mandatory. Amendment 1:2024 added climate change wording to clauses 4.1 and 4.2 and changed nothing in Annex A.
Complies assists with compliance workflows. It is not legal advice, and it does not certify you or guarantee audit outcomes. Your auditor decides; Complies gets you ready.
Last updated August 2026
Three things you do with the control list once you have it
Decide which controls apply
Annex A is a cross-check, not an order form. You assess risk, choose treatments, then walk the 93 controls to see whether you missed anything. Every control ends up either in scope with an owner or excluded with a written reason, and both of those decisions live in the Statement of Applicability. Auditors spend more time on the exclusions than on the inclusions, because a thin justification is the fastest way to a nonconformity.
control mapping softwareMap each control once, across every framework
A quarterly access review is A.5.18 here, SOC 2 CC6.2, GDPR Article 32, HIPAA 164.308(a)(4) and PCI DSS Requirement 7 elsewhere. Maintaining that work five times is how small teams lose whole quarters. Map the control once and let it count everywhere it applies, so the second framework costs a fraction of the first.
framework crosswalkAttach evidence to the control it proves
A control with no artifact behind it is an intention. Each control needs the thing that shows it operated: the review record, the config export, the signed acknowledgment, the ticket. Evidence that refreshes on a schedule beats evidence gathered in a panic the week the auditor arrives, and it is the difference between a clean Stage 2 and a list of findings.
automated evidence collectionThe four Annex A themes, and who ends up owning each
The 2022 restructure replaced 14 domains with four themes. That matters practically, because the themes map onto different people in a small company. Here is what each theme covers, how many controls it holds, and who typically ends up doing the work in a team of 5 to 200.
| Theme | Controls | What the theme covers | Who usually owns it |
|---|---|---|---|
| A.5 Organizational | 37 controls, A.5.1 to A.5.37 | Policies, roles, asset inventory, classification, access policy, supplier and cloud security, incident management, continuity, legal obligations | Whoever owns compliance, usually a founder, ops lead or the security-minded engineer |
| A.6 People | 8 controls, A.6.1 to A.6.8 | Screening, employment terms, awareness training, disciplinary process, post-employment duties, NDAs, remote working, event reporting | HR or the people ops function, with security setting the requirements |
| A.7 Physical | 14 controls, A.7.1 to A.7.14 | Perimeters, entry controls, secure areas, monitoring, environmental threats, clear desk, off-site assets, media, utilities, cabling, disposal | Office or facilities, and for a remote-first company mostly your data center or cloud provider |
| A.8 Technological | 34 controls, A.8.1 to A.8.34 | Endpoints, privileged access, authentication, malware, vulnerabilities, configuration, deletion, masking, DLP, backup, logging, monitoring, networks, cryptography, secure development, change management | Engineering and IT, which is why this theme is where implementation time actually goes |
A remote-first software company will find most of A.7 inherited from its cloud provider and its landlord, but inherited is not the same as ignored: you still record the decision and the justification behind it. If you are picking tooling to run this rather than just reading the list, compare the platforms on Vanta alternatives, Drata alternatives and Sprinto alternatives.
All 93 ISO 27001 Annex A controls, A.5.1 to A.8.34
Every control in ISO/IEC 27001:2022 Annex A, in order, with its theme and a plain description of what an auditor typically wants to see. Control titles follow ISO/IEC 27002:2022. The last column is our own wording, not the text of the standard, because reproducing ISO control text is a licensing matter and a paraphrase is more useful anyway. Controls introduced in the 2022 edition are marked.
| Control | Annex A control | Theme | What an auditor looks for |
|---|---|---|---|
| A.5.1 | Policies for information security | Organizational | An approved policy set, published to staff, reviewed at least annually |
| A.5.2 | Information security roles and responsibilities | Organizational | A named owner for each security responsibility, documented and communicated |
| A.5.3 | Segregation of duties | Organizational | Conflicting duties split so no one person can act and approve alone |
| A.5.4 | Management responsibilities | Organizational | Evidence leadership requires staff to apply the policies, not just publish them |
| A.5.5 | Contact with authorities | Organizational | A documented route to regulators and law enforcement before you need it |
| A.5.6 | Contact with special interest groups | Organizational | Membership or subscriptions that feed you security advisories |
| A.5.7 | Threat intelligence | Organizational | Threat feeds collected, analyzed and actually used in decisions. New in 2022 |
| A.5.8 | Information security in project management | Organizational | Security requirements raised at project kickoff, not at launch |
| A.5.9 | Inventory of information and other associated assets | Organizational | A maintained asset inventory with an owner against each entry |
| A.5.10 | Acceptable use of information and associated assets | Organizational | An acceptable use policy staff have acknowledged |
| A.5.11 | Return of assets | Organizational | Offboarding records showing laptops, tokens and data came back |
| A.5.12 | Classification of information | Organizational | A classification scheme applied to real data, not just written down |
| A.5.13 | Labelling of information | Organizational | Labels on documents and systems that match the classification scheme |
| A.5.14 | Information transfer | Organizational | Rules and controls for sending data by email, file share and physical media |
| A.5.15 | Access control | Organizational | An access control policy driven by business and security requirements |
| A.5.16 | Identity management | Organizational | One identity per person, managed across its full lifecycle |
| A.5.17 | Authentication information | Organizational | Password and secret handling rules, plus how credentials are issued |
| A.5.18 | Access rights | Organizational | Provisioning, review and revocation records, usually a quarterly access review |
| A.5.19 | Information security in supplier relationships | Organizational | A documented approach to supplier security risk |
| A.5.20 | Addressing information security within supplier agreements | Organizational | Security clauses in the contracts themselves |
| A.5.21 | Managing information security in the ICT supply chain | Organizational | Attention to sub-suppliers and components, not just your direct vendor |
| A.5.22 | Monitoring, review and change management of supplier services | Organizational | Evidence you re-check suppliers on a schedule and handle their changes |
| A.5.23 | Information security for use of cloud services | Organizational | Cloud acquisition, use and exit rules. New in 2022 |
| A.5.24 | Information security incident management planning and preparation | Organizational | An incident response plan with roles assigned before an incident |
| A.5.25 | Assessment and decision on information security events | Organizational | A triage step that decides which events become incidents |
| A.5.26 | Response to information security incidents | Organizational | Incident records showing the documented procedure was followed |
| A.5.27 | Learning from information security incidents | Organizational | Post-incident reviews that changed a control or a procedure |
| A.5.28 | Collection of evidence | Organizational | Procedures for identifying and preserving evidence that would survive scrutiny |
| A.5.29 | Information security during disruption | Organizational | Security maintained during an outage or crisis, not suspended |
| A.5.30 | ICT readiness for business continuity | Organizational | Tested recovery objectives for the systems the business depends on. New in 2022 |
| A.5.31 | Legal, statutory, regulatory and contractual requirements | Organizational | A register of the obligations you carry and who owns each |
| A.5.32 | Intellectual property rights | Organizational | License compliance and IP handling procedures |
| A.5.33 | Protection of records | Organizational | Retention, integrity and disposal rules for records |
| A.5.34 | Privacy and protection of PII | Organizational | Personal data handled per applicable privacy law, GDPR included |
| A.5.35 | Independent review of information security | Organizational | An independent review at planned intervals or after major change |
| A.5.36 | Compliance with policies, rules and standards for information security | Organizational | Checks that people follow the policy, with findings tracked to closure |
| A.5.37 | Documented operating procedures | Organizational | Runbooks for the operational tasks security depends on |
| A.6.1 | Screening | People | Background checks proportionate to the role, performed before access |
| A.6.2 | Terms and conditions of employment | People | Security responsibilities written into employment contracts |
| A.6.3 | Information security awareness, education and training | People | Training records showing who completed what, and when |
| A.6.4 | Disciplinary process | People | A defined, communicated process for security policy violations |
| A.6.5 | Responsibilities after termination or change of employment | People | Duties that survive departure, spelled out and acknowledged |
| A.6.6 | Confidentiality or non-disclosure agreements | People | Signed NDAs, reviewed for whether they still say what you need |
| A.6.7 | Remote working | People | Rules and controls for work done outside your premises |
| A.6.8 | Information security event reporting | People | A reporting channel staff know about and have actually used |
| A.7.1 | Physical security perimeters | Physical | Defined perimeters around areas holding information and systems |
| A.7.2 | Physical entry | Physical | Entry controls and visitor records for secure areas |
| A.7.3 | Securing offices, rooms and facilities | Physical | Physical security designed into the space itself |
| A.7.4 | Physical security monitoring | Physical | Continuous monitoring of premises for unauthorized access. New in 2022 |
| A.7.5 | Protecting against physical and environmental threats | Physical | Protection from fire, flood, power loss and similar hazards |
| A.7.6 | Working in secure areas | Physical | Rules for what people may do inside a secure area |
| A.7.7 | Clear desk and clear screen | Physical | An enforced clear desk and screen lock standard |
| A.7.8 | Equipment siting and protection | Physical | Equipment placed to reduce environmental and access risk |
| A.7.9 | Security of assets off-premises | Physical | Protection for laptops, phones and media outside the office |
| A.7.10 | Storage media | Physical | Lifecycle handling for removable media through to disposal |
| A.7.11 | Supporting utilities | Physical | Power, cooling and network resilience for critical facilities |
| A.7.12 | Cabling security | Physical | Power and data cabling protected from interception and damage |
| A.7.13 | Equipment maintenance | Physical | A maintenance schedule that keeps equipment available and intact |
| A.7.14 | Secure disposal or re-use of equipment | Physical | Wipe or destruction certificates before equipment leaves or is reused |
| A.8.1 | User endpoint devices | Technological | Managed laptops with disk encryption, screen lock and enforced patching |
| A.8.2 | Privileged access rights | Technological | Admin rights restricted, approved and reviewed separately |
| A.8.3 | Information access restriction | Technological | Access limited by the access control policy, enforced in the systems |
| A.8.4 | Access to source code | Technological | Repository permissions and read and write control over code |
| A.8.5 | Secure authentication | Technological | MFA and authentication strength matched to the risk |
| A.8.6 | Capacity management | Technological | Capacity monitored and forecast so availability holds |
| A.8.7 | Protection against malware | Technological | Malware protection deployed and supported by user awareness |
| A.8.8 | Management of technical vulnerabilities | Technological | Vulnerabilities found, prioritized and remediated inside a stated SLA |
| A.8.9 | Configuration management | Technological | Secure baselines defined, applied and monitored for drift. New in 2022 |
| A.8.10 | Information deletion | Technological | Data deleted when it is no longer required, provably. New in 2022 |
| A.8.11 | Data masking | Technological | Masking or pseudonymization where full data is not needed. New in 2022 |
| A.8.12 | Data leakage prevention | Technological | Measures against unauthorized extraction of sensitive data. New in 2022 |
| A.8.13 | Information backup | Technological | Backups taken on a schedule and, crucially, restore-tested |
| A.8.14 | Redundancy of information processing facilities | Technological | Redundancy sufficient for your stated availability requirements |
| A.8.15 | Logging | Technological | Logs produced, protected from tampering and retained |
| A.8.16 | Monitoring activities | Technological | Networks and systems monitored for anomalous behavior. New in 2022 |
| A.8.17 | Clock synchronization | Technological | Clocks synchronized to an approved time source so logs correlate |
| A.8.18 | Use of privileged utility programs | Technological | Utilities that can override controls restricted and logged |
| A.8.19 | Installation of software on operational systems | Technological | Controlled procedures for installing software in production |
| A.8.20 | Networks security | Technological | Networks managed and protected to defend the systems on them |
| A.8.21 | Security of network services | Technological | Security mechanisms and service levels identified for each network service |
| A.8.22 | Segregation of networks | Technological | Network segmentation between services, users and information groups |
| A.8.23 | Web filtering | Technological | Access to external websites managed to reduce malicious exposure. New in 2022 |
| A.8.24 | Use of cryptography | Technological | A cryptography policy, including key management through the full lifecycle |
| A.8.25 | Secure development life cycle | Technological | Security rules built into how software is developed |
| A.8.26 | Application security requirements | Technological | Security requirements identified and specified per application |
| A.8.27 | Secure system architecture and engineering principles | Technological | Secure engineering principles documented and applied to system work |
| A.8.28 | Secure coding | Technological | Secure coding standards applied in development. New in 2022 |
| A.8.29 | Security testing in development and acceptance | Technological | Security testing defined and run before release |
| A.8.30 | Outsourced development | Technological | Outsourced development directed, monitored and reviewed |
| A.8.31 | Separation of development, test and production environments | Technological | Environments genuinely separated, with production data controlled |
| A.8.32 | Change management | Technological | Changes to systems put through a documented change control procedure |
| A.8.33 | Test information | Technological | Test data selected, protected and managed, not a copy of production |
| A.8.34 | Protection of information systems during audit testing | Technological | Audit tests on operational systems planned and agreed to limit disruption |
Counts check out: 37 plus 8 plus 14 plus 34 is 93. If a source tells you there are 114 controls in 14 domains, it is describing ISO 27001:2013, which stopped being certifiable when the transition period closed on 31 October 2025. Amendment 1:2024 added climate change wording to clauses 4.1 and 4.2 in February 2024 and added no controls to Annex A at all, so any list claiming 94 or more controls is wrong.
What running the 93 controls actually takes
A Statement of Applicability that survives review
The SoA lists all 93 controls with an applicable-or-not decision, a justification, and the implementation status of each one. It is the document a certification auditor opens first, and a thin one predicts a difficult Stage 2. Generate it from the live control set rather than maintaining it as a separate spreadsheet, so it cannot quietly drift away from what you actually do.
Owners on controls, not on a policy document
A control with no name against it is nobody's job. Each applicable control needs a person, a frequency and a due date: A.5.18 access rights quarterly, A.6.3 awareness training annually, A.8.8 vulnerability management continuously. Most failed first audits are missed cadences, not missing intent.
Cross-mapping so the second framework is cheap
Annex A overlaps heavily with the SOC 2 Trust Services Criteria, GDPR Article 32, the HIPAA Security Rule and PCI DSS. Controls mapped once count everywhere they apply, which is the difference between adding a framework and starting a second program from scratch.
Evidence that refreshes on a schedule
Configuration reads from AWS, GitHub, Google Workspace and Okta land against the controls they prove, on a cadence, reading configuration rather than your customer data. A.8.9 configuration management, A.8.15 logging and A.5.18 access rights are all far easier to evidence continuously than to reconstruct.
A risk assessment the control choices trace back to
Annex A only makes sense downstream of risk. Every applicable control should trace to a risk you identified and a treatment you chose, and the auditor will follow that thread in both directions. A risk register with owners, treatments and review dates is what makes the SoA defensible instead of arbitrary.
A price you can read before you talk to anyone
Starter is $79 a month, Growth $199 and Scale $499 at the yearly rate, published on the pricing page. All five frameworks are cross-mapped from Growth up, so ISO 27001 and SOC 2 are one program rather than two quotes. Monthly billing is available, which means the tool re-earns its seat every cycle.
How to work through Annex A without a consultant
Scope the ISMS and run the risk assessment first
Decide what is in scope, then identify the risks to that scope and choose treatments. Controls come out of this step, not before it. Teams that start by copying all 93 controls into a spreadsheet end up with a control set they cannot justify and an auditor asking why.
Walk all 93 and record a decision on each
Go control by control and mark it applicable or not, with a reason. Physical controls often carry a cloud provider or landlord justification; data masking may not apply if you hold no data worth masking. Write the reason at the time, because reconstructing it six months later is guesswork.
Assign an owner, a frequency and evidence to every applicable control
Each in-scope control gets a person, a cadence and a named artifact that proves it ran. Connect AWS, GitHub, Google Workspace and Okta so the recurring technical evidence collects itself, and put calendar-driven reminders on the human ones like access reviews and policy approvals.
Close the gaps, then bring in the certification body
Work the ranked gap list until the readiness score stops moving, run an internal audit and a management review (clauses 9.2 and 9.3, both mandatory), then book Stage 1 and Stage 2 with an accredited certification body. The certification body is a separate company you pay separately, and it, not your software, decides the outcome.
Who this is for, and who it is not
A GOOD FIT WHEN
- You are working through Annex A for a first ISO 27001 certification and need the whole control set in one place.
- You are writing or rebuilding a Statement of Applicability and want the decisions generated from live controls rather than kept in a spreadsheet.
- You already hold SOC 2 and want to know how much of it counts toward ISO 27001.
- You are 5 to 200 people and nobody's full-time job is compliance.
- You want a published price and a signup form instead of a demo and a quote.
LOOK ELSEWHERE WHEN
- You need the official text of the controls. Buy ISO/IEC 27001:2022 and ISO/IEC 27002:2022 from ISO or your national standards body. This page describes the controls, it does not reproduce them.
- You want certification itself. Only an accredited certification body can certify you, and no software can promise that outcome.
- You need CMMC, FedRAMP or a NIST 800-53 profile. Complies does not ship any of those control sets.
- You run a multi-entity ISMS with a dedicated GRC team, where an enterprise suite earns its price.
Questions people ask about the ISO 27001 controls
ISO/IEC 27001:2022 Annex A contains 93 controls, split into 37 organizational, 8 people, 14 physical and 34 technological controls. The previous 2013 edition had 114 controls across 14 domains. The count fell because overlapping controls were merged, not because requirements were dropped, and 11 new controls were added at the same time.
The four themes are organizational controls (A.5), people controls (A.6), physical controls (A.7) and technological controls (A.8). They replaced the 14 domains used in the 2013 edition. The regrouping was structural rather than substantive: the same protection is present, organized by who does the work instead of by subject area.
No. Annex A is a reference set you check your risk treatment plan against, not a mandatory checklist. You implement the controls your risk assessment justifies and exclude the rest, recording a reason for every decision in your Statement of Applicability. What is mandatory is clauses 4 to 10 of the standard, the management system requirements themselves.
Threat intelligence (A.5.7), information security for use of cloud services (A.5.23), ICT readiness for business continuity (A.5.30), physical security monitoring (A.7.4), configuration management (A.8.9), information deletion (A.8.10), data masking (A.8.11), data leakage prevention (A.8.12), monitoring activities (A.8.16), web filtering (A.8.23) and secure coding (A.8.28). Most reflect cloud and detection practice that had become normal since 2013.
Clauses 4 to 10 are the mandatory management system requirements: context, leadership, planning, support, operation, performance evaluation and improvement. Annex A controls are the security measures you select to treat the risks you identified. You cannot be certified without the clauses. You can be certified while excluding many Annex A controls, provided you justify each exclusion.
The Statement of Applicability, or SoA, is the document that lists all 93 Annex A controls and records for each one whether it applies, why, and its implementation status. It is required by clause 6.1.3(d) and it is the first document most certification auditors read, because it is the map between your risk assessment and the controls they are about to test.
No. The transition period for ISO 27001:2013 certificates closed on 31 October 2025, so 2022 is the operative edition. If you find a controls list with 114 controls in 14 domains, it describes the withdrawn edition. Certificates issued against 2013 are no longer current and any new certification runs against the 2022 controls.
Amendment 1:2024, published in February 2024, added two pieces of climate change wording: clause 4.1 now requires you to determine whether climate change is a relevant issue, and clause 4.2 carries a note that interested parties can have climate-related requirements. It added no Annex A controls and created no new edition, and certification bodies check it at your next surveillance or recertification audit.
Substantially, which is why teams that hold one often pursue the other. Access control lines up (A.5.15 to A.5.18 against the SOC 2 CC6 series), as do change management (A.8.32 against CC8.1), vulnerability management, logging and monitoring (A.8.8, A.8.15, A.8.16 against CC7), incident response (A.5.24 to A.5.27 against CC7.3 to CC7.5), vendor management (A.5.19 to A.5.22 against CC9.2) and awareness training (A.6.3 against CC1.4). The gap is that ISO adds an explicit management system layer, and SOC 2 leaves control design entirely to you.
They describe the same 93 controls, at different depth. Annex A of ISO 27001 lists the control titles and is what your certificate is issued against. ISO/IEC 27002:2022 is the implementation guidance standard that explains each control at length with purpose, guidance and attributes. You get certified against 27001; you use 27002 to work out what to actually build.
For a company of 5 to 200 people starting from nothing, plan on three to nine months to implementation, then a certification audit split into Stage 1 and Stage 2. What drives the range is not the control count but how much already exists: teams with an SSO provider, managed laptops, a code review process and a backup routine are further along than they think. Teams holding SOC 2 already are usually much further along again.
No, and be suspicious of anything that says otherwise. Software can hold the control library, keep the Statement of Applicability in sync, chase owners on the recurring work, collect the technical evidence and show you the gaps. Someone still has to make the risk decisions, write the policies, run the training and fix the findings. The certification body then tests the result and decides, and no platform can commit to that outcome on your behalf.
Frameworks and guides
ISO 27001 compliance software
SOC 2SOC 2 compliance software
ISO 27001ISO 27001 Checklist: 13 Steps From Scope to Certification
CROSS-FRAMEWORKSOC 2 vs ISO 27001: Which One Do You Need? (Or Both)
ISO27001ISO 27001 Certification Cost: Full 2026 Breakdown
CROSSWALKControl Mapping: SOC 2, ISO 27001, HIPAA, PCI DSS
All 93 controls, mapped once, with owners and evidence
Prices published, $79 to $499 a month. Monthly billing. Start today, no sales call.