What European IT teams actually need to do — and in what order
Tobias Schüle is a senior Microsoft 365 architect and founder of Opsora, with over a decade of enterprise IT transformation experience across European mid-market organisations.
On this page
NIS2 arrived with considerable noise — regulatory briefings, legal summaries, vendor webinars promising to solve everything in a single product. The reality for most IT teams is quieter and more uncomfortable: the directive imposes concrete obligations on a wide range of European organisations, penalties for non-compliance are significant, and most Microsoft 365 environments are not configured to meet the requirements out of the box.
This is a practical roadmap — the technical and organisational sequence that gets an M365 environment from default configuration to a defensible, documented compliance posture. Legal interpretation is your legal team's job. This covers the IT work.
NIS2 (EU 2022/2555) applies to medium and large organisations in essential and important sectors — energy, transport, health, digital infrastructure, manufacturing, and others. It requires organisations to implement risk-appropriate security measures covering: incident response, business continuity, supply chain security, access control, cryptography, and multi-factor authentication.
The directive does not prescribe specific technology. It prescribes outcomes. What that means in practice is that you need to demonstrate that you have identified your risks, implemented proportionate controls, and can evidence both. Microsoft 365, when properly configured, can satisfy a significant portion of those requirements — but "properly configured" is doing a lot of work in that sentence.
Microsoft 365 ships with sensible defaults for a generic enterprise. It does not ship pre-configured for NIS2. The gap is not a failure of the product — it is a mismatch between what an out-of-the-box tenant looks like and what the directive demands.
Common default-state problems include: legacy authentication protocols still enabled, no conditional access policies beyond basic MFA prompts, no audit log retention beyond the default 90 days, no data classification or sensitivity labelling, no documented incident response procedure, and external sharing enabled without governance. Any one of these can represent a material gap against NIS2's Article 21 requirements. Most environments have all of them.
Opsora runs structured assessments for European IT teams on exactly these challenges. Book a 30-minute briefing with a senior architect — no sales layer, no prepared deck.
Book a BriefingBefore touching a single configuration, establish what is in scope. NIS2 scope is entity-level — if your organisation qualifies, the entire organisation is subject to the directive, not just specific systems. But within that, you need to classify your data and services by criticality. Which systems, if unavailable, would cause significant disruption? Which data, if exposed, would have serious consequences?
In a Microsoft 365 context, this means identifying your critical workloads: Exchange Online for communications, SharePoint and OneDrive for document management, Teams for collaboration. It also means identifying your identity and access infrastructure — Entra ID is the control plane for everything, and it warrants the most attention.
Document your scope formally. This is not bureaucracy for its own sake — it is the foundation of your risk register, and auditors will ask for it.
Identity is where most NIS2 work happens in Microsoft 365, and it is where most current gaps exist. The requirements in practical terms:
Multi-factor authentication must be enforced via Conditional Access policy — not just enabled. There is a critical difference. Enabled means users can opt in. Enforced via CA means they have no choice. Legacy authentication protocols (SMTP AUTH, IMAP, POP3, basic auth) must be blocked entirely — these bypass MFA regardless of your policy settings.
Privileged access requires particular attention. Global Administrator, Exchange Administrator, SharePoint Administrator, and similar roles should be protected with separate accounts, Privileged Identity Management (PIM) for just-in-time elevation, and dedicated phishing-resistant MFA (FIDO2 or certificate-based). Persistent privileged sessions are a direct NIS2 risk.
Access reviews must be conducted regularly. Entra ID access reviews can automate the schedule — quarterly for privileged roles, semi-annually for group membership. The output must be documented.
NIS2 requires proportionate measures for endpoint security. In practice, this means managed devices under a consistent policy baseline. If you are using Microsoft Intune, your device compliance policies need to enforce: disk encryption (BitLocker on Windows, FileVault on macOS), up-to-date OS and patch levels, endpoint detection and response (Microsoft Defender for Endpoint at minimum), and screen lock after inactivity.
Conditional Access should then be used to require compliant device status for access to sensitive applications. Unmanaged devices — personal phones, contractor laptops — should either be blocked from accessing corporate data entirely, or limited to read-only access with session controls applied.
NIS2 requires organisations to have an incident response capability and to notify competent authorities within 24 hours of becoming aware of a significant incident (with a fuller report within 72 hours). This is one of the most operationally demanding requirements, and the one that most mid-market IT teams are least prepared for.
In Microsoft 365 terms, incident response readiness means: unified audit log enabled and retained for at least 12 months (the NIS2-aligned recommendation; default is 90 days), Microsoft Sentinel or equivalent SIEM connected for alerting, a documented incident response plan that assigns roles and escalation paths, and at least one tabletop exercise completed.
The 24-hour notification requirement is not aspirational — it is legal. If you do not have a process for detecting, escalating, and reporting incidents within that window, that gap is itself a compliance failure.
NIS2 is not self-certifying. You need to demonstrate compliance, which means documentation: your risk assessment, your control mapping, your access review records, your incident response plan, and your evidence of policy enforcement.
Microsoft 365 generates substantial audit data — sign-in logs, admin activity logs, mailbox access logs. The question is whether that data is being retained, monitored, and can be retrieved on demand. Audit log retention should be extended to 12 months for all users, and to 12 months for admin activity. Export these logs to a durable storage location that is not dependent on your M365 licence remaining active.
Maintain a register of your key configurations. When you change a Conditional Access policy, record why, when, and who authorised it. This is the difference between compliance that holds up under scrutiny and compliance that looks good in a spreadsheet.
Three mistakes appear repeatedly in NIS2 readiness assessments:
MFA enabled but not enforced. The Microsoft 365 tenant shows MFA as "enabled" in the legacy per-user settings, but no Conditional Access policy requires it. Users who set up MFA are protected; users who skipped the prompt are not. This is a common state and a critical gap.
Audit logs not retained. The default audit log retention in Microsoft 365 is 90 days for most licence levels. NIS2 alignment requires at minimum 12 months. This is a configuration change, not a product limitation, but it requires a deliberate decision and, in some cases, a licence upgrade or external log storage.
No supply chain assessment. NIS2 Article 21 explicitly includes supply chain security. If your Microsoft 365 environment connects to third-party SaaS applications via OAuth, or if you have external contractors with privileged access, those relationships need to be assessed and documented. Most organisations have not done this.
A compliant Microsoft 365 posture under NIS2 is not a perfect environment — it is a defensible one. It means: MFA enforced for all users via Conditional Access, legacy authentication blocked, privileged access governed with PIM and regular reviews, managed devices required for data access, audit logs retained for 12 months, an incident response plan documented and tested, and a risk register that maps your controls to the directive's requirements.
This is achievable for most mid-market organisations within 8–12 weeks of focused effort. The work is not technically exotic. What it requires is prioritisation, sequencing, and documentation discipline.
If you are working through a NIS2 readiness programme and need a structured assessment of your current M365 posture, that is exactly the engagement Opsora runs — a gap analysis against the directive, a prioritised remediation roadmap, and implementation support for the controls that require it. Learn more about our NIS2 compliance and security services.
Copilot surfaces data your users already have access to. If your permissions and classification are wrong, Copilot will make that visible — fast.
After 50+ M365 environments assessed, the same five governance gaps appear repeatedly — and each one creates real operational and compliance risk.
Opsora works with European IT directors and CTOs on exactly these challenges. A typical engagement starts with a 30-minute briefing and a clear scope within a week.