From loose measures to structural NIS2 compliance

Why loose measures are not enough

The problem with ad hoc measures

Loose measures usually arise reactively. A customer asks for a security policy, so a policy document is written. An audit flags that there's no backup procedure, so one is drafted. A news story about ransomware leads to the purchase of a detection tool. Each measure in itself makes sense, but together they don't form a system. They're not based on a risk analysis, not linked to responsibilities and not included in a cycle of evaluation and improvement.

The consequence is that nobody has the complete picture. The IT department knows which technical measures exist, but not which risks management has accepted. Management knows there's a security policy, but not whether it's being followed. The legal department has signed data processing agreements, but nobody checks whether suppliers comply with them. This creates an organisation that has arranged a lot on paper, but is in practice vulnerable at exactly the spots nobody is watching.

What makes NIS2 different from a project list

NIS2 doesn't ask for a checklist of measures. The directive requires a management system: a coherent approach in which governance, risk management, technical measures, incident response and supply chain security are interconnected. Article 21 lists ten measure categories, but the guiding principle is that those measures must be appropriate and proportionate to the risks. That requires a risk analysis as the foundation, not a list of popular security measures.

A supervisor won't only ask whether you've implemented two-factor authentication, but also why you chose that measure, based on which risk assessment, who is responsible for it and how you verify that the measure is still effective. You don't reach that level of substantiation and coherence with loose actions. It requires a structure that connects the measures and embeds them in an ongoing process.

The risk of false security

The most dangerous consequence of an ad hoc approach is false security. The organisation feels it's "doing a lot for security", but has no insight into residual risks. Measures that were once implemented are not evaluated. Policy documents age. New systems are put into use without anyone assessing whether the existing measures also apply to them.

During a supervisor inspection or, worse, during a security incident, that false security becomes painfully visible. The organisation cannot demonstrate that it made conscious choices, that its measures are based on a current risk analysis or that it structurally works on improvement. In the worst case, measures that once worked have since become outdated, making the organisation more vulnerable than it thinks.

What structural NIS2 compliance entails

Governance as the starting point

Structural compliance starts with governance. That means the board doesn't just sign a security policy, but is actively involved in setting the risk appetite, approving controls and monitoring progress. NIS2 explicitly places that responsibility with the board and provides for personal liability in cases of structural non-compliance.

In practice, governance translates into three things. First: a clear mandate. The board commissions the establishment of a management system and makes available the resources needed for it. Second: periodic reporting. The board regularly receives an overview of the most important risks, the status of controls and outstanding deviations. Third: decision-making. The board makes conscious decisions about which risks are accepted and which additional measures are needed. Those decisions are recorded, so they are demonstrable to the supervisor.

Ownership at every level

One of the most important differences between loose measures and a structural approach is ownership. In an ad hoc situation, measures often belong to "IT" or to "nobody in particular". In a structural approach, every control has an owner: someone responsible for implementation, maintenance and evidence that the control works.

Ownership goes beyond a name in a spreadsheet. It means the owner understands what the control entails, why it was chosen and how to act if the control no longer suffices. It also means there's an escalation path: if an owner determines that a control is not feasible or no longer appropriate, that finding must reach somewhere it can be acted upon. Without ownership, controls remain stuck in good intentions.

Coherence between controls

Structural compliance means controls don't stand alone but are part of a logical whole. The risk analysis determines which controls are needed. Those controls are recorded with ownership, evidence and an evaluation cycle. Deviations are registered and tracked until resolved. Incidents are evaluated and lessons learned are incorporated into adjustments to controls or policy.

That coherence is exactly what distinguishes a management system from a collection of loose actions. It's the plan-do-check-act cycle that ensures your organisation is not only compliant today, but remains so amid changing risks, new threats and organisational growth. NIS2 expects that cycle: the directive requires organisations to assess the effectiveness of their measures and adapt their approach when circumstances call for it.

The risks of an unstructured approach

Unclear responsibilities

Without formal ownership, nobody knows who is responsible when a control fails. Is it the IT administrator who set the configuration? The manager who approved the policy? Or the board that exercised insufficient oversight? During a supervisor inspection, "we thought IT was handling that" is not an acceptable answer. NIS2 requires that responsibilities are explicitly assigned and demonstrable.

In practice, unclear ownership leads to another problem: tasks that remain undone. If nobody feels ownership of updating a supplier assessment or testing the incident response plan, it simply doesn't happen. The control exists on paper, but becomes outdated in practice. That's exactly the type of situation a supervisor exposes.

Fragmentation of information

A second risk is fragmentation. Policy documents sit in a shared folder. Risk assessments are in a spreadsheet. Evidence of technical controls is in the IT administrator's mailbox. Supplier assessments are stored in the CRM. Incident logs are maintained in a separate ticketing system.

None of these storage locations is wrong in itself. But the complete picture is spread across five or six systems that aren't connected. Nobody can see at a glance how the organisation is doing. And when the supervisor asks for evidence that a specific control works, it takes hours to find the right information. Fragmentation makes compliance fragile: it works as long as the one person who has the overview is available, but falls apart as soon as that person isn't there.

Lack of continuous insight

Loose measures are often implemented once and then never checked again. A configuration that was correct at installation may have been changed months later without anyone noticing. A supplier that scored well at the first assessment may have since been acquired by a party with a very different security level. A policy document approved last year may no longer cover the current situation.

Without continuous monitoring, there's no insight into whether your controls still work. Your compliance status is a snapshot of the past, not a current picture of the present. That's problematic in light of NIS2, which explicitly asks for ongoing evaluation of the effectiveness of controls. A supervisor doesn't want to know how you were doing at the last audit, but how you're doing right now.

How to make the transition

Start with an overview

The first step towards structural compliance is not adding new controls, but mapping what already exists. Which controls have you implemented? Where are they documented? Who is responsible? Is there evidence they work? And how do they relate to the risks you've identified?

That inventory often yields a sobering picture. There turn out to be controls nobody maintains anymore. There are risks for which no control has been taken. There's policy that no longer matches reality. That's not a reason for panic, but it is an honest starting point. From that overview, you can prioritise purposefully instead of blindly adding new controls.

Link controls to risks

The next step is connecting your controls to your risks. Every control should be traceable to a risk from your risk analysis. If you can't link a control to a concrete risk, the question is justified whether that control is needed. Conversely: if there are risks for which no control has been taken, that's a gap that needs to be closed.

That linkage also reveals the proportionality NIS2 requires. An organisation with a high risk profile in a critical sector needs different controls than an organisation with a lower risk profile. By explicitly linking controls to risks, you can substantiate to a supervisor why you've made certain choices and why you have or haven't implemented certain controls.

Establish a regular rhythm

Structural compliance requires regularity. Not an annual sprint towards an audit, but a regular rhythm of activities embedded in your operations. Think of a monthly check of control status, a quarterly report to the board, a semi-annual reassessment of the most important risks and an annual evaluation of the complete management system.

That rhythm doesn't need to be heavy. The goal is not to organise more meetings, but to ensure compliance activities aren't dependent on the urgency of the moment. If you only look at your controls when there's an incident or when a customer asks about them, you're reactive by definition. A regular rhythm makes you proactive and prevents things from deteriorating unnoticed.

Use a framework as a guide

You don't need to invent the structure yourself. Existing frameworks offer a proven setup you can follow. The CyberFundamentals framework offers three levels (Basic, Important, Essential) with concrete controls per level. The NIS2 Supply Chain framework focuses specifically on supply chain security. ISO 27001 offers a complete management system for information security that closely aligns with the NIS2 requirements.

The advantage of a framework is that it forces you to work systematically. You can't selectively choose the parts you find easy and skip the rest. The framework shows which areas you need to cover and how they relate to each other. That's exactly the coherence that's missing when you work with loose measures.

The difference in practice

From document to working system

In an ad hoc approach, a policy document is the end result. It's written, approved and stored. In a structural approach, the policy is a starting point. It describes the framework within which the organisation operates. Those frameworks are translated into concrete controls with owners. The owners implement the controls and provide evidence they work. Deviations are recorded and resolved. And periodically, the policy is evaluated and updated where needed.

That difference sounds subtle, but the effect is significant. In the first case, you have a document. In the second case, you have a working system that actually protects the organisation and that you can demonstrate to supervisors, customers and partners. It's the difference between a car sitting in the garage and a car that drives.

From incident-driven to risk-driven

Another fundamental shift is the transition from incident-driven to risk-driven working. In an ad hoc approach, measures are taken in response to incidents, audits or customer questions. It's a defensive posture: you solve problems when they arise. In a structural approach, you identify risks in advance and take measures to prevent them or limit the impact.

That shift has direct value. You invest your time and budget where the risk is greatest, instead of reacting to the complaint that's loudest. You can explain to the board which risks you've covered and which residual risks have been consciously accepted. And you can show a supervisor that your choices are based on a substantiated analysis, not on chance or reaction.

From periodic checking to continuous monitoring

The third shift is the transition from periodic checks to continuous monitoring. In an ad hoc approach, the status of controls is checked at audits or quarterly reviews. Between those moments, there's no visibility into whether controls still function. In a structural approach, controls are continuously monitored, so deviations are immediately flagged.

Continuous monitoring doesn't mean someone stares at dashboards all day. It means automated tests at regular intervals check whether configurations are still correct, whether access rights are still current and whether security settings haven't been unintentionally changed. When a deviation occurs, a notification follows so the owner can take action. That model is more scalable, more reliable and less dependent on individual people than manual checks.

Where tooling makes the difference

Centralising controls and evidence

Ensuring coherence between controls, risks, ownership and evidence is manually possible with a small number of controls. But as the organisation grows and the number of controls increases, maintaining everything in spreadsheets and shared folders becomes unmanageable. A GRC platform centralises all components in one place: controls are linked to risks, owners are assigned, evidence is linked to the control it applies to and deviations are tracked until resolved.

Tidal Control provides that central structure. The platform contains pre-built controls and policy templates for the CyberFundamentals framework and the NIS2 Supply Chain framework. Every control can be assigned an owner, tasks and deadlines. Evidence is automatically collected through integrations with your cloud environments and development tools. More than 150 automated tests continuously check whether your controls actually function.

Safeguarding workflows and responsibilities

Structural compliance stands or falls with safeguarding responsibilities in workable processes. Tooling makes it possible to set up workflows that ensure tasks don't remain undone. Automatic reminders when a reassessment is scheduled. Escalation paths when a deviation isn't resolved within the set timeframe. Notifications when an automated test detects a failure.

This isn't a matter of adding bureaucracy. It's removing dependence on individual people. In a manual approach, compliance depends on the discipline and availability of a few key people. In a tooling-supported approach, processes are safeguarded in the platform and continue running, even when an employee is on holiday or the organisation's composition changes.

Growing with the organisation

A final advantage of tooling is scalability. Organisations starting with NIS2 compliance today often begin with a limited scope: the most critical systems, the most important suppliers, the first set of controls. As the organisation grows, so does the scope. New systems are put into use, new suppliers are added, additional frameworks become relevant.

Tidal Control is designed to scale with you. Organisations that follow ISO 27001, SOC 2 or other standards alongside NIS2 manage all frameworks in one platform. Controls that apply to multiple standards are implemented once and automatically mapped to the relevant frameworks. This prevents duplicate work and ensures the transition from an initial set of controls to a mature management system proceeds gradually and manageably.

Frequently asked questions

What is the difference between loose NIS2 measures and structural compliance?

Loose measures solve individual problems but lack coherence, ownership and a cycle of evaluation and improvement. Structural compliance means controls are based on a risk analysis, are provided with ownership and evidence, and are maintained in an ongoing improvement cycle. The difference is that between a collection of documents versus a working management system.

When is the right moment to switch from ad hoc to structural?

The moment is when you notice the overview is disappearing: controls without owners, evidence scattered across multiple systems, a board that doesn't know how the organisation is doing, or the inability to quickly provide a current picture of your compliance status. For organisations that fall under NIS2, the answer is essentially: now. The Cybersecurity Act is expected to come into force in the second quarter of 2026, and a structural approach takes months to set up.

Which elements are most often overlooked in the transition?

Three elements are consistently underestimated. First: linking controls to risks. Many organisations implement controls without a formal risk analysis, meaning they cannot substantiate why they've made certain choices. Second: ownership. Controls exist on paper, but nobody feels responsible for maintenance. Third: the improvement cycle. Incidents and audits are handled, but lessons learned are not structurally incorporated into adjustments to controls or policy.

How do you prevent structural compliance from becoming too bureaucratic?

By using proportionality as a guiding principle. Not every control needs the same depth. Not every risk assessment needs to be an exhaustive document. The goal is a workable system that protects the organisation and that you can demonstrate, not a paper reality nobody uses. Start small, focus on the controls with the highest impact and gradually expand. Choose concise policies that employees actually read, instead of extensive documents that disappear into a drawer.

How does tooling help with the transition to structural NIS2 compliance?

Tooling centralises controls, ownership, evidence and deviations in one place. It automates repetitive tasks such as evidence collection and status checks. It safeguards workflows so responsibilities don't depend on individual people. And it provides continuous insight into your compliance status, so you know how you're doing not just at audits but at any moment. That makes the transition from ad hoc to structural not only achievable, but also sustainable in the long term.