3.1 Annex A Architecture & Attribute Taxonomy

ISO/IEC 27001:2022 Annex A Architecture & Attribute Taxonomy

Auditor Note: The transition from ISO/IEC 27001:2013 to ISO/IEC 27002:2022 and ISO/IEC 27001:2022 represents a fundamental shift in control organization. Lead auditors must understand not only the reduction in total control count from 114 to 93, but also the operational utility of the new 5-attribute taxonomy model when evaluating an organization's Statement of Applicability (SoA).

---

1. Structural Evolution: 2013 vs. 2022 Architecture

The 2013 edition of Annex A structured controls into 14 domains (A.5 through A.18) containing 35 control objectives and 114 controls. While comprehensive, this structure led to artificial silos between physical, technical, and operational security measures, making it cumbersome for cloud-native, remote, and hybrid enterprises.

ISO/IEC 27001:2022 radically simplified this framework by organizing controls into 4 thematic clauses based on operational ownership:

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

In addition to consolidating domains, the 2022 revision removed explicit control objectives, replacing them with concise purpose statements for each control within ISO/IEC 27002:2022. This focuses the auditor's attention on intent and risk mitigation outcomes rather than prescriptive boilerplate compliance.

+-----------------------------------------------------------------------------------+
|                             STRUCTURAL REORGANIZATION                             |
+-----------------------------------------------------------------------------------+
|  ISO/IEC 27001:2013                                  ISO/IEC 27001:2022          |
|  ------------------                                  ------------------          |
|  - 14 Domains (A.5 - A.18)                           - 4 Themes (Clause 5 - 8)   |
|  - 35 Control Objectives                             - 0 Control Objectives      |
|  - 114 Total Controls                                - 93 Total Controls         |
|                                                      - 11 New Controls           |
|                                                      - 24 Merged Controls        |
|                                                      - 58 Updated Controls       |
+-----------------------------------------------------------------------------------+

---

2. Quantitative Breakdown: New, Merged, and Updated Controls

Although the total control count dropped from 114 to 93, the actual scope of security controls expanded. The numerical reduction was achieved primarily through consolidation:

• 58 Controls Updated: Retained single-control mapping from 2013, with modernized wording to cover cloud, remote work, and modern threat vectors.
• 24 Controls Merged: Combined 57 legacy controls into 24 broader, logically grouped controls (e.g., combining separate mobile device and teleworking policies into unified controls).
• 1 Control Split: ISO/IEC 27001:2013 A.18.2.3 (Technical compliance review) was divided to distinguish general technical compliance from secure coding and configuration auditing.
• 11 Brand-New Controls: Introduced to plug critical coverage gaps in modern enterprise environments.

Summary Table of the 11 New Annex A Controls

---

3. The 5-Attribute Taxonomy Framework

To prevent the 93 controls from becoming a rigid monolithic list, ISO/IEC 27002:2022 introduced a standardized 5-attribute taxonomy. Each control is assigned metadata across five distinct taxonomy dimensions, allowing organizations and lead auditors to view, slice, filter, and audit controls through multiple operational lenses.

+-----------------------------------------------------------------------------------+
|                         THE 5 ATTRIBUTE TAXONOMY DIMENSIONS                       |
+-----------------------------------------------------------------------------------+
| 1. CONTROL TYPE             ---> [Preventive] [Detective] [Corrective]            |
| 2. INFOSEC PROPERTIES       ---> [Confidentiality] [Integrity] [Availability]      |
| 3. CYBERSECURITY CONCEPTS   ---> [Identify] [Protect] [Detect] [Respond] [Recover] |
| 4. OPERATIONAL CAPABILITIES ---> [15 Functional Areas e.g., Governance, IAM]       |
| 5. SECURITY DOMAINS         ---> [Governance_&_Ecosystem] [Protection] [Defense]... |
+-----------------------------------------------------------------------------------+

1. Control Type

Defines the temporal mechanism by which the control affects a risk event:

• Preventive: Inhibits the occurrence of an incident (e.g., multi-factor authentication, physical locks).
• Detective: Identifies when an incident or policy violation occurs (e.g., SIEM alerts, physical intrusion alarms).
• Corrective: Restores normal operations or mitigates impact after an incident (e.g., data backups, incident response playbook execution).

2. Information Security Properties

Aligns controls directly with the CIA Triad:

• Confidentiality: Protects against unauthorized disclosure (e.g., Data Masking 8.11, DLP 8.12).
• Integrity: Protects against unauthorized modification or destruction (e.g., Secure Coding 8.28, Configuration Management 8.9).
• Availability: Ensures timely and reliable access (e.g., ICT Readiness for Business Continuity 5.30, Redundancy 8.14).

3. Cybersecurity Concepts

Maps controls directly to the international cybersecurity lifecycle (aligned with ISO/IEC 27032 and the NIST Cybersecurity Framework):

• Identify | Protect | Detect | Respond | Recover

4. Operational Capabilities

Categorizes controls into 15 practical security functions within an enterprise IT organization:

1. Governance
2. Asset management
3. Information protection
4. Human resource security
5. Physical security
6. System and network security
7. Application security
8. Secure configuration
9. Identity and access management (IAM)
10. Threat and vulnerability management
11. Continuity
12. Supplier relationships security
13. Legal and compliance
14. Information security event management
15. Information security assurance

5. Security Domains

Groups controls according to strategic architectural domains:

• Governance and Ecosystem: Executive oversight, risk management, third-party relations.
• Protection: Safeguarding assets, access management, cryptography.
• Defense: Active threat detection, SOC monitoring, network defense.
• Resilience: Business continuity, disaster recovery, incident handling.

---

4. Statement of Applicability (SoA) & Attribute Mapping in Audits

During an ISO/IEC 27001 audit, the Statement of Applicability (SoA) is a core audit artifact (Clause 6.1.3 d). The SoA must list all 93 controls, state whether each control is included or excluded, provide clear justification for exclusions, and document the implementation status.

How Lead Auditors Evaluate Attribute-Tagged SoAs

1. Dynamic Filtering for Risk Assessment: Auditors cross-reference the organization's Risk Treatment Plan (RTP) against attribute tags. For example, if a high-risk finding relates to ransomware, the auditor filters the SoA by Cybersecurity Concept: #Recover and Operational Capability: #Continuity to verify that all corresponding controls (e.g., 5.30, 8.13) are marked as Applicable.
2. Custom Attribute Extensions: Organizations are permitted to define custom attributes (e.g., #GDPR_Compliance, #PCI_DSS, #Cloud_Native). Lead auditors verify that custom attributes accurately reflect regulatory and contractual boundaries.
3. Justification of Exclusions: Under ISO/IEC 27001:2022, excluding any of the 93 controls requires explicit justification. If an organization excludes Control 8.11 (Data Masking), the lead auditor must verify whether PII or sensitive data exists in development or testing environments.

---

5. Lead Auditor Worked Scenario

Scenario Background

During a Stage 2 Certification Audit of CloudNexus Systems, a SaaS platform provider, Lead Auditor Elena is reviewing the organization's SoA transition from ISO/IEC 27001:2013 to the 2022 version. CloudNexus operates entirely within AWS and uses third-party threat feeds.

Audit Observation & Evidence Review

1. SoA Exclusions: CloudNexus marked Control 7.4 (Physical security monitoring) as Excluded, stating: "We operate 100% in AWS, so physical controls do not apply to us."
2. Attribute Mapping Check: CloudNexus mapped Control 5.7 (Threat intelligence) under Control Type: #Preventive, but failed to assign operational responsibility or link it to their threat vulnerability management process.
3. Control 5.23 (Cloud Services): CloudNexus implemented AWS GuardDuty and Security Hub, but had no documented policy governing cloud configuration reviews or third-party cloud SLA reviews.

Auditor Evaluation & Findings

• Finding 1 (Minor Nonconformity against Clause 6.1.3 d & Control 7.4): While CloudNexus does not own physical data centers, they maintain physical corporate headquarters housing executive endpoints and network equipment. Control 7.4 was excluded without assessing physical perimeter monitoring for corporate premises.
• Finding 2 (Opportunity for Improvement against Control 5.7): Threat intelligence (5.7) is tagged only as #Preventive. The auditor recommends adding #Detective and #Identify attribute tags to ensure feeds feed directly into the SOC's incident response playbooks.
• Finding 3 (Minor Nonconformity against Control 5.23): Absence of documented cloud governance and vendor SLA monitoring criteria violates the mandatory requirements of Control 5.23 for a 100% cloud-dependent organization.