If you pick up ISO 27001:2022 and flip to Clause 4, you will notice something that might seem strange at first. The clause headings — 'Understanding the organization and its context', 'Understanding the needs and expectations of interested parties', 'Determining the scope' — sound almost generic. They could apply to a quality management system, an environmental program, or a business continuity framework.
That is not an accident. It is the result of a deliberate architectural decision made by ISO in 2012 that fundamentally changed how all ISO management system standards are structured. That decision is called the High-Level Structure — HLS — and understanding it is essential for anyone who wants to implement ISO 27001 efficiently, integrate it with other management systems, or understand why the standard is written the way it is.
This article explains what the HLS is, why it was introduced, how it shapes ISO 27001's clause structure, and what it means practically for organizations implementing or integrating ISO 27001 alongside other standards.
The Problem the HLS Was Designed to Solve
Before 2012, every ISO management system standard was a structural island. ISO 9001 for quality had its own clause numbering, its own terminology, its own definition of 'scope', its own documentation requirements. ISO 14001 for environmental management had a different structure entirely. When ISO 27001:2005 was published, it added a third incompatible architecture.
For organizations that needed to operate multiple management systems — which was increasingly common — this created a real operational problem. The quality team ran one management system. The environmental team ran a different one. The security team ran a third. Each had separate documentation, separate audit programs, separate management review cycles, and separate training requirements. There was no shared vocabulary, no integrated policy framework, and no ability to conduct combined audits efficiently.
The duplication was costly, the inconsistencies were confusing, and the fragmentation undermined the case for management systems as a serious governance tool. Something needed to change.
| THE PROBLEM IN ONE SENTENCE | Before HLS: an organization running ISO 9001, ISO 14001, and ISO 27001 was effectively running three independent management systems with incompatible structures, terminology, and audit programs — tripling the overhead and eliminating most of the integration benefit. |
What the HLS Actually Is
In 2012, ISO published what was then called Annex SL — a document that defined a common high-level structure, shared core text, and common terms and definitions that all new and revised ISO management system standards would be required to follow. This structure was subsequently renamed the Harmonized Structure, and in ISO's latest guidance documents it is referred to simply as the High-Level Structure or HLS.
The HLS mandates that every conforming management system standard uses the same ten-clause architecture, with identical clause numbers, identical clause titles, and — critically — identical 'shall' text for common requirements. Only the domain-specific content is added on top of this shared foundation.
ISO 27001:2013 was one of the first major standards to adopt this structure, which is why it looks the way it does. ISO 27001:2022 refined the application further, making the clause structure even more harmonized with other recently revised standards.
The Ten-Clause Architecture of ISO 27001
The HLS mandates a ten-clause structure. In ISO 27001, this maps as follows — with each clause's PDCA phase (Plan, Do, Check, Act) showing how the structure embeds the continual improvement cycle:
| § | Clause | Title | PDCA | What it requires |
| 1–3 | 1–3 | Scope, References, Terms | Foundation | These introductory clauses establish the standard's scope, normative references, and the vocabulary used throughout. They are informative — not auditable requirements. |
| 4 | 4 | Context of the Organization | Plan | Understand internal/external issues, identify interested parties, define the ISMS scope. The starting point for every ISMS. |
| 5 | 5 | Leadership | Plan | Top management commitment, information security policy, roles and responsibilities. Leadership cannot be delegated away. |
| 6 | 6 | Planning | Plan | Risk assessment and treatment, information security objectives, planning for change (new in 2022). The intellectual core of the ISMS. |
| 7 | 7 | Support | Do | Resources, competence, awareness, communication, documented information. The infrastructure that makes the ISMS operational. |
| 8 | 8 | Operation | Do | Execute the risk treatment plan, manage operational processes, control changes. Where planning meets reality. |
| 9 | 9 | Performance Evaluation | Check | Monitoring and measurement, internal audit, management review. How the ISMS proves it is working. |
| 10 | 10 | Improvement | Act | Nonconformity and corrective action, continual improvement. What the ISMS does when it finds problems. |
Clauses 1 through 3 are introductory and informative — they set the scene but do not impose auditable requirements. Clauses 4 through 10 are normative — they contain 'shall' requirements that an organization must meet to claim conformance with ISO 27001. Every certification audit is an examination of whether an organization meets the requirements of Clauses 4 through 10.
| Practical note for auditors and implementers: When an auditor issues a nonconformity, they always reference a specific clause number and sub-clause. Understanding the HLS structure means you can immediately locate any nonconformity in the standard's architecture and understand which part of the management system it belongs to. A Clause 6.1 nonconformity is a risk planning problem. A Clause 9.2 nonconformity is an internal audit problem. A Clause 5.1 nonconformity is a leadership and commitment problem. |
Before and After HLS: The Integration Difference
The practical impact of HLS becomes clearest when you compare what multi-standard management looked like before and after its introduction:
| Area | Before HLS (pre-2012) | With HLS (ISO 27001:2013 onwards) |
| Clause structure | Unique per standard — different numbering, different groupings, incompatible structure | 10 clauses, identical numbering and titles across all HLS-aligned standards |
| Common definitions | Each standard defines its own terms — conflicts and inconsistencies between standards | Shared core definitions — 'risk', 'interested parties', 'documented information' mean the same thing across standards |
| Management system text | No common text — policies, scope, objectives, reviews all defined differently | Identical 'shall' text for common requirements — copy-paste integration across standards |
| Joint auditing | Separate audit programs per standard — duplication of effort, inconsistent findings | Combined audits possible — one audit program, multiple standard coverage, significant cost reduction |
| Staff training | Staff must learn different structures for each management system | One management system structure — security, quality, and continuity teams share the same framework language |
| Policy integration | Separate policy documents per system — potential contradictions | Single integrated policy set covers all management systems through common framework |
The integration savings are real and substantial. An organization running ISO 27001 and ISO 9001 under the HLS framework can conduct a single management review that satisfies the requirements of both standards, maintain a single integrated policy framework, and engage one audit team to assess both standards simultaneously. Organizations with all three major standards — ISO 9001, ISO 14001, and ISO 27001 — routinely reduce their total audit overhead by 30–40% compared to the pre-HLS approach.
The Shared 'Shall' Text: What Identical Actually Means
The most powerful aspect of the HLS is not just the shared clause structure — it is the shared normative text. For the common requirements, ISO has mandated that all HLS-aligned standards use the same 'shall' language, with only domain-specific brackets replacing the management system name. The table below shows the key shared clauses and what their identical text means in practice:
| § | Clause title | Shared 'shall' text (paraphrased) | Integration benefit |
| 4.1 | Understanding the organization and its context | The organization shall determine external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its [management system]. | Identical requirement in ISO 9001, 14001, 22301, 27001, 45001, 42001. |
| 4.2 | Understanding needs and expectations of interested parties | The organization shall determine the interested parties that are relevant to the [management system] and their relevant requirements. | The 'interested parties' concept is a shared HLS construct — same definition across all standards. |
| 5.1 | Leadership and commitment | Top management shall demonstrate leadership and commitment with respect to the [management system] by taking accountability for the effectiveness of the [management system]. | Leadership obligations are structurally identical — preventing management from delegating accountability away. |
| 6.1 | Actions to address risks and opportunities | When planning for the [management system], the organization shall consider the issues and requirements and determine the risks and opportunities that need to be addressed. | The risk-based thinking requirement is identical across standards — only the risk domain differs. |
| 7.5 | Documented information | The organization's [management system] shall include documented information required by this document and documented information determined by the organization as being necessary for the effectiveness of the [management system]. | Same documentation framework across all standards — same version control, retention, and accessibility rules. |
| 9.3 | Management review | Top management shall review the organization's [management system] at planned intervals to ensure its continuing suitability, adequacy, effectiveness and alignment with the strategic direction of the organization. | Management review inputs and outputs are nearly identical across HLS standards — enabling combined reviews. |
| 10.2 | Continual improvement | The organization shall continually improve the suitability, adequacy and effectiveness of the [management system]. | The improvement obligation is structurally identical — one improvement cycle can serve multiple standards. |
What this means practically: an organization that has already implemented the common clauses for ISO 9001 has already done most of the structural work for ISO 27001's common clauses. The policy framework, the stakeholder analysis, the management review process, the documented information controls — all of these translate directly. The only work specific to ISO 27001 is the information security content: the risk assessment, the Annex A controls, the security-specific policies and procedures.
| Bitlion integration insight: When organizations implement ISO 27001 alongside an existing ISO 9001 or ISO 22301 ISMS, Bitlion's platform identifies which policy documents, risk processes, and management review templates already satisfy the shared HLS requirements — eliminating duplication and mapping existing artifacts to ISO 27001 clause requirements automatically. |
The ISO Management System Standards Family
ISO 27001 does not exist in isolation — it is one member of a growing family of HLS-aligned management system standards. Understanding which other standards share its architecture is important for organizations planning an integrated management system:
| Standard | Topic | HLS | Latest | Relevance for Indonesian organizations |
| ISO 27001 | Information Security | ✓ | 2022 | The certifiable ISMS standard — subject of this documentation series |
| ISO 9001 | Quality Management | ✓ | 2015 | Most widely certified ISO standard globally — often combined with ISO 27001 |
| ISO 14001 | Environmental Management | ✓ | 2015 | Integrates well with ISO 27001 for sustainability-focused organizations |
| ISO 22301 | Business Continuity | ✓ | 2019 | Directly complementary to ISO 27001 — shared risk and continuity scope |
| ISO 45001 | Occupational Health & Safety | ✓ | 2018 | Relevant for organizations with physical security and safety obligations |
| ISO 42001 | AI Management System | ✓ | 2023 | Newest HLS standard — growing relevance for AI-enabled organizations including fintech |
| ISO 37001 | Anti-Bribery Management | ✓ | 2016 | Relevant for Indonesian organizations in government procurement and regulated sectors |
The newest addition to this family — ISO 42001 for AI Management Systems, published in December 2023 — is particularly relevant for Indonesian organizations in financial services and technology. As AI becomes embedded in credit scoring, fraud detection, customer service, and regulatory reporting, the question of how AI governance integrates with information security governance becomes urgent. ISO 42001's HLS alignment means it can be integrated with ISO 27001 using exactly the same approach as any other paired standard.
| 2026 context: Regulators globally are beginning to reference ISO 42001 in AI governance guidance. Indonesia's OJK has signaled interest in AI governance frameworks for financial institutions. Organizations that implement ISO 27001 now and build their ISMS using the HLS framework are well-positioned to extend that foundation to ISO 42001 when the regulatory requirement arrives — without rebuilding from scratch. |
The PDCA Cycle Embedded in the HLS
The HLS clause structure embeds the Plan-Do-Check-Act (PDCA) cycle — the classic management improvement loop — directly into the standard's architecture. This is not incidental. It reflects ISO's fundamental philosophy that management systems exist to drive continual improvement, not to establish static compliance.
Plan — Clauses 4, 5, 6
The planning phase covers everything required to define and design the management system before implementation. In ISO 27001 terms: understanding the organizational context and scope (Clause 4), establishing leadership commitment and policy (Clause 5), and completing the risk assessment and risk treatment plan (Clause 6). Planning outputs are documented — the ISMS scope statement, the information security policy, the risk assessment results, and the risk treatment plan are all required outputs of this phase.
Do — Clauses 7, 8
The operational phase covers what the organization actually does to run the management system. Clause 7 addresses the support infrastructure — resources, competence, awareness, communication, and documentation. Clause 8 addresses operational execution — implementing the risk treatment plan, managing changes, and controlling the processes that protect information assets. The Do phase is where policy meets practice.
Check — Clause 9
The evaluation phase covers how the organization measures whether the ISMS is working. Clause 9 requires monitoring and measurement of information security performance, internal audits conducted at planned intervals, and management reviews that assess the ISMS's overall suitability, adequacy, and effectiveness. The Check phase produces the evidence that demonstrates operational reality — not just documented intent.
Act — Clause 10
The improvement phase covers what happens when the Check phase reveals problems. Clause 10 requires documented processes for identifying and correcting nonconformities, implementing corrective actions, and driving continual improvement of the ISMS as a whole. The Act phase closes the loop — the outputs of improvement feed back into the Plan phase for the next cycle.
| Why PDCA matters beyond the theory: Organizations that understand the PDCA logic behind the HLS structure approach audit preparation very differently from those that treat ISO 27001 as a documentation checklist. A well-functioning ISMS produces evidence of all four phases naturally — because the management review minutes, audit reports, corrective action records, and improvement decisions are the outputs of a genuinely operating system. Organizations that fake PDCA produce documentation that looks right but fails to show the cause-and-effect relationships between findings and actions that auditors look for. |
What Changed in the 2022 Revision's HLS Application
ISO 27001:2022 adopted the most recent version of the HLS framework, which introduced some refinements to the common clauses. The most notable change for ISO 27001 was the addition of Clause 6.3 — Planning of changes — which requires that changes to the ISMS be carried out in a planned manner. This was implicit in previous versions but is now an explicit 'shall' requirement.
The 2022 revision also refined the language around documented information (Clause 7.5), making it clearer that organizations have flexibility in how they structure and maintain ISMS documentation — the standard does not mandate specific document formats or titles, only that the required documented information exists, is controlled, and is accessible when needed.
For organizations transitioning from ISO 27001:2013 to 2022, the normative clause changes are relatively modest. The significant changes were in Annex A — which is covered in detail in Article 4.1 of this documentation series. The HLS foundation remains structurally stable.
Practical Implications for Your ISMS Implementation
Understanding the HLS has direct practical implications for how you structure your ISMS implementation project. Three of these are worth emphasizing explicitly.
Design for integration from the start
Even if you are only implementing ISO 27001 today, design your management system architecture with HLS integration in mind. Use clause references in your policy documents. Structure your management review agenda around HLS inputs and outputs. Build your internal audit program against clause numbers. When you add a second standard later — whether ISO 22301 for business continuity or ISO 42001 for AI governance — the integration effort will be a fraction of what it would be if you had built a siloed ISMS.
Map nonconformities to clauses immediately
When gap assessments, internal audits, or external auditors identify issues, map them to HLS clause numbers immediately. This makes the ISMS's improvement cycle traceable — you can see which parts of the management system are generating recurring issues, which phases of PDCA are weakest, and where management attention is most needed. A corrective action log organized by clause number is far more useful than one organized by date or by the person who raised the issue.
Use HLS to explain the ISMS to non-security audiences
The HLS structure gives you a management vocabulary that translates across disciplines. When presenting the ISMS to a CEO who is familiar with ISO 9001, you can use the shared language directly — they already understand what a management review is, what documented information means, and what continual improvement looks like in practice. The HLS makes ISO 27001 legible to people who have never worked in information security.
| Bitlion GRC platform: Bitlion organizes all ISMS activities — risk assessments, control evidence, audit findings, management review records, corrective actions — against HLS clause references natively. This means your ISMS documentation always reflects the standard's structure, audit evidence is instantly locatable by clause, and gap reports map directly to the normative requirements auditors will test. |