In this article

How Many Controls Are in ISO 27001? A Complete Breakdown of the ISO 27001 Controls List

This article explains how many controls are included in ISO/IEC 27001:2022, breaking down the 93 Annex A controls across Organizational, People, Physical, and Technological categories. It clarifies the common confusion between the current 93-control structure and the previous 114-control version, while explaining how Annex A supports the ISO 27001 risk treatment process. The article is designed for security leaders, compliance teams, SaaS companies, and organizations preparing for ISO 27001 certification who want a practical understanding of the ISO 27001 controls list and how controls are selected based on risk rather than treated as a simple compliance checklist.

a man with long hair wearing a blue shirt
By Tom Rozen

Published October 6, 2026

ISO 27001 Controls Explained

ISO/IEC 27001:2022 Annex A contains 93 information security controls. They are organized into four themes: 37 Organizational controls, 8 People controls, 14 Physical controls, and 34 Technological controls. ISO/IEC JTC 1/SC 27, the committee responsible for the ISO/IEC 27000 family, confirms this structure.

If you have seen references to 114 controls, those relate to the previous 2013 structure. More importantly, the move to 93 controls does not mean ISO 27001 certification is a 93-box checklist.

Annex A is a reference set used as part of your information security risk-treatment process. Your organization determines the controls it needs based on its risks and requirements, then compares those controls against Annex A to ensure it hasn't overlooked anything necessary.

That distinction is what makes the ISO 27001 controls list useful in practice.

» Need help with ISO implementation? Contact GRSee for fast assistance

How are the 93 ISO 27001 controls organized?

The 93 ISO 27001 controls fall into four themes: organizational, human, physical, and technological.

Annex A theme

# of controls

Broad focus

A.5 Organizational

37

Governance, processes, suppliers, incidents, and information handling

A.6 People

8

Workforce-related information security

A.7 Physical

14

Premises, equipment, media, and physical protection

A.8 Technological

34

Systems, networks, applications, and technical safeguards

A.5 Organizational controls — 37 controls

Organizational controls address how the business governs and manages information security.

They cover areas such as security policies and responsibilities, management of information and associated assets, access governance, supplier relationships, cloud-service use, security incident management, information security during disruption, and relevant legal or contractual considerations.

This is the largest of the four themes because effective information security depends on more than technical safeguards. Organizations need clear ownership, repeatable processes, supplier oversight, and mechanisms to respond when things change or go wrong.

One point is worth keeping clear: Annex A's Organizational controls are not a substitute for the broader management-system requirements in ISO 27001. The standard's requirements for risk assessment, leadership, planning, internal audit, management review, and continual improvement sit in the main clauses of ISO 27001.

A.6 People controls — 8 controls

People controls address security throughout the workforce lifecycle.

They cover areas including screening, employment-related security responsibilities, awareness and training, confidentiality expectations, remote working, and reporting security events.

These controls recognize a basic operational reality: technical security can be undermined if people do not understand what is expected of them or if access and responsibilities are poorly managed as roles change.

The goal is not simply to run annual awareness training. The People theme connects information security expectations to how personnel are hired, managed, supported, and eventually leave or change roles.

A.7 Physical controls — 14 controls

Physical controls address the environments and assets that support information processing.

Relevant areas include physical access, secure areas, physical monitoring, equipment protection, storage media, maintenance, environmental considerations, and secure disposal.

For a cloud-first SaaS company, this theme may look different from the equivalent controls at an organization that operates its own data centres. That does not make physical security irrelevant. It means the organization must understand which physical risks it controls directly and which depend on facilities, cloud providers, offices, or other suppliers.

A.8 Technological controls — 34 controls

Technological controls cover technical safeguards applied to systems, applications, networks, and information.

They address areas such as identity and access management, privileged access, authentication, endpoints, vulnerability and configuration management, malware protection, backups, logging and monitoring, network security, cryptography, secure development, and change management.

This is often the section engineering and security teams recognize first. But implementing strong technical controls alone does not create an ISO 27001-conforming Information Security Management System (ISMS). Those controls need to sit inside the wider risk-management and governance process defined by the standard.

GRSee iso services logo

ISO 27001 Compliance Starts With Security

Avoid penalties and security risks by aligning with ISO 27001 and PCI DSS. Test your internal security controls today.

Achieve ISO Compliance

Do you have to implement all 93 ISO 27001 controls?

No. ISO 27001 does not require every organization to implement all 93 Annex A controls automatically.

Clause 6.1.3 takes a risk-based approach. The organization determines how it will treat its information security risks, identifies the controls needed to support that treatment, and then compares those controls with Annex A to verify that it has not omitted any necessary controls.

That sequence matters. A practical way to think about it is:

  1. Assess your information security risks. Understand the risks that could affect the confidentiality, integrity, or availability of information within your ISMS.
  2. Determine appropriate risk-treatment options. Decide how to handle those risks.
  3. Determine the necessary controls. Identify the safeguards required to implement the chosen treatment.
  4. Compare your controls with Annex A. Use the 93-control reference set as a completeness check.
  5. Document and justify your decisions. Record the resulting control set through the Statement of Applicability and associated risk-treatment documentation.

Annex A therefore supports the decision-making process rather than replacing it. SC 27's guidance explicitly describes Annex A as a reference set of controls and notes that the organization can also design necessary controls or draw them from other appropriate sources.

So an organization may conclude that a particular Annex A control is not necessary for its ISMS. But that conclusion should come from its context, risks, legal or contractual obligations, and treatment decisions—not simply because the control is inconvenient to implement.

Likewise, there is no meaningful universal answer to questions such as, "How many of the 93 controls should a SaaS company implement?" Two SaaS companies may have very different architectures, suppliers, data, contractual obligations, risk tolerances, and ISMS scopes.

How does the Statement of Applicability fit in?

The Statement of Applicability (SoA) links your risk-treatment process to your control environment.

Under Clause 6.1.3, the SoA must capture the organization's necessary controls, why they are included, whether they have been implemented, and justification for excluding Annex A controls. Necessary controls that do not originate in Annex A must also be represented appropriately.

This makes the SoA much more than a spreadsheet with 93 Yes/No fields.

A useful SoA should make the reasoning behind the control environment understandable. If a control is included, it should have a defensible reason. If an Annex A control is excluded, the organization should be able to explain why it is unnecessary based on its own circumstances.

That is why starting with a pre-filled control checklist can put the process backwards. The direction should be risk → treatment → necessary controls → Annex A comparison, not Annex A first and risk justification afterwards.

What is the difference between ISO 27001 requirements and Annex A controls?

The 93 Annex A controls are only one part of ISO 27001. ISO/IEC 27001 is the requirements standard for establishing, implementing, maintaining, and continually improving an ISMS. ISO currently lists ISO/IEC 27001:2022 as the published third edition, with Amendment 1:2024.

The main management-system requirements are contained in Clauses 4 through 10:

  • Context of the organization
  • Leadership
  • Planning
  • Support
  • Operation
  • Performance evaluation
  • Improvement

These requirements create the management system that governs information security risks and controls.

Annex A provides the reference control set used during risk treatment.

This also explains the difference between ISO/IEC 27001 and ISO/IEC 27002. ISO 27001 specifies the ISMS requirements organizations can be certified against. ISO/IEC 27002 provides more detailed guidance and recommended practices for information security controls. ISO explicitly states that ISO/IEC 27002 itself is not a certification standard.

In practical terms, ISO 27001 tells you what the management system must achieve and what it requires. ISO 27002 helps you understand how to implement information security controls.

A company cannot therefore become ISO 27001-ready by focusing exclusively on technical or administrative controls while ignoring the management-system requirements around leadership, risk, objectives, internal auditing, performance evaluation, corrective action, and continual improvement.

Why do some ISO 27001 resources still say there are 114 controls?

The 114-control figure comes from the previous 2013 edition of the ISO/IEC 27002 control structure, which organized 114 controls into 14 categories. SC 27's own materials describing the earlier standard confirm that structure.

The 2022 edition reorganized the control set into 93 controls across the four current themes.

This does not mean the update removed 21 security controls.

The revision reduced redundancies, merged some existing controls, updated guidance, and added new controls to reflect changes in security practices and technology. ISO/IEC 27002's editors say they added 11 new controls. In comparison, 24 current controls resulted from mergers of 56 controls in the previous edition.

So if you are working from an old spreadsheet organized around 114 controls and 14 categories, you should not treat it as a current ISO 27001:2022 implementation resource.

The 2013 edition is now withdrawn, and the formal transition period for accredited certification to ISO/IEC 27001:2022 ended on October 31 2025.

How should organizations use the ISO 27001 controls list in practice?

Start with your ISMS and its risks, not with row one of an Annex A checklist.

A practical risk-to-control workflow looks like this:

  1. Define the ISMS scope.
    • Establish the organizational boundaries, information, systems, processes, people, locations, and relevant interfaces the management system covers.
  2. Assess information security risks.
    • Identify the risks that could affect information within that scope and evaluate them using your organization's defined risk criteria.
  3. Select risk-treatment options.
    • Decide what to do with risks that require treatment.
  4. Determine necessary controls.
    • Identify the organizational, people, physical, and technological safeguards needed to carry out those treatment decisions.
  5. Compare those controls with Annex A.
    • Review the 93 controls to check whether your treatment process has overlooked a necessary safeguard. This is the role Annex A was designed to play.
  6. Build or update the Statement of Applicability.
    • Document the necessary controls, inclusion decisions, implementation status, and justified Annex A exclusions.
  7. Implement, operate, and review the controls.
    • A control documented in the SoA still needs to work in practice. Controls should operate within the ISMS and be reviewed through the organization's wider performance-evaluation and improvement processes.

Consider a cloud-native SaaS company preparing for its first ISO 27001 certification.

If the team starts with a generic "93 controls checklist," it may quickly spend engineering and compliance time implementing documentation or safeguards without first connecting them to the company's actual risks.

Instead, its risk analysis might show that cloud-service dependencies, supplier management, identity and privileged access, secure development, vulnerability management, backups, and logging matter most. Those conclusions can then drive the necessary control set, with Annex A acting as the completeness check.

The difference is subtle but important: the controls support the risk-management program; the controls list is not the program.

» Ready to explore ISO 27001 for your organization? Get expert support to assess your readiness and build a practical implementation roadmap.

Turn the ISO 27001 controls list into a practical certification-readiness plan

Knowing that ISO 27001 has 93 controls is the easy part. The harder questions are specific to your organization: What belongs in scope? Which risks need treatment? Which safeguards are already working? Where are the gaps? And what needs to change before the certification audit?

GRSee's current ISO 27001 services cover gap assessment, information security risk assessment (Clause 6.1.2), remediation planning, implementation support, internal audit, the certification-body audit process, and ongoing compliance support.

We focus on turning ISO 27001 requirements into a clear set of priorities for your actual environment rather than handing your team a generic Annex A checklist. That means connecting the ISMS, risk treatment, controls, documentation, and readiness work. Hence, engineering and compliance teams know what needs attention and why.

If you're preparing for ISO 27001 certification, review your current ISMS gaps and determine which controls and remediation priorities belong in your certification-readiness plan before treating all 93 controls as your project backlog.

The GRSee Way

At GRSee, we don't just help you prepare—we guide you step-by-step, ensuring your ISMS is audit-ready and strategically aligned with your business goals.

Contact Us

FAQs

Can ISO 27001 controls come from outside Annex A?

Yes. ISO 27001 requires organizations to determine the controls needed for their risk treatment and compare them with Annex A. SC 27 guidance confirms that organizations can design their own controls or use controls from other suitable sources when needed.

Can an Annex A control be marked not applicable?

Yes, if the organization can justify why the control is unnecessary based on its context, risks, requirements, and risk-treatment decisions. The Statement of Applicability must address the justification for excluding an Annex A control.

Is ISO 27002 the same as the ISO 27001 controls list?

Not exactly. ISO 27001 Annex A reflects the same 93 control concepts, while ISO/IEC 27002 provides much more detailed implementation guidance for those controls. ISO 27001 is the certifiable ISMS requirements standard; ISO 27002 provides guidance and cannot itself be certified to.

Does implementing all 93 controls guarantee ISO 27001 certification?

No. Certification assesses conformity of the ISMS as a whole with ISO/IEC 27001. Implementing every Annex A control would not compensate for missing management-system requirements such as risk management, internal audit, management review, corrective action, or continual improvement.