ISO 27001 Annex A: How to Use the Control Reference Without Getting Lost in It

Pick up any ISO 27001 implementation guide written before 2022 and you will likely find a spreadsheet with 114 rows, one for each Annex A control in the previous version of the standard. Each row has a status column: implemented, partially implemented, or not implemented. The goal, as those guides present it, is to get every row to green. That framing is incorrect and it leads organisations into expensive, time-consuming work that does not reflect how the standard actually operates.

The 2022 revision reduced the control count to 93, reorganised them into four themes, and introduced new controls covering areas such as threat intelligence, information security for cloud services, and data masking. The reduction and reorganisation did not make Annex A simpler to navigate. It made it more important to understand what the list is actually for.

Annex A Is a Reference Set, Not a Checklist

Annex A exists to ensure that organisations do not overlook controls that might be relevant to their risk treatment plan. The standard requires that during risk treatment, organisations compare the controls they have selected against Annex A to confirm nothing relevant has been missed. It does not require that every control in Annex A be implemented. Controls that are not applicable must be documented in the Statement of Applicability with a justification for their exclusion.

This distinction matters in practice. A five-person SaaS company with no physical office, no paper records, and no manufacturing process will legitimately exclude several physical and environmental controls. A financial services firm handling regulated customer data will find most controls applicable and will need to implement them with considerable rigour. The correct output of an Annex A review is not a percentage score. It is a documented, risk-justified set of inclusions and exclusions.

The Four Themes and What They Cover

The 2022 structure organises controls into organisational controls (37 controls covering governance, policies, supplier relationships, and incident management), people controls (8 controls covering employment lifecycle and security awareness), physical controls (14 controls covering premises, equipment, and clear desk practices), and technological controls (34 controls covering access management, cryptography, logging, vulnerability management, and more). Each control in ISO 27002, the companion guidance document, includes a purpose statement, implementation guidance, and attributes such as control type and security properties.

For most growth-stage technology companies, the technological and organisational themes carry the most weight. Access control, cryptography, secure development, change management, logging and monitoring, and vulnerability management are controls that auditors examine closely and that enterprise buyers ask about in security questionnaires. Getting those right matters more than achieving a technically compliant Statement of Applicability that excludes controls with weak justifications.

Which Controls Matter Most for a Growth-Stage Company

Based on our work with Australian SaaS and technology companies pursuing ISO 27001, the controls that generate the most audit findings and the most customer scrutiny tend to fall into a consistent set:

• Access control and identity management, including privileged access and onboarding/offboarding processes
• Cryptography policy and key management
• Secure development practices and change management
• Logging, monitoring, and audit trail integrity
• Supplier and third-party security assessment
• Incident management, including detection, response, and post-incident review
• Business continuity and recovery testing

These are also the controls most likely to be tested operationally during a Stage 2 audit, meaning the auditor will ask to see evidence that they are functioning, not just documented. A policy that describes access control procedures carries less weight than access logs, provisioning records, and regular access reviews that show those procedures are followed.

How to Approach the Statement of Applicability

The Statement of Applicability should be built from the risk register outward, not from Annex A inward. Identify the risks, determine how each will be treated, select controls that address those treatments, and then cross-reference Annex A to check for gaps. Each control included should be linked to the risk or requirement that drove its inclusion. Each control excluded should carry a justification that would satisfy an auditor who asks why it was not needed.

We have seen organisations arrive at certification audits with Statements of Applicability built from template defaults, where every control is marked as applicable because no one was willing to justify exclusions. Auditors notice this. It raises questions about whether the risk assessment was genuine. A well-constructed Statement of Applicability that excludes a third of the controls with clear, defensible reasoning is more credible than one that includes everything without explanation.

To discuss ISO 27001 Annex A and how to build a Statement of Applicability that holds up at audit, contact Cyberlinx at info@cyberlinx.com.au.