Looking for a NIS-2 Tool? Why an Operating Model Must Come Before Software

"We need a tool for NIS-2." This is a sentence heard in boardrooms and IT departments across mid-sized companies almost every week. The expectation is clear: a smart software solution should tame the complexity of the European cybersecurity directive. But a closer look reveals that reaching for a tool is often the second step taken before the first. Without a clear operating model, even the best software only automates existing chaos.

Why the Call for a Tool Reveals the Real Problem

The question "Which tool do we need?" sounds pragmatic. In practice, however, it signals that fundamental groundwork has not yet been completed. If you do not know which evidence must be provided to which authorities, you cannot meaningfully configure any tool. If you have not clarified which processes already exist and which need to be built from scratch, any software will fail against reality. And if operational responsibility has not been assigned to specific individuals, you end up with a system that nobody maintains.

In many mid-sized companies, NIS-2 is initially understood as an IT project. Yet at its core, the directive is a governance issue: it requires organizations to strategically manage their information security, systematically assess risks, and clearly assign responsibilities. A tool can support this framework but can never replace it.

Three Questions Before Any Tool Decision

Before any market analysis takes place, three central questions should be answered. First: What exactly needs to be demonstrated, and to whom? NIS-2 requires evidence for national supervisory authorities but also for business partners in the supply chain. Requirements vary by industry, company size, and classification as an essential or important entity. Without this clarity, there is no foundation for a targeted tool selection.

Second: Which processes already exist? Many organizations already have elements of an information security management system in place without labeling them as such. Backup routines, access controls, patch management, or incident response plans are often present but not documented or standardized. A good tool digitizes these existing processes and makes them auditable. Poor tool deployment, on the other hand, forces organizations to adapt their workflows to the software rather than the other way around.

Third: Who is operationally responsible? On paper, the IT department is often listed. In practice, however, NIS-2 requires a clear owner who can manage both the technical and organizational dimensions. Whether CISO, information security officer, or another role: without a person who lives and drives the system, every tool becomes an unused investment.

The Operating Model as Foundation

An operating model for information security describes how security processes work in day-to-day operations. It defines roles, responsibilities, escalation paths, and reporting cycles. It specifies how risk assessments are conducted, how measures are tracked, and how audits are prepared. This model does not need to be perfect before a tool is introduced. But it must exist, at least as a robust foundational structure.

Organizations that skip this step frequently experience the same pattern: the tool is introduced, initially populated with enthusiasm, then increasingly neglected. After six months, most stakeholders are back to working with spreadsheets and emails because the tool does not reflect actual workflows. The investment is lost, and the compliance gap remains.

Practical Recommendation: Structure First, Digitize Second

The pragmatic path begins with an honest assessment of the current state. Which security processes are already running? Where are the gaps? Who bears which responsibility? From these answers, an operating model emerges that forms the basis for every tool decision. Only then does it make sense to survey the market, because then organizations know what the tool must deliver and can select purposefully instead of being dazzled by feature lists.

NIS-2 is not a software project. It is an organizational project that can be supported by software. Those who respect this sequence not only save budget but also build a security structure that survives the next regulatory requirement.