What is the NIS2 Directive?

Documented risk analysis methodology and written security policies covering all information systems. Policies must be approved at management/board level.

What this looks like in practice

• A written risk assessment updated at least annually and after every major infrastructure change, with risks scored by likelihood and impact.
• A board-approved information security policy covering asset classification, access control, and incident response — signed by the CEO or equivalent.
• An asset inventory listing every system and data store with its owner, sensitivity level, and the controls applied to it.

Formal incident response plans including detection, containment, eradication, recovery, and post-incident review. Incident classification aligned with the 24-72-1 reporting rule.

What this looks like in practice

• A tested incident response playbook with assigned roles: Incident Commander, communications lead, legal contact, and a designated NIS2 reporting owner.
• A severity matrix: P1 (service outage affecting customers) triggers the 24h NIS2 early warning; P2 (degraded performance) is logged internally but not reported.
• Post-incident reviews documented with root cause, timeline, and corrective actions with named owners and due dates.

BCP and DR plans with defined Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs). Regular testing of backup systems is mandatory.

What this looks like in practice

• Documented RTO of 4 hours and RPO of 1 hour for critical systems, with offsite backups tested monthly using actual restore procedures.
• An annual full failover drill with written pass/fail criteria, observed by a member of senior management.
• A Crisis Management Team charter specifying who declares a disaster, who communicates externally, and in what order systems are restored.

Assessment and contractual security requirements for all direct suppliers and service providers. Includes software supply chain and open-source components.

What this looks like in practice

• A security questionnaire or ISO 27001 certificate required from all critical suppliers before contract signing, with annual re-assessment.
• Contract clauses requiring suppliers to notify your security team of any incident affecting your data within 24 hours, with an annual right-to-audit.
• Automated open-source component scanning (e.g., Snyk or OWASP Dependency-Check) integrated into the CI/CD pipeline, blocking builds with critical CVEs.

Security requirements integrated into procurement, development, and maintenance of ICT systems. Includes vulnerability handling and disclosure policies.

What this looks like in practice

• Every RFP for new ICT systems includes a security annex requiring OWASP Top 10 coverage and a penetration test report dated within 12 months.
• A coordinated vulnerability disclosure policy published on the company website so researchers can report findings without legal risk.
• A patching SLA: critical CVEs applied within 72 hours, high severity within 7 days, medium within 30 days — with exceptions logged and approved.

Documented cyber hygiene practices and regular security awareness training for all staff. Board-level cybersecurity training is also required.

What this looks like in practice

• Annual phishing simulation with at least 90% staff participation; employees who click receive mandatory remediation training within 5 working days.
• A documented password and credential policy: minimum 12-character passphrases, no shared accounts, password manager provided to all staff.
• A board-level cybersecurity briefing held at least once per year covering the current threat landscape and the organisation's NIS2 posture.

Policies for the use of cryptography and, where appropriate, encryption of data in transit and at rest. Key management processes must be documented.

What this looks like in practice

• TLS 1.2 or higher enforced on all external-facing services; TLS 1.0 and 1.1 disabled on all endpoints — verified by quarterly automated scans.
• Databases and file stores containing personal or sensitive data encrypted at rest using AES-256 or equivalent.
• A key management procedure covering generation, storage (HSM or equivalent), rotation frequency (at least annually), and revocation steps.

Background checks where permitted, security obligations in employment contracts, and a formal access control policy based on least-privilege principles.

What this looks like in practice

• A joiners/movers/leavers process: system access provisioned within 1 business day of a start date, revoked within 4 hours of a departure notification.
• Role-based access control (RBAC) with quarterly reviews of all privileged accounts; any account inactive for 90 days automatically disabled.
• Security obligations written into employment contracts and a signed acceptable use agreement required before first system access is granted.

MFA or continuous authentication solutions must be used for all privileged access and all remote access to network and information systems.

What this looks like in practice

• MFA enforced on all VPN, RDP, and cloud admin portals (Azure AD, AWS IAM, Google Workspace) without exception, including service accounts.
• Hardware tokens or authenticator apps required for privileged accounts; SMS-only MFA not accepted for administrator or root access.
• Conditional access policies blocking logins from unmanaged or non-compliant device profiles, with alerts sent to the SOC for every blocked attempt.

Encrypted and authenticated communications for voice, video, and text. Emergency communications systems with adequate security controls.

What this looks like in practice

• An end-to-end encrypted messaging channel (separate from normal email) designated for incident response communications and tested quarterly.
• An out-of-band crisis communication system that operates independently of the primary IT infrastructure — so it stays up even if the main network is down.
• Email gateway configured with DMARC, DKIM, and SPF records in enforced mode, plus attachment sandboxing for inbound files.