"ISO controls" almost always means the Annex A controls in ISO/IEC 27001, the reference list of safeguards your Information Security Management System draws from, with implementation detail spelled out in ISO/IEC 27002. The current version contains 93 controls across four themes: Organizational (37), People (8), Physical (14), and Technological (34).
TL;DR:
- Less than half of the 93 controls are organizational and technological; most effort is focused on policies, governance, and system protections.
- The 2022 revision reduced controls from 114 to 93, introducing new areas like cloud security, threat intelligence, and data masking.
- Proper control selection relies on a thorough risk assessment, with detailed evidence and justified exclusions documented in the Statement of Applicability.
- Controls are mapped to frameworks like NIST CSF using attributes, but manual evidence collection remains time-consuming without automation tools.
- Implementing all controls is unnecessary; selection should be based on actual risks, with regular updates and ownership to maintain audit readiness and operational effectiveness.
Table of Contents
- What Are ISO Controls in an ISMS?
- How Are the 93 Annex A Controls Organized?
- What Changed in the ISO 27001:2026 Revision?
- Annex A vs. ISO 27002: What's the Difference?
- How Do You Select Annex A Controls and Build a Statement of Applicability?
- How Do You Map Annex A Controls to NIST CSF and Other Frameworks?
- Why Implement ISO Controls in an ISMS?
- How Does Risk Assessment Drive Control Selection?
- What Are Common Pitfalls in ISO 27001 Implementation?
- How Are ISO Controls Applied Across Industries?
- What Practitioners Get Wrong About Annex A
- Where Automation Fits Into Annex A Maintenance
- Sources
- FAQ
What Are ISO Controls in an ISMS?
Annex A works as a reference portfolio, not a mandatory checklist. Once you finish a risk assessment, you turn to Annex A to see which of the 93 controls address the risks you found, then document your choices in the Statement of Applicability (SoA).
Clauses 4 through 10 of ISO/IEC 27001 are the normative backbone of your ISMS. They dictate the requirements you must meet: leadership commitment, planning, operational processes, performance evaluation, and continual improvement. Annex A, by contrast, is informative. It offers 93 candidate controls, but nothing forces you to implement all of them.
Auditors know this distinction well, and they test it directly. They expect to see a clear line from your risk assessment through your risk treatment decisions to the specific controls you selected, and they expect the SoA to tell that story. A company that copies the entire Annex A list into its SoA without justification raises a red flag faster than one that excludes several controls with solid, documented reasoning. The ISO/IEC 27001:2022 standard treats risk based selection as the whole point of Annex A, not an afterthought.
How Are the 93 Annex A Controls Organized?
Annex A groups its 93 controls into four themes, and the distribution tells you something about where security work actually concentrates. Organizational controls make up the largest group at 37, covering policy, governance, supplier relationships, and incident management. Technological controls come in close behind at 34, covering the tools and configurations that protect systems and data. People controls, at just 8, and Physical controls, at 14, round out the set.
Here's what typically falls under each theme:
- Organizational (37): information security policies, roles and responsibilities, supplier security, incident management, business continuity
- People (8): screening, terms of employment, security awareness training, disciplinary process
- Physical (14): secure areas, equipment siting, clear desk and clear screen, physical entry controls
- Technological (34): access control, cryptography, logging and monitoring, network security, secure coding
| Theme | Control range (Annex A numbering) | Number of controls |
|---|---|---|
| Organizational | A.5.1 to A.5.37 | 37 |
| People | A.6.1 to A.6.8 | 8 |
| Physical | A.7.1 to A.7.8 | 14 |
| Technological | A.8.1 to A.8.34 | 34 |
Notice that Technological and Organizational controls together account for 71 of the 93 total, which is why most ISMS implementation effort lands on policy work and technical safeguards rather than physical security or personnel measures.
What Changed in the ISO 27001:2026 Revision?
The 2022 revision consolidated the previous 114 controls down to 93, folding overlapping items together and cutting anything that had grown outdated. The rationale was relevance: security teams in 2026 face cloud infrastructure, remote workforces, and threat actors that the 2013 version of the standard never anticipated.
Eleven controls are genuinely new, and they signal where ISO expects organizations to invest attention now:
- Threat intelligence
- Information security for use of cloud services
- ICT readiness for business continuity
- Physical security monitoring
- Configuration management
- Information deletion
- Data masking
- Data leakage prevention
- Monitoring activities
- Web filtering
- Secure coding
Alongside the new controls, ISO introduced control attributes: purpose, security concept, operational capability, and security domain. Each of the 93 controls now carries these tags, which sounds like a minor administrative detail until you try to filter 93 controls by function. Tag a control by operational capability (say, "detection") and you can pull every relevant control in seconds instead of reading through the whole annex.
Annex A vs. ISO 27002: What's the Difference?
Annex A is the list. ISO/IEC 27002 is the manual. Annex A tells you what the 93 controls are; ISO 27002 tells you how to actually implement each one, complete with purpose statements, implementation guidance, and other supporting notes.
Certification bodies audit you against ISO/IEC 27001, not ISO/IEC 27002. You cannot get "ISO 27002 certified," because 27002 isn't a management system standard, it's a companion reference. Where this matters practically: when you select control A.8.12 (data leakage prevention) for your SoA, ISO 27002 gives you the operational detail, sample approaches, and things to consider that turn a one-line control name into something your team can actually build. Skip 27002 and you're implementing controls from a title alone, which is how organizations end up with a checkbox that doesn't hold up to audit scrutiny.
How Do You Select Annex A Controls and Build a Statement of Applicability?
Building a defensible SoA follows a repeatable sequence, and skipping steps is exactly where audits go wrong.
- Define your ISMS scope. Know which systems, locations, and business units the certification covers.
- Run the risk assessment. Identify assets, threats, and vulnerabilities, then score likelihood and impact.
- Choose risk treatment options. Decide whether to mitigate, transfer, avoid, or accept each identified risk.
- Map treatments to Annex A controls. For each risk you're mitigating, select the specific control (or controls) that address it.
- Document everything in the SoA. For all 93 controls, record whether it's applicable, whether it's implemented, and your justification either way.
A defensible SoA doesn't just say "excluded." It states why, tied back to actual risk evidence. Language like "Control A.7.4 is excluded because the organization operates no physical server rooms; all infrastructure is cloud hosted" gives an auditor something to verify. "Not applicable" with no explanation gives them nothing, and auditors reject exactly that pattern more than almost any other SoA weakness.
Pro Tip: Assign one named owner to the SoA document itself, separate from control owners. When ownership is split across a dozen people, exclusions quietly go undocumented and nobody notices until the audit.
The most common audit failure isn't a missing control. It's a control marked "implemented" with no supporting evidence attached, or an exclusion with no risk assessment behind it. Fix both by treating evidence collection as part of control selection, not a separate task you do later.
How Do You Map Annex A Controls to NIST CSF and Other Frameworks?
Control attributes exist for exactly this problem: mapping ISO controls to other frameworks without redoing your risk analysis from scratch. Two examples make the pattern concrete. Annex A's threat intelligence control (A.5.7) maps naturally to the NIST CSF 2.0 "Identify" function, since both are about understanding your threat landscape before you act on it. Annex A's monitoring activities control (A.8.16) lines up with NIST CSF's "Detect" function, since both describe ongoing visibility into anomalous behavior.
The efficient approach is mapping by security function and control attribute rather than chasing one-to-one name matches between frameworks that were never designed to align perfectly. Tag your controls by operational capability, then group by the NIST function that capability supports.
This is exactly where GRC teams start feeling the weight of manual work. Filtering 93 controls by attribute across multiple frameworks, then pulling evidence for each one, then updating the SoA when scope changes, adds up to hours of repetitive effort every quarter. A tool built for control library management and repeatable evidence retrieval turns that recurring task into something closer to a lookup.
Why Implement ISO Controls in an ISMS?
The purpose of Annex A isn't compliance for its own sake. It's giving your organization a structured, risk based way to decide what to protect and how, instead of reinventing security decisions from scratch every time a new system comes online.
The benefits show up in three places. First, consistency: once controls are documented in your SoA, new hires and new projects inherit a known baseline instead of ad hoc judgment calls. Second, stakeholder trust: certification to ISO/IEC 27001 signals to customers, auditors, and partners that your security decisions follow a documented, externally verified process rather than internal assurances alone. Third, defensibility: when an incident happens, having a documented control rationale means you can show what you did and why, rather than reconstructing your security posture after the fact.
None of this works if the ISMS becomes paperwork detached from actual operations. The controls you select need to reflect real risks to real systems, reviewed on a cadence, not written once during a certification push and never revisited. Organizations that treat the SoA as a living document, updated whenever scope or risk changes, get more operational value out of certification than those that treat it as a one-time deliverable for the auditor.
That operational value compounds over time. A well maintained control set becomes the reference point for vendor due diligence, security questionnaires, and internal audits alike, cutting down the redundant work of explaining your security posture from scratch to every new counterparty.
How Does Risk Assessment Drive Control Selection?
Risk assessment comes before control selection, always, and the order matters more than it sounds. You cannot pick meaningful Annex A controls until you know what you're protecting against.
The process typically runs through four stages. First, asset identification: catalog what you're protecting, whether that's customer data, source code, or infrastructure. Second, threat and vulnerability identification: for each asset, identify what could go wrong and where weaknesses exist. Third, risk scoring: rate each identified risk by likelihood and impact, usually on a simple scale that lets you rank risks against each other. Fourth, risk treatment: decide, for each risk above your acceptance threshold, whether to mitigate it with a control, transfer it (insurance, contractual terms), avoid it (don't build the risky thing), or formally accept it.
Only after this sequence do you open Annex A and start mapping. A risk assessment that identifies "unauthorized access to customer databases" as a high priority risk points you toward specific technological controls, access control and cryptography among them, rather than a vague sense that "we should probably do something about security."
Prioritization follows naturally from the scoring. Controls addressing your highest scored risks get implemented first; controls addressing low probability, low impact risks might get documented in the SoA as accepted risk rather than actively mitigated. This is where organizations often overcorrect, either treating every risk as critical (which burns resources on low value controls) or underscoring genuine risks to avoid implementation work. Neither serves the ISMS well, and both tend to surface during audit review when the risk register doesn't match the SoA's stated priorities.
What Are Common Pitfalls in ISO 27001 Implementation?
The single most common mistake is treating Annex A as a mandatory checklist rather than a reference set. Teams implement all 93 controls regardless of relevance, burning budget on physical security controls for a fully remote company, then wonder why the ISMS feels disconnected from actual risk.
A second pitfall is inconsistent evidence. Controls get marked "implemented" in the SoA without a clear evidence trail behind them, which auditors flag as a documentation gap even when the control genuinely exists in practice. The fix is straightforward: every implemented control needs a designated evidence artifact, whether that's a policy document, a system configuration screenshot, or a log export, refreshed on a schedule rather than gathered once for certification.
A third pitfall is unclear ownership. When no single person owns a given control, or the SoA itself, updates lag behind actual changes in the environment. New cloud services get adopted without anyone reassessing the cloud security control; staff turnover happens without anyone updating the screening control's evidence. Copla's implementation guidance points to the same root cause across most audit findings: exclusions and gaps that trace back to nobody being clearly accountable.
The best practice that addresses all three: assign named owners per control, require evidence refresh dates, and review the SoA at fixed intervals rather than only before recertification. Smaller organizations often resist this structure as bureaucratic overhead, but the alternative, an SoA nobody maintains between audits, is worse.
How Are ISO Controls Applied Across Industries?
A SaaS company's Annex A priorities look different from a manufacturing firm's, even though both draw from the same 93 controls. For a cloud software vendor, Technological and Organizational controls dominate: encryption, access management, supplier security for the cloud infrastructure they run on, and incident response procedures customers will ask about directly in security questionnaires.
A financial services firm handling regulated customer data typically leans harder into data protection controls, information deletion, data masking, and access control, partly because GDPR and similar regulations create overlapping obligations. Mapping ISO controls to GDPR articles is common practice here: encryption and access control support GDPR's data protection requirements, while information deletion controls support the "right to erasure."
A manufacturing company with physical facilities and industrial control systems weights Physical controls more heavily than a remote-first software company ever would, alongside Technological controls covering the operational technology network. Equipment siting, secure areas, and physical entry controls carry real operational weight when a compromised facility means production downtime, not just a data breach.
The common thread across all three: the risk assessment, not the industry template, decides which of the 93 controls matter most. A software company that skips physical controls entirely because "we're cloud based" still needs to justify that exclusion in the SoA with evidence, not assumption.
What Practitioners Get Wrong About Annex A
The friction we see most often isn't technical. It's organizational. Teams treat all 93 controls as mandatory, evidence sits scattered across a dozen tools with no single owner, and nobody revisits the SoA until the next audit forces the issue.
The fix is almost always structural, not procedural: name one SoA owner, build a minimal control library with reusable evidence templates, and use automation to pull evidence rather than chasing it manually every quarter. We've covered several of these implementation patterns in more depth on the Skypher blog, including how control-based compliance management actually works day to day.
— Gaspard
Where Automation Fits Into Annex A Maintenance
Selecting Annex A controls and keeping the SoA current is manual work by design, at least until you're managing 93 controls across multiple products, customers asking for evidence in security questionnaires, and a risk register that shifts every quarter. Skypher approaches this from the evidence side rather than the certification side: instead of replacing your risk assessment process, it automates the repetitive parts that eat analyst time.
The AI powered recommendation engine suggests responses and supporting evidence when a security questionnaire asks about a specific control, drawing from your existing documentation instead of forcing someone to rewrite the same access control explanation for the fortieth vendor review. Import and export workflows pull evidence from wherever it already lives, Confluence, SharePoint, Google Drive, so control owners aren't hunting across five systems every time an auditor or prospect asks for proof. And a customizable Trust Center lets you publish your SoA-backed security posture directly to customers, cutting the back and forth that usually follows a sales team's promise to "send over our security documentation."
None of this replaces your ISMS. It removes the busywork around maintaining one. If your team is spending more hours formatting evidence than actually managing risk, book a walkthrough of Skypher's questionnaire automation and see what that time actually costs you.
Sources
- ISO/IEC 27001:2022 - Information security management systems
- ISO 27001 Controls: Overview of all measures from Annex A
- ISO 27001 Annex A Controls List: All 93 Controls by Theme
FAQ
How Many ISO Controls Are There?
Annex A of ISO/IEC 27001:2022 contains 93 controls, organized into four themes: Organizational (37), People (8), Physical (14), and Technological (34).
What Does ISO Stand For?
ISO is the International Organization for Standardization, an independent body that develops and publishes international standards, including ISO/IEC 27001 for information security management.
What's the Difference Between Annex A Controls and ISO 27002?
Annex A, part of ISO/IEC 27001, lists the 93 controls you can select from; ISO/IEC 27002 provides the detailed implementation guidance for each one. You get certified against ISO/IEC 27001, never against ISO 27002 alone.
Are Vehicle or Emissions Controls ISO or SAE Standards?
Vehicle emissions and automotive engineering controls typically fall under SAE International standards, not ISO/IEC 27001 Annex A, which addresses information security exclusively and has no connection to automotive or mechanical engineering specifications.
Do I Need to Implement All 93 Annex A Controls?
No. Annex A is a reference set, and you select controls based on your risk assessment, documenting your choices and any exclusions with justification in the Statement of Applicability.