The Afternoon 37 Controls Became 37 Separate Projects
Marcus Webb had a spreadsheet problem before he had a security problem. As the newly hired Head of Information Security at Halden Logistics — a 340-employee freight brokerage running certification toward its first ISO 27001 audit — Marcus inherited a Statement of Applicability with all 93 Annex A controls marked "applicable" and a project tracker that had turned each one into its own Jira epic. Thirty-seven of those epics belonged to the Organizational theme alone, and every one of them had been assigned, independently, to a different manager: IT owned "access control," HR owned "screening" (a People control, but nobody had noticed), Legal owned "compliance," and the outsourced helpdesk vendor had somehow been made accountable for "contact with authorities."
Six months and roughly $180,000 in contractor day-rates later, Halden had produced 37 disconnected policy documents, none of which referenced each other, three of which contradicted each other on data retention, and zero of which had been operationalized. The external auditor's Stage 1 review took one look at the document set and handed back a nonconformity for lack of a coherent management system — the individual controls existed on paper, but nothing tied them together the way Clause 6 planning and risk treatment are supposed to. Marcus had spent a security budget the size of a small acquisition treating Annex A's biggest theme as 37 unrelated homework assignments instead of what it actually is: seven or eight tightly related clusters that reinforce each other.
That is the mistake this article exists to prevent. The Organizational controls are not a checklist to plow through top to bottom — they are a system of governance, asset stewardship, access discipline, supplier oversight, incident response, continuity, and legal/compliance obligations that, done right, take a fraction of Halden's spend and timeline. Understanding how the 37 controls cluster — and which ones genuinely apply to your context versus which ones are boilerplate for a five-person SaaS startup — is the single highest-leverage thing you can do before you start writing policy.
What makes this theme uniquely dangerous to under-plan is scale: 37 is a large enough number that most teams instinctively reach for a spreadsheet and a division-of-labor mindset rather than a systems mindset. Compare that to the People theme's 8 controls or Continuity's 2 — nobody tries to "divide and conquer" a theme that small. But at 37 controls spanning governance, assets, access, suppliers, incidents, continuity, and law, the temptation to parallelize by simply assigning numbers to whoever's available is enormous, and it is exactly the wrong instinct. Marcus didn't lack good people at Halden. He lacked a map of how the pieces fit together before he started handing out assignments — which is the gap this article is built to close.
Who This Is For
This article is for the person who has just been told "we're doing ISO 27001" and has opened Annex A for the first time to see 37 organizational line items staring back. It's for ISMS managers building their Statement of Applicability who need to understand what each control actually demands before they can justify an inclusion or exclusion. It's for consultants who need a fast, accurate reference to walk a client through in a scoping call. You'll walk away able to name and explain every one of the 37 Organizational controls, know which clusters matter most for a typical mid-size organization, and have a sequencing plan that doesn't burn six figures re-learning what Marcus learned the hard way.
Four Themes, 93 Controls, and Where Organizational Sits
ISO/IEC 27001:2022's Annex A restructured what used to be 14 loosely-numbered clause groupings into four clean themes covering 93 controls total: Organizational (5.1–5.37, 37 controls), People (6.1–6.8, 8 controls), Physical (7.1–7.14, 14 controls), and Technological (8.1–8.34, 34 controls). Organizational is, by a wide margin, the largest theme — accounting for exactly 40% of all Annex A controls. If you've read the deep dive on the differences between the standard and its companion guidance, in ISO 27001 vs ISO 27002: Understanding the Difference, you already know that ISO 27001 mandates that these controls exist and be justified in the SoA, while ISO 27002:2022 is where the "how" guidance lives.
Why so many controls in one theme? Because "Organizational" is really a catch-all for everything that isn't a physical control (locks, cabling, entry systems), a people control (screening, training, disciplinary process), or a technological control (encryption, logging, malware defense). It covers governance, policy, roles, asset stewardship, access management, supplier oversight, incident response, continuity, and legal/compliance — in other words, most of what a management system is. That's precisely why treating it as 37 flat line items backfires: the theme is internally structured, even though the standard presents it as a flat numbered list.
The Five ISO 27002 Attributes, Briefly
ISO 27002:2022 tags every control — Organizational controls included — with five attributes that help you slice Annex A different ways depending on the audience you're briefing. Control type (preventive, detective, corrective) tells you where in the timeline a control acts. Information security properties map to confidentiality, integrity, and availability (C/I/A). Cybersecurity concepts align to the five NIST-style functions: Identify, Protect, Detect, Respond, Recover. Operational capabilities describe the practical domain (governance, asset management, human resource security, and so on). Security domains group controls into governance-and-ecosystem, protection, defense, and resilience. You don't need to memorize the attribute values for all 93 controls, but knowing they exist matters: when an auditor or a board member asks "how does this control help us detect an incident faster," the attribute framework is the vocabulary ISO expects you to use in that answer.
What the Attributes Look Like Applied
The attributes only earn their keep once you see them applied to real controls. Here's a worked sample across five Organizational controls spanning different parts of the theme, showing how the same control can be tagged for entirely different audiences depending on which attribute you lead with.
Control | Control Type | C/I/A Property | Cybersecurity Concept | Typical Audience Use |
|---|---|---|---|---|
5.1 Policies for information security | Preventive | Confidentiality, Integrity, Availability | Identify, Protect | Board-level governance reporting |
5.7 Threat intelligence | Preventive, Detective | Confidentiality, Integrity, Availability | Identify, Detect | Security operations prioritization |
5.15 Access control | Preventive | Confidentiality, Integrity | Protect | IT and audit committee reporting |
5.24 Incident management planning and preparation | Preventive, Corrective | Confidentiality, Integrity, Availability | Respond, Recover | Executive incident-readiness briefing |
5.34 Privacy and protection of PII | Preventive | Confidentiality | Protect | Legal and privacy program reporting |
Notice the pattern: governance controls (5.1) skew preventive and touch all three C/I/A properties because policy is meant to shape everything downstream; incident controls (5.24) are explicitly tagged Respond and Recover because that's their job in the lifecycle, not prevention. When you're building a board deck or a risk committee report, leading with the cybersecurity concept attribute (Identify/Protect/Detect/Respond/Recover) rather than the raw control number is almost always the more persuasive framing — it answers "why does this matter" instead of just "what is this."
Grouping the 37 Into Clusters That Actually Work Together
Here's the map we'll use for the rest of this article — seven clusters, each a coherent unit of work rather than a grab-bag of numbers:
Governance and Policy (5.1–5.8) — the constitution of your ISMS.
Asset and Information Management (5.9–5.14) — knowing what you have and how it's handled.
Access Control and Identity (5.15–5.18) — who gets in, and how.
Supplier and Cloud (5.19–5.23) — extending your controls to third parties.
Incident Management (5.24–5.28) — the lifecycle of a bad day.
Continuity (5.29–5.30) — staying operational when things break.
Legal, Compliance, and Privacy (5.31–5.37) — the obligations that don't go away just because you're certified.
Each cluster below gets a table with what the control requires, what "good" looks like in practice, and the most common gap I see in initial assessments.
Cluster 1: Governance and Policy Foundations (5.1–5.8)
This cluster is the constitutional layer — the controls that establish who decides what and how decisions get written down and enforced. Get this cluster wrong and every downstream control inherits the weakness, because none of the other 30 controls have an authority structure to hang off of.
Control | What It Requires | What Good Looks Like | Common Gap |
|---|---|---|---|
5.1 Policies for information security | A top-level information security policy, approved by management, communicated, and periodically reviewed | A concise policy set (not one 80-page document) with clear ownership, version control, and a defined review cadence tied to Clause 9 management review | Policy written once for the audit and never touched again |
5.2 Information security roles and responsibilities | Defined, allocated, and communicated security roles | A RACI-style matrix naming actual people (or roles), not "IT department" | Responsibilities exist only in job descriptions nobody has read since onboarding |
5.3 Segregation of duties | Conflicting duties and responsibilities separated to reduce misuse risk | Documented separation between requesting, approving, and executing sensitive actions (e.g., code deploy vs. code review vs. production access) | Small teams claim segregation is "impossible," when compensating controls (dual approval, logging) were never considered |
5.4 Management responsibilities | Management actively requires all personnel to apply security in line with policy | Managers include security expectations in onboarding, performance reviews, and team meetings, not just HR paperwork | Security treated as "IT's job" with no line-management reinforcement |
5.5 Contact with authorities | Defined process and contact points for authorities (law enforcement, regulators, supervisory bodies) | A maintained contact list with escalation triggers, tested at least annually | Contact list exists but nobody knows when it's supposed to be used |
5.6 Contact with special interest groups | Appropriate contact with security forums, professional associations, and threat-sharing communities | Active membership in an ISAC, vendor security bulletin subscriptions, or peer CISO networks with evidence of information actually being used | "Contact" limited to one LinkedIn connection with no evidence of exchange |
5.7 Threat intelligence (new in 2022) | Collection and analysis of information relating to threats, to inform mitigating action | A structured feed (commercial, open-source, or sector-specific) reviewed on a cadence and tied to risk register updates | Threat intel treated as a newsletter nobody reads rather than an input to risk treatment |
5.8 Information security in project management | Security integrated into project management methodology, regardless of project type | Security checkpoints built into the standard project template — from kickoff through go-live — not a bolt-on review at the end | Security only invited to review after the architecture is already locked in |
Three of these controls deserve their own deep dive because of how often teams get them subtly wrong: our full breakdown of Information Security Policies: ISO 27001 Control 5.1 Explained covers policy structure and review cadence in detail, our guide to Roles and Responsibilities in Information Security: ISO 27001 Controls 5.2–5.4 walks through building a real RACI, and our dedicated piece on Threat Intelligence and ISO 27001: Control 5.7 Implementation Guide is essential reading since 5.7 is one of the eleven controls new to the 2022 revision and auditors are still calibrating how much evidence they expect. Likewise, Information Security in Project Management: ISO 27001 Control 5.8 explains how to avoid the "security as a gate at the end" trap.
"We treated 5.1 through 5.8 as paperwork until our first internal audit flagged that nobody outside the security team could explain who owned what. Once we built a single-page RACI and hung it in the incident channel, three other controls got easier overnight — because half our 'gaps' were really just unclear ownership wearing different disguises." — Priya Anand, Director of Governance, Rutherglen Health Analytics
Cluster 2: Asset and Information Management (5.9–5.14)
You cannot protect what you haven't inventoried, and you cannot classify what you haven't inventoried consistently. This cluster is where "security" starts to look like operational discipline rather than policy theater — it's also, in my experience across audits, the cluster most likely to be underscoped in a Statement of Applicability because organizations assume a spreadsheet from three years ago still counts as an inventory.
Control | What It Requires | What Good Looks Like | Common Gap |
|---|---|---|---|
5.9 Inventory of information and other associated assets | An accurate, maintained inventory of information and assets, with owners assigned | An asset register (CMDB or equivalent) reconciled at least quarterly against actual infrastructure and SaaS usage | Inventory built once for certification, drifting out of date within weeks |
5.10 Acceptable use of information and other associated assets | Rules for acceptable use of assets identified, documented, and implemented | An acceptable use policy acknowledged at onboarding and re-acknowledged annually, with real enforcement examples | Policy exists in the handbook but has never been referenced in a disciplinary case |
5.11 Return of assets | Personnel return organizational assets on change or termination of employment | An offboarding checklist tied to HR systems that blocks final payroll/exit sign-off until assets are confirmed returned | Laptops and access badges "returned eventually," with no hard gate in the offboarding process |
5.12 Classification of information | Information classified according to confidentiality, integrity, availability, and relevant legal requirements | A simple 3–4 tier classification scheme (e.g., Public, Internal, Confidential, Restricted) applied consistently across systems, not just documents | Classification scheme exists on paper but most files and repositories are never actually labeled |
5.13 Labelling of information | Procedures for information labelling developed and implemented in line with the classification scheme | Automated labelling (email headers, document metadata, storage bucket tags) wherever tooling allows, manual labelling where it doesn't | Labelling policy assumes manual discipline at scale, which quietly fails within months |
5.14 Information transfer | Rules, procedures, and agreements for information transfer, internally and with external parties | Defined secure transfer mechanisms (encrypted file transfer, DLP-checked email, contractual transfer clauses) mapped to classification tiers | "Transfer rules" only cover email, missing SaaS-to-SaaS integrations and API transfers |
Control 5.12 is a control we get more scoping questions about than almost any other in this cluster, because organizations conflate "we have a policy" with "we classify things." A dedicated deep dive on classification of information (proposed slug: iso-27001-control-5-12-classification-of-information) is not yet published on this pillar, but if you're building your SoA now, treat 5.12 as a prerequisite for 5.13 and much of the Technological theme's data protection controls — you cannot apply data-handling rules you haven't defined.
"Our asset inventory looked complete until we ran a shadow-IT discovery scan and found 40 SaaS tools nobody in security had approved. Control 5.9 isn't a one-time spreadsheet — it's a living process, and the day we started reconciling it monthly was the day our audit findings dropped by half." — Devon Okafor, IT Asset Manager, Bramwell Financial Services
Cluster 3: Access Control and Identity (5.15–5.18)
This cluster is small in number but enormous in blast radius — access control failures show up in nearly every breach case study you'll ever read. It's also the cluster with the tightest interlock with the Technological theme: the Organizational controls here set the rules, while controls like privileged access rights (8.2) and secure authentication (8.5) implement them technically.
Control | What It Requires | What Good Looks Like | Common Gap |
|---|---|---|---|
5.15 Access control | Rules to control physical and logical access based on business and security requirements | A documented access control policy following least-privilege and need-to-know, reviewed against business requirements at least annually | Policy references "role-based access" but roles were never formally mapped to systems |
5.16 Identity management | Full lifecycle management of identities | A single source of truth for identity (directory service) with automated joiner-mover-leaver workflows | Multiple disconnected identity stores with manual reconciliation "when someone remembers" |
5.17 Authentication information | Allocation and management of authentication information (passwords, tokens, keys) controlled by a process, including secure handling | A managed credential lifecycle with enforced rotation, secure storage (password managers/vaults), and MFA as standard | Shared credentials for service accounts with no rotation or ownership |
5.18 Access rights | Access rights provisioned, reviewed, modified, and removed in accordance with the access control policy | Quarterly (or more frequent for privileged access) access recertification with evidence of removed/adjusted entitlements | Access reviews performed but findings never actioned — "reviewed" becomes a checkbox, not a control |
Control 5.15 in particular deserves its own deep dive given how much weight auditors place on it — a full breakdown of access control (proposed slug: iso-27001-control-5-15-access-control) is on our roadmap but not yet published; until then, treat the table above as your working reference, and lean on the ISMS Core Concepts article for how access governance fits into the broader management system.
"5.18 was our most embarrassing finding two audits running. We did the access reviews — we just never closed the loop on revoking anything the review flagged. The control isn't 'review access.' It's 'review, then actually change something.'" — Lena Marchetti, Identity and Access Manager, Corvid Underwriting Group
Cluster 4: Supplier and Cloud Relationships (5.19–5.23)
Five controls, and arguably the fastest-growing source of audit findings across the organizations I've worked with in the last three years, because supply chains and cloud footprints have grown faster than most third-party risk programs have matured.
Control | What It Requires | What Good Looks Like | Common Gap |
|---|---|---|---|
5.19 Information security in supplier relationships | Processes to manage security risks associated with supplier products and services | A tiered supplier risk assessment process (critical/high/medium/low) applied before onboarding any new vendor | Supplier risk assessed once at signing, never revisited over the life of the contract |
5.20 Addressing information security within supplier agreements | Relevant security requirements established and agreed with each supplier | Standard security addendum/clauses in the master service agreement template, scaled by supplier tier | Security requirements exist as a side letter that legal never actually attaches to signed contracts |
5.21 Managing information security in the ICT supply chain | Processes to manage security risks in the ICT supply chain (sub-suppliers, hardware, software) | Visibility into fourth-party dependencies for critical suppliers, with contractual flow-down of security obligations | No visibility beyond the direct supplier — sub-processors are a black box |
5.22 Monitoring, review and change management of supplier services | Regular monitoring, review, and change management of supplier security practices | Scheduled supplier reviews (SOC 2 reports, penetration test summaries, security questionnaires) with a defined escalation path for gaps | Supplier questionnaire collected once at onboarding and filed away, never revisited |
5.23 Information security for use of cloud services (new in 2022) | Processes for acquisition, use, management, and exit from cloud services | A cloud security policy covering shared-responsibility boundaries, configuration baselines, and a documented exit/portability plan for each cloud provider | Organizations assume the cloud provider's certifications (e.g., ISO 27001, SOC 2) cover their own configuration responsibilities |
Control 5.23 is one of the three organizational controls new to the 2022 revision (alongside 5.7 and 5.30), and it's the one auditors ask about most often now that nearly every organization runs meaningfully on cloud infrastructure — the shared-responsibility model is a frequent nonconformity trigger because teams assume the provider's certification transfers to them. Supplier relationships more broadly (control 5.19) is a topic deep enough to warrant its own article — a dedicated deep dive on information security in supplier relationships (proposed slug: iso-27001-control-5-19-supplier-relationships) is not yet published on this pillar, but the gap analysis in your SoA should flag it as a priority regardless.
"5.23 caught us off guard. We'd assumed our cloud provider's own ISO 27001 certificate meant we inherited compliance. Our auditor's first question was 'show me your configuration baseline for the buckets you control' — and we didn't have one. That was a $40,000 quarter of remediation we could have avoided with a two-page policy written six months earlier." — Tomás Ferreira, Cloud Security Lead, Halyard Retail Group
If your organization operates across regulatory regimes, this cluster is also where cross-pillar thinking pays off — supplier and cloud obligations under ISO 27001 overlap heavily with vendor-management expectations in frameworks like SOC 2 and the EU's DORA third-party risk requirements, so mapping your supplier tiering once and reusing it across frameworks saves real audit-prep time.
Cluster 5: Incident Management (5.24–5.28)
Five controls that form a single lifecycle — planning, triage, response, learning, and evidence — and one of the clusters where I most often see organizations implement the middle (response) while skipping the bookends (planning and learning).
Control | What It Requires | What Good Looks Like | Common Gap |
|---|---|---|---|
5.24 Information security incident management planning and preparation | Roles, responsibilities, and processes for incident management defined in advance | A documented incident response plan with named roles, communication templates, and a tested tabletop exercise cadence | Plan exists as a document but has never been rehearsed against a realistic scenario |
5.25 Assessment and decision on information security events | Consistent process to assess events and decide if they qualify as incidents | A triage matrix (severity criteria, escalation thresholds) applied consistently, not left to individual judgment | Every event is escalated as a full incident, or conversely, real incidents are dismissed as "just an alert" |
5.26 Response to information security incidents | Incidents responded to according to documented procedures | Response playbooks per incident category (ransomware, data exposure, DDoS) with clear containment and communication steps | One generic playbook used regardless of incident type, slowing containment |
5.27 Learning from information security incidents | Knowledge gained from incidents used to strengthen controls | Formal post-incident reviews that feed directly into risk register updates and control changes | Post-mortems written and filed, but corrective actions never tracked to closure |
5.28 Collection of evidence | Procedures for identification, collection, acquisition, and preservation of evidence | A defined chain-of-custody process, especially where legal or regulatory action may follow | Evidence collected informally, undermining its usability in legal or disciplinary proceedings |
Incident management planning (control 5.24) is frequently the single most-cited nonconformity source in Stage 2 audits I've supported, because organizations conflate "we have an incident response plan" with "we have exercised it." A dedicated deep dive on incident management planning and preparation (proposed slug: iso-27001-control-5-24-incident-management-planning) is not yet live on this pillar — treat the table above as your interim reference and prioritize at least one tabletop exercise before your certification audit.
"5.27 is the control that separates organizations that mature year over year from organizations that have the same audit findings every cycle. We started requiring every incident post-mortem to produce at least one line item in the risk register, no exceptions — and our repeat findings dropped to zero within two audit cycles." — Grace Liu, Head of Security Operations, Northfield Insurance Partners
Cluster 6: Continuity (5.29–5.30)
Only two controls, but they carry outsized weight because they're where information security intersects with business continuity management — a discipline many organizations run in a completely different department with its own plans that never mention information security at all.
Control | What It Requires | What Good Looks Like | Common Gap |
|---|---|---|---|
5.29 Information security during disruption | Information security maintained at an appropriate level during disruption | Security requirements explicitly built into business continuity and disaster recovery plans, not treated as "paused" during an incident | Security controls quietly relaxed during a disruption "to get things back up faster," creating a second incident |
5.30 ICT readiness for business continuity (new in 2022) | ICT readiness planned, implemented, maintained, and tested based on business continuity objectives | Tested ICT recovery capability (backups, failover, recovery time/point objectives) aligned to actual business continuity requirements, not just IT's assumptions | Backup and recovery exists technically but has never been tested against the business's actual RTO/RPO targets |
Control 5.30 is the third of the three organizational controls new in the 2022 revision, and it exists specifically to close a gap the 2013 version left open: business continuity plans that assumed IT recovery would "just happen" without ever defining or testing what "recovery" actually meant in ICT terms. If your organization already runs disaster recovery testing, the gap here is usually less about capability and more about documented alignment to business continuity objectives — auditors want to see the thread connecting a business impact analysis to an actual ICT recovery time.
Cluster 7: Legal, Compliance, and Privacy (5.31–5.37)
The final cluster, and the one most likely to overlap with obligations you already have outside of ISO 27001 — GDPR, sector regulation, contractual commitments. This is also where the standard is most explicit that certification supports, rather than replaces, your legal obligations.
Control | What It Requires | What Good Looks Like | Common Gap |
|---|---|---|---|
5.31 Legal, statutory, regulatory and contractual requirements | Requirements identified, documented, and kept up to date | A maintained legal/regulatory register reviewed at least annually and after major regulatory change | Register built once during scoping and never revisited as laws change |
5.32 Intellectual property rights | Procedures to protect intellectual property rights | Clear ownership and licensing controls for software, content, and proprietary data, including license compliance audits | Software license compliance handled informally, with no audit trail |
5.33 Protection of records | Records protected from loss, destruction, falsification, and unauthorized access, in line with legal/regulatory/contractual requirements | A records retention schedule mapped to legal requirements, with defined secure disposal timelines | Retention "forever by default" because nobody wants to decide what to delete |
5.34 Privacy and protection of personal identifiable information (PII) | Compliance with applicable privacy legislation and contractual requirements identified and met | A privacy program aligned with applicable law (e.g., supporting GDPR obligations), with data mapping and a named privacy owner | Privacy treated as a legal-team-only concern with no operational link to the ISMS |
5.35 Independent review of information security | Independent review of the organization's approach to security at planned intervals or after significant change | Genuinely independent reviews (internal audit function separate from the team being audited, or external assessors), not self-assessment | "Independent" review performed by the same person who implemented the controls |
5.36 Compliance with policies, rules and standards for information security | Compliance with the organization's own security policy regularly reviewed | A compliance monitoring calendar checking business units against internal policy, not just external standards | Compliance checked only during the external certification audit window |
5.37 Documented operating procedures | Operating procedures for information processing facilities documented and available | Living runbooks maintained alongside the systems they describe, version-controlled and reviewed on change | Procedures written once at go-live and never updated as systems change |
Control 5.34 deserves a callout: ISO 27001 certification supports privacy obligations like GDPR — it does not, on its own, make an organization "GDPR compliant." Treat control 5.34 as the bridge between your ISMS and your privacy program, not a replacement for one. If you operate in multiple jurisdictions, our sibling coverage of GDPR's data protection impact assessment requirements is worth reading alongside this control specifically.
"Legal thought ISO 27001 would 'handle' our GDPR obligations. It doesn't — 5.34 just makes sure privacy has a formal seat inside the ISMS. Once we mapped our data flows and named an actual privacy owner, the two programs started reinforcing each other instead of competing for the same three people's time." — Sofia Kowalski, Data Protection Officer, Meridian Health Alliance
Quick Reference: All 37 Organizational Controls at a Glance
Once you've worked through all seven clusters, it helps to see the full set in one place — useful as a working checklist when you're building your SoA line by line or briefing a colleague who needs the whole picture in under a minute.
# | Control | Cluster |
|---|---|---|
5.1 | Policies for information security | Governance and Policy |
5.2 | Information security roles and responsibilities | Governance and Policy |
5.3 | Segregation of duties | Governance and Policy |
5.4 | Management responsibilities | Governance and Policy |
5.5 | Contact with authorities | Governance and Policy |
5.6 | Contact with special interest groups | Governance and Policy |
5.7 | Threat intelligence (new in 2022) | Governance and Policy |
5.8 | Information security in project management | Governance and Policy |
5.9 | Inventory of information and other associated assets | Asset and Information Management |
5.10 | Acceptable use of information and other associated assets | Asset and Information Management |
5.11 | Return of assets | Asset and Information Management |
5.12 | Classification of information | Asset and Information Management |
5.13 | Labelling of information | Asset and Information Management |
5.14 | Information transfer | Asset and Information Management |
5.15 | Access control | Access Control and Identity |
5.16 | Identity management | Access Control and Identity |
5.17 | Authentication information | Access Control and Identity |
5.18 | Access rights | Access Control and Identity |
5.19 | Information security in supplier relationships | Supplier and Cloud |
5.20 | Addressing information security within supplier agreements | Supplier and Cloud |
5.21 | Managing information security in the ICT supply chain | Supplier and Cloud |
5.22 | Monitoring, review and change management of supplier services | Supplier and Cloud |
5.23 | Information security for use of cloud services (new in 2022) | Supplier and Cloud |
5.24 | Information security incident management planning and preparation | Incident Management |
5.25 | Assessment and decision on information security events | Incident Management |
5.26 | Response to information security incidents | Incident Management |
5.27 | Learning from information security incidents | Incident Management |
5.28 | Collection of evidence | Incident Management |
5.29 | Information security during disruption | Continuity |
5.30 | ICT readiness for business continuity (new in 2022) | Continuity |
5.31 | Legal, statutory, regulatory and contractual requirements | Legal, Compliance, and Privacy |
5.32 | Intellectual property rights | Legal, Compliance, and Privacy |
5.33 | Protection of records | Legal, Compliance, and Privacy |
5.34 | Privacy and protection of personal identifiable information (PII) | Legal, Compliance, and Privacy |
5.35 | Independent review of information security | Legal, Compliance, and Privacy |
5.36 | Compliance with policies, rules and standards for information security | Legal, Compliance, and Privacy |
5.37 | Documented operating procedures | Legal, Compliance, and Privacy |
Keep this table next to your Statement of Applicability as you draft it — every row here needs a corresponding row in your SoA, and the cluster column tells you which governance narrative each control's justification should reference.
What This Theme Costs: Illustrative Effort and Budget by Cluster
Every organization's numbers will differ, but clients consistently ask for a ballpark before they commit to a program. The figures below are illustrative estimates drawn from mid-size implementations (roughly 100–500 employees) and are meant to guide relative prioritization, not to substitute for your own scoping exercise.
Cluster | Typical Effort (Person-Weeks) | Illustrative Budget Range | Primary Cost Driver |
|---|---|---|---|
1. Governance and Policy (5.1–5.8) | 6–10 | $15,000–$30,000 | Policy drafting, RACI workshops, leadership sign-off cycles |
2. Asset and Information Management (5.9–5.14) | 8–14 | $20,000–$45,000 | Asset discovery tooling, classification workshops, labelling rollout |
3. Access Control and Identity (5.15–5.18) | 6–12 | $18,000–$50,000 | Identity governance tooling, access recertification process design |
4. Supplier and Cloud (5.19–5.23) | 10–16 | $25,000–$60,000 | Vendor risk tiering, contract renegotiation, cloud configuration baselining |
5. Incident Management (5.24–5.28) | 6–10 | $15,000–$40,000 | Playbook development, tabletop exercises, evidence-handling procedures |
6. Continuity (5.29–5.30) | 4–8 | $10,000–$30,000 | DR/BC testing, RTO/RPO alignment work |
7. Legal, Compliance, and Privacy (5.31–5.37) | 6–10 | $15,000–$35,000 | Legal register maintenance, privacy program alignment, independent review |
Two patterns hold up across nearly every engagement I've run: Supplier and Cloud (Cluster 4) is almost always the most expensive cluster in both time and dollars, because it depends on external parties who don't move on your timeline, and Continuity (Cluster 6) is almost always the cheapest in raw control count but frequently gets bottlenecked by needing sign-off from a business continuity function outside of security's direct control. Budget your program calendar around those two realities specifically — start supplier work early, and secure business continuity stakeholder time well before you need it.
Which Controls Are Near-Universal vs Context-Dependent
Not all 37 controls carry equal weight for every organization, and one of the fastest ways to blow a budget the way Halden Logistics did is to treat them as uniformly heavy. In my experience across more than 200 implementations, a clear pattern emerges.
Tier | Controls | Why |
|---|---|---|
Near-universal (almost always fully applicable) | 5.1, 5.2, 5.9, 5.15, 5.16, 5.17, 5.18, 5.24, 5.25, 5.26, 5.31, 5.36, 5.37 | Core governance, identity, incident response, and legal-compliance controls apply regardless of size, sector, or business model |
Usually applicable, scoped by size | 5.3, 5.4, 5.8, 5.10, 5.11, 5.12, 5.13, 5.14, 5.27, 5.28, 5.29, 5.35 | Applicable almost everywhere, but the depth of implementation scales heavily with headcount and system complexity |
Context-dependent | 5.5, 5.6, 5.7, 5.19, 5.20, 5.21, 5.22, 5.23, 5.30, 5.32, 5.33, 5.34 | Weight depends heavily on regulatory exposure, supply chain complexity, cloud footprint, IP intensity, and jurisdiction |
A five-person SaaS startup with no physical offices, no regulated data, and a single cloud provider will justify very different depth on 5.19–5.23 (supplier and cloud) than a 2,000-employee logistics company running dozens of ICT sub-processors. That's not an excuse to exclude a control from the SoA — under ISO 27001, exclusion requires a documented risk-based justification, not convenience — but it is a legitimate basis for scaling the rigor of implementation.
"The question I ask every client before we scope Organizational controls is: which of these 37 would genuinely embarrass you in a regulator's office, and which would just be an audit finding? That question alone reorders the priority list faster than any framework matrix." — Marcus Webb, Head of Information Security, Halden Logistics (post-remediation)
A Practical Implementation Sequence
Sequencing matters more than most teams expect, because several controls are genuine prerequisites for others. Here's the order I recommend, mapped against the clusters above.
Phase | Controls to Prioritize | Rationale |
|---|---|---|
Phase 1 — Foundation (weeks 1–6) | 5.1, 5.2, 5.4, 5.9, 5.15 | Policy, ownership, and asset visibility are prerequisites for almost everything else |
Phase 2 — Access and Data Discipline (weeks 4–10, overlapping) | 5.3, 5.10, 5.11, 5.12, 5.13, 5.16, 5.17, 5.18 | Once you know your assets and owners, lock down who touches them and how they're classified |
Phase 3 — Operational Readiness (weeks 8–14) | 5.8, 5.14, 5.24, 5.25, 5.26, 5.37 | Build the muscle memory for handling events and running documented procedures before you rely on it under pressure |
Phase 4 — Extended Ecosystem (weeks 10–16) | 5.19, 5.20, 5.21, 5.22, 5.23 | Supplier and cloud controls take longest because they depend on contract cycles and vendor cooperation — start these early even though they land later |
Phase 5 — Resilience and Learning (weeks 14–18) | 5.27, 5.28, 5.29, 5.30 | Incident learning and continuity testing depend on having a functioning incident process (Phase 3) already in place |
Phase 6 — Assurance and Legal Closure (weeks 16–20) | 5.5, 5.6, 5.7, 5.31, 5.32, 5.33, 5.34, 5.35, 5.36 | Independent review and legal/compliance sign-off logically come after the operational controls they're reviewing |
This is a reference sequence, not a rigid schedule — a 20-week timeline compresses hard for a smaller organization and stretches for a global enterprise with multiple business units. What doesn't change is the dependency logic: don't build supplier security requirements (5.20) before you've classified the data you're asking suppliers to protect (5.12), and don't attempt independent review (5.35) before the controls being reviewed have had time to operate.
The most common sequencing mistake I see isn't skipping a phase — it's running every phase in parallel from day one because a project sponsor wants "visible progress everywhere" for a steering committee update. That instinct produces exactly the Halden Logistics outcome: 37 workstreams moving simultaneously with no shared foundation, so every cluster has to be partially redone once the governance layer (Phase 1) finally solidifies and everyone realizes their asset definitions, role names, or classification tiers don't match. It is genuinely faster, start to finish, to let Phase 1 finish first even if it means three or four weeks where the steering committee sees "only" governance work underway.
Mapping the 37 Controls to Your Statement of Applicability
Every one of these 37 controls needs a line in your Statement of Applicability — applicable or not, with justification either way. In practice, the SoA is where the clustering approach in this article pays off directly: instead of writing 37 independent justifications, write one governance narrative per cluster (why this cluster matters to your risk profile, per the risk assessment done under ISO 27001 Clause 6: Planning) and then a short, specific justification per control that references the cluster narrative. Auditors read SoAs that show a coherent risk-based logic far more favorably than SoAs that read like 37 copy-pasted paragraphs with the control number swapped out.
SoA Column | What to Capture Per Control |
|---|---|
Control reference | Exact Annex A number and name (e.g., "5.23 Information security for use of cloud services") |
Applicable (Y/N) | Justified by risk assessment, not convenience |
Justification for inclusion/exclusion | Tied to the cluster-level risk narrative, plus anything control-specific |
Implementation status | Not started / in progress / operating / independently reviewed |
Evidence reference | Link to the policy, procedure, or record demonstrating operation |
A very small number of Organizational controls are legitimately excludable in narrow circumstances — for example, 5.6 (contact with special interest groups) might be marked not applicable for a sole proprietor with no employees to send to forums — but the overwhelming majority of the 37 apply to any organization pursuing certification. Treat "we don't need this one" as the exception you have to justify, not the default.
Evidence Auditors Actually Ask to See, By Cluster
Knowing what a control requires is only half the job — you also need to know what an auditor will ask to see. Documentation alone rarely satisfies a Stage 2 auditor; they're looking for operating evidence, meaning records that prove the control has actually run, not just that it's been written down.
Cluster | Documentation Auditors Expect | Operating Evidence Auditors Actually Ask For |
|---|---|---|
Governance and Policy | Policy set, RACI matrix | Meeting minutes referencing security, evidence of management review cadence |
Asset and Information Management | Asset register, classification scheme | Reconciliation logs, sample of labelled documents/systems |
Access Control and Identity | Access control policy, identity lifecycle procedure | Access recertification records, joiner-mover-leaver tickets with timestamps |
Supplier and Cloud | Supplier risk process, cloud security policy | Signed vendor security addenda, supplier review meeting notes, cloud configuration baseline exports |
Incident Management | Incident response plan, playbooks | Tabletop exercise records, real incident tickets showing triage-to-closure, post-incident review outputs |
Continuity | Business continuity plan, ICT recovery plan | DR test results with actual RTO/RPO measurements against targets |
Legal, Compliance, and Privacy | Legal register, privacy program documentation | Independent review reports, compliance monitoring records, evidence of corrective action closure |
If you take one thing from this table into your audit preparation, make it this: for every policy document you produce, plan to produce at least one corresponding operating record before your Stage 2 audit. A policy with zero operating evidence behind it is the single most common source of major nonconformities across the engagements I've supported.
Case Study 1: The Mid-Market Manufacturer That Clustered Its Way to Certification
Ashgrove Industrial Components, a 190-employee precision manufacturer supplying automotive suppliers, began its ISO 27001 program the same way Halden did — a flat 37-item spreadsheet assigned by control number to whichever manager happened to be free. After a failed internal readiness assessment flagged inconsistent ownership and contradictory documentation, the new ISMS manager, Aaron Reyes, restructured the entire Organizational theme into the seven clusters described above, assigning one accountable owner per cluster instead of one owner per control. Governance and Policy (5.1–5.8) went to the CISO directly; Supplier and Cloud (5.19–5.23) went to procurement working jointly with IT; Legal, Compliance, and Privacy (5.31–5.37) went to the general counsel's office. The result: 37 controls collapsed into 7 owned work-streams, each producing one coherent policy document instead of five to six fragmented ones. Total remediation cost came in at approximately $62,000 — roughly a third of what Halden spent for a comparably sized organization — and Ashgrove passed Stage 2 with two minor nonconformities, both in the Technological theme, none in Organizational.
Case Study 2: The Fintech Startup That Over-Scoped Supplier Controls
Verrado Payments Technologies, a 45-person payments startup, made the opposite mistake: recognizing that supplier and cloud controls (5.19–5.23) were "important," the team spent four months building an enterprise-grade third-party risk program — annual on-site supplier audits, custom risk-scoring software, a 40-question due-diligence questionnaire sent to every vendor including the office coffee supplier. The effort consumed roughly $95,000 in contractor and tooling spend before the fractional CISO brought in for the certification push pointed out that Verrado had exactly four suppliers with access to cardholder-adjacent data and eleven with no data access at all. Rescoping supplier risk tiers to match actual exposure — full rigor for the four critical suppliers, a lightweight questionnaire for everyone else — cut the ongoing program cost by roughly 70% while satisfying the same control requirements, and freed budget that was redirected into the incident management cluster (5.24–5.28), which had been comparatively under-resourced.
Case Study 3: The Healthcare Network That Fixed Its Incident Learning Loop
Northshore Community Health Network, operating six clinics and a shared services center, had a functioning incident response process — controls 5.24 through 5.26 were operating well and had been for two audit cycles. What kept generating findings was control 5.27, learning from information security incidents: post-incident reviews were written, filed, and never converted into actual control changes. After the third consecutive minor nonconformity on the same theme, the security team built a simple rule — every post-incident review had to produce at least one line item added to the risk register with an owner and a due date, tracked to closure in the same system used for internal audit findings. Within one full audit cycle, repeat findings on 5.27 dropped to zero, and two other controls (5.9 asset inventory and 5.18 access rights) improved as a side effect, because several of the "lessons learned" turned out to be inventory and access hygiene issues nobody had previously connected to the incident program.
What these three case studies share is more instructive than any single outcome: Ashgrove won by clustering ownership before writing a single policy; Verrado won by matching control rigor to actual risk exposure instead of a generic best-practice template; Northshore won by closing the loop between one control (5.27) and the controls it was supposed to feed (5.9, 5.18). None of the three fixes required new headcount or new tooling budgets — all three were sequencing and ownership corrections, which is precisely why this article leads with clustering and sequencing rather than a tool or vendor recommendation.
Visualizing the Organizational Theme
flowchart TB
A["Annex A Organizational Controls\n5.1 - 5.37 (37 total)"] --> C1
A --> C2
A --> C3
A --> C4
A --> C5
A --> C6
A --> C7
C1["Cluster 1: Governance & Policy\n5.1-5.8"]
C2["Cluster 2: Asset & Information Mgmt\n5.9-5.14"]
C3["Cluster 3: Access Control & Identity\n5.15-5.18"]
C4["Cluster 4: Supplier & Cloud\n5.19-5.23"]
C5["Cluster 5: Incident Management\n5.24-5.28"]
C6["Cluster 6: Continuity\n5.29-5.30"]
C7["Cluster 7: Legal, Compliance & Privacy\n5.31-5.37"]
C1 --> C2
C2 --> C3
C3 --> C4
C1 --> C5
C4 --> C5
C5 --> C6
C1 --> C7
C6 --> C7The dependency arrows aren't arbitrary: governance (Cluster 1) underpins everything, asset visibility (Cluster 2) has to exist before access rules (Cluster 3) mean anything, and a functioning incident process (Cluster 5) is the input both continuity testing (Cluster 6) and legal evidence handling (Cluster 7, via 5.28) depend on.
The Strategic Close: Governance as Competitive Advantage
Here's the reframe that changes how most leadership teams see this theme once they understand it: the Organizational controls are not overhead bolted onto the business — they're the operating discipline that lets a growing company scale without its risk profile scaling faster than its controls. A company that has genuinely operationalized Clusters 1 through 7 — clear governance, known assets, disciplined access, vetted suppliers, a tested incident process, tested continuity, and closed-loop legal compliance — is a company that can answer a customer's security questionnaire in an afternoon instead of a week, onboard a new enterprise client without a six-month security review cycle, and survive a cloud provider outage or a ransomware attempt without an existential crisis. That's the business case Marcus Webb eventually made to Halden's board, after the expensive first pass: certification isn't the finish line, and the 37 Organizational controls, clustered and sequenced correctly, are what makes the rest of Annex A — the People, Physical, and Technological themes — actually function as a system rather than a pile of independent requirements.
There's also a quieter, longer-term payoff worth naming directly: once these seven clusters are operating, most of the ongoing maintenance burden of ISO 27001 shrinks dramatically, because you're maintaining seven living processes rather than re-discovering 37 static documents every audit cycle. Organizations in year three or four of certification who invested properly in this theme up front routinely tell me their annual surveillance audits have become almost boring — which, in this line of work, is the highest compliment a management system can earn.
If you're scoping this theme right now, start by pulling our Annex A — All 93 Controls at a Glance cheat sheet to see how Organizational sits alongside the other three themes, then use our Statement of Applicability (SoA) Template to draft cluster-level justifications instead of 37 disconnected ones. If you're not yet sure how much work is ahead of you, our ISO 27001 Gap Analysis Tool will benchmark your current state against all 37 controls in under an hour, and our ISO 27001 Mandatory Documents Checklist will tell you exactly which policies this theme requires you to produce. For teams building the full program from scratch, The Complete ISO 27001 Implementation Guide walks through sequencing every theme, not just this one, end to end.
Whatever stage you're at, don't do what Halden did first: don't open the spreadsheet and start at control 5.1. Cluster first, sequence second, then start writing.