Building an ISMS: Step-by-step instructions according to ISO 27001:2022

An information security management system (ISMS) according to ISO/IEC 27001:2022 is not a documentation project, but a control system with 93 controls from Annex A, a binding statement of applicability, a risk management process according to clause 6 and a continuous improvement cycle according to clause 10. Anyone who sets up an ISMS coordinates a chain of scope, stakeholder analysis, risk assessment over 12 to 18 months. Action planning, implementation, internal audit and certification audit. The international transition period for the new version of the standard runs until October 2026, after which only certificates according to ISO/IEC 27001:2022 will be recognised, and only those companies that were audited in a timely manner will retain their certificate.

This article describes ten operational phases, each of which is backed by clear artifacts, responsibilities and realistic timelines. It is aimed at information security officers (ISB), IT managers, compliance officers and managing directors who are introducing an ISMS for the first time or are making the transition to the 2022 version. The focus is on the operational question of how the structure works without isolated solutions. Instead of a pure standard description, we show which templates, reporting lines and interfaces are really needed, and how CIVAC, as a compliance platform and officer-as-a-service, bundles the structure in one system so that audit traces, risk registers and action plans are not lost in Excel files, but are documented in a versioned and reproducible manner.

ISO/IEC 27001:2022 requires in clause 4 to determine the context of the organisation, the relevant interested parties and the scope of the ISMS. This phase decides how much effort the entire project generates and which business processes, locations and IT systems are certified. A scope that is too broad creates an unnecessary burden and overwhelms internal resources; a scope that is too narrow is critically questioned in audit practice and can lead to findings that delay or endanger the initial audit.

Operationally, the scope definition is carried out as a written document with three sections. Firstly, organisational delimitation: which business areas, subsidiaries and locations are included. Secondly, technical delimitation: which IT systems, platforms, cloud services and network segments fall into the scope. Thirdly, interfaces: which external service providers, processors and customers touch the scope. Clause 4.3 explicitly requires a justification for exclusions, which is later taken up again in the Statement of Applicability and remains relevant to the audit.

The stakeholder analysis identifies requirements that are relevant for the ISMS. Customers with ISMS requirements in contracts, regulators with reporting obligations such as NIS-2 or DORA, supervisory authorities, data protection supervisors and internal stakeholders such as the board of directors, works council and audit committee. Each requirement is documented as an entry in the stakeholder register, with source, frequency, person responsible and the specific consequence for the ISMS, such as additional reporting, a specific control requirement or a contractual clause with audit rights for the client.

In the CIVAC workspace there is a template for the scope documentation and the stakeholder register, derived from the ISO clause tree. The Information Security Officer works in the same system as the management, so that releases are dated and signed and the subsequent auditor can fully understand the versioning without the need for separate document management coordination or the creation of parallel files.

Clause 5.2 requires an information security policy formally approved by management. It is not a detailed regulation, but a one- to three-page document that states the purpose of the ISMS, the strategic goals, the commitment to continuous improvement and the responsibility of the management. In terms of content, it contains the minimum components of clause 5.2 and refers to downstream guidelines without duplicating or anticipating their content.

The responsibilities are regulated in clause 5.3. Management appoints a central role for the ISMS, usually the ISB or Chief Information Security Officer (CISO). The written appointment certificate documents the scope of tasks, professional freedom from instructions, reporting line to management and escalation rights. The appointment certificate, signed, filed, verifiable. In addition, roles for risk owners, those responsible for measures and internal auditors are defined, each with clear representation regulations.

A common mistake is to appoint the IT manager alone as ISB. Although clause 5.3 does not require organisational separation, in practice the personnel union creates a conflict of interest between security requirements and operational reality, especially when budgets are tight. Better practice is an independent ISB with a reporting line to the management, which controls IT security technically without being subordinate to the IT line. Supervisory authorities specifically pay attention to this structural separation in Stage 2 audits.

CIVAC provides ready-made guideline templates and appointment certificates that are referenced with the 93 controls according to ISO/IEC 27001:2022. The dual model approach is specifically effective here. Licence the workspace for your internal representatives or have our representatives appointed if the professional independence cannot be represented within your own ranks, for example in medium-sized structures with personnel shortages in IT management and without a dedicated security budget for a separate position.

Clause 6.1 requires systematic risk management. The procedure must be documented, carried out regularly and deliver reproducible results. In practice, ISMS projects go through four steps. Firstly, identification of the values ​​(assets), secondly, identification of threats and vulnerabilities, thirdly, risk analysis with probability of occurrence and impact, fourthly, risk assessment against previously defined acceptance criteria. The methodology itself is a mandatory document and is checked by the auditor at the beginning of Stage 1, as is the consistency of the rating scales used.

The list of values ​​includes information, applications, infrastructure, personnel, physical assets and suppliers. A pragmatic size is a register with 50 to 200 values ​​depending on the size of the company. Each asset is given an owner, a confidentiality, integrity and availability score, and a link to the business processes it supports. Cloud services and processors are managed as separate values in order to prepare the supply chain analysis later and to create audit trails for the contracts, including the order processing contracts according to Art. 28 GDPR.

The threat analysis is often based on catalogues such as the BSI threat overview or ISO/IEC 27005. 30 to 50 threat categories are common, which are combined with the values Threat-value mapping results. The vulnerability analysis complements the view from audit reports, penetration tests, vulnerability scans and incident data from the last 24 months, so that empirical findings are incorporated and the risk analysis is based not only on assumptions, but on real incidents.

The risk assessment is typically carried out as a matrix with probability of occurrence and impact, each on a four or five-stage scale. Acceptance criteria are set before the assessment, for example risks above level eight must be addressed. In the workspace, the risk register is kept in a versioned manner, the risk owners receive quarterly reminders about the reporting line, and audit templates from the CIVAC inventory cover the Clause 6.1 requirement in a standard-compliant manner.

Clause 6.1.3 requires a decision per risk: Avoid, Reduce, Transfer or Accept. If you choose reduce, you select those that appropriately reduce the risk from the 93 controls in Annex A of ISO/IEC 27001:2022. The new version of the standard groups the controls into four topics: Organizational (37), People-related (8), Physical (14) and Technological (34). If you keep an overview, you keep the project under control, especially during the transition from the 2013 version with its 114 controls and eleven new controls in the current version.

The Statement of Applicability (SoA) is the central audit document. For each of the 93 controls, it lists whether it is applicable, whether it is implemented, why it is excluded (if applicable), and which risk treatment it addresses. Auditors regularly begin Stage 1 audits with the SoA because the entire ISMS maturity level can be derived from it. An incomplete or inconsistent SoA is the most common reason for findings in the initial audit, especially if justifications for exclusions are missing or the implementation status and risk register do not match.

The risk treatment plan supplements the SoA with measures, deadlines, responsible persons and residual risk assessments. Measures are specifically formulated, not abstract: not improving access control, but multi-factor authentication for all privileged accounts by June 30th, responsible for IT operations, with measurable proof of effectiveness. Residual risks are formally accepted by the risk owner and documented in the risk register with a date and signature, so that it is clear in the audit who consciously accepted which residual risk and with what written justification.

CIVAC supplies SoA templates with the complete control list of the 2022 version, supplemented by cross-references to BSI-Grundschutz and NIS 2 mandatory measures. This creates a consolidated view of compliance requirements, instead of parallel Excel files for each standard. Audit-proof, documented, § 27001-proof, and Stage 1-prepared.

ISO/IEC 27001:2022 requires documented information in several places without prescribing a rigid documentation format. Mandatory requirements include, among other things, the scope of application, the information security policy, the risk methodology, the results of the risk assessment, the risk treatment plan, the statement of applicability, the security objectives and the evidence of effectiveness measurement according to Clause 9. These documents form the skeleton that is checked first in the audit and they are the ticket to the actual effectiveness test in Stage 2.

In addition, there are guidelines and procedural instructions that are derived from the controls. Typical mandatory documents include an access control policy (A.5.15), a cryptography policy (A.8.24), a supplier policy (A.5.19), an incident management policy (A.5.24), a business continuity policy (A.5.30) and an asset management policy (A.5.9). The exact list results from the SoA and the risks. A generic transfer from sample collections almost always leads to findings because the company-specific reality is missing and the audit discussion quickly reveals the discrepancy.

Operational evidence is just as important as guidelines. Auditors ask not just whether a policy exists, but whether it is being lived. Examples: Who checks authorizations and when, where are training participations documented, where are the incident tickets from the last 12 months, how were supplier audits carried out, which CAPA tickets are open. Without this evidence, the ISMS remains paper, and Stage 2 becomes an unpleasant experience.

In the workspace, the document pyramid is managed on a role-based basis. Guidelines, guidelines, work instructions and records are versioned, released and linked to the 93 controls. The auditor calls, the evidence is ready. Linked to the risk register and the action plan, a seamless path is created from the standard requirement through the risk assessment to the concretely implemented measure, including an escalation path to management and effectiveness measurement per quarter.

Clauses 7.2 and 7.3 require competence and awareness for all persons working under the control of the organisation and carrying out activities that affect information security. In practice, this means a three-stage training concept. General awareness training for all employees, role-specific in-depth training for particularly sensitive functions, in-depth training for ISMS-relevant roles such as risk owners and internal auditors. Each stage is planned separately in terms of content, frequency and effectiveness measurement, with clear responsibility.

In terms of content, the awareness training includes at least the topics of password security, phishing detection, safe mobile device use, data classification, reporting channels in the event of incidents, clean desk behaviour and behaviour in the workplace, including home office and mobile devices. Training takes place annually or upon entry, effectiveness is measured through knowledge tests, phishing simulations or random samples. Pure click-through modules without testing are considered inadequate and will be criticized in the audit.

In-depth training is required for particularly critical roles such as administrators, developers, personnel with access to secrets or personnel in contact with personal data. Contents include secure configuration, patch management, secure software development according to OWASP logic, secure handling of cryptographic keys, data protection-specific content and the consequences of violations, including employment law measures and disciplinary escalation paths. Training records are archived on a personal basis.

Effectiveness is measured in accordance with clause 9.1. Key figures include training rate, phishing click rate, knowledge test pass rate, time to report phishing emails. In the CIVAC workspace, training participation and effectiveness measurements are carried out on a role-based basis. The reporting line to management contains the awareness metrics on a monthly basis, so that clause 9.1 is continuously met. Others manage compliance like a filing cabinet, here it is managed like software, with clear thresholds, escalation logic and automated quarterly reporting for management assessment. External training providers can be connected so that only one learning management system is maintained.

Clause 8 requires the implementation of the risk treatment plan and the operational management of information security. This is the most time-consuming phase and typically lasts six to nine months. The measures from the SoA are introduced step by step, starting with the highest risks and the quick wins that can be implemented without a major project, such as multi-factor authentication, minimum password lengths, updating password rules according to NIST SP 800-63B or hardening exposed server configurations.

Operational control means that measures must be measurable. Examples include the patch rate for critical systems within 14 days, the authorisation review frequency per quarter, the backup restore times in regular tests or the supplier audit frequency per year. Each measure is managed in a KPI dashboard, ideally with target and actual values ​​and an escalation if the goals are missed, supplemented by a comment track on causes and the link to the responsible measure owner.

Outsourcing relationships are a complex of their own. Clause A.5.19 to A.5.23 governs supplier management and cloud services. In practice, this means that contracts with processors contain an information security clause, suppliers are regularly audited and emergency plans take into account the dependency on critical service providers. NIS-2 tightens the requirements if the client is essential or important within the meaning of the BSI Act, with extended supply chain obligations and a separate reporting obligation for incidents in the supply chain.

In the workspace, measures, supplier requirements and KPIs are managed in one system. Links between measures, controls and risks are consistently visible, so that the path remains traceable in the audit. The reporting line provides management with monthly status without anyone having to put together Excel slides, supplemented by automatic escalation when thresholds are exceeded and colour marking of critical actions.

Clause 9.2 requires a full internal audit prior to the certification audit, covering all clauses and all applicable controls from the SoA. An internal audit is carried out by independent internal auditors or external auditors who are professionally qualified and organizationally independent. The audit plan, audit criteria and audit reports are documented information and are first requested by the auditor in Stage 1, supplemented by the evidence to close the internal audit findings.

The management assessment in accordance with Clause 9.3 is carried out at least annually at management level. Inputs include, but are not limited to, the results of internal audits, incidents, complaints, risk assessments, effectiveness measurements, customer feedback and changes in interested parties. Outputs are documented decisions for improvement, resource requirements and adjustment of security goals. The meeting minutes are mandatory evidence in the audit, missing minutes are a classic finding that can delay the initial audit.

Clause 10 requires continuous improvement. Specifically, deviations from internal audits, external audits, incidents or effectiveness measurements are recorded in a CAPA system (Corrective and Preventive Actions). Each deviation receives a root cause analysis, a corrective action, a deadline, a responsible person and proof of effectiveness. CAPA tickets are the most common source of initial audit findings when they are incomplete or without proof of effectiveness, such as only closing date without proof of effectiveness or without re-testing of the original deviation.

CIVAC maintains internal audit, management review and CAPA in one system. Audit plan and audit reports are derived from the 490 ready-to-use audit templates and linked to the SoA. The reporting line to management contains the agenda of the management review with preparation materials, so that the Clause 9.3 meeting does not have to be improvised, but is structured and documented in an audit-proof manner. Quarterly reviews and CAPA final reports can be exported from the system; management can see the progress without an Excel folder.

Phase 9 is the certification audit. It takes place in two stages. Stage 1 is a document review with an on-site appointment in which the auditor reviews the SoA, the risk methodology, the guidelines and the audit planning. Stage 2 is the main audit, typically lasting three to five days, in which the effectiveness of the controls is assessed on site and in interviews. Findings are listed in three categories: major deviation, minor deviation, observation, each with a correction deadline.

After successful Stage 2, the certification body issues the certificate, valid for three years with annual monitoring audits. Re-certification audits take place after the three years have expired. In the case of major deviations, the defect must be remedied and proven within a specified period of time before the certificate is issued. The transition period to the 2022 version ends in October 2026, after which only certificates according to ISO/IEC 27001:2022 will be recognised and 2013 certificates will no longer be valid.

Phase 10 is the permanent task. The ISMS lives through repetition. The internal audit, the management assessment, the risk reviews and the update of the SoA take place annually. Key performance indicators are reported to management and authorizations are reviewed on a quarterly basis. Incidents and CAPA tickets are maintained monthly. The ISMS is not an end product, but a control system that grows with the company and ideally remains visible in day-to-day business.

Turn reading into a mandate. CIVAC is a compliance platform and officer-as-a-service. Licence the workspace for your internal representatives or have our representatives order it. Write to info@civac.de or use the contact form on civac.de. We discuss the scope, previous experience and target timeline, then you will receive a model proposal. The appointment certificate, signed, filed, verifiable. Anyone who chooses the external information security officer gains time and retains responsibility.