Organizational controls are where ISO 27001 implementation either holds together or falls apart. Of the 93 controls in Annex A of ISO/IEC 27001:2022, 37 fall under the organizational category covering governance structures, information security policies, risk treatment, supplier relationships, incident management, and business continuity. For US organizations pursuing ISMS certification, these controls form the operational backbone that auditors scrutinize most.
The 2022 revision reorganized and expanded these controls significantly from the 2013 version. Understanding what each control requires and how they connect to frameworks like NIST SP 800-53, CMMC 2.0, and SOC 2 determines whether your implementation passes certification or cycles through corrective actions.
What Are ISO 27001 Organizational Controls?
ISO 27001 Annex A groups its 93 controls into four categories: organizational (37 controls), people (8 controls), physical (14 controls), and technological (34 controls). Organizational controls address the policies, processes, governance structures, and third-party relationships that shape how an organization manages information security at a systemic level.
These are not technical safeguards they are the decisions, structures, and agreements that make technical controls coherent. A firewall rule without an access control policy is a configuration. A configuration without governance is a liability.
The organizational controls span five broad themes: governance and policy, roles and responsibilities, risk management, supplier security, and incident and continuity management. Each maps directly to the ISMS’s Plan-Do-Check-Act cycle, which means gaps in organizational controls tend to produce cascading deficiencies across audit findings.
| ISO 27001:2022 vs. 2013: What ChangedThe 2022 revision consolidated 114 controls into 93, introduced 11 new controls (including A.5.7 Threat Intelligence and A.5.23 Information Security for Use of Cloud Services), and reorganized the structure from 14 domains to 4 themes. Organizations holding 2013 certifications had until October 2025 to transition. |
Governance Controls: Policy, Roles, and Accountability
The foundation of every organizational control cluster is A.5.1 Policies for Information Security. This control requires that senior management approve a documented information security policy, communicate it across the organization, and review it at planned intervals or when significant changes occur. The policy does not need to be a single document; most mature organizations maintain a hierarchy with a master policy and topic-specific standards beneath it.
A.5.2 takes that policy and assigns it to people. Information Security Roles and Responsibilities requires that responsibilities for information security are clearly defined and allocated. This is where many US organizations underestimate scope: the control requires documented accountability, not just job titles. An organization that says “the IT team is responsible for security” has not met A.5.2. What is required is specific allocation who owns each asset, who approves access, who escalates incidents, who reviews policies.
Segregation of duties (A.5.3) addresses a control that directly intersects with SOC 2 Trust Service Criteria and SEC cybersecurity disclosure requirements. Conflicting duties must be separated, and where full separation is not practical common in smaller organizations compensating controls such as activity monitoring or management review must be documented.
Contact with authorities (A.5.5) and contact with special interest groups (A.5.6) are often treated as checkbox items, but they carry genuine weight in US regulatory contexts. For organizations subject to HIPAA breach notification or SEC incident disclosure rules, having pre-established relationships with relevant agencies the FBI’s IC3, CISA, relevant sector ISACs is both an ISO requirement and a practical incident response necessity.
The 2022 revision introduced A.5.7 Threat Intelligence as a new organizational control. Organizations must collect, analyze, and act on threat intelligence relevant to their information security. For US enterprises, this typically means integration with CISA advisories, sector-specific ISACs, and commercial threat feeds and documented processes for translating intelligence into control adjustments.
Risk Management Controls: From Assessment to Treatment
ISO 27001’s approach to risk is deliberately non-prescriptive the standard requires a systematic process but does not mandate a specific methodology. What A.5.8 (Information Security in Project Management), read alongside clauses 6.1 and 6.2, demands is that risk assessment is integrated into the ISMS systematically and that treatment decisions are documented with clear rationale.
For US organizations aligning to NIST SP 800-53 Rev 5, the mapping is straightforward. ISO 27001’s risk assessment requirements correspond to NIST’s RA (Risk Assessment) control family. NIST SP 800-30 provides risk assessment guidance that satisfies both frameworks simultaneously. Organizations pursuing FedRAMP authorization will find that a well-documented ISO 27001 risk register gives them a strong starting point for the required System Security Plan (SSP).
A.5.8 specifically requires that information security be integrated into project management. This means new projects system deployments, application development, third-party integrations must undergo security review as part of project governance, not as an afterthought. The control requires evidence: project charters, security review checkpoints, approval records.
The treatment options under ISO 27001 align with NIST’s risk response categories: modify (implement controls), avoid (discontinue the activity), share (transfer via insurance or contracts), or retain (accept). Each treatment decision must be documented in a risk treatment plan, and the plan must be approved by risk owners. Residual risk what remains after treatment must be explicitly accepted by appropriate authority.
ISO 27001 Risk Treatment Options vs. NIST SP 800-30 Alignment
| ISO 27001 Treatment | NIST Equivalent | Documentation Required | US Regulatory Relevance |
|---|---|---|---|
| Modify (apply controls) | Implement | Risk Treatment Plan, Control Implementation Evidence | CMMC 2.0 Practice Requirements |
| Avoid (cease activity) | Avoid | Risk Decision Record, Management Approval | HIPAA Risk Analysis Documentation |
| Share (transfer/contract) | Transfer | Insurance Policy, Contract Clauses, SLA Terms | SEC Cybersecurity Disclosure |
| Retain (accept risk) | Accept | Risk Acceptance Statement, Owner Sign-off | SOC 2 Exceptions Documentation |
Supplier and Third-Party Security Controls
Supply chain risk is where ISO 27001’s organizational controls have the sharpest teeth for US organizations. The SolarWinds breach, the MOVEit zero-day, and the Change Healthcare ransomware incident each exposed the same structural problem: insufficient third-party security governance. ISO 27001:2022 addresses this with a dedicated cluster of controls.
A.5.19 (Information Security in Supplier Relationships) requires that organizations establish policies for managing supplier risk and apply appropriate controls to protect information accessed by suppliers. This means before a supplier touches your data or systems, there must be a documented process for evaluating their security posture.
A.5.20 (Addressing Information Security Within Supplier Agreements) mandates that security requirements appear in contracts. Generic terms are insufficient agreements must specify the security controls the supplier will maintain, incident notification timelines, audit rights, data handling requirements, and what happens at contract termination. For US organizations with HIPAA obligations, this control is essentially a formal mapping requirement for Business Associate Agreements (BAAs).
A.5.21 (Managing Information Security in the ICT Supply Chain) extends control to the supplier’s suppliers. Organizations must understand and address risks introduced by the upstream supply chain software libraries, hardware components, managed service providers. This is the control most directly aligned to CMMC 2.0’s supply chain risk management requirements and NIST SP 800-161.
A.5.22 (Monitoring, Review, and Change Management of Supplier Services) closes the loop. Initial due diligence is not sufficient; supplier security must be monitored continuously. This means annual security reviews, audit report requests (SOC 2 Type II is the US standard mechanism), and contractual change notification requirements.
A.5.23 (Information Security for Use of Cloud Services) is a new 2022 control specifically addressing cloud providers. It requires that cloud-specific risks are assessed, contractual security requirements are established, and data residency and access controls are documented. For US organizations using AWS, Azure, or Google Cloud in regulated environments, this control requires explicit documentation of the shared responsibility model and what the organization has accepted responsibility for.
| CISO Action Item: Supplier Security Checklist: For each critical supplier: (1) Document the security assessment performed before engagement. (2) Confirm security clauses exist in the contract. (3) Confirm annual review is scheduled. (4) Confirm incident notification requirements are defined. Missing any of these four produces a nonconformity finding against A.5.19-A.5.22. |
Incident Management and Business Continuity Controls
A.5.24 through A.5.28 cover the full incident management lifecycle: planning and preparation, reporting, assessment, response, and learning from incidents. These controls are among the most auditor-scrutinized in any ISO 27001 certification audit, because they require documented procedures and evidence of actual execution not just policies.
A.5.24 (Information Security Incident Management Planning and Preparation) requires that the incident management process is documented, roles are assigned, and response capabilities are tested. For US organizations, this maps directly to NIST SP 800-61 Computer Security Incident Handling Guide. Organizations subject to SEC cybersecurity rules the 2023 regulations require disclosure of material incidents within four business days must ensure their A.5.24 procedures include the assessment criteria and escalation path for materiality determinations.
A.5.26 (Response to Information Security Incidents) requires that incidents are responded to according to documented procedures. The key audit evidence here is incident records tickets, logs, communication trails, decision records. Organizations that handle incidents informally, without documentation, consistently fail this control.
A.5.28 (Collection of Evidence) is often overlooked until it is critically needed. The control requires that evidence related to incidents is collected and preserved in a manner suitable for legal proceedings. For US organizations, this intersects with e-discovery requirements and chain-of-custody considerations.
Business continuity controls A.5.29 (Information Security During Disruption) and A.5.30 (ICT Readiness for Business Continuity) require that security controls are maintained during operational disruptions and that ICT continuity requirements are defined and tested. NIST SP 800-34 provides continuity planning guidance that satisfies both controls. Organizations in regulated industries (financial services, healthcare) will find these controls already anticipated by their sector-specific continuity requirements.
Compliance and Intellectual Property Controls
The compliance-focused organizational controls A.5.31 through A.5.36 address legal, regulatory, and contractual obligations. For US organizations, this cluster has direct implications for HIPAA Privacy Rule compliance, CCPA data subject rights, export control regulations, and software licensing obligations.
A.5.31 (Legal, Statutory, Regulatory, and Contractual Requirements) requires that all applicable requirements are identified, documented, and kept current. This is not a one-time exercise the regulatory environment for US organizations is active, with state privacy laws, SEC cybersecurity rules, and sector-specific guidance evolving continuously. The control requires a process for staying current, not just a snapshot list.
A.5.32 (Intellectual Property Rights) addresses software licensing compliance. Organizations must have documented processes ensuring that only licensed software is used. For US enterprises, BSA audits and software licensing disputes create genuine legal exposure; this control requires the kind of software asset management that also satisfies CMMC 2.0 practice CM.L2-3.4.1.
A.5.34 (Privacy and Protection of PII) is the organizational control most directly relevant to US privacy law compliance. The control requires that privacy and PII protection requirements are identified and addressed. For organizations subject to HIPAA, this maps to the Privacy Rule’s minimum necessary standard. For those covered by CCPA/CPRA, it requires documented data subject rights procedures.
A.5.36 (Compliance with Policies, Rules, and Standards) closes the loop by requiring that information security compliance is regularly reviewed. This means internal audit activity against the ISMS, not just external certification audits. The cadence, scope, and output of internal audits must be documented and driven by risk.
Identity and Access Management in the Organizational Control Set
While many identity and access management controls fall in the technological category, several organizational controls directly govern the policies and processes that IAM systems must enforce.
A.5.15 (Access Control) requires that access control rules and rights are established based on business and information security requirements. This is the organizational backbone for technical controls like A.8.2 (Privileged Access Rights) and A.8.5 (Secure Authentication). Without a documented access control policy that defines how access is granted, reviewed, and revoked, technical IAM configurations are ungoverned.
A.5.16 (Identity Management) and A.5.17 (Authentication Information) require that the full lifecycle of identities and credentials is managed from provisioning through regular review to deprovisioning. For US federal contractors, these controls align with CMMC 2.0 practices IA.L1-3.5.1 and IA.L1-3.5.2. FedRAMP’s identity requirements under NIST SP 800-53 IA controls map directly to this control pair.
A.5.18 (Access Rights) requires that access rights are provisioned, modified, removed, and periodically reviewed in a controlled manner. The access review cadence quarterly for privileged accounts is the common standard must be documented and evidenced. This is a consistent finding in ISO 27001 audits: organizations that conduct access reviews but do not retain documentation of the review process and decisions fail this control.
ISO 27001 Access Controls vs. US Framework Alignment
| ISO 27001 Control | NIST SP 800-53 | CMMC 2.0 Practice | SOC 2 Criteria |
|---|---|---|---|
| A.5.15 Access Control | AC-1, AC-2 | AC.L1-3.1.1, AC.L1-3.1.2 | CC6.1, CC6.2 |
| A.5.16 Identity Management | IA-1, IA-4 | IA.L1-3.5.1 | CC6.2, CC6.3 |
| A.5.17 Authentication Information | IA-5 | IA.L1-3.5.2 | CC6.1 |
| A.5.18 Access Rights | AC-2(7), AC-6 | AC.L2-3.1.6 | CC6.3, CC6.6 |
Certifying Your ISO 27001 Organizational Controls Knowledge
Understanding organizational controls at the policy level is necessary but not sufficient for certification audits or professional credentialing. Auditors probe whether practitioners understand control intent, implementation rationale, and how controls interact within the ISMS. For US professionals managing or auditing ISMS implementations, formal credentialing validates that depth.
GAICC’s ISO/IEC 27001 Lead Implementer certification covers the full spectrum of organizational controls from policy development and governance structures through risk treatment, supplier management, and incident response procedures. The curriculum is aligned to US regulatory crosswalks including NIST, CMMC, HIPAA, and SOC 2, making it particularly relevant for US-based security and compliance practitioners.
The GAICC ISO/IEC 27001 Lead Auditor certification takes the practitioner perspective and trains professionals to assess organizational control implementation against ISO 27001 requirements the critical skill for internal audit programs and pre-certification gap assessments.
Compliance professionals evaluating different credential levels can compare the complete ISO 27001 certification path for information security professionals to choose the right certification based on career goals.
Implementation Priorities for US Organizations
The 37 organizational controls cannot all receive equal attention simultaneously. Organizations implementing ISO 27001 for the first time or transitioning from the 2013 standard benefit from sequencing control implementation by risk impact and audit visibility.
Start with the governance foundation: A.5.1 (Policies) and A.5.2 (Roles and Responsibilities) must be established before other controls can function coherently. Without a documented policy hierarchy and clear ownership, every other control exists in a vacuum.
Supplier controls deserve early priority for US organizations. Given SEC cybersecurity disclosure obligations and the regulatory scrutiny on supply chain risk following recent high-profile incidents, documented supplier security programs provide both compliance value and risk reduction that is visible to executive leadership.
Incident management procedures should be tested before they are needed. Table-top exercises that walk through A.5.24-A.5.28 controls under simulated conditions produce evidence of testing (required by the standard) and reveal procedural gaps before an actual incident exposes them to auditors or regulators.
The compliance controls A.5.31 through A.5.36 benefit from legal and privacy counsel input, particularly for organizations navigating overlapping US regulatory requirements. A single legal register that captures HIPAA, CCPA, sector-specific requirements, and contractual obligations satisfies A.5.31 while also informing the organization’s overall compliance posture.
| Quick Win: Start with These Three Organizational Controls: 1. A.5.1 Draft or update your information security policy and get formal management approval documented. 2. A.5.2 Create a RACI matrix mapping security responsibilities to named roles. 3. A.5.19 Conduct a supplier inventory and verify security clauses exist in top-tier vendor contracts. These three actions address the most common initial audit findings and provide the governance foundation for all other controls. |
Frequently Asked Questions
What is the difference between ISO 27001 organizational controls and technical controls?
Organizational controls govern the policies, processes, roles, and agreements that define how security is managed including governance structures, risk treatment decisions, supplier agreements, and incident response procedures. Technical controls are the system-level safeguards such as encryption, access logging, and malware detection. Organizational controls provide the governance framework that gives technical controls their authority and direction.
How many organizational controls are in ISO 27001:2022?
ISO 27001:2022 Annex A contains 37 organizational controls, down from 35 in the 2013 version but restructured significantly. The 2022 revision introduced new controls such as A.5.7 (Threat Intelligence) and A.5.23 (Information Security for Use of Cloud Services), reflecting the evolved threat and technology environment.
Which ISO 27001 organizational controls are most commonly cited in US audit findings?
Based on ISO 27001 audit patterns, the most frequent nonconformities in organizational controls involve A.5.2 (undocumented responsibility assignments), A.5.18 (access reviews conducted without retained evidence), A.5.22 (supplier monitoring documented in policy but not evidenced in practice), and A.5.26 (incident response executed informally without records).
How do ISO 27001 organizational controls map to CMMC 2.0?
ISO 27001 organizational controls align closely with several CMMC 2.0 domains. Access management controls map to CMMC’s AC domain, identity controls to IA, incident management to IR, risk assessment controls to RA, and supplier security controls to the SR (Supply Chain Risk Management) domain introduced in CMMC 2.0. Many CMMC practices can be satisfied through evidence generated for ISO 27001 compliance.
Do ISO 27001 organizational controls satisfy HIPAA Security Rule requirements?
ISO 27001 organizational controls satisfy many HIPAA Security Rule administrative safeguard requirements. A.5.31 supports the Required Implementation Specification for regulatory compliance, A.5.24-A.5.28 satisfy the Security Incident Procedures standard, A.5.2 addresses the Assigned Security Responsibility standard, and A.5.19-A.5.22 support Business Associate Agreement management. ISO 27001 certification does not automatically constitute HIPAA compliance, but it addresses the majority of Security Rule administrative requirements.
What evidence do auditors look for when assessing ISO 27001 organizational controls?
Auditors seek four types of evidence: documented policies and procedures (the what), records of implementation (the when and who), records of review and monitoring activity, and records of corrective actions taken when gaps were identified. For supplier controls, this means contracts with security clauses plus evidence of annual review. For incident controls, this means documented incident records. Policies alone, without implementation evidence, consistently produce nonconformity findings.
Is a Statement of Applicability required for organizational controls?
Yes. The Statement of Applicability (SoA) must address every Annex A control, including all 37 organizational controls. For each control, the SoA must state whether it is applicable or excluded, provide justification for exclusions, and describe the implementation status. Controls cannot be excluded simply because they are difficult to implement exclusions require documented justification based on risk assessment outcomes.
Conclusion
ISO 27001 organizational controls are the governance architecture that separates a functional ISMS from a collection of technical tools. The 37 controls in Annex A’s organizational category establish how decisions get made, who owns what, how suppliers are managed, and how incidents are handled everything that makes technical controls purposeful rather than incidental.
For US organizations, the alignment between these controls and NIST SP 800-53, CMMC 2.0, HIPAA, and SOC 2 means that well-implemented organizational controls simultaneously advance multiple compliance objectives. The investment is not incremental it is foundational.
Start with governance: document roles, approve policies, and map your supplier landscape. The rest of the ISMS depends on that foundation being solid. Ready to formalize your ISO 27001 expertise? Explore GAICC’s ISO/IEC 27001 Lead Implementer and Lead Auditor certifications.
