ISO/IEC 27001:2022: Architecture and Building Blocks of the Modern ISMS

The question any information security officer should ask when approaching ISO/IEC 27001:2022 is not "how many new controls does it have?", but "what management architecture does it require and how does it articulate with what already exists in my organization?". The implementation guide published by the ISACA Germany Chapter (https://isaca.de/publikationen/publikationen/leitfaeden/implementierungsleitfaden-iso-iec-27001-2022.html) answers precisely that question with a pragmatic orientation that goes beyond mere normative exegesis. Its reading allows for the identification of both the conceptual scaffolding of the standard and the frictions that practice generates when confronting it with real organizational structures.

The Standard as a Governance System, Not a Catalog of Controls

A frequent interpretative error consists in reducing ISO/IEC 27001:2022 to its Annex A—now composed of 93 controls compared to 114 in the 2013 version—without noticing that the standard is, above all, a management system. The guide underlines this distinction by articulating the Information Security Management System (ISMS) from three complementary perspectives that are not merely descriptive categories but design criteria: the Governance view, aimed at aligning security objectives with business objectives; the Risk view, which bases decision-making on the systematic evaluation of threats to the confidentiality, integrity, and availability of information assets; and the Compliance view, which integrates legal, regulatory, and contractual requirements as design vectors for the ISMS.

It is worth remembering that this triple perspective does not operate independently. The guide represents it graphically as a system in which corporate management—with its objectives and risk appetite—filters down to operational security measures, while compliance reports and audit results feed back up into management decisions. This integrated model, attributed to Carmao GmbH, makes explicit a premise that the normative text only suggests: information security is not a peripheral technical function but a component of the corporate governance system.

The Fourteen Functional Blocks: Rationality of the Structure

The guide's most original methodological contribution consists in reorganizing the contents of ISO/IEC 27001:2022—which follows the harmonized structure of Annex SL—into fourteen functional blocks that reflect the operational logic of an ISMS rather than the standard's numbering. This editorial decision is not trivial: it recognizes that the structure of the standard responds to criteria for cross-cutting standardization among ISO management systems, not necessarily to the logical sequence in which an organization must approach implementation.

The fourteen blocks are: Context of the Organization; Leadership and Commitment; Information Security Objectives; Security Policy; Roles, Responsibilities, and Competencies; Risk Management; Performance, Risk, and Compliance Monitoring; Documentation; Communication; Awareness; Supplier Relations; Internal Audit; Incident Management; and Continual Improvement. A systematic reading of the guide allows for verifying that these blocks are not watertight compartments but nodes of a graph in which each one conditions the design of the others.

Organizational Context and Scope: The First Error That Contaminates Everything

The guide devotes privileged attention to the Organization's Context block because it warns—based on audit experience—that errors made in defining the ISMS scope are the most costly to correct. A poorly defined scope produces a Statement of Applicability (SoA) that does not reflect real assets at risk, certifications that do not cover relevant processes for third parties, and risk analyses built on a deficient foundation.

The standard requires the scope to be documented and to identify the assets—processes, business units, locations, applications—included and excluded. But the guide goes further by noting that the appropriate level of detail does not derive from a formal criterion but from the internal and external information security requirements for the area in question. Environment analysis and requirements analysis are the instruments that feed this determination. The first maps organizational and technical interfaces—other management systems, risk departments, human resources, data protection—as well as the external environment, including suppliers and strategic partners. The second establishes what stakeholders exist and what requirements they impose on the organization: from the GDPR and instructions from regulatory authorities to contractual obligations with clients.

What is striking in this analysis is the practical warning about using certificates as substitutes for a detailed scope. The guide points out that, in practice, organizations present ISO/IEC 27001 certificates to third-party requests that—upon careful reading—do not cover the processes or infrastructures that the requester needs to verify. This observation points to a systemic problem: certification can generate a compliance signal that obscures the reality of the effective scope.

Leadership, Commitment, and the "Tone from the Top" Problem

The section dedicated to Leadership and Commitment frankly addresses a tension that any CISO knows: the ISMS's structural dependence on a management mandate that, in practice, does not always translate into observable behavior. ISO/IEC 27001:2022 requires that top management demonstrably assume global responsibility for information security. This requirement has two dimensions. The first, visible in the normative text, refers to the allocation of resources, communicating the importance of the ISMS, and conducting management reviews. The second, highlighted by the guide, concerns the role-modeling function management exerts—the so-called tone from the top—in accepting non-conformities, exemplary compliance with security requirements, and visible support for unpopular measures.

The guide clarifies the concept of "top management" for the purposes of the standard: it does not necessarily refer to the highest level of the corporate group, but to the level that controls the area covered by the ISMS and decides on resource allocation. This clarification has direct relevance for parent organizations or those with divisional structures, where the CISO may operate under an intermediate management level that, for normative purposes, acts as top management. The implication for certification processes is that the certification body may require the participation of a higher hierarchical level if the ISMS scope justifies it.

Risk Management: Process Over Tool

The treatment of risk management in the guide deserves particular attention because it shifts the focus from tools—assessment matrices, risk registers—to the underlying process. The standard requires a risk assessment process that produces consistent, valid, and comparable results, without prescribing a specific methodology. This margin of discretion is valued by the guide as a strength of the standard, but also as a source of frequent design errors.

The recommended process follows the ISO 31000:2018 structure in four steps: risk identification, analysis, evaluation, and treatment. What the guide adds to this known sequence is an articulation of specific risk sources for information environments—internal and external data exchange, legacy systems that cannot be updated, remote access to corporate networks, cloud computing, social engineering, natural disasters—which anchors the methodology in operational reality rather than abstract categories.

That said, the most substantive contribution is the discussion on risk acceptance criteria. The guide points out that defining these criteria is the central task of the risk management process because it allows for differentiating between risks requiring priority treatment and risks that can be accepted or transferred. Without well-defined criteria, the process tends to produce long lists of nominally identified risks but without real prioritization. Now, the guide warns against the temptation to establish excessively permissive or excessively restrictive criteria: the former generate an ISMS that accepts risks the organization's real appetite would not tolerate; the latter produce a system that requires the treatment of every identified risk, consuming disproportionate resources.

The responsibility for treatment is assigned to the risk owner, defined as the entity that bears the economic impact when the risk materializes. This definition has a relevant organizational implication: although risks may originate in IT systems managed by the technology department, the responsibility for treatment lies with the business units whose processes depend on those systems. The dissociation between execution responsibility (IT) and global responsibility (accountability, business units) is a distinction the guide considers critical for the ISMS to function as a governance instrument and not as a subordinate technical function.

Monitoring and Metrics: The Measurability Problem

The block dedicated to performance monitoring introduces the framework of key indicators—KPIs (Key Performance Indicators), KRIs (Key Risk Indicators), and KCIs (Key Control Indicators)—as instruments to make the ISMS effectiveness observable. The distinction between the three categories is not merely formal: KPIs measure success in achieving security objectives; KRIs signal changes in the risk profile that could exceed defined tolerance limits; KCIs verify that established controls operate with the intended effectiveness.

The guide is honest about the practical difficulty of this block. Formulating indicators that are simultaneously specific, measurable, relevant to security, and viable in terms of data collection costs is one of the most demanding challenges of ISMS implementation. The standard requires security objectives to be measurable "where practicable," a wording the guide interprets as more flexible than "where possible," although without justifying the abandonment of measurability. The practical recommendation is to start with a small number of significant indicators for the specific organization and progressively expand the system as the ISMS matures.

Internal Audit and Continual Improvement: The Feedback Loop

The internal audit of the ISMS—distinguished both from the certification audit and the internal control system (ICS)—operates as the primary feedback mechanism of the improvement cycle. The guide distinguishes between the audit program—the organizational structure defining frequency, criteria, auditor competencies, and findings management—and the specific audit activities, and points out that in organizations of a certain size, it is advisable to organizationally separate the responsibility for both dimensions.

The audit program must ensure that all processes covered by the ISMS are audited at least once every three years regarding the security requirements applicable at the time of the audit. This periodicity is not an arbitrary criterion but a reflection of a balance between the need for complete coverage and the limitation of resources available for internal audit.

The PDCA (Plan-Do-Check-Act) cycle underlies the continual improvement block as a frame of reference, although the guide articulates it in terms of corrective actions—aimed at eliminating the root cause of non-conformities to prevent their recurrence—and corrections—aimed at remedying the immediate non-conforming situation without necessarily addressing the cause. This distinction, established by the standard in its section 10.1, is relevant because organizations frequently apply corrections without implementing corrective actions, which generates the recurrence of the same problems in successive audit cycles.

Changes from the 2013 Version: What the Standard Updates

The 2022 version of ISO/IEC 27001 introduces modifications to the main body of the standard—adapted to the new Harmonized Structure of Annex SL—and a substantial renewal of Annex A, which now fully reflects the controls of ISO/IEC 27002:2022. Modifications in the main body include: the requirement to determine which stakeholder requirements are addressed within the ISMS framework (section 4.2); the explicit incorporation of change planning for the ISMS (section 6.3); the addition of security objective monitoring (section 6.2); and the reorganization of Chapter 10 to place continual improvement before non-conformities, indicating an orientation toward proactivity rather than reactive correction.

In Annex A, the reduction from 114 to 93 controls does not represent a decrease in requirements but a rationalization through grouping and elimination of redundancies: 57 controls from the previous version are consolidated into 24, one control is split into two, and 11 new controls are added addressing emerging areas. Notable new controls include Threat intelligence (5.7), information security for cloud services (5.23), ICT readiness for business continuity (5.30), data masking (8.11), data leakage prevention (8.12), configuration management (8.9), information deletion (8.10), monitoring activities (8.16), web filtering (8.23), and secure coding (8.28). The restructuring into four categories—organizational, people, physical, and technological controls—facilitates the assignment of responsibilities by domain and the creation of differentiated views for different stakeholders through new control attributes.

Integration with Other Management Systems: The Economy of Compliance

The guide devotes a final chapter to the integration of the ISMS with other management systems—ISO 9001, ISO 22301, ISO 14001—and operationalization through what it calls a "corporate controls database." This consolidated control architecture, which aligns controls from multiple standards over a layer of common thematic domains, responds to a reality that organizations with multiple certifications know well: the parallel management of equivalent controls in different regulatory frameworks generates duplications, increases the evidentiary burden, and produces confusion in operational managers about which requirement from which standard they are addressing at any given time.

The methodological proposal—organizing controls by thematic domain and linking them through a meta-structure to the various applicable standards—is not new in the field of GRC (Governance, Risk, and Compliance), but the guide presents it with sufficient specificity to guide real design decisions. The reference to COBIT 2019 as an orientation framework for the domain structure is consistent with the ISACA audience profile, although the guide recognizes that the secondary control framework may vary by sector: TISAX for automotive, CSA's Cloud Control Matrix for software-as-a-service providers, BSI's IT-Grundschutz Compendium in German regulated environments.

Conclusion: What the Standard Requires and What the Guide Provides

Three conclusions articulate the doctrinal value of this implementation guide. First, that ISO/IEC 27001:2022 fundamentally requires an information security governance system—with a management mandate, risk management based on organizational context, measurable objectives, and a continual improvement cycle—and that the 93 controls in Annex A are instruments of that system, not its essential content. Second, that the fourteen functional blocks proposed by ISACA allow for approaching implementation with an operational logic closer to organizational reality than the standard's harmonized structure, while still meeting all normative requirements. Third, that the most costly errors in ISMS implementation are not technical but design-related: a poorly defined scope, poorly calibrated risk acceptance criteria, and the absence of a clearly identified risk owner for each treated risk are the factors that most frequently compromise the system's real effectiveness versus the mere appearance of compliance.