Views: 5
Most ISO 27001 guides read like a copy of the standard with prettier formatting. This one is written from the practitioner’s side of the table — the side where you’re the consultant or ISMS manager who actually has to walk an organization through Annex A, build an audit-ready Statement of Applicability (SoA), and make sure the controls survive first contact with a Stage 2 auditor.
If you’re preparing for certification, running a gap assessment, or making sense of the 2022 restructure, this is your working reference — control by control, category by category, with the pitfalls that don’t usually make it into the marketing brochure.
The 2022 Restructure, in Plain Terms
ISO/IEC 27001:2022 didn’t add new requirements so much as it reorganized and consolidated the old 2013 control set. The headline number everyone quotes — 93 controls, down from 114 — is true but slightly misleading. Roughly two dozen 2013-era controls were merged into single, broader controls, and 11 genuinely new controls were introduced to reflect the threat landscape as it actually looks today: cloud, threat intelligence, secure coding, and data leakage prevention among them.
The four-category structure is the real usability win:
| Category | Prefix | Control Count |
|---|---|---|
| Organizational | A.5 | 37 |
| People | A.6 | 8 |
| Physical | A.7 | 14 |
| Technological | A.8 | 34 |
💡 PRO TIP: Don’t map your ISMS documentation to the old 2013 clause numbers “for continuity.” Keeping a legacy numbering scheme running in parallel with the 2022 structure creates a permanent translation burden during every internal audit and confuses auditors trained on the current standard. Remap everything to 2022 numbering in a single pass rather than maintaining two systems indefinitely.
The 11 New Controls You Need to Know Cold
Auditors probe the new controls specifically because organizations that certified under 2013 and transitioned often bolt these on as an afterthought. Know them by heart:
- A.5.7 Threat intelligence
- A.5.23 Information security for use of cloud services
- A.5.30 ICT readiness for business continuity
- A.7.4 Physical security monitoring
- A.8.9 Configuration management
- A.8.10 Information deletion
- A.8.11 Data masking
- A.8.12 Data leakage prevention
- A.8.16 Monitoring activities
- A.8.23 Web filtering
- A.8.28 Secure coding
💡 PRO TIP: If a Statement of Applicability marks any of these 11 as “Not Applicable,” treat that as a flag during the gap assessment, not a default answer. Auditors treat blanket exclusions of the new controls as a sign of a superficial risk assessment. If exclusion is genuinely justified — for example, A.8.28 for an organization with no in-house development — the justification should reference the actual risk assessment output, not a generic sentence copy-pasted across every excluded control.
Organizational Controls (A.5) — The Governance Layer
This is where the ISMS either has teeth or doesn’t. 37 controls covering policy, roles, asset handling, supplier management, incident response, and legal compliance. It’s the category auditors spend the most time in during Stage 1, because if governance is weak, every technical control downstream becomes harder to verify.
| Control | Name | What It Actually Requires |
|---|---|---|
| A.5.1 | Policies for information security | A living policy set, reviewed on a defined cadence — not a document nobody has opened since certification |
| A.5.7 | Threat intelligence | Structured consumption of threat data, tied back into risk treatment decisions |
| A.5.9 | Inventory of information and other associated assets | An asset register that’s actually used during incident response, not a spreadsheet frozen in time |
| A.5.15 | Access control | A documented access control policy driving least-privilege provisioning |
| A.5.19–5.22 | Supplier relationship controls | Security clauses in contracts, ICT supply chain risk assessment, ongoing supplier monitoring |
| A.5.23 | Information security for use of cloud services | A cloud usage policy addressing shared responsibility, exit strategy, and data residency |
| A.5.24–5.28 | Incident management controls | Planning, assessment, response, learning, and evidence collection as a connected chain |
| A.5.30 | ICT readiness for business continuity | Recovery capability tested against realistic RTO/RPO targets, not theoretical ones |
💡 PRO TIP: The single most common audit finding in A.5 isn’t a missing policy — it’s a policy with no evidence of review. Every policy document needs a version history showing an actual review date, reviewer, and change rationale. Maintain a simple register (owner, last review date, next review due, linked risk IDs) rather than relying on document metadata alone; auditors will ask you to produce it on demand.
💡 PRO TIP: For A.5.7 (Threat Intelligence), don’t just show that a subscription or feed exists — show what changed because of it. The evidence an auditor wants to see is the loop closing: intelligence received, risk or detection action taken, outcome recorded. A feed nobody acted on in twelve months is not evidence of a functioning control.
💡 PRO TIP: For organizations subject to sector- or region-specific breach notification laws layered on top of ISO 27001, map A.5.5 (Contact with authorities) directly to those specific legal obligations now, not during an actual incident. Name the exact regulator, the exact notification trigger, and the exact timeline in the incident response plan — a vague “notify relevant authorities” line will not hold up when an auditor asks how the organization would actually meet a short statutory deadline.
People Controls (A.6) — The Human Layer
Only 8 controls, but they cover the failure mode responsible for the majority of real-world breaches: a person clicking, misconfiguring, or retaining access after they should no longer have it.
| Control | Name | What It Actually Requires |
|---|---|---|
| A.6.1 | Screening | Background verification scaled to role sensitivity, documented and repeatable |
| A.6.3 | Security awareness, education, and training | Role-specific training, not a single annual session for everyone |
| A.6.4 | Disciplinary process | A formal, communicated process — and evidence it’s been invoked when needed |
| A.6.5 | Responsibilities after termination | An offboarding checklist tied to actual, verified access revocation |
| A.6.7 | Remote working | Explicit controls for home networks, split tunneling, and physical security of remote workspaces |
| A.6.8 | Information security event reporting | A frictionless reporting channel employees will actually use |
💡 PRO TIP: Measure A.6.3 training effectiveness with a baseline assessment before rollout and a follow-up assessment 60–90 days later. A completion certificate proves attendance, not comprehension — auditors increasingly expect behavioral or knowledge-based evidence, not just training-platform completion percentages.
💡 PRO TIP: A.6.5 is where organizations most often get caught off guard. Sample the last 90 days of terminations and cross-reference the offboarding date against the actual account deactivation timestamp in the identity system. Any gap between last working day and access revocation is a finding waiting to happen — and it’s one of the easiest gaps to close once it’s visible.
Physical Controls (A.7) — The Overlooked Layer
14 controls that organizations tend to underinvest in because “we’re mostly cloud now.” That’s precisely why auditors probe here — physical control neglect is common and relatively easy to verify.
| Control | Name | What It Actually Requires |
|---|---|---|
| A.7.1–7.3 | Perimeter, entry controls, securing offices | Layered physical access matched to asset sensitivity |
| A.7.4 | Physical security monitoring | Surveillance/alarm coverage with a defined retention and review process |
| A.7.7 | Clear desk and clear screen | Enforced in practice, not just written policy — spot checks are the real evidence |
| A.7.9 | Security of assets off-premises | Device controls for hybrid and field workers |
| A.7.10 | Storage media | Documented handling and secure disposal, including removable media |
| A.7.14 | Secure disposal or reuse of equipment | Certified data destruction records, especially for leased or returned hardware |
💡 PRO TIP: For hybrid and remote teams, A.7.9 is where “we have a laptop policy” collapses under audit scrutiny. The strongest evidence doesn’t come from asking employees to self-attest — it comes from technical enforcement. Where devices are enrolled in a device management platform, pull compliance reports showing screen-lock timeout, disk encryption status, and patch level as objective evidence, rather than relying solely on a signed acknowledgment.
💡 PRO TIP: A.7.14 disposal records are one of the easiest quick-win evidence packages to build. A single register — asset tag, disposal date, destruction method, certificate reference — closes out years of accumulated audit risk in a short amount of time and is worth prioritizing early in any implementation project.
Technological Controls (A.8) — The Depth Layer
34 controls, and this is where technical depth pays for itself. Auditors can be satisfied by a policy document for much of A.5; for A.8 they generally want to see controls working — configurations, logs, test results.
| Control | Name | What It Actually Requires |
|---|---|---|
| A.8.1–8.2 | User endpoint devices, privileged access rights | Endpoint protection coverage and a genuinely enforced least-privilege model |
| A.8.7 | Protection against malware | Layered detection, not signature-based antivirus alone |
| A.8.8 | Management of technical vulnerabilities | A patch SLA tied to severity and exploitability, with evidence of adherence |
| A.8.9 | Configuration management | Baseline configurations, drift detection, and change approval |
| A.8.10 | Information deletion | Provable deletion at end-of-retention, including in backups |
| A.8.11 | Data masking | Applied consistently in non-production environments |
| A.8.12 | Data leakage prevention | Technical controls mapped to the data classification scheme |
| A.8.15–8.16 | Logging, monitoring activities | Centralized, correlated, and — critically — actually reviewed |
| A.8.23 | Web filtering | Enforced at the network egress point, not just endpoint policy |
| A.8.24 | Use of cryptography | A documented cryptographic control policy, including key management |
| A.8.28 | Secure coding | Integrated into the development lifecycle, with review or testing evidence |
| A.8.29 | Security testing in development and acceptance | Test results retained and remediation tracked to closure |
💡 PRO TIP: A.8.16 (Monitoring activities) is one of the most common audit failures — not because logging is absent, but because nobody can demonstrate review. Centralizing logs satisfies half the control; the other half is a documented alert triage process with timestamps showing that someone actually looked at and acted on what was flagged. Even a lightweight, well-defined rule set with a documented weekly review beats an expensive platform nobody looks at.
💡 PRO TIP: Don’t let A.8.8 (Vulnerability Management) live purely as a scanning cadence. Auditors increasingly want to see the full loop: scan, risk-rank, remediate within SLA, verify. Base the patch SLA on real-world exploitability rather than severity score alone — it produces both a stronger control and a more defensible answer when asked why a given vulnerability sat unpatched past its target date.
💡 PRO TIP: For A.8.28 (Secure coding), the fastest way to generate genuine evidence from a small development team is a mandatory, lightweight security checklist embedded in the code review process — authentication checks, input validation, secrets handling — rather than a heavyweight tooling rollout the team will resent and route around. Start light, and expand tooling once the habit is established.
💡 PRO TIP: Test your own control set before the auditor does. Each quarter, pick a handful of technological controls and actively try to defeat them in a controlled exercise. A control that looks sound on paper but fails against a realistic test is a finding you want to catch yourself — not one an auditor, or an attacker, catches for you.
Turning This Into a Statement of Applicability That Survives Audit
The SoA is the document auditors interrogate hardest, and it’s also the one most organizations treat as a formality. A defensible SoA does three things for every control:
- States applicability with a reason tied to the risk assessment — not a boilerplate sentence
- Cites implementation status with a pointer to actual evidence — a policy version, a tool, a log source, a test result
- Links back to a specific risk in the risk register, so the “why” of every control is traceable
💡 PRO TIP: Build the SoA as a living document, not a point-in-time export. Cross-link the SoA, the risk register, and the control evidence register by control ID, so updating one risk flags every SoA entry that references it. Static SoAs go stale within a quarter, and auditors notice quickly when the “last reviewed” date doesn’t match the organization’s actual pace of change.
💡 PRO TIP: Before a Stage 2 audit, run a mock exercise: pick 10 controls at random and ask, honestly, “could I produce evidence of this within five minutes?” Any control where the answer is no is where remaining preparation time should go — not the controls that are already known to be strong.
Closing Thought
Annex A isn’t a checklist to survive an audit once a year — it’s a working risk-management vocabulary that should show up in how the organization actually operates: in offboarding tickets, patch SLAs, incident tickets, and supplier contracts. The organizations that get real value out of ISO 27001 are the ones where Annex A stops being an auditor’s document and becomes an operational one.
Whether the goal is a first-time certification, a regulatory-driven alignment, or a re-certification under the 2022 revision, the work is the same either way: turn each control into something that can be pointed at, not something that can only be described.
