The place where ISMS projects usually stall first is Annex A. You see the number 93, feel that all of it has to be done, start filling in a spreadsheet from the top, and grind to a halt around day three. It is a common way in — and it is the wrong way in.
Annex A is not a checklist to work down. It is a catalogue used to confirm that nothing has been missed when deciding risk treatment. There is no obligation to implement all 93; anything irrelevant to your organisation can simply be explained as irrelevant. Reading it with that premise roughly halves the work.
This article maps how the 93 controls are organised into four themes, how you decide and record what applies, and what the attributes are actually for. Theme-by-theme detail is split across four further articles, so get the shape first and then go where you need to. If you want the standard's overall shape first, start with What Is an ISMS (ISO/IEC 27001)? A Complete Guide for Healthcare Companies.
Disclaimer: This article is general information. The control titles and requirement text live in the standard itself. Out of respect for copyright we do not quote them; we describe the intent in our own words. Base actual decisions on ISO/IEC 27001 (JIS Q 27001) and the publications of the accreditation and certification bodies.
Annex A Is a Catalogue of Controls
ISO/IEC 27001 has two layers: the main text (clauses 4–10) and Annex A. Certification is decided against the main text; Annex A sits inside it as the reference used for risk treatment under clause 6 (planning).
The order is:
- Define the scope (clause 4)
- Inventory information assets and assess risk (clause 6)
- Decide treatment per risk (reduce / transfer / avoid / accept)
- For risks you chose to reduce, decide which controls to use
- Compare your decisions against Annex A to check for gaps
- Record inclusion, exclusion, and the reasoning in the Statement of Applicability (SoA)
Most organisations fail by skipping 1–3 and starting at 4. Implementing controls before the risks are settled leaves you unable to explain why at audit. Conversely, with a solid risk assessment, the Annex A comparison becomes a verification step rather than a project.
See Running a Risk Assessment and Risk Treatment Plans and Risk Acceptance.
The Structure: Four Themes, 93 Controls
The 2022 edition organises controls into four themes totalling 93 items, consolidated and extended from the 114 controls in 14 domains of the 2013 edition.
| Theme | Ref | Controls | Coverage | Typical owner |
|---|---|---|---|---|
| Organizational | A.5 | 37 | Policy, roles, asset management, suppliers, incidents, continuity, compliance | Executive / corporate functions |
| People | A.6 | 8 | Screening, training, discipline, post-employment duties, remote work, event reporting | HR / everyone |
| Physical | A.7 | 14 | Perimeters and entry, environmental threats, equipment, media, disposal | Facilities / IT |
| Technological | A.8 | 34 | Access control, cryptography, logging, vulnerability management, networks, secure development | Engineering / IT |
The distribution is meaningful. Organizational (37) and technological (34) account for about 80% of the catalogue, and that is where the work sits. People controls number only eight, but what fails at audit there is missing records, not the small count. Of the 14 physical controls, most are excluded or pushed into supplier management at an organisation without offices.
The four companion articles:
- Reading the 37 Organizational Controls
- Reading the 8 People Controls
- Reading the 14 Physical Controls
- Reading the 34 Technological Controls
There Is No Duty to Implement All 93
This is the most misunderstood point. Annex A is not a list of mandatory items. What the standard requires is that you decide the controls needed for risk treatment, compare against Annex A to confirm nothing is missing, and document what is included, what is excluded, and why.
Exclusions that hold up look like this:
| Situation | Typical exclusions | How to phrase it |
|---|---|---|
| No in-house software development | Secure coding, separation of environments, outsourced development | No development activity exists within scope |
| No physical office | Physical security perimeters, working in secure areas | No self-managed physical facility; facilities sit under supplier control |
| No own data centre | Supporting utilities, cabling security | Managed by the cloud provider; addressed through supplier management |
| No paper or removable media | Parts of storage media management | The relevant media are not handled in our operations |
Exclusions that do not hold up are equally important. "No budget" and "no staff" are not reasons. If resource constraints prevent implementation, that is a different decision — risk acceptance — and acceptance requires a recorded approval.
Formats and worked examples are in Writing the Statement of Applicability. It is the first document an auditor opens, and a sloppy one sets the tone for everything after.
What the Attributes Are For
The 2022 edition assigns attributes to each control: control type, information security properties, cybersecurity concepts, operational capabilities, and security domains. The same 93 items can be sliced along any of these.
| Attribute axis | Example values | Where it helps |
|---|---|---|
| Control type | Preventive / detective / corrective | Checking that detection and correction are not thin |
| Information security properties | Confidentiality / integrity / availability | Confirming availability is more than a policy statement |
| Cybersecurity concepts | Identify / protect / detect / respond / recover | Mapping to other frameworks |
| Operational capabilities | Governance, asset management, threat management, etc. | Assigning ownership to departments |
| Security domains | Governance and ecosystem, protection, defence, resilience | Reporting at board granularity |
Note that recording attributes is not a certification requirement. You can certify without using them. They earn their place in two situations. One is internal audit: pulling only the detective controls and auditing those together quickly reveals whether logging and monitoring have become paperwork. The other is reporting to management: item-by-item status across 93 controls communicates nothing, whereas "protection is in place but detection and recovery are thin" leads to an investment decision.
The Order a Healthcare Company Should Work In
Working through 93 items evenly is inefficient. For an organisation handling medical or personal health information, this sequence is realistic:
- Organizational: policy, roles, asset management — the foundation; without an asset register a risk assessment cannot begin
- Technological: access control and authentication — access to medical information carries a heavy burden of "who saw what, when"
- Organizational: suppliers and cloud services — a cloud-native architecture needs demarcation settled here
- Technological: logging, monitoring, vulnerability management — heavy overlap with Japan's three-ministry guidelines
- Incident management and continuity — customers will always ask how you avoid stopping clinical operations
- People and physical controls — few in number and largely overlapping existing HR rules; these can wait
For the level hospitals expect, see The Three-Ministry Guidelines; for demarcation in cloud architectures, Shared Responsibility in AI EMR Security Design.
The transition deadline from the 2013 edition (31 October 2025) has passed, so new certifications target the 2022 edition only. If the delta still matters to you, see Transitioning to ISO/IEC 27001:2022.
Conclusion
- Annex A is a catalogue, not a checklist — finish the risk assessment first, then use it as a gap check
- The structure is four themes, 93 controls (37 / 8 / 14 / 34); organizational and technological are ~80% of it
- There is no duty to implement all 93 — record inclusion, exclusion, and reasoning in the SoA
- Valid exclusions rest on "the activity or asset does not exist here." Lack of resources is not a reason
- Attributes are not required for certification but are useful as an internal audit lens and a board-level reporting grain
- A realistic order: policy and assets → access control → suppliers → logging and vulnerabilities → incidents
Pottech supports ISMS certification with a focus on healthcare. Deciding what applies in Annex A is less about interpreting the standard than about articulating how your business actually works. We can draft the Statement of Applicability and leave your team with only the decisions to make.
See ISMS Certification Support for scope and pricing, or contact us.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- On the transition to ISO/IEC 27001:2022 | ISMS-AC
- ISO/IEC 27001 Information security management systems | ISO
- ISO/IEC 27002 Information security controls | ISO
- Guidelines for the Safe Management of Medical Information Systems | MHLW
Note: interpretation of controls, the acceptability of exclusions, and the handling of certification can change with revisions to the standard and the practices of certification bodies. Check the standard and the bodies' own publications for current treatment.