Building an ISMS: A 6-step implementation guide

Key takeaways:

• Building an ISMS is achieved in six steps: commitment, scope, asset inventory, risk assessment, measures and roles, and continuous monitoring.
• Without up-to-date IT documentation, any risk assessment lacks a data foundation—this is the most common reason why projects stall.
• Since the NIS2UmsuCG (in effect since December 6, 2025), structured risk management is no longer optional but mandatory for around 29,500 German companies.

Only about 38.5 percent of companies subject to NIS-2 had registered with the BSI by the March 6, 2026 deadline. The NIS2UmsuCG has been in effect since December 6, 2025, without a transition period for around 29,500 companies – for most of them, structured risk management is no longer optional, but mandatory. Anyone looking to build an ISMS now needs a sequence that can be maintained in day-to-day operations. This article outlines six steps to ensure a successful implementation without getting bogged down in a chaos of Excel spreadsheets and questions of responsibility.

What does it mean to build an ISMS?

Building an ISMS means transforming information security from a collection of individual measures into a system of policies, processes, and clear responsibilities. Instead of isolated firewall rules or ad-hoc backups, you create a structure that systematically identifies, assesses, and addresses risks. This structure is reviewed regularly; it is not something you set up once and then forget.

The trigger for implementation is usually an external requirement: NIS-2 compliance, a customer request for security documentation, or the desire for ISO 27001 certification. Some companies start proactively because they want to improve their risk posture before an incident forces their hand. What exactly an Information Security Management System entails in detail and how it differs from pure IT security is described in detail elsewhere. This article focuses exclusively on the path to getting there: six steps that build on one another and make sense in this specific order. Without a defined scope, the asset inventory lacks a framework; without an inventory, the risk assessment lacks a foundation. If you skip steps, you will end up doing the work twice later on.

It is important to have realistic expectations regarding the effort involved: Building a robust system takes anywhere from several months to several years, depending on the size of the company. Anyone who underestimates this will plan too tightly from the start and find themselves under pressure by the third or fourth month, precisely when diligence is most critical.

What prerequisites must be in place before starting?

Before taking the first step, three points should be clarified. Experience shows that if any of these are missing, the project will fizzle out:

• Management commitment: Budget, time, and visible support – not just a signature on a document.
• Responsible person: At least one person or a small team must lead the implementation, usually as an Information Security Officer (ISO).
• Realistic timeframe: For a medium-sized company with around 100 employees, 9 to 12 months is a standard benchmark to reach a certification-ready state.

Without support from the top, implementation almost always fails due to a lack of resources or insufficient authority to enforce changes across departments. Management must treat information security as a priority, not as a side note for the IT department.

In practice, implementation is often mistakenly left entirely to the IT department. This backfires as soon as measures affect departments like HR, procurement, or sales, where no one has the mandate to change processes. A small, cross-functional team—comprising IT, compliance, and at least one person with decision-making authority—prevents this bottleneck from the start.

How do you define the scope?

The scope determines which locations, systems, processes, and service providers are included. This decision is made at the beginning and has consequences for the entire implementation process.

A scope that is too broad overwhelms small teams from the start. A scope that is too narrow creates gaps that will inevitably be exposed during the audit. A deliberately limited initial scope, which is gradually expanded after the first certification, is the more pragmatic approach in practice than attempting to cover the entire company at once. Cloud services and external providers must be explicitly included in this consideration—they are frequently forgotten in practice and then overlooked during risk assessment.

The specific ISO 27001 requirements for a scope are defined in the standard itself and can be used as a checklist for scope definition.

An example from our consulting experience illustrates the significance of this decision: A manufacturing company with two sites initially wanted to include both plants plus all cloud applications in the scope. After an initial assessment, it became clear that one site contained significantly fewer security-critical processes than the other. The decision to initially cover only the more critical site and add the second in the next expansion phase significantly shortened the time to the first internal readiness audit. A limited but thoroughly considered scope beats an ambitious but incomplete one.

How do you build the asset inventory?

In practice, this is where you determine whether your further implementation will be built on a solid foundation. An asset inventory records all systems, applications, data sets, and processes that belong to the scope. What is not recorded cannot be assessed or protected later.

Many companies attempt this step using Excel lists that are outdated after just a few weeks: new servers are added during operations but not recorded. Permissions for departed employees remain because no one maintains the list. A reliable asset inventory requires a data source that updates automatically rather than being maintained manually. Agentless inventory tools like Docusnap continuously track servers, clients, network devices, and cloud services, providing the foundation upon which subsequent steps can reliably function.

Without this foundation, any subsequent risk assessment becomes a guess rather than a well-founded analysis.

A common pattern in consulting practice: A mid-sized company with around 150 employees began its inventory in three separate Excel files—one for servers, one for permissions, and one for software licenses. After six months, all three lists were incomplete and partially contradictory. Only an automated inventory brought the data back to a common, reliable state. This experience is repeated across industries because manual lists structurally cannot keep pace with the rate of change in real IT environments. New cloud services, changing staff, and patch cycles ensure that every snapshot becomes outdated within weeks.

How does risk assessment work?

Based on the asset inventory, threats and vulnerabilities are assessed according to their value: What could happen, how likely is it, and how severe would the damage be? A common, pragmatic approach for mid-sized companies is a 5×5 matrix that rates both the probability of occurrence and the impact on a scale of 1 to 5 and calculates a risk score from these.

Decisions are derived from the results: risks are reduced, transferred (e.g., via cyber insurance), accepted, or avoided through process changes. This decision must be documented and justified in a traceable manner – auditors check not only whether a risk assessment exists, but whether the decisions made match the actual risk profile.

A typical practical example: A manufacturing company identifies outdated access rights on a file server as a medium risk. Instead of a complex technical solution, a simple but consistently enforced permission cleanup is often sufficient here.

Risk assessment is therefore the true heart of the entire framework. It distinguishes a professional system from a mere collection of checklists because it explains why certain measures are prioritized and others can wait. It is important to define the methodology once and then consistently maintain it. Anyone who invents new criteria for every assessment cycle loses comparability between cycles and, with it, the ability to demonstrate genuine improvement.

Which roles and measures belong in this phase?

The risk assessment leads to concrete measures—technical ones like encryption and access controls, but also organizational ones like policies and training. Five roles recur in almost every setup: Management, the Information Security Officer, IT managers, risk owners for each department, and the staff as a whole.

At the end of this phase is the document signed by management: Information Security Policy: the foundational document that bindingly establishes goals, scope, and responsibilities. Employee training is not an optional extra – the most common mistake when building an ISMS is neglecting awareness measures, even though people remain the most frequent gateway for security incidents.

Roles and responsibilities should be documented in writing from the start, rather than just agreed upon verbally. Who is the risk owner for each area? Who decides when a risk exceeds the defined tolerance level? Who reports incidents, and to whom? These questions may seem trivial at first, but they determine whether you can act quickly and in a coordinated manner in an emergency, or whether you have to waste time clarifying responsibilities while the damage is already mounting.

How do you turn implementation into an ongoing process?

An ISMS project does not end with the implementation of the first set of measures. The PDCA cycle – Plan, Do, Check, Act – turns it into a continuous process: controls are tested, effectiveness is measured, and vulnerabilities are fed into the next planning round.

An internal ISMS audit at least once a year shows whether documents still reflect the actual state of the IT environment. Anyone who only checks whether documents exist, rather than whether they are accurate, misses the true value of the audit. There is no one-size-fits-all solution when choosing the underlying standard. In addition to ISO 27001, BSI IT-Grundschutz is an equivalent, well-established alternative in Germany, especially for companies with ties to public administration or critical infrastructure sectors.

Once the setup is successfully completed, the next question often arises: Is it worth taking the step toward formal ISMS certification? For companies with clients in regulated industries or those with supply chain requirements, this is often the logical next step, but it is not a mandatory requirement for an effective management system.

Even after the first round is complete, the data foundation remains critical: controls can only be tested effectively if you know which systems are actually affected. An up-to-date asset inventory is therefore not just a one-time starting point, but the foundation for every subsequent iteration of the PDCA cycle. Tools that continuously monitor the IT landscape eliminate the recurring manual effort that would otherwise be required for every audit cycle.

What has changed in ISMS implementation for 2026?

Three developments are relevant for 2026 planning:

• The NIS-2 registration deadline with the BSI ended on March 6, 2026 – by that date, only about 38.5 percent of affected companies had registered, but late registration remains possible and is in any case preferable to taking no action at all.
• The first required proof of compliance was postponed from the end of 2025 to June 30, 2026 – this additional time should be used for structured implementation, not for further delay.
• The BSI portal for registration has been live since January 2026 and also provides resources for risk analysis as well as current security notifications.

Anyone starting their project now should use these deadlines as a framework. Do not skip the logical sequence—commitment, scope, inventory, risk assessment, measures, effectiveness testing—just to finish faster. A hastily assembled system without a reliable data foundation will withstand neither a real security incident nor a thorough audit.