ISO 27001:2022 lists 93 controls in Annex A. They’re organized into four domains: Organizational (A.5), People (A.6), Physical (A.7), and Technological (A.8). The standard is clear about which controls to implement: select them based on your risk assessment.

Most security teams skip the risk assessment, mark every control as “applicable,” and spend six months filling out implementation sheets for controls they’ll never verify.

Here’s what happens when you stop treating Annex A as a checklist and start treating each control as a real security discipline.

The Myth of Applicability

The SoA (Statement of Applicability) is the heart of ISO 27001 certification. You declare each control applicable or not, with justification. The temptation is to mark everything applicable — after all, isn’t information security important everywhere?

It’s not.

I’ve seen teams mark A.7.4 (Physical security monitoring) as applicable for a team of three developers working from home offices with no on-premises infrastructure. They spent four months documenting camera coverage of a storage closet that held two rack-mounted servers, none of which contained data worth more than the cost of replacement.

Rule of thumb: A control is applicable only if its absence creates a risk your risk assessment flagged. If you have no physical premises, A.7.1–A.7.14 are noise. Document it. Move on.

Domain-by-Domain: What Actually Matters

A.5: Organizational Controls (37 controls)

This is the biggest domain and the most abused. Thirty-seven controls sounds like a lot of work. In practice, about 15 of them overlap significantly, and the rest are low-effort.

A.5.1 (Policies for information security): One document. If you have an infosec policy and everyone can find it, you’re done. No need for a 40-page policy manual.

A.5.7 (Threat intelligence): This is the one most teams ignore until audit season. Threat intel doesn’t mean a paid feed. RSS digests from oss-sec, CISA KEV, and vendor advisories count. The requirement is that you receive and process threat intelligence. You don’t need to act on every finding — just review them.

A.5.9 (Inventory of information and assets): This is the control that feeds everything else. Without an asset inventory, you can’t prioritize, you can’t map controls to assets, and your risk assessment is guessing. Spend the time here. It pays dividends.

A.5.19–A.5.23 (Supplier security relationships): Five controls that boil down to: know your suppliers, assess their risk, contract for security, monitor them, and have exit plans. One spreadsheet with supplier names, risk levels, contract dates, and next review dates covers most of it.

A.5.29–A.5.30 (Information security during disruption / ICT readiness): These two overlap with business continuity. If you have a BCM team, coordinate with them. If you don’t, a documented recovery plan for your critical systems is enough.

A.6: People Controls (8 controls)

Eight controls. Four are easy:

A.6.3 (Security awareness, education, training): Quarterly phishing tests and annual training sessions. That’s it. No need for a custom LMS.

A.6.7 (Remote working): One policy covering VPN, device encryption, and screen visibility. Most teams already have this in their employee handbook.

A.6.8 (Security event reporting): A Slack channel or email alias where people can report suspicious activity. If nobody reports anything for six months, that’s a good sign — or that nobody knows about the channel.

The other four (screening, terms of employment, disciplinary process, termination responsibilities) are HR controls that security teams inherit by default. Assign an HR contact and verify they’re doing the work.

A.7: Physical Controls (14 controls)

If you’re cloud-native, this is the smallest ROI domain. Most of A.7 covers:

  • Facility perimeters and entry points (A.7.1–A.7.2)
  • Monitoring and CCTV (A.7.4)
  • Clear desk/screen (A.7.7)
  • Power and cooling (A.7.11)
  • Equipment disposal (A.7.14)

For a cloud-only org, A.7.11 and A.7.14 are the only ones that matter (your cloud provider handles the rest). Document their data sheet and move on.

A.8: Technological Controls (34 controls)

This is where the security work actually happens. Thirty-four controls sounds like a lot, but many map to the same tools:

A.8.8 (Management of technical vulnerabilities): The control that matters most for a bug bounty team. Scan, triage, patch, verify. Repeat. The standard doesn’t say how often — your risk assessment does. For internet-facing assets, monthly at minimum.

A.8.9 (Configuration management): Baseline configs, drift detection, and change approval. Ansible or Terraform state files count as your configuration inventory. You don’t need a CMDB.

A.8.10 (Data leakage prevention): DLP doesn’t need to be fancy. Email filtering, cloud bucket permissions, and USB policy cover the basics. If you’re a dev shop, DLP on dev environments is overkill.

A.8.16 (Monitoring activities): Logs, alerts, and dashboards. The standard requires you to monitor for unusual activity. You don’t need a SIEM — journalctl, CloudTrail, and a cron job with grep work fine for small orgs.

A.8.24 (Use of cryptography): TLS everywhere, AES-256 for data at rest, SSH keys instead of passwords. The control is about having a crypto policy and following it. You don’t need to invent new algorithms.

The Implementation Framework

Here’s what actually works when implementing Annex A controls without burning out:

Phase 1: Filter to Applicable (Day 1–7)

Go through all 93 controls. Mark as “not applicable” if:

  • Your org has no physical premises (A.7 controls)
  • Your org has fewer than 5 employees (A.6.4 disciplinary process, A.6.6 confidentiality agreements — cover in employment contracts instead)
  • A control’s outcome is already achieved by another control you’re implementing

Document the justification. One sentence per control is enough.

Phase 2: Map to Tools (Week 2–3)

For each applicable control, identify the tool or process that implements it. If you can’t name a tool or process, the control isn’t implemented — it’s aspirational.

Control Tool/Process
A.8.8 Vulnerability mgmt Trivy + Jira board
A.8.9 Configuration mgmt Ansible playbooks + diff
A.8.16 Monitoring CloudWatch + alerts
A.5.1 Policy /docs/infosec-policy.md
A.5.9 Asset inventory software-landscape-catalog.md

Phase 3: Verify, Don’t Assume (Week 4)

Every “implemented” control needs verification:

  • A.8.8: Last scan date + patch rate
  • A.8.9: Config drift count this quarter
  • A.8.16: Alert volume and response time
  • A.5.1: Policy review date

If you can’t answer the verification question, the control needs work.

Phase 4: Repeat Quarterly

Controls drift. A vulnerability scanner that worked three months ago might be scanning the wrong endpoints. A policy written last quarter might not cover a new cloud service added last month. Schedule verification as a recurring task, not an annual event.

What I Get Wrong

I used to think the biggest barrier to ISO 27001 compliance was the controls themselves. It’s not. The barrier is verification discipline — the habit of checking that what you documented actually matches what’s running.

I used to mark every control “implemented” because I had a tool for it. A.8.16 (monitoring) had CloudWatch. But CloudWatch was only logging API Gateway and Lambda. RDS and EC2 had no log groups. The control was half-implemented, and I didn’t know until the auditor asked.

Now I verify every control quarterly with a single question: Show me. Show me the scan report. Show me the config diff. Show me the alert that fired last week. If you can show me, the control is implemented. If you can’t, it’s a checkbox with no substance.

TL;DR

  • 93 controls is the starting point, not the workload. Many don’t apply to your org.
  • Map each applicable control to a real tool or process. No tools = no implementation.
  • Verify quarterly with a single question: show me.
  • The biggest risk isn’t missing controls — it’s claiming controls you haven’t verified.

Further Reading