TL;DR
ISO 27001 Annex A has 93 controls across four domains. Most small teams drown in the number. The trick isn’t implementing all 93 — it’s implementing the right ones and making the rest work for you. This post walks through a practical implementation strategy: start with the 14 controls that cover 80% of real risk, automate the repetitive ones, and document the rest as “not applicable” with real justifications. No compliance team required.
The Problem: 93 Controls Looks Like a Mountain
When you first open Annex A of ISO 27001:2022, the 93 controls in 4 domains look like a consulting engagement:
| Domain | Controls | Examples |
|---|---|---|
| A.5 Organizational | 37 | Policies, risk treatment, supplier security |
| A.6 People | 8 | Screening, training, remote work |
| A.7 Physical | 14 | Perimeters, entry, monitoring, clear desk |
| A.8 Technological | 34 | Access control, crypto, monitoring, secure coding |
A small team (1–2 security people, maybe a DevOps engineer) can’t meaningfully implement all 93 controls from scratch. If you try, you’ll spend six months writing policies and still have gaps in the controls that actually prevent breaches.
The mistake is treating every control as equal. They’re not. Some prevent the most common attacks. Others are audit theater. The difference matters when you have limited bandwidth.
Step 1: Implement the 14 Controls That Matter Most
Not all controls prevent the same amount of risk. Based on breach data, CISA KEV patterns, and bug bounty findings, here are the controls that cover roughly 80% of real-world incidents:
The Breach-Prevention Core
A.5.7 — Threat intelligence. You can’t prioritize vulnerabilities if you don’t know what’s being exploited. Feed CISA KEV, vendor advisories, and your bug bounty program findings into a daily triage loop.
A.5.9 — Inventory of assets. Controls without assets are abstract. Know what you run: software, versions, cloud accounts, keys. If it’s not in the inventory, it won’t get patched.
A.5.23 — Information security for cloud services. Most small teams run on AWS, GCP, or Azure. The controls for cloud (shared responsibility, configuration management, logging) cover more ground than almost any other single control.
A.8.8 — Management of technical vulnerabilities. This is CVE management. Patch Tuesday, KEV due dates, EPSS scoring, asset matching. The controls that get exploited in the wild get patched first.
A.8.9 — Configuration management. Hardening baselines, drift detection, secure defaults. Most breaches happen because default configs were never changed.
A.8.5 — Secure authentication. MFA everywhere, strong passwords, session management. Covers password spray, credential stuffing, session hijacking.
A.8.10 — Data leakage prevention. Classification, DLP rules, export controls. Stops exfiltration after the breach happens.
A.8.16 — Monitoring activities. Logs that actually detect something. Not “we have logs” — “we have logs we check.”
A.8.1 — User endpoint devices. Laptops, phones, workstations. BitLocker/FileVault, EDR, disk encryption. The endpoint is where most attackers land.
A.5.19 — Supplier security. Third-party access, vendor assessments, contractual clauses. You can’t control your supply chain without this control.
A.5.29–A.5.30 — Information security during disruption. Backups, recovery, BCP. Covers ransomware recovery.
A.8.24 — Use of cryptography. TLS everywhere, key management, encryption at rest. Covers data in transit and at rest.
A.5.1 — Policies for information security. One living document that says what you care about. Not 20 policies — one, updated quarterly.
A.5.10 — Acceptable use. What users can and can’t do with company assets. The simplest control with the biggest cultural impact.
These 14 controls form your implementation baseline. They’re the ones that show up in breach reports, the ones CISA cares about, the ones your bug bounty findings expose. Get these right first.
Step 2: Automate What You Can
Manual control verification doesn’t scale. Automate the repetitive ones:
Automated checks (run daily or weekly):
- A.5.8 — Logging: verify log retention and integrity (checksum rotation)
- A.5.15 — Access control: scan for stale accounts, dormant permissions, overprivileged service accounts
- A.8.5 — Authentication: check MFA coverage across all accounts
- A.8.8 — Vulnerability management: run CVE triage against asset inventory (EPSS + KEV + asset matching)
- A.8.9 — Configuration: baseline drift detection on servers and containers
- A.8.16 — Monitoring: verify log sources are sending, alert rules are active
How to automate:
- Shell scripts + cron for simple checks
- Ansible playbooks for configuration drift
- Python scripts for CVE triage against your asset list
- GitHub Actions for CI/CD security gates
The goal is to have controls that verify themselves. If you have to manually check a control every month, it’s not implemented — it’s a checklist item.
Step 3: Document “Not Applicable” With Real Justifications
This is where most small teams fail. ISO 27001 doesn’t require implementing all 93 controls — it requires deciding whether each one is applicable, and documenting your reasoning.
The Statement of Applicability (SoA) is the document. For each control, you mark it as:
- Applicable — implementing it now
- Not applicable — with a justification that an auditor can verify
- Not determined — needs review
Here’s what “not applicable” looks like done right:
| Control | Status | Justification |
|---|---|---|
| A.7.1 — Physical security perimeters | Not applicable | All infrastructure is in AWS us-east-1 and us-west-2; no on-premises data centers |
| A.7.7 — Clear desk | Not applicable | 100% remote team; no shared physical workspaces |
| A.7.14 — Secure disposal of equipment | Not applicable | Laptops returned to vendor for recycling; SSDs wiped before return |
Here’s what it looks like done wrong:
| Control | Status | Justification |
|---|---|---|
| A.7.1 — Physical security perimeters | Not applicable | N/A |
| A.7.7 — Clear desk | Not applicable | N/A |
The difference? A real auditor can verify the first table. “N/A” is a placeholder for “I didn’t think about this.”
Rule: Every “not applicable” justification should answer: “What would change if this control were applied?” If nothing changes, it’s genuinely not applicable.
Step 4: Accept Trade-offs Explicitly
Not every applicable control can be implemented to the ideal state. Document what you accept:
- A.5.32 — Segregation of duties: Not fully implemented. On a team of 2, the developer who writes the code also deploys it. Control: deployment requires a second reviewer on pull requests.
- A.8.12 — Data leakage prevention: Partial. Outbound email scanning via SPF/DKIM/DMARC. DLP on file shares pending tool procurement.
- A.6.6 — Confidentiality agreements: Signed on hire, but not annually refreshed. Risk: mid-year leavers who join competitors.
These aren’t failures. They’re trade-offs. The key is documenting them so the auditor sees intentionality, not negligence.
Step 5: Map Controls to What You Already Do
Here’s the data-reuse pattern that makes ISO 27001 practical for small teams: every control you implement should cover multiple frameworks simultaneously.
A.8.5 (Secure authentication) covers:
- ISO 27001: MFA, session management
- DORA Art. 9: Protection against external threats
- NIS2 Art. 21(2)(h): Authentication and access management
- BaFin BAIT 2.2: IT access controls
- SOC 2 CC5.2: Logical access
A.5.9 (Asset inventory) covers:
- ISO 27001: Asset identification and classification
- DORA Art. 8: Identification and classification
- NIS2 Art. 21(2)(g): Asset management
- BaFin BAIT 3.1: Inventory of IT components
A.8.8 (Vulnerability management) covers:
- ISO 27001: Vulnerability scanning and patching
- DORA Art. 10: Detection of anomalies and events
- NIS2 Art. 21(2)(a): Risk analysis
- BaFin BAIT 3.5: Vulnerability management
Implement one control. Get compliance credit from multiple frameworks. That’s how you scale a small team across 93 controls without drowning.
The Implementation Timeline
Here’s a realistic timeline for a team of 2:
| Phase | Duration | What |
|---|---|---|
| 1. Baseline | Weeks 1–4 | Asset inventory (A.5.9), threat intel feed (A.5.7), vulnerability management process (A.8.8) |
| 2. Core controls | Weeks 5–8 | Auth (A.8.5), config management (A.8.9), monitoring (A.8.16), endpoint (A.8.1), cloud (A.5.23) |
| 3. Data & suppliers | Weeks 9–12 | DLP (A.8.10), supplier security (A.5.19), crypto (A.8.24), backups (A.5.29) |
| 4. Policy & people | Weeks 13–16 | Security policy (A.5.1), training (A.6.3), acceptable use (A.5.10), SoA finalization |
| 5. Verification | Weeks 17–20 | Internal audit, evidence collection, gap closure |
Six months from start to certification-ready. The timeline compresses if you already have some controls running (most teams do — they just don’t have them labeled as controls).
Common Mistakes
Mistake 1: Writing 93 policies. You don’t need one policy per control. A single security policy document with appendices covers A.5.1, A.5.10, and more. One procedure for vulnerability management covers A.8.8. One for access control covers A.8.5.
Mistake 2: Implementing A.7 before A.8. If you’re mostly cloud, physical controls (A.7) can wait. Get your cloud security right first, then revisit physical controls when you add on-prem.
Mistake 3: Automating verification but not monitoring. A cron job that runs a check and logs the result is nice. A cron job that alerts when the check fails is useful. Don’t settle for nice.
Mistake 4: Skipping the SoA justification review. “Not applicable: N/A” gets flagged in audit. “Not applicable: all infra is AWS, no on-prem data centers” passes. Write justifications that a non-employee can verify.
Mistake 5: Treating ISO 27001 as the goal. It’s not. It’s a framework that helps you build security. The goal is fewer breaches, faster detection, and easier audits. ISO 27001 is the map, not the destination.
Conclusion
93 controls sounds overwhelming until you realize you don’t need to implement all of them from scratch. Start with the 14 that prevent the most common attacks. Automate the verification. Document “not applicable” with real justifications. Map each control to multiple frameworks. Accept trade-offs explicitly.
The teams that succeed at ISO 27001 aren’t the ones with the biggest compliance staff. They’re the ones that treat the standard as a prioritization framework, not a checklist. Controls that prevent breaches get implemented first. Audit theater gets deferred. Everything else is documented.