If you’re supporting an EU based business in 2026, NIS2 probably isn’t a one time project anymore. It’s a steady expectation: prove you can spot incidents, fix weaknesses fast, control admin power, and manage supplier risk.
The hard part isn’t buying tools. It’s turning daily ops into repeatable routines with evidence. This NIS2 checklist focuses on what IT admins can control: logging and alerting, patch and vulnerability flow, access control, and supplier risk you can measure.
For the legal text, keep the official directive close, for example the NIS2 Directive PDF text and the European Parliament NIS2 briefing. Then map it to what you can show in tickets, logs, and reports.
NIS2 in 2026: what you’ll be judged on (and when)
By February 2026, enforcement still varies by country because some national laws landed late. However, regulators and auditors tend to ask the same thing: can you manage risk, detect incidents, and prove it with records. Keep one eye on your national transposition, especially for reporting timelines and evidence retention.
Use this quick priority plan to get moving without boiling the ocean:
| Priority window | Logging and detection | Patching and vulnerabilities | Access control and admins | Supplier risk |
|---|---|---|---|---|
| Do this now | Centralize security logs, turn on audit logs, set on-call routing | Define patch SLAs, inventory internet-facing assets | Enforce MFA on remote access, lock down admin accounts | List critical suppliers, identify highest impact services |
| Next 30 days | Add EDR, firewall, VPN, M365, identity logs, build top alerts | Start weekly vuln scans, create emergency patch playbook | Deploy PAM or JIT admin, implement joiner-mover-leaver | Send a short questionnaire, add incident notice clause |
| Next quarter | Tune alerts, run tabletop, test log restore | Measure SLA compliance, reduce patch exceptions | Review least privilege, test break-glass, log admin actions | Monitor supplier changes, test supplier incident workflow |
A good rule: if you can’t explain your controls in ten minutes, you can’t run them at 2 a.m.
Logging in NIS2: central sources, retention, and basic detection
Think of logging like CCTV for your network. Cameras don’t stop theft, but they help you see what happened, when it started, and what else got touched.
Start by collecting the few sources that answer most incident questions. Then improve coverage over time. This table is a practical baseline for a central log platform (SIEM or simpler):
| Log source | Why it matters | Minimum events to ingest |
|---|---|---|
| AD and Entra ID (Azure AD) | Identity is the new perimeter | Sign-ins, MFA changes, admin role changes, password resets |
| VPN and ZTNA | Proves remote entry paths | Auth success/fail, geo anomalies, device posture results |
| EDR | Shows execution and spread | High severity detections, quarantines, isolation actions |
| Firewalls and WAF | Confirms exposure and scanning | Denies, allowed inbound to critical services, config changes |
| Microsoft 365 | Email is still a top entry point | Mailbox rules, risky sign-ins, audit log events |
| Linux auth logs | Many “small” servers become pivots | SSH auth, sudo use, new users, PAM failures |
If it isn’t logged, you’ll end up guessing. Guessing is expensive during an incident.
Retention guidance (assumptions): NIS2 doesn’t give a single log retention number. Set a written policy, justify it, and align to national rules and sector expectations. A common starting point is 90 to 180 days searchable (hot) and 12 months archived (cold). Keep longer for high impact systems or if local law requires it.
Alerting basics that work in real life: keep it small at first. Start with alerts that map to clear action, for example impossible travel sign-ins, repeated VPN failures, new global admin assignment, EDR high severity on servers, and firewall policy changes outside change windows. Route alerts to an on-call path, and record every closure decision in the ticket.
Patching under NIS2: SLAs, emergency flow, and proof you did it
Patching is where many teams fail audits, not because they miss one update, but because they can’t show control. Auditors look for an agreed SLA, an exception process, and evidence that you hit your targets.
Use risk-based SLAs that match your environment. Here’s a workable set for mixed Windows and Linux estates:
| Patch class | Examples | Target SLA | Notes admins should document |
|---|---|---|---|
| Emergency | Active exploitation, exposed VPN, auth bypass | 24 to 72 hours | May bypass normal change window, record risk approval |
| Critical | Windows monthly security update, Linux kernel fix | 7 to 14 days | Faster for internet-facing systems and identity |
| High | Important browser, email client, agent updates | 30 days | Use rings and phased rollout |
| Routine | Low risk fixes, feature updates | 60 to 90 days | Bundle into standard maintenance windows |
Concrete workflow for emergency patches (keep it simple): confirm exposure, identify affected asset list, take a snapshot or backup, patch a canary, patch the fleet, validate service health, then document results. After that, run a short retrospective and update your baselines so the next one is easier.
Vulnerability management should support patching, not fight it. Run authenticated scans weekly for servers and monthly for endpoints, then tie findings to owners and due dates. When you can’t patch, require a time-boxed exception with a compensating control (virtual patching, network rule, service removal).
For extra structure, ENISA’s technical implementation guidance (June 2025) is often used as a reference set, even when it’s non-binding. Pair it with whatever your national authority expects.
Access control that holds up: MFA, PAM, least privilege, break-glass
Access control under NIS2 isn’t only about MFA. It’s about stopping silent privilege creep, and proving you can trace admin actions.
Start with MFA everywhere that matters, then tighten admin paths:
- MFA on all remote entry points: VPN, VDI, admin portals, cloud consoles, and email. Remove legacy auth where possible.
- Privileged Access Management (PAM): prefer just-in-time admin elevation, approval workflows, and session logging for sensitive systems.
- Least privilege by default: give roles, not direct rights, and review group membership on a set cadence.
- Break-glass accounts: keep 2 accounts per tenant or forest, store credentials offline, alert on any use, and test quarterly.
- Joiner-mover-leaver (JML): automate account creation and removal, then audit “movers” for leftover rights.
- Log privileged actions: changes to identity roles, firewall rules, GPO, EDR policy, and cloud security settings should all create audit events.
A practical test: pick one admin. Can you answer what they changed last week, and why, in under five minutes?
Supplier risk in NIS2: start small, contract smart, monitor continuously
Supplier risk becomes real when your VPN provider has an outage, your MSP gets hit, or your SaaS tenant gets misconfigured by a subcontractor. NIS2 pushes you to manage that chain, not just sign a vendor once.
Begin with a short questionnaire for any supplier that can impact availability, confidentiality, or incident response:
- What data do you access, and where is it stored and processed?
- Do you use subcontractors, and how do you approve them?
- What’s your incident notification time, and what details will you share?
- Do you have MFA and PAM for your own admins?
- How do you patch, and what are your vulnerability SLAs?
- Can you provide recent security reports (ISO 27001 cert, SOC 2, pen test summary)?
Then check contracts for clauses that map to your operational needs: incident notification windows, security SLAs, right to audit or receive assurance reports, limits on subcontractors, data location and transfer rules, and clear responsibilities for logs during joint incidents.
Continuous monitoring doesn’t need a fancy platform. Track renewal dates, key contacts, service health, major product changes, and “security events” like credential leaks or public incidents. Most importantly, rehearse one supplier incident scenario with your internal team, so comms and access are ready.
What auditors ask for, plus a practical evidence pack
Auditors usually sample. They’ll pick a system, a month, and a few events. Then they test whether your story matches your evidence.
What they ask for in 2026
Expect questions like: which logs are centralized, who responds to alerts, what your patch SLA is, how exceptions work, how admin access is granted, and how you assess key suppliers. They also ask if reporting timelines are understood and tested.
For a quick external view of “evidence to keep”, compare notes with a third-party summary like NIS2 evidence examples and cross-check against the NIS2 full text by article for wording.
Appendix: evidence pack you can assemble this week
Keep artifacts in a single folder per control area:
- Logging architecture diagram, SIEM data source list, sample alert tickets
- Patch policy, patch compliance reports, emergency patch change tickets
- MFA and conditional access screenshots, PAM configuration exports, admin role review records
- Break-glass test record, JML workflow evidence, privileged action audit logs
- Supplier register, completed questionnaires, contract clauses, supplier incident drill notes
Close the loop by dating documents, naming owners, and linking tickets to controls.
Conclusion
NIS2 compliance in 2026 rewards teams that run security like operations, with repeatable routines and records. Build your NIS2 checklist around what you can prove: centralized logs with usable alerts, patch SLAs with exceptions, tight admin access, and suppliers held to clear terms. Once those basics run well, audits become a review, not a firefight.
