NIS2 enforcement started in October 2024. There is no grace period. There is no "we're working on it" exemption for small businesses. If your organization falls under the directive, the obligations are active now.
The fines are real: up to €10,000,000 or 2% of global annual turnover for Essential Entities, up to €7,000,000 or 1.4% for Important Entities — whichever is higher. Your national competent authority (NCA) administers enforcement, and the first wave of formal audits is already underway in several member states.
Most NIS2 compliance guides are written for enterprise legal and security teams. This one is written for the IT manager, founder, or sysadmin at a 30–200 person business who needs to know exactly what to do, in what order, and what constitutes sufficient evidence.
Step 0: Confirm Whether NIS2 Applies to You
Before building a compliance program, confirm your scope. NIS2 applies to medium-sized and larger organizations — 50+ employees or €10M+ annual turnover — operating in covered sectors.
Essential Entities (higher fine exposure, stricter supervision):
- Energy (electricity, oil, gas, district heating, hydrogen)
- Transport (air, rail, water, road)
- Banking and financial market infrastructure
- Health (hospitals, labs, pharmaceutical manufacturers)
- Drinking water and wastewater
- Digital infrastructure — this is the catch-all that captures many SaaS companies. Cloud providers, data centers, CDNs, DNS providers, internet exchange points, and trust service providers all fall here above certain thresholds.
- ICT service management (managed service providers, managed security providers)
- Public administration
- Space
Important Entities (lower fine exposure, reactive supervision):
- Postal and courier services
- Waste management
- Manufacture and distribution of chemicals
- Food production, processing, and distribution
- Manufacturing of medical devices, electronics, machinery, motor vehicles
- Digital providers: online marketplaces, online search engines, social networking platforms
- Research organizations
If you provide B2B software or infrastructure services to organizations in any of the above sectors, you may fall under NIS2 as an ICT third-party provider even if your own sector is not listed.
If you are outside the EU but provide services to EU organizations in covered sectors, NIS2 may still apply to you.
If your organization is below the size thresholds, you may still be covered if a member state has designated you as critical infrastructure. When in doubt, check with your national competent authority.
The Core Legal Requirement: Article 21
Everything in NIS2 compliance for technical teams flows through Article 21 — Cybersecurity Risk-Management Measures. It requires "appropriate and proportionate technical, operational and organisational measures" across ten areas.
For small businesses, the areas that translate directly into auditable technical controls are:
| Article 21 Sub-Clause | What it covers | Technical equivalent |
|---|---|---|
| 21.2c | Business continuity | Redundant DNS, MX failover |
| 21.2d | Supply chain security | Email authentication (SPF, DKIM, DMARC) |
| 21.2g | Cryptography and encryption | DNSSEC, MTA-STS, TLS |
| 21.2h | Human resources, access control | Staff training, access management |
| 21.2i | Multi-factor authentication | MFA on all admin accounts |
| 21.2j | Secure communications | Encrypted email transport, TLS-RPT monitoring |
The critical word in Article 21 is "appropriate." Auditors do not expect a 20-person business to operate a 24/7 SOC. They do expect documented controls that are proportionate to your size, sector, and risk exposure — and evidence that those controls are actively maintained, not configured once and forgotten.
The NIS2 Technical Checklist for Small Businesses
Work through this in order. The first section covers the technical DNS and email controls that map directly to Article 21. The second covers the documentation and process evidence auditors look for on top of the technical layer.
Section 1: DNS and Email Security Controls
These are the technical measures that auditors check first because they are objectively verifiable. Pass or fail is deterministic — either the record exists and is correctly configured, or it does not.
1.1 — SPF record is published and valid (Article 21.2d)
SPF (Sender Policy Framework) lists which mail servers are authorized to send email from your domain. Without it, anyone can send forged email claiming to be from your address.
Check:
dig yourdomain.com TXT +short | grep spf
Pass condition: a TXT record starting with v=spf1 exists, includes all your sending services, and ends with ~all or -all. The record must not exceed 10 DNS lookups. Two v=spf1 records on the same domain is an automatic fail — only one is allowed.
NIS2 mapping: Article 21.2d — supply chain. Email sent from your domain on behalf of business processes is part of your ICT supply chain. Unauthenticated email is an uncontrolled attack surface.
1.2 — DKIM is configured for all sending services (Article 21.2d)
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing email. Receiving servers verify the signature against a public key you publish in DNS. If the signature doesn't match, the email is flagged or rejected.
Check:
dig selector._domainkey.yourdomain.com TXT +short
Replace selector with the selector name from your email provider (commonly google, selector1, or default).
Pass condition: a TXT record starting with v=DKIM1; k=rsa; p= exists for each active email service. Key length must be 2048 bits — 1024-bit keys are considered weak and should be rotated. Selectors with empty p= values indicate a revoked key and should be removed from DNS.
NIS2 mapping: Article 21.2d — supply chain security, and Article 21.2g — cryptography. DKIM is a cryptographic control on email transmission.
1.3 — DMARC policy is p=quarantine or p=reject (Article 21.2d)
This is the single most common NIS2 compliance failure on email. p=none does not satisfy Article 21.2d because it does not enforce the policy — it only monitors. Auditors will explicitly check this.
Check:
dig _dmarc.yourdomain.com TXT +short
Pass condition: a TXT record exists at _dmarc.yourdomain.com with p=quarantine or p=reject. A rua= address for receiving aggregate reports must also be present — without it you have no visibility into what is failing.
NIS2 mapping: Article 21.2d. p=none explicitly does not qualify as an enforced control under NIS2. The requirement is enforcement, not observation.
If you are currently at p=none:
- Monitor DMARC reports for 2–4 weeks using a parser (Postmark DMARC Digests, DMARC Analyzer)
- Confirm all legitimate sending services pass SPF and DKIM
- Move to
p=quarantine - After another 2–4 weeks of clean reports, move to
p=reject
Do not jump directly to p=reject — it will block legitimate emails if any sending service is not yet authenticated.
1.4 — DNSSEC is enabled (Article 21.2g)
DNSSEC adds cryptographic signatures to your DNS records, allowing resolvers to verify that answers have not been tampered with in transit. Without DNSSEC, cache poisoning attacks can redirect your domain's traffic to an attacker's server — silently, with no warning to your users.
Check:
dig yourdomain.com DNSKEY +short
Pass condition: DNSKEY records are present and a DS record exists in the parent zone (your TLD). The full chain of trust can be verified at dnsviz.net.
Setup on managed providers:
- Cloudflare: DNS → Settings → DNSSEC → Enable → copy DS record to registrar
-
Route53: Hosted zone → DNSSEC signing → Enable → add DS record at registrar (KMS key must be in
us-east-1) - Google Cloud DNS: Cloud DNS → zone → DNSSEC → Enable → copy DS record to registrar
NIS2 mapping: Article 21.2g — cryptography and encryption. DNSSEC is explicitly a cryptographic measure for DNS integrity.
1.5 — MTA-STS is configured in enforce mode (Article 21.2g / 21.2j)
MTA-STS (Mail Transfer Agent Strict Transport Security) instructs other mail servers to use TLS when connecting to yours, and prevents downgrade attacks that would allow email to be transmitted unencrypted. Without MTA-STS, an attacker on the network path between two mail servers can strip TLS and read email in transit.
MTA-STS requires two components:
- A policy file hosted at
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt - A TXT record at
_mta-sts.yourdomain.com
The policy file content for enforce mode:
version: STSv1
mode: enforce
mx: mail.yourdomain.com
max_age: 86400
The DNS record:
_mta-sts.yourdomain.com TXT "v=STSv1; id=20240101000000"
The id value must change whenever you update the policy file — it signals to other mail servers that they should fetch the new policy.
NIS2 mapping: Article 21.2g (cryptography) and Article 21.2j (secure communications). MTA-STS is a transport encryption enforcement measure for email.
1.6 — TLS-RPT is configured (Article 21.2j)
TLS-RPT (TLS Reporting) sends you daily reports from other mail servers about TLS negotiation failures when they attempt to deliver email to your domain. Without it, you have no visibility into whether your email transport encryption is working correctly in practice.
dig _smtp._tls.yourdomain.com TXT +short
Pass condition: a TXT record exists at _smtp._tls.yourdomain.com with a rua= address to receive reports.
NIS2 mapping: Article 21.2j — secure communications monitoring.
1.7 — Redundant nameservers in separate geographic locations (Article 21.2c)
NIS2 Article 21.2c requires business continuity measures for ICT systems. For DNS, this means at minimum two nameservers that are geographically and network-separated — so a single regional outage does not take your domain offline entirely.
Check:
dig yourdomain.com NS +short
Pass condition: at least two nameservers are returned. Managed DNS providers (Cloudflare, Route53, Google Cloud DNS) satisfy geographic redundancy by default through their Anycast networks — if you are using one of these, this control is met.
If you are running self-hosted DNS, verify that your secondary nameserver is on a different ASN and in a different data center region from your primary.
NIS2 mapping: Article 21.2c — business continuity and crisis management.
1.8 — Blacklist monitoring is active (Article 21.2d)
If your sending IP or domain appears on a major blacklist (Spamhaus, Barracuda, Microsoft SNDS), your email is rejected by large portions of the internet. This is an active and ongoing supply chain risk — blacklistings happen without warning and can persist for days before anyone on your team notices through manual checks.
Manual check:
# Spamhaus combined zone (SBL + XBL + PBL):
dig {reversed-ip}.zen.spamhaus.org A
# NXDOMAIN = clean. Any other response = listed.
For continuous coverage, automated blacklist monitoring across 50+ databases is the practical requirement — manual checks only tell you the status at the moment you run them.
NIS2 mapping: Article 21.2d — supply chain security. Blacklist status directly affects whether your business communications reach their intended recipients.
1.9 — SSL certificate expiry monitoring (Article 21.2g)
An expired SSL certificate causes browser trust errors on your website and can break encrypted services. For NIS2 purposes, certificate expiry monitoring is part of cryptographic hygiene under Article 21.2g.
Check:
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates
Pass condition: notAfter is at least 30 days in the future. Automated monitoring that alerts before expiry eliminates the failure mode entirely.
1.10 — CAA records restrict certificate issuance (Article 21.2g)
CAA (Certification Authority Authorization) records specify which certificate authorities are permitted to issue SSL certificates for your domain. Without CAA records, any of the hundreds of publicly trusted certificate authorities in the world can issue a certificate for your domain — including in response to a phishing or social engineering attack.
dig yourdomain.com CAA +short
Pass condition: at least one CAA record authorizing your current CA exists. Add one issue record for each CA you actively use.
NIS2 mapping: Article 21.2g — cryptographic controls on certificate issuance.
Section 2: Documentation and Evidence
The technical controls in Section 1 are necessary but not sufficient. NIS2 auditors require documented evidence that controls exist and are continuously maintained. Point-in-time evidence — a scan result you generate the day before the audit — does not demonstrate continuous monitoring.
2.1 — ICT risk register includes DNS and email infrastructure
Your risk register must document DNS zone and email infrastructure as critical ICT assets. For each asset, document: the threat, the likelihood, the impact, and the current control in place.
Minimum entry format:
Asset: DNS zone (yourdomain.com)
Threat: DNS hijacking / cache poisoning
Likelihood: Medium
Impact: High (complete service outage, credential harvesting)
Control: DNSSEC enabled, nameserver monitoring active
Review date: [quarterly]
The register must be dated and versioned. Version history is itself evidence of ongoing maintenance.
2.2 — Incident response plan covers DNS and email incidents
Your IRP must cover the scenario where DNS records are modified without authorization, or where your sending IP is blacklisted. For NIS2, significant incidents must be reported to your national CSIRT within 24 hours of detection, with a full report within 72 hours.
The plan must document:
- Detection (how will you know?)
- Containment (what do you do immediately?)
- CSIRT notification (who contacts them, with what information?)
- Recovery (how do you restore correct state?)
- Post-incident review (what changed?)
A three-page document that covers these five points is sufficient. It must exist, be dated, and be tested at least annually via tabletop exercise.
2.3 — Continuous monitoring evidence with timestamps
This is the hardest requirement to satisfy with manual processes. Auditors look for a continuous, timestamped record of monitoring activity — not a report you generated for the audit.
Acceptable continuous monitoring evidence:
- Automated scan results with timestamps covering the audit period (90+ days)
- Alert history showing that when a control changed, your team was notified
- Remediation records showing that alerts were investigated and resolved
Not acceptable as continuous monitoring evidence:
- A single clean scan report dated the week before the audit
- A spreadsheet of manual checks without timestamps
- Screenshots of current DNS records without historical context
Tools like ZeroHook run continuous DNS and email security scans, maintain a timestamped audit log, and generate compliance-mapped evidence packages for NIS2 auditors — the kind of output that directly answers "show me your continuous monitoring" without manual assembly.
2.4 — Supply chain vendor register
NIS2 Article 21.2d requires you to assess the security posture of ICT suppliers that have access to your systems or handle your data. This includes your email provider, DNS host, cloud hosting, and any SaaS tools with access to sensitive data.
Minimum vendor register entry:
Vendor: [Name]
Service: [What they provide]
Data accessed: [Customer data / employee data / none]
Security certification: [ISO 27001 cert no. / SOC2 report / N/A]
Last reviewed: [Date]
Contractual DPA: [Yes / No]
Requesting a vendor's security certification or sending a brief questionnaire — documented in an email thread — constitutes active supply chain due diligence. The fact of having asked, with a date, is evidence.
2.5 — Staff security training records
Article 21.2h requires human resources security including cybersecurity awareness. For small businesses, the minimum viable evidence is:
- A security awareness training session covering phishing, password hygiene, and incident reporting — at least annually
- Attendance records or completion certificates
- A written policy for reporting suspected incidents (even a one-page document)
Phishing simulation results are a strong positive signal in an audit — they demonstrate active testing of human controls, not just training delivery.
2.6 — MFA is enforced on all administrative accounts (Article 21.2i)
Article 21.2i explicitly requires multi-factor authentication for remote access and administrative access to systems. This is one of the clearest mandatory requirements in NIS2.
Document:
- List of administrative accounts (email, DNS, cloud, critical SaaS)
- MFA method for each (TOTP, hardware key, etc.)
- Enforcement status (is MFA enforced by policy, or optional?)
MFA must be enforced, not optional. If users can bypass MFA on admin accounts, the control is not in place for NIS2 purposes.
NIS2 Compliance Status: A Quick Self-Assessment
Use this scoring table to gauge where you stand before a formal audit.
| Control | Status | NIS2 Article |
|---|---|---|
| SPF published and valid | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2d |
| DKIM configured, 2048-bit keys | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2d, 21.2g |
| DMARC at p=quarantine or p=reject | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2d |
| DNSSEC enabled | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2g |
| MTA-STS in enforce mode | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2g, 21.2j |
| TLS-RPT configured | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2j |
| Redundant nameservers | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2c |
| Blacklist monitoring active | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2d |
| SSL expiry monitored | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2g |
| CAA records in place | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2g |
| ICT risk register maintained | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2a |
| Incident response plan documented | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2b |
| Continuous monitoring evidence | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2 (general) |
| Vendor security register | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2d |
| Staff security training records | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2h |
| MFA enforced on admin accounts | ✅ Pass · ❌ Fail · ⬜ Pending | 21.2i |
12 or more passes, with no critical failures in DMARC, DNSSEC, or MTA-STS: you are in defensible shape for an initial audit.
Fewer than 8 passes: prioritize the technical controls in Section 1 before addressing documentation. Auditors verify technical controls first, then look for documentation.
The Two Controls That Get Small Businesses in Trouble Most Often
Based on the pattern of NIS2 compliance gaps, two controls account for the majority of Article 21 failures in SMB audits.
DMARC at p=none. This is the most common. Organizations set up DMARC for monitoring, never advance to enforcement, and arrive at an audit with a p=none record they believe is compliant. It is not. NIS2 requires enforcement. A DMARC record with p=none is treated the same as no DMARC record from a compliance perspective.
No continuous monitoring evidence. The second most common. An organization has all the correct technical controls in place but cannot produce timestamped evidence that those controls were continuously active during the audit period. Running a scan the morning of the audit does not demonstrate that the controls were in place three months ago.
Both of these are solvable. The DMARC fix is a record update. The monitoring evidence problem requires putting automated, continuous monitoring in place before the audit cycle starts — not after you receive the audit notice.
TL;DR
- NIS2 enforcement is active as of October 2024 — fines up to €10M for Essential Entities, €7M for Important Entities — there is no grace period for small businesses in scope
- The core technical requirement is Article 21 — DNS security (DNSSEC, redundant nameservers, CAA), email authentication (SPF, DKIM, DMARC at p=quarantine or p=reject), and transport encryption (MTA-STS in enforce mode, TLS-RPT)
- p=none DMARC does not satisfy Article 21.2d — enforcement is required, not monitoring. This is the single most common compliance gap in SMB audits
- Continuous monitoring evidence is mandatory — point-in-time scan results do not satisfy the requirement. Timestamped automated monitoring covering the audit period is what auditors ask for
- Documentation requirements are proportionate — a dated risk register, a 3-page incident response plan, a vendor register, and staff training records are sufficient for most small businesses
- MFA on all administrative accounts is explicitly required under Article 21.2i — optional MFA does not satisfy the requirement
*Part of an ongoing series on DNS security and compliance.
Top comments (0)