NIS2 Compliance Checklist

1.1 Assign an information security owner

Someone at leadership level needs to be accountable for NIS2 compliance. In a startup, this is usually the CTO or Head of Engineering. In a larger company, it's a CISO or similar role. "Everyone is responsible" means no one is.

1.2 Approve a cybersecurity policy at board level

Your leadership team needs to formally approve a written information security policy. This does not have to be 80 pages. A clear, signed policy covering data protection, access control, incident response, and acceptable use is enough to start.

1.3 Document management training on cybersecurity risks

NIS2 explicitly requires that management bodies receive training and stay up to date on cybersecurity risks. This can be quarterly briefings, an annual security review session with your leadership team, or structured awareness training. Document it.

1.4 Establish a register of critical systems and services

List the systems your business depends on. For each one, identify what happens if it goes down for 24 hours. If the answer is "we can't operate," it's critical. This list becomes the backbone of your risk management approach.

2.1 Conduct a formal risk assessment

You need a documented process for identifying, assessing, and treating security risks. This does not require a specialist consultant. A structured spreadsheet mapping threats, likelihood, impact, and mitigations is a valid starting point. What matters is that it exists, is reviewed regularly, and drives real decisions.

2.2 Define and document risk treatment decisions

For each identified risk: accept it, mitigate it, transfer it (insurance), or avoid it. Write down what you decided and why. Regulators and auditors want to see that you thought about risk deliberately, not that you chose only perfect outcomes.

2.3 Review your risk assessment at least annually

NIS2 requires ongoing risk management, not a one-time exercise. Put a recurring calendar item in your team's calendar. If a significant incident occurs or your tech stack changes substantially, review it sooner.

3.1 Multi-factor authentication (MFA) across all critical systems

Turn it on. Every admin account. Every cloud console. Every code repository. Every SaaS tool with access to production data. No exceptions. If a vendor doesn't support MFA, that is a vendor risk you need to document.

3.2 Encryption of data at rest and in transit

All customer data stored on your systems must be encrypted at rest. All data transmitted between systems must use TLS 1.2 or higher. Audit your storage configurations and your API traffic. Both matter.

3.3 Access control and least privilege

Every employee, contractor, and service account should have only the access they need for their current role. Conduct a quarterly access review. Remove accounts for departed employees within 24 hours. Revoke overprivileged access. This is one of the cheapest and most impactful controls you can implement.

3.4 Patch and vulnerability management

You need a process for tracking and applying security patches. For critical vulnerabilities (CVSS score 9.0+), your target should be patching within 72 hours. For high severity (7.0-8.9), within two weeks. Document your patching process and your exceptions.

3.5 Network segmentation

Production systems should be isolated from development and internal tooling. Your customer data should not be accessible from the same network segment as your office Slack. If you're on AWS, GCP, or Azure, this is achievable with VPCs and security groups. It does not require building a new data centre.

3.6 Endpoint security on company devices

All employee laptops and mobile devices accessing company systems need endpoint protection: MDM enrollment, disk encryption (FileVault or BitLocker), screen lock, and remote wipe capability. If you use BYOD, define a clear policy for minimum device standards.

3.7 Secure configuration baseline for your infrastructure

Cloud environments drift from secure configurations over time. Run a configuration audit against CIS Benchmarks or your cloud provider's security best practices. AWS Security Hub, Azure Defender, and GCP Security Command Center all offer automated scoring. Get your score above 80% before anything else.

3.8 Penetration testing

NIS2 does not mandate annual penetration tests by name, but regulators expect you to actively test your defenses. A penetration test from a qualified third party, covering your public-facing application and your cloud infrastructure, is the clearest way to demonstrate this. Budget: €5,000 to €20,000 depending on scope, annually.

4.1 Inventory your third-party vendors with system access

List every vendor, tool, or service that processes your customer data or has access to your systems. Include SaaS tools, cloud providers, contractors, subprocessors. Prioritise them by how much access they have and how critical they are.

4.2 Conduct security assessments of critical vendors

For your highest-risk vendors, review their security posture. This means requesting their SOC 2 report or ISO 27001 certificate, reviewing their data processing agreement, and checking their breach disclosure history. You don't need to audit every tool. Focus on the ones that would hurt you most if compromised.

4.3 Include security requirements in vendor contracts

Your contracts with vendors who process personal data or have system access should include: minimum security standards, breach notification timelines (NIS2 requires 24-hour notification to authorities), data handling obligations, and the right to audit.

4.4 Monitor vendor security posture on an ongoing basis

Quarterly is enough for most vendors. Annual is acceptable for low-risk tools. Critical vendors with production access warrant more frequent checks.

5.1 Document an incident response plan

Write down what you do when something goes wrong. Who gets notified? Who decides whether it's a reportable incident? Who communicates with customers? Who talks to regulators? A two-page document covering these questions is enough to start.

5.2 Know your NIS2 notification obligations

This is the part that will trip you up if you don't know it.

Under NIS2, if you experience a significant incident affecting the security of your network and information systems, you must:

• • Notify the relevant national authority within 24 hours of becoming aware (early warning)
• • Submit a full incident notification within 72 hours (including initial assessment, severity, indicators of compromise)
• • Provide a final incident report within one month

A "significant incident" is one that has caused or is capable of causing severe operational disruption, financial loss, or material damage to others. If customer data was accessed without authorisation, it's significant.

5.3 Test your incident response plan

Run a tabletop exercise at least annually. Pick a realistic scenario ("we discovered an unauthorised access to our database three days ago"). Walk through your response. Find the gaps before an actual incident does.

5.4 Log and monitor your critical systems

You cannot detect an incident you're not logging for. At minimum: authentication events, privileged access, API calls to sensitive data, and system configuration changes. Centralise your logs. Set up alerts for anomalous behaviour. Retain logs for at least 12 months.

6.1 Maintain and test backups

Backups of critical systems and data must exist, must be encrypted, and must be tested. "We have backups" is not enough. The question is: how long does it take to restore from backup, and did you actually test it in the last six months?

6.2 Document recovery time objectives (RTOs)

For each critical service, define how long you can tolerate it being unavailable (RTO) and how much data loss is acceptable (RPO). Write it down. Verify that your backup and recovery processes can actually meet those targets.

6.3 Document a business continuity plan

What do you do if your primary cloud region goes down? What if your offices are inaccessible? What if a key employee is unavailable during a crisis? These scenarios don't need perfect answers. They need documented procedures that the rest of your team can follow without the person who "just knows."

7.1 Register with your national competent authority

Most EU member states have designated a national authority responsible for NIS2 oversight. In France, it's ANSSI. In Germany, BSI. In the Netherlands, NCSC-NL. In Ireland, the NCSC. If your business falls under NIS2, you are required to register with the relevant authority. Check whether your country has published a public register or registration process. Many did this through 2024 and 2025.

7.2 Understand which authority has jurisdiction over you

If you operate across multiple EU member states, jurisdiction is generally determined by your main establishment (where your EU headquarters or principal operations are). Get clarity on this before an incident forces the question.

7.3 Document evidence of compliance

NIS2 does not require a formal certification the way ISO 27001 does. But it does require that you can demonstrate compliance when asked. Maintain a compliance register: the controls you've implemented, the policies you've approved, the risk assessments you've conducted, and the incidents you've handled. This evidence file is your defence in a regulatory investigation.