3.1 Organizational Controls: Governance, Roles & Threat Intelligence (A.5.1–A.5.8)

3.1 Organizational Controls: Governance, Roles & Threat Intelligence (A.5.1–A.5.8)

In the updated ISO/IEC 27001:2022 standard, Annex A underwent a major structural modernization. The previous 14 domain structure containing 114 controls (from the 2013 edition) was consolidated into 93 controls categorized across four distinct themes:

1. Organizational controls (37 controls — Clause A.5)
2. People controls (8 controls — Clause A.6)
3. Physical controls (14 controls — Clause A.7)
4. Technological controls (34 controls — Clause A.8)

For an ISO/IEC 27001 Lead Implementer, mastering the Organizational theme is essential. Organizational controls establish the administrative, governance, legal, structural, and strategic framework required to direct and manage information security across the enterprise.

---

Overview of Governance & Administrative Controls (A.5.1 – A.5.8)

---

Deep-Dive: Information Security Policies (A.5.1)

Control A.5.1 forms the structural foundation of the Information Security Management System (ISMS). Policies articulate executive intent and establish mandatory security expectations across the entity. The Lead Implementer must architect a two-tier policy hierarchy:

1. Overarching Information Security Policy (High-Level Policy): Approved directly by Executive Management or the Board of Directors. It outlines the ISMS scope, core security principles (Confidentiality, Integrity, Availability), security objectives, regulatory compliance baselines, management commitment, and governance oversight structures.
2. Topic-Specific Policies (Operational Sub-Policies): Practical, detailed operational rules tailored to specific operational domains. Key topic-specific policies mandated by Annex A include Access Control Policy, Data Classification Policy, Cryptographic Policy, Clean Desk & Clear Screen Policy, Supplier Security Policy, Backup Policy, and Remote Working Policy.

Review and Lifecycle Requirements

Policies cannot remain static, passive documents. Control A.5.1 mandates formal policy reviews under two specific triggers:

• Planned Intervals: Conducted at least annually to confirm ongoing suitability, adequacy, and effectiveness.
• Significant Changes: Conducted immediately following major business changes, such as infrastructure migrations to cloud environments, corporate mergers and acquisitions, major security incidents, or new regulatory mandates (e.g., EU NIS2, DORA, or revised state privacy laws).

---

Roles, Responsibilities & Segregation of Duties (A.5.2 & A.5.3)

Defining Roles and Responsibilities (A.5.2)

Information security is an enterprise-wide responsibility, not an isolated IT function. The Lead Implementer must formalize clear security ownership across all organizational echelons using a RACI Matrix (Responsible, Accountable, Consulted, Informed):

• Top Management: Ultimate accountability for ISMS success, approving policies, allocating necessary budget/resources, and accepting residual risks.
• Chief Information Security Officer (CISO) / ISMS Steering Committee: Operational leadership, risk management execution, incident response coordination, and reporting ISMS performance to executive management.
• Asset Owners: Business unit leads accountable for classifying data assets under their purview and approving user access permissions.
• Asset Custodians (IT / DevOps): Technical teams responsible for implementing technical safeguards (encryption, patching, backup execution) specified by Asset Owners.
• All Employees & Contractors: Duty to comply with security policies, complete training, and immediately report security events.

Segregation of Duties (A.5.3)

Segregation of Duties (SoD) reduces the risk of fraud, intentional misuse, and unintentional operational errors by ensuring that no single individual possesses end-to-end control over a critical business process.

+-------------------------------------------------------------------------+
| CLASSIC SEGREGATION OF DUTIES (SoD) BOUNDARIES                          |
+-------------------------------------------------------------------------+
| Developer Role    --> Writes and tests application software code.       |
|                       CANNOT deploy code directly to Production.        |
+-------------------------------------------------------------------------+
| Change Manager    --> Approves release tickets following peer review.   |
|                       CANNOT write code or perform deployment.         |
+-------------------------------------------------------------------------+
| Release / DevOps  --> Deploys approved build artifacts to Production.   |
|                       CANNOT modify source code or bypass approvals.   |
+-------------------------------------------------------------------------+

Lead Implementer Guidance on Small Teams: Where strict Segregation of Duties is constrained by limited team headcounts, Lead Implementers must implement compensating controls—such as mandatory dual-custody approval workflows, automated peer code reviews, independent secondary audit logs, and heightened executive monitoring.

---

Authority Contacts & Special Interest Groups (A.5.5 & A.5.6)

Contact with Authorities (A.5.5)

Organizations must maintain an updated Authority Contact Register detailing escalation pathways to regulatory agencies, data protection authorities (DPAs), law enforcement (e.g., FBI Cyber Division, Europol), national CERTs/CSIRTs, and emergency services. This ensures that legal notification deadlines (such as GDPR's 72-hour breach reporting window) are met without delay during a severe security incident.

Contact with Special Interest Groups (A.5.6)

Maintaining active memberships in professional associations (e.g., ISACA, (ISC)², SANs), industry-specific Information Sharing and Analysis Centers (ISACs), and cybersecurity forums allows organizations to keep abreast of best practices, emerging attack vectors, threat intelligence, and evolving regulatory compliance requirements.

---

Deep-Dive: Threat Intelligence (A.5.7) — New in ISO 27001:2022

Control A.5.7 Threat Intelligence represents a pivotal evolution in ISO/IEC 27001, shifting ISMS defense from reactive incident management to proactive threat hunting and vulnerability risk mitigation. Organizations must establish formal processes to collect, analyze, and process threat data.

The Three Horizons of Threat Intelligence

Lead Implementers must structure threat intelligence feeds and reports across three functional tiers:

+-------------------------------------------------------------------------+
| STRATEGIC THREAT INTEL                                                 |
| Focus: High-level risk trends, threat actor motivations, geopolitical   |
|        cyber risks, industry targeting patterns.                        |
| Target Audience: Board of Directors, CISO, Executive Steering Committee |
+-------------------------------------------------------------------------+
                                   |                                       
                                   v Directs operational security strategy 
+-------------------------------------------------------------------------+
| OPERATIONAL THREAT INTEL                                                |
| Focus: Specific adversary Tactics, Techniques, & Procedures (TTPs),     |
|        MITRE ATT&CK framework mapping, campaign analysis.               |
| Target Audience: Security Architects, Incident Response Team, SOC Mgrs  |
+-------------------------------------------------------------------------+
                                   |                                       
                                   v Informs technical defense mechanisms  
+-------------------------------------------------------------------------+
| TACTICAL THREAT INTEL                                                   |
| Focus: Technical Indicators of Compromise (IoCs) — malicious IPs,       |
|        file hashes (SHA-256), malicious domain URLs, CVE exploits.      |
| Target Audience: Firewalls, SIEM/SOAR platforms, EDR/NDR agents          |
+-------------------------------------------------------------------------+

Implementing the Threat Intelligence Lifecycle

1. Planning & Direction: Define intelligence requirements based on asset criticality and organizational threat landscape.
2. Collection: Ingest raw threat telemetry from commercial vendors, open-source intelligence (OSINT), government alerts (CISA), and sector ISAC feeds via STIX/TAXII protocols.
3. Processing & Analysis: Filter out noise, deduplicate indicators, and evaluate relevance to the organization's technological stack.
4. Dissemination & Action: Feed tactical IoCs into automated firewall/SIEM detection rules, update risk registries, and adjust vulnerability patching priorities based on actively exploited CVEs.

---

Security in Project Management (A.5.8)

Control A.5.8 mandates that information security be fully integrated into project management methodologies across the enterprise lifecycle, regardless of whether projects follow Waterfall, Agile, or DevSecOps approaches.

Project Security Gateways & Sign-offs:

• Project Initiation: Conduct preliminary security risk assessment; establish data protection and compliance baselines.
• Design & Architecture: Perform Threat Modeling (e.g., STRIDE methodology); design security controls into system architecture.
• Development & Build: Enforce secure coding standards; execute automated Static Application Security Testing (SAST) and Dependency Scanning.
• Testing & Verification: Conduct Dynamic Application Security Testing (DAST), vulnerability scanning, and third-party penetration testing.
• Deployment Gate: Formal security sign-off from the CISO and Asset Owner required before promoting code to production.

---

Real-World Implementation Scenario:
FinTech Express is developing a microservices-based mobile payment platform. The Lead Implementer establishes Control A.5.8 by embedding automated security testing into their GitLab CI/CD pipeline. If SAST scanners detect SQL injection flaws or if threat intelligence (A.5.7) identifies active exploitation of an open-source library used in the build, the pipeline automatically halts. Concurrently, Segregation of Duties (A.5.3) dictates that developers cannot approve their own pull requests or push code directly to production without automated CI/CD security gate sign-off.