NIS2 2026: 7 Technical Controls Every Company with 50+ Employees Needs to Have in Place

The NIS2 Directive's transposition deadline has passed. If your company operates in the EU — or provides services to EU entities — and employs more than 50 people, Article 21 applies to you. Not as a distant recommendation. As an enforceable legal obligation, with administrative fines of up to €10 million or 2% of global annual turnover, whichever is higher.

Most guides stop at “implement an ISMS” and call it a day. This one doesn't. We are going to walk through the seven technical control areas that NIS2 auditors and cyber insurers look at first — what they mean in practice, what evidence you need to produce, and where the gaps most commonly appear in organisations with 50–250 employees.

This is not legal advice. It is a technical orientation guide. Your specific obligations depend on your sector, member state transposition legislation, and whether you fall under “essential” or “important” entity classification. Review with a qualified advisor.

The scope is much wider than most teams assume. The European Commission estimates that around 160,000 entities across the EU now fall under NIS2 — a large share of them mid-sized companies that were never regulated under the original NIS Directive. The obligations themselves are set out in Article 21 of the NIS2 Directive (EU) 2022/2555, and the European Union Agency for Cybersecurity (ENISA) has published technical guidance mapping those obligations to ISO 27001/27002 and NIST CSF 2.0 controls that national regulators now treat as primary evidence of compliance.

Table of Contents

• Why 50–250 employees is the exact danger zone
• Control 1: Vulnerability Management and Technical Testing
• Control 2: Access Control and Authentication
• Control 3: Incident Detection and Logging
• Control 4: Secure Configuration and Patch Management
• Control 5: Backup and Recovery
• Control 6: Supply Chain Security
• Control 7: Cryptography and Data Protection
• What comes next: from checklist to evidence
• Frequently Asked Questions

Why 50–250 employees is the exact danger zone

Larger enterprises have CISO teams and established security programmes. Smaller companies often fall below the NIS2 threshold. Companies in the 50–250 range are frequently in the worst position: large enough to be regulated, but without the internal security function to respond.

The seven controls below are weighted toward what is realistic and testable at this scale — not what requires a 12-month enterprise GRC programme.

Control 1: Vulnerability Management and Technical Testing (Article 21(2)(e))

NIS2 explicitly names vulnerability management as part of required risk-management measures. In practice:

• Maintain an inventory of all externally reachable services (web apps, APIs, cloud endpoints, email infrastructure).
• Conduct regular technical testing to identify exploitable weaknesses — not just automated scanning, but testing that confirms whether a vulnerability is actually exploitable in your configuration.
• Remediate findings within defined timeframes, with evidence of remediation.

The gap we see most often: a vulnerability scanner runs, but there is no process for confirming which findings are real versus noise, and no documented remediation timeline. An auditor will ask for both.

What evidence looks like: a testing report that maps findings to CVE or CWE identifiers, assigns severity, includes a reproducible proof-of-concept for critical findings, and documents remediation status. Reports generated by platforms like AssurePort are structured to meet this format.

Control 2: Access Control and Authentication (Article 21(2)(i))

Network access control and authentication management are explicitly named in Article 21(2)(i) under “human resources security, access control policies and asset management.”

• Multi-factor authentication (MFA) enforced for all administrative accounts, remote access, and cloud control planes.
• Privileged access reviewed quarterly and documented.
• Inactive accounts disabled within a defined period (30 days is a common benchmark).
• Active Directory or identity provider configurations reviewed for Kerberoasting and ASREPRoasting exposure where on-premises AD is in use.

The gap we see most often: MFA adopted for primary SaaS tools but missing on cloud console access (AWS IAM, Azure portal) and internal admin panels. These are the surfaces attackers target first.

What evidence looks like: an access control policy document + screenshot evidence of MFA enforcement + an access review log from the last quarter.

Control 3: Incident Detection and Logging (Article 21(2)(b))

“Detection” is a named control under NIS2's incident-handling requirements. You need more than a firewall.

• Centralised logging for authentication events, admin actions, and outbound network connections.
• Log retention for at least 90 days (12 months recommended for the NIS2 serious-incident threshold).
• Defined detection rules or alerts for known attack patterns (failed-auth bursts, privilege escalation, data-exfiltration signals).
• A tested incident response process (documented, not just planned).

The gap we see most often: logs exist but no one is reading them, no alerting is configured, and the retention policy has never been tested. A breach discovered months after the fact — which happens in the majority of SME incidents — indicates this control is absent.

What evidence looks like: a logging architecture diagram + a sample log export + alert configuration documentation + an incident response runbook with at least one documented tabletop exercise.

Control 4: Secure Configuration and Patch Management (Article 21(2)(e)+(f))

NIS2 combines vulnerability management with supply chain security. Secure configuration is the baseline that makes both possible.

• Operating system and server software patched within 30 days of critical-severity advisories.
• Web application frameworks and dependencies tracked via software composition analysis (SCA).
• TLS configuration current (TLS 1.2 minimum, TLS 1.3 preferred; weak cipher suites disabled).
• HTTP security headers present and correctly configured (Content-Security-Policy, HSTS, X-Frame-Options, Referrer-Policy).

The gap we see most often: a patch-management process exists on paper but isn't enforced consistently for web application dependencies. A Node.js or Python dependency three versions behind a critical CVE is exactly what an auditor's first automated scan will surface.

What evidence looks like: dependency scan output (npm audit, Snyk, or equivalent) + a TLS configuration report + security headers grader output. AssurePort's free Security Headers Grader and TLS Check tools generate these reports without requiring an account.

Control 5: Backup and Recovery (Article 21(2)(c))

Ransomware is still the dominant threat pattern for companies in NIS2 scope. Article 21(2)(c) explicitly names “business continuity and crisis management, including backup management.”

• Daily automated backups for all systems containing business-critical data.
• Backups stored in a location logically and physically separate from production (ideally offline or immutable storage).
• Recovery tested at least annually — not assumed to work, but actually tested.
• Recovery Time Objective (RTO) and Recovery Point Objective (RPO) documented and accepted by management.

The gap we see most often: backups exist but have never been restored. The test that matters is not “does the backup job complete” but “can we restore the system from this backup and reach a functional state within our RTO.”

What evidence looks like: backup configuration documentation + a last-restoration test report (with date, scope, result) + signed management acceptance of RTO/RPO.

Control 6: Supply Chain Security (Article 21(2)(d)+(f))

Article 21(2)(d) names “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure by providers” as a required control. Article 21(2)(f) adds supply chain security explicitly.

For a company with 50–250 employees, this doesn't mean auditing every vendor's SOC 2 report. It means:

• Maintaining a register of third-party services with access to your systems or data.
• Reviewing the security posture of your top five critical vendors annually.
• Including security requirements in vendor contracts (data processing agreements, minimum security controls).
• Having a process for responding when a vendor reports a breach affecting your data.

The gap we see most often: SaaS sprawl with no central register. Teams adopt tools without security review, and no one has a current list of what has access to production data. This is a day-one audit question.

What evidence looks like: a vendor register + a sample vendor security review (questionnaire or review of their published security documentation) + a template DPA addendum in vendor contracts.

Control 7: Cryptography and Data Protection in Transit and at Rest (Article 21(2)(h))

Article 21(2)(h) specifically names “policies and procedures regarding the use of cryptography and, where appropriate, encryption.”

• All data in transit encrypted with TLS 1.2+.
• All sensitive data at rest encrypted (database-level or storage-level encryption, not application-level only).
• API keys, credentials, and secrets stored in a dedicated secrets manager — not in environment variables committed to Git.
• Encryption keys rotated on a defined schedule.

The gap we see most often: TLS is in place on the frontend, but internal service-to-service traffic (between microservices, between application and database) runs unencrypted. Also: secrets committed to GitHub repositories (public or private) — our GitHub SAST engine finds this in approximately 1 in 3 repositories it scans.

What evidence looks like: a TLS configuration report for all externally reachable services + a secrets scan report showing zero committed credentials + an encryption policy document.

What comes next: from checklist to evidence

Going through these seven controls and deciding where your gaps are is a useful first step. But a gap list without evidence doesn't satisfy an auditor. What auditors, insurers, and procurement teams ask for is documented, timestamped, technically-derived evidence that the control is in place — not a policy that says it should be.

Technical testing is how you produce that evidence. A penetration test that maps findings to NIS2 Article 21 controls, documents what is exploitable and what is not, and provides remediation guidance gives you a usable starting point for your readiness assessment.

Or check your current surface posture right now — no signup required — using the free intel tools, or the surface preview on our homepage.

Frequently Asked Questions

Which companies fall under NIS2?

NIS2 applies to medium and large entities (generally 50+ employees or €10M+ turnover) operating in one of 18 sectors deemed essential or important, as well as their EU service providers. The European Commission estimates roughly 160,000 entities across the EU are now in scope — many of them mid-sized companies that were never regulated before.

Does NIS2 require a penetration test?

NIS2 Article 21(2)(e) names vulnerability handling and disclosure, and Article 21(2)(f) requires policies to assess the effectiveness of cybersecurity measures. It does not mandate a specific test, but technical testing that confirms which weaknesses are actually exploitable is the most direct way to produce the evidence auditors ask for.

What are the fines for NIS2 non-compliance?

Essential entities face administrative fines of up to €10 million or 2% of global annual turnover, whichever is higher. Important entities face up to €7 million or 1.4% of turnover. Management bodies can also be held personally liable for supervising the implementation of security measures.

What evidence do NIS2 auditors actually ask for?

Auditors want documented, timestamped, technically-derived evidence — not a policy that says a control should exist. Typical artefacts include a vulnerability testing report mapped to CVE or CWE identifiers, MFA enforcement evidence, log retention and alerting configuration, tested backup restoration reports, a vendor register, and a TLS and secrets scan.

When did NIS2 take effect?

NIS2 entered into force in January 2023 with a national transposition deadline of 17 October 2024. Member States were required to establish their lists of essential and important entities by 17 April 2025, and national regulators have since begun systematic audits and issued the first fines.