How to comply with ISO/IEC 27001:2022 Annex A controls
Customer records, payment data, source code, and clinical or financial files are the operating assets of a modern organisation, and the people entrusting them to you expect precision, availability, and confidentiality at all times. A single mishandled access right or an unpatched server is rarely just an IT inconvenience — it becomes a regulatory notification, a contractual breach, and a loss of customer trust that takes years to rebuild.
This is precisely why ISO/IEC 27001:2022 imposes a rigour that generic quality standards do not. Where ISO 9001:2015 asks an organisation to control its processes, ISO/IEC 27001 requires it to identify information security risks, treat them, and then justify — control by control — every safeguard it has chosen to apply or exclude. Annex A is where that justification lives.
What is Annex A?
Annex A of ISO/IEC 27001:2022 is a reference set of 93 information security controls. It is useful to contrast it against ISO 9001:2015, which contains no equivalent control catalogue at all, and against the EU GDPR, whose Article 32 demands "appropriate technical and organisational measures" without ever listing them. Annex A is the list. The 2022 edition consolidated the previous 114 controls of the 2013 edition into 93, restructured them from 14 clauses into four themes, and introduced 11 new controls addressing cloud services, threat intelligence, and data leakage prevention.
The four themes are: A.5 Organizational controls (37), A.6 People controls (8), A.7 Physical controls (14), and A.8 Technological controls (34). A frequent misreading should be corrected early: Annex A is not a checklist to be implemented in full. In the scope of clause 6.1.3(c), the organization is mandated to compare the controls determined during risk treatment against Annex A to verify that no necessary control has been omitted — the risk assessment drives the controls, not the other way round.
The procedure
The following sequence reflects what a certification body will actually look for during a Stage 1 and Stage 2 audit.
Defined scope and context: Before a single control is selected, the boundaries of the information security management system must be documented in the scope of clause 4.3. An organisation running a SaaS platform on a public cloud, for example, must state clearly whether the underlying infrastructure is in scope, and where the responsibility of the cloud provider begins. Auditors routinely open with this document, because an inflated scope produces unenforceable controls and a narrow one produces a certificate of little commercial value.
Asset and risk identification: In the scope of clause 6.1.2, information assets, their owners, and the risks to their confidentiality, integrity, and availability are identified and evaluated against defined acceptance criteria. A customer database replicated across two regions carries a different availability risk profile than a single-instance internal wiki, and the treatment decisions should reflect that difference rather than applying one uniform safeguard to both.
Risk treatment and control selection: Each unacceptable risk is treated by modifying, avoiding, sharing, or retaining it, and only the modification path produces controls. This is where Annex A is consulted. Consider a risk of former employees retaining access to production systems: the treatment maps to A.5.18 (access rights) and A.6.5 (responsibilities after termination of employment), not to a vague instruction to "improve offboarding".
Statement of Applicability: The SoA, required in the scope of clause 6.1.3(d), is the single most scrutinised document in the entire certification. It lists all 93 controls and, for each one, records whether it is applicable, the justification for inclusion or exclusion, and its current implementation status. Excluding A.7.4 (physical security monitoring) may be entirely defensible for a fully remote organisation with no premises — but the justification must be written down. Is the exclusion based on a documented risk decision, or simply on the fact that nobody got around to it?
Organizational controls (A.5): This theme carries the governance weight — policies, roles, supplier relationships, incident management, and legal obligations. A.5.19 through A.5.22 deal specifically with supplier and cloud-service security, and they are frequently underestimated. If a payroll processor holds employee data on your behalf, the contractual security terms, the right to audit, and the monitoring of that supplier's performance all sit within this theme.
People controls (A.6): Eight controls covering screening, terms of employment, awareness, disciplinary process, and remote working. Awareness training under A.6.3 is where most organisations produce the weakest evidence. Attendance sheets alone rarely satisfy an auditor; records showing role-specific content, completion dates, and some form of comprehension check demonstrate that the control operates rather than merely exists.
Physical controls (A.7): Perimeters, entry control, equipment siting, clear desk and clear screen, and secure disposal. The edge cases matter here. What happens to a laptop when an employee resigns? Are decommissioned drives destroyed under a certificate, or handed to a recycler with no record? Is the server cupboard genuinely locked, or locked only when a visitor is expected?
Technological controls (A.8): The largest theme, spanning endpoint protection, privileged access, cryptography, logging, secure development, and the new A.8.23 (web filtering) and A.8.28 (secure coding). Logging under A.8.15 deserves particular attention: logs must be produced, protected from tampering, and actually reviewed. An audit trail that nobody reads is a control on paper only.
Documented evidence of operation: In the scope of clause 7.5, each applicable control needs retained evidence that it functions over time — access review records, patch reports, incident tickets, supplier assessments. Certification is granted on operating effectiveness, not on intent.
Internal audit and management review: Clauses 9.2 and 9.3 close the loop. Internal audit tests the controls against the SoA; management review evaluates performance, nonconformities, and the continued adequacy of the risk treatment. Correction and corrective action are distinct here — replacing a shared administrator password is a correction, while removing the practice of shared accounts across the estate is the corrective action.
Where organisations lose time
The technical difficulty of Annex A is rarely the obstacle. The obstacle is the volume of interlinked documentation: 93 justification entries, a risk register that must stay synchronised with the SoA, policies that must reference the controls they implement, and evidence that must be gathered on a schedule. Done manually across spreadsheets and shared drives, this is the work that turns a three-month project into a twelve-month one — and it is the work that decays quietly between surveillance audits.
This is the part ComplyEncrypt automates. The platform runs the gap analysis, maps identified risks to the relevant Annex A controls, generates the Statement of Applicability and the supporting policy set, and schedules the evidence collection so the management system stays audit-ready rather than being reconstructed each year. The intent is not to replace the organisation's judgement — the risk decisions remain yours — but to remove the administrative mass that surrounds them, so an in-house team can carry roughly 90% of the certification effort without a resident consultant.
Call for a defensible control set
An organisation that can explain, control by control, why each safeguard was selected and how it operates does more than pass a certification audit. It answers customer security questionnaires in hours rather than weeks, it satisfies GDPR Article 32 with documented rather than asserted measures, and it enters procurement processes that would otherwise be closed to it. Compliance framed this way stops being an annual cost and becomes a commercial asset. Who would wish for less?
ComplyEncrypt's ISO/IEC 27001 module includes the full Annex A control mapping, an auto-generated Statement of Applicability, and the complete mandatory document set — a one-time purchase with lifetime access.
