NIS2 in practice: where to start implementation in a company

NIS2 often enters board conversations as pressure: “we must be compliant.” In practice it is better to start with another question: which systems, processes and suppliers are critical for continuity, and where is basic security hygiene missing today?

I write this from day-to-day work on implementing NIS2 and the Polish KSC amendment requirements in a large organisation — from risk management and documentation to incident processes and collaboration with audit. This text is a starting guide, not legal advice. Regulatory hub: National Cybersecurity System.

Legal status in Poland – 27 July 2026

Legal status checked: 27 July 2026. The amendment entered into force on 3 April 2026. Dates below apply to entities meeting statutory criteria — confirm qualification with an advisor (does your company fall under KSC?).

What NIS2 means in day-to-day work

For IT and operations teams the topic usually means stronger focus on risk management, access control, updates, continuity, incident reporting and supply-chain oversight. It is not a one-off Friday checklist.

What this text is not: an interpretation of whether your organisation “definitely” falls under the regime, or a guarantee of an audit outcome. Here we focus on practical actions that make sense anyway. For formal depth see ISMS under KSC and serious incident reporting.

More on the service direction is on the cybersecurity and NIS2 page.

Step 1: context and critical services

Map which business services must not stop, which systems support them, and who owns process versus system. Also list processed data and supplier dependencies. The supply chain is a common blind spot.

Step 2: a fast gap view

A sensible start is a workshop plus a review of documentation and configuration in key areas: privileged access and MFA, updates, backups with restore tests, remote access, logging, incident procedures, email security and awareness, and expectations toward critical suppliers.

The output should be a prioritised gap list. An IT security audit or penetration testing of selected systems can then verify technical controls — without replacing risk management.

Step 3: priorities for the first 90 days

Close a few high-impact controls first:

1. Privileged accounts and MFA where it matters most.
2. Backups with a restore test for systems you cannot run without.
3. Patching / update process for external exposure.
4. A minimal incident playbook.
5. Inventory of critical assets and suppliers.

These points do not “finish the directive”, but they reduce real risk and create a foundation for further formalisation.

Step 4: ownership and escalation

Name who accepts risk, who maintains accounts, who approves exceptions and who leads incidents. Document exception decisions and keep shared accounts rare, constrained and time-bound.

Step 5: suppliers and a simple operating rhythm

Ask critical suppliers about incident reporting, their staff access to your systems, escalation contacts and offboarding. In a smaller organisation a simple monthly/quarterly rhythm for access, backups, updates and supplier review is easier to sustain than a one-off “NIS2 project”.

Documentation that helps under pressure

Documentation is useful only when people can use it during an incident. Instead of writing volumes of policy, start with short artefacts: a system and owner map, privileged account list, offboarding procedure, incident playbook, exception register, and expectations for critical suppliers. Every document should have an owner and a last-review date.

When preparing for an audit, consistency matters more than length: what is written must match how the team actually works. If a procedure requires MFA while production still uses shared accounts, an auditor will find that quickly. A short truthful procedure plus a gap-closure plan beats an impressive document disconnected from reality.

Preparing for audit without theatre

An audit is not a goal in itself. It is a way to check whether controls work and where they need strengthening. Preparation includes a current inventory, evidence that controls operate (restore tests, logs, access reviews), clear ownership, and a known-gap list with a remediation plan. That turns the auditor conversation into facts instead of a last-minute document hunt.

In parallel, keep application and infrastructure hygiene in view: access control, updates, secrets, environments and monitoring. Those foundations support both product operations and later regulatory discussions.

Common mistakes that slow delivery

The most common mistake is treating NIS2 as a documentation project instead of an operational change programme. The second is postponing inventory “for later,” even though without a map of services and suppliers it is hard to prioritise. The third is missing owners: if nobody owns MFA, backups or offboarding, even a good gap list will not turn into progress.

A fourth mistake is promising certification or “full compliance” without a clear scope. In practice it is better to talk about closing concrete gaps, preparing artefacts and being ready for an auditor conversation where audit duty actually applies. Fifth: copying policy templates without fitting them to company scale — documents quickly become unused.

What you can close in 90 days

In the first three months it is usually realistic to: finish MFA on privileged accounts, run a restore test for a critical system backup, update the incident procedure with escalation contacts, review remote access, and write a short requirement list for two or three critical suppliers. That does not close the whole scope, but it builds rhythm and evidence.

The next quarter naturally expands into monitoring, hardening selected services, awareness training for people with access to critical systems, and clearer role definitions. Each stage should end with something measurable: who, what, by when, and which evidence.

Summary

Start with critical services and high-impact gaps, close a few controls in 90 days, name owners and measure progress. Handle legal qualification separately with the right advisor.

Want to discuss a practical scope of work? See cybersecurity and NIS2 or the KSC hub or write via contact.