How many controls does ISO 27001 have?

The 2022 edition has 93 controls in Annex A, split across four themes. The 2013 edition had 114 in 14 domains. The lower number is mostly the result of merging controls, not removing them.

Do I have to implement all 93 controls?

No. You consider all of them, but you implement what your risks call for. For each control, the Statement of Applicability records whether it applies and why.

Which controls are new in ISO 27001:2022?

Eleven, including threat intelligence (5.7), information security for cloud services (5.23), configuration management (8.9), monitoring activities (8.16) and secure coding (8.28).

What is the difference between Annex A and ISO 27002?

Annex A of ISO 27001 lists the controls briefly. ISO/IEC 27002:2022 uses the same numbering and gives guidance on each control. You certify against ISO 27001, not against ISO 27002.

Does the old list of 114 controls still apply?

No. Certificates based on ISO 27001:2013 expired or were withdrawn by 31 October 2025 at the latest. Certification has been against the 2022 edition since then.

ISO 27001 controls: the 93 Annex A controls, grouped the way an IT company experiences them

ISO 27001:2022 contains 93 controls in Annex A, split across four themes: 37 organisational, 8 people, 14 physical and 34 technological. Eleven of them are new compared with the 2013 edition. Annex A is a reference list, not a mandatory checklist: which controls you apply follows from your risk assessment and is recorded in the Statement of Applicability.

ISO 27001:2022 contains 93 controls in Annex A, split across four themes. It is a reference list, not a checklist to work through from top to bottom. You go through every control, choose what your risks call for, and record that choice in the Statement of Applicability. An auditor mainly checks whether those choices match what your company actually does.

What changed in 2022

The 2013 edition had 114 controls in 14 domains. The 2022 edition has 93 in four themes. The lower number is mostly the result of merging controls; on top of that, 11 new ones were added. Certificates based on the old edition expired or were withdrawn by 31 October 2025 at the latest.

Annex A describes each control in a single line. The explanation and implementation guidance sit in ISO/IEC 27002:2022, which follows the same numbering. If you want to understand a control properly, that is where to read on.

The four themes

Theme	Numbers	Count	What it covers
Organisational	5.1 to 5.37	37	Policy, roles, assets, access, suppliers, incidents, continuity, legal requirements.
People	6.1 to 6.8	8	Screening, terms of employment, awareness, remote working, reporting events.
Physical	7.1 to 7.14	14	Offices and rooms, equipment, storage media, disposal.
Technological	8.1 to 8.34	34	Endpoints, authentication, logging, networks, backups, cryptography, development.

The themes are convenient for an auditor, but they are not how a software company talks about its work. So below you will find the new controls first, followed by a grouping based on where you meet them in practice.

The 11 new controls

No.	Subject	What it means for a software company
5.7	Threat intelligence	Keeping track of relevant threats, for example through national CERT advisories and alerts about your own stack.
5.23	Cloud services	Agreeing how you select, use and eventually leave AWS, Azure or a local hosting provider.
5.30	ICT readiness for business continuity	Showing that your platform can come back within the agreed time, not only that a plan exists.
7.4	Physical security monitoring	Surveillance of rooms holding sensitive equipment; with full cloud hosting this is usually covered by the provider.
8.9	Configuration management	Recorded and monitored configurations of servers, containers and cloud accounts.
8.10	Information deletion	Demonstrably deleting customer data once it is no longer needed, including from backups and logs where feasible.
8.11	Data masking	Shielding personal data, for example in test and support environments.
8.12	Data leakage prevention	Measures against data leaving unintentionally, from email to public storage buckets.
8.16	Monitoring activities	Spotting and following up unusual behaviour on networks and systems.
8.23	Web filtering	Limiting which websites company devices can reach.
8.28	Secure coding	Secure programming as a standing practice, backed by conventions, reviews and tooling.

How a software company experiences them

The numbers below are our own groupings, not a structure from the standard. Some controls belong to more than one group.

Development

For a SaaS or healthcare software provider this is where the weight lies. It covers security in projects (5.8), access to source code (8.4), a secure development life cycle (8.25), security requirements for applications (8.26), secure architecture principles (8.27), secure coding (8.28), testing (8.29), outsourced development (8.30), separated environments (8.31), change management (8.32) and test data (8.33). An auditor will ask about pull requests, review rules and how production data stays out of test.

Hosting and cloud

Cloud services (5.23), capacity (8.6), malware (8.7), vulnerability management (8.8), configuration management (8.9), backups (8.13), redundancy (8.14), logging (8.15), monitoring (8.16), clock synchronisation (8.17), network security (8.20 to 8.22) and cryptography (8.24). A hosting company or SaaS business shows most of its evidence here, straight from its own systems.

People and access

The whole people theme (6.1 to 6.8), plus access control policy (5.15), identities (5.16), passwords and other authentication information (5.17), access rights (5.18), laptops and phones (8.1), privileged access (8.2) and secure authentication (8.5). In a team of 10 to 100 people it comes down to joiners and leavers: who gets what, who revokes it, and where that is recorded.

Suppliers

Security in supplier relationships (5.19), contract terms (5.20), the ICT supply chain (5.21), monitoring suppliers (5.22) and cloud services (5.23). For a software company that mostly means the hosting provider, the email service, the ticketing tool and external developers. Your own customers ask you the same questions.

Incidents and continuity

Preparing for incidents (5.24), assessing events (5.25), responding (5.26), learning (5.27), collecting evidence (5.28), security during disruption (5.29), ICT readiness (5.30) and reporting by staff (6.8). Threat intelligence (5.7) feeds this group.

What often stays small

In a company without its own server room, many physical controls shrink to the office and the equipment: access to the building (7.1 to 7.3), clear desk and clear screen (7.7), equipment off-site (7.9), storage media (7.10) and secure disposal (7.14). The rest is often placed with the hosting provider, with a reference to its certificate. That is a justified choice, not an exception.

The remaining organisational controls, such as inventory (5.9), classification (5.12), legal and contractual requirements (5.31), privacy (5.34) and independent review (5.35), touch the whole company and fit none of the boxes above.

From list to way of working

A list of 93 numbers helps an auditor, but not the developer who wants to know what is expected of them. It works better to describe controls in the language of your own processes and attach the numbers behind them. Trustbird works that way: one set of controls in business language, mapped to the numbers of ISO 27001 and, where relevant, NEN 7510. Whatever form you choose, the choices and the reasoning behind them stay with the organisation.