Denmark NIS2 Compliance Guide: How Virk.dk, CFCS Authority, and Lov om Net- og Informationssikkerhed Apply to Your Organisation

On 27 June 2017, the NotPetya worm reached Maersk through a compromised Ukrainian accounting software package, halting 76 global port terminals and costing the Danish shipping giant an estimated $300 million USD. No Danish law required Maersk to document its supplier security controls, segment its networks, or report the incident to a national authority on a defined timeline. NIS2 exists, in part, to change that.

Denmark transposed the NIS2 Directive into national law as Lov nr. 434 af 6. maj 2025 — the general cybersecurity act that entered into force on 1 July 2025 [4]. The European Commission had already opened infringement proceedings, issuing a reasoned opinion on 7 May 2025 after Denmark missed the EU’s October 2024 deadline [4]. The delay shortened preparation windows for Danish organisations, but it has not softened obligations: approximately 6,000 entities are now in scope, registration closed on 1 October 2025, and security measures are enforceable from 1 July 2025.

What makes Denmark distinctive is its architecture. Most EU member states channel NIS2 notifications to a single competent authority. Denmark routes all registrations and incident reports through one national portal — Virk.dk — which automatically distributes filings to the relevant sector regulator. At the incident layer, the Centre for Cyber Security (CFCS), now operating under Styrelsen for Samfundssikkerhed (SAMSIK), receives every significant incident notification regardless of sector. This guide explains who is in scope, how to register, what CFCS actually does, and what practical steps your organisation should take now.

Does NIS2 Apply to Your Organisation?

The NIS2 scope framework classifies covered entities into two tiers. Danish law uses the terms Væsentlig enhed (VE — Essential Entity) and Vigtig enhed (VI — Important Entity), mirroring Article 3 of Directive 2022/2555 [1]:

Entity Type	Danish Term	Threshold (either condition)	Example Sectors
Essential Entity	Væsentlig enhed (VE)	≥ 250 employees OR ≥ €50M annual turnover	Energy, transport, banking, healthcare, water, digital infrastructure, public administration
Important Entity	Vigtig enhed (VI)	50–249 employees AND €10M–€50M turnover	Manufacturing, food, postal services, waste management, digital providers, research
Auto-included (any size)	N/A — size irrelevant	Applies regardless of headcount or turnover	Telecom operators, DNS providers, TLD registries, trust service providers

The roughly 6,000 organisations now in scope represent a sixfold expansion over NIS1 [8]. If your organisation operates critical infrastructure, provides managed IT or security services, runs a healthcare facility, or operates digital platforms serving Danish users, the starting assumption should be coverage. Use the SAMSIK self-assessment tool to confirm your classification before engaging with registration.

A practical decision test: if you have 50 or more employees and operate in any of the 18 sectors listed in NIS2 Annex I or Annex II — from energy distribution to online marketplaces — treat yourself as in scope and verify with the competent authority. Sectors added under NIS2 that were not covered by NIS1 include manufacturing of certain products, food production, postal services, and waste management. If you are unsure whether your specific activity qualifies, the Danish Agency for Digital Government operates a dedicated NIS2 helpdesk at NIS2@digst.dk [2].

Denmark’s Implementation Framework — Lov nr. 434 and the Multi-Sector Architecture

Denmark chose not to consolidate NIS2 into a single omnibus statute. The framework rests on a general act supplemented by sector-specific legislation:

The general act: Lov nr. 434 af 6. maj 2025 — formally titled the Law on Measures to Ensure a High Level of Cybersecurity, commonly called Cybersikkerhedsloven or NIS-2-loven — entered into force 1 July 2025 [5]. It sets the scope definitions, entity classification thresholds, governance obligations, registration requirements, and the penalty framework that apply across all covered sectors.

The Energy Sector Act: Lov nr. 258 af 6. marts 2025 entered into force 7 March 2025 — earlier than the general act, reflecting the energy sector’s pre-existing supervisory framework under the Danish Energy Agency [5].

The Telecoms Act: Lov nr. 435 af 6. maj 2025 entered into force alongside the general act on 1 July 2025, covering cybersecurity obligations for telecom providers and digital infrastructure operators [5].

The practical implication: a manufacturing company reads Lov nr. 434 and a sector ministerial order. A bank reads Lov nr. 434 and the Financial Business Act amendments simultaneously, with Finanstilsynet as its compliance supervisor. A telecom operator reads both Lov nr. 434 and Lov nr. 435. Obligations are additive — the stricter requirement of overlapping frameworks applies.

Denmark missed the EU’s transposition deadline of 17 October 2024, and the European Commission issued a reasoned opinion on 7 May 2025, the second formal stage of infringement proceedings [4]. Lov nr. 434 entering force on 1 July 2025 resolved the formal transposition gap. For organisations that waited for the national law before beginning compliance work, the effective preparation window was compressed to roughly three months before the 1 October 2025 registration deadline.

CFCS and the Distributed Regulator Model

Understanding Danish NIS2 governance requires separating two distinct functions: incident notification and compliance supervision. CFCS handles one; your sector authority handles the other.

Incident notification flows to CFCS regardless of sector. The Centre for Cyber Security serves as Denmark’s designated national CSIRT under NIS2 and the EU single point of contact for cybersecurity [4]. All significant cyber incidents — defined under Article 23 of Directive 2022/2555 as incidents causing or capable of causing significant service disruption — must be reported through the Virk.dk portal, from which CFCS receives them directly [7].

Compliance supervision is sector-distributed. The regulator auditing your security documentation, issuing corrective instructions, and imposing fines is your sector authority, not CFCS:

Sector	Supervisory Authority	Contact
Energy	Danish Energy Agency (Energistyrelsen)	beredskab@ens.dk
Finance	Financial Supervisory Authority (Finanstilsynet)	—
Healthcare	Danish Health Authority (Sundhedsstyrelsen)	—
Transport (aviation, maritime, rail, road)	Sector-specific transport agencies	—
Digital services (DNS, cloud, CDN, MSP, MSSP)	Danish Business Authority (Erhvervsstyrelsen)	—
Digital governance / cross-sector	Danish Agency for Digital Government (Digitaliseringsstyrelsen)	NIS2@digst.dk
General coordination and incident CSIRT	Styrelsen for Samfundssikkerhed (SAMSIK / CFCS)	via samsik.dk

The GovCERT legacy. CFCS traces directly to Denmark’s former Government CERT (GovCERT). In 2014, CFCS established its Network Security Service (Netsikkerhedstjenesten), absorbing both GovCERT and the military CERT (MILCERT) into a single civilian cyber authority. CFCS has since been formally integrated into the Styrelsen for Samfundssikkerhed structure — cfcs.dk now redirects to samsik.dk — reflecting the broader consolidation of Danish national resilience functions under one ministry.

DKCERT is a separate entity with no NIS2 supervisory role for commercial or public sector organisations. DKCERT handles security incidents on forskningsnettet — Denmark’s national research and education network — under DeiC (the Danish e-Infrastructure Consortium). Its mandate is limited to academic institutions on that network. A CISO at a hospital, manufacturer, or digital service provider has no compliance relationship with DKCERT.

A practical benefit of CFCS’s incident coordination role: organisations uncertain whether a specific event crosses the “significant incident” threshold can request a confidential pre-assessment consultation before formal notification is required [7]. This is particularly useful for borderline cases where operational disruption is present but its downstream impact is unclear.

Registering via Virk.dk — Denmark’s Single-Entry Architecture

Virk.dk is Denmark’s official business portal — the same platform used for VAT registration and company filings — repurposed as the single NIS2 intake gateway. No other EU member state uses this model: one commercial-government portal acts as the registration and incident reporting point for all covered sectors simultaneously [2].

Registration was mandatory by 1 October 2025. The process:

1. Access virk.dk and navigate to the NIS2 self-service section (live from 1 July 2025).
2. Authenticate with MitID Erhverv — Denmark’s digital business signature, linked to your CVR (company registration) number.
3. Select all applicable sectors. If your organisation operates in two sectors (for example, maritime transport and managed IT services), select both.
4. Submit. The system automatically distributes your registration to each relevant sector authority — no separate filings required [2].
5. Receive confirmation on-screen and via Digital Post (the official Danish digital mailbox for businesses).

The multi-sector automatic distribution is the architecture’s distinctive feature. A logistics operator running port facilities (maritime transport) and a digital operations platform (digital service provider) files once and simultaneously notifies both the relevant transport authority and the Danish Business Authority. In most EU member states, that requires two separate filings to two separate bodies.

The foreign entity challenge. Organisations with Danish operations but no Danish CVR number face a structural barrier: MitID Erhverv is only available to entities registered in the Danish business registry [3]. If your organisation operates a Danish branch, data centre, or critical service in Denmark but is headquartered elsewhere, the alternatives are:

• Designating a Danish-registered subsidiary or representative to handle the filing on your behalf
• Using an approved electronic business ID from another EU member state (availability is limited)
• Submitting the downloadable registration form directly to NIS2@digst.dk (for digital service providers) [2]
• Applying for an exemption from the digital communication requirement

Energy-sector entities without Danish digital credentials should contact the Danish Energy Agency directly at beredskab@ens.dk [3].

Incident reporting uses the same Virk.dk portal from 1 July 2025. Early warnings, 72-hour updates, and final reports all route through the portal to CFCS, with automatic forwarding to sector authorities where required.

Security Measures Required Under Article 21 and Danish Law

Cybersikkerhedsloven implements Article 21 of Directive 2022/2555 without material deviation [1]. The 10 security domains listed in Article 21(2)(a)–(j) are directly binding on all covered Danish entities:

Article 21(2)	Measure	Danish Compliance Expectation
(a)	Risk analysis and security policies	Documented risk assessment; reviewed at defined intervals or after significant change
(b)	Incident handling	Detection, containment, and notification procedures mapped to Art. 23 timelines
(c)	Business continuity and disaster recovery	Tested BCP and DRP with defined recovery time objectives
(d)	Supply chain security	Supplier classification by criticality; contractual security requirements for direct suppliers
(e)	Security in acquisition, development, and maintenance	Vulnerability management; secure configuration standards; patch cadence documented
(f)	Effectiveness assessment	Internal audits; penetration testing at defined frequency
(g)	Cyber hygiene and training	Staff training programme; board-level cybersecurity training mandatory under Art. 20(4)
(h)	Cryptography and encryption	Encryption policy covering data in transit and at rest
(i)	Human resources security and access control	HR vetting procedures; role-based access; prompt de-provisioning on departure
(j)	Multi-factor authentication	MFA required for remote access and all privileged accounts

Article 20(4) of the directive [1] places an additional obligation on management bodies: members must receive training sufficient to identify risks and assess security management practices. This is not a one-time induction — the requirement is for ongoing, regular training. Danish boards cannot delegate the Article 20(1) accountability to the CISO alone. Management body members bear personal accountability for the governance oversight function, including approving and actively overseeing security risk management measures.

For supply chain security under Article 21(2)(d), the obligation requires documented classification of every direct supplier by criticality, with security requirements flowing into supplier contracts. The Maersk NotPetya attack — discussed in the section below — entered precisely through a trusted direct supplier.

Incident Notification Obligations

When a significant incident occurs, Article 23 of Directive 2022/2555 [1] applies directly through Cybersikkerhedsloven. The three-stage reporting structure:

Stage	Deadline	Minimum Content Required
Early warning	Within 24 hours of becoming aware	Was a cyberattack suspected? Is a cross-border effect likely?
Notification	Within 72 hours	Initial assessment: severity, geographic impact, indicators of compromise
Final report	Within 1 month	Full technical account, root cause analysis, remediation measures taken

All three stages are submitted via Virk.dk to CFCS. Where a sector supervisory authority also requires notification under a parallel obligation, the portal’s automatic distribution handles that simultaneously.

The "significant incident" threshold follows Article 23(3) of the directive [1]: an incident is significant if it has caused or is capable of causing severe operational disruption, financial loss to the affected entity, or significant damage to other natural or legal persons. For borderline cases, CFCS’s confidential pre-assessment service — available before formal reporting — is the most practical mechanism for resolving threshold uncertainty.

Penalties and Management Personal Liability

Danish law mirrors the directive’s two-tier penalty structure [1][8]:

Entity Type	Maximum Administrative Fine
Essential Entity (Væsentlig enhed)	€10,000,000 or 2% of total annual global turnover — whichever is higher
Important Entity (Vigtig enhed)	€7,000,000 or 1.4% of total annual global turnover — whichever is higher

Enforcement powers extend beyond fines. Sector authorities can issue binding security instructions, mandate immediate corrective actions, order suspension of specific services, and — for repeated or severe violations — seek temporary bans on individuals from exercising management functions [8].

Management personal liability is the element most frequently underestimated in initial compliance assessments. Article 20(1) of Directive 2022/2555 [1] requires management bodies to approve cybersecurity risk management measures and actively oversee their implementation. Management body members are personally accountable for compliance failures in their domain. A CISO cannot absorb the board’s liability by independently signing off on policies. If a sector authority identifies that the management body failed to exercise adequate oversight — for example, by not reviewing risk assessments or approving security investments — individual board members face personal enforcement action.

The Maersk NotPetya Precedent — Why Danish Compliance Culture Changed in 2017

On 27 June 2017, the NotPetya worm reached Maersk’s global network through a compromised Ukrainian accounting software package (M.E.Doc). Within hours, 45,000 PCs and 4,000 servers were infected. Operations at 76 global port terminals halted. The company ran terminal operations on paper for days. The final cost estimate: $300 million USD [6]. Recovery to 80% operational capacity took 6–12 days.

For the ~6,000 Danish organisations now in NIS2 scope, the Maersk case maps directly onto the framework’s architecture:

Article 21(2)(d) — supply chain entry point. The NotPetya infection entered through a trusted direct supplier relationship — the M.E.Doc software that Maersk’s Ukrainian entities used for tax filings. Article 21(2)(d) requires documented supplier classification and security requirements flowing contractually to every direct supplier. Maersk had no requirement to assess the cybersecurity practices of a local accounting software vendor. Under NIS2, that gap is no longer legally permissible.

Article 21(2)(e) — network propagation. NotPetya spread laterally across Maersk’s flat network architecture, reaching every segment rapidly. The network security and security-in-acquisition obligations under Article 21(2)(e) are designed to limit lateral propagation through segmentation and controlled connectivity — not merely to prevent initial entry.

Article 20 — board-level accountability. Following the attack, Maersk’s leadership concluded that cybersecurity needed to function as “a competitive advantage” rather than a compliance checkbox. Article 20(1) legislates that cultural shift: board approval and oversight of security risk management is now a legal obligation, not a strategic aspiration.

NotPetya was not a targeted attack on Maersk. It was a cyberweapon aimed at Ukrainian infrastructure that found a path through a Danish company’s globally connected network. The lesson for entities in NIS2 scope is the same: scale and geography do not create immunity. The question is whether documented, tested controls would have detected or limited the damage before it reached $300 million.

Practical Compliance Checklist for Danish Organisations

The minimum actions required under Cybersikkerhedsloven:

Scope determination

• Map your sector(s) against NIS2 Annex I and Annex II
• Confirm employee count and turnover against VE / VI thresholds
• Check for auto-inclusion criteria (telecom, DNS, trust services)

Registration

• Register via Virk.dk with MitID Erhverv before 1 October 2025
• Select all applicable sectors — Virk.dk auto-distributes to each regulator
• If no Danish CVR: contact NIS2@digst.dk or your sector authority for the alternative pathway [2][3]
• File and retain the Digital Post confirmation

Governance

• Management body receives cybersecurity training (Art. 20(4))
• Board resolution approving the security risk management approach (Art. 20(1))
• Document personal accountability assignments for the Article 20 oversight function

Security measures

• Risk assessment methodology documented, approved, and dated (Art. 21(2)(a))
• Incident handling procedures covering the 24h/72h/1-month Virk.dk reporting path (Art. 21(2)(b))
• Supplier classification for every direct supplier (Art. 21(2)(d))
• MFA deployed for all remote access and privileged accounts (Art. 21(2)(j))
• Business continuity plan documented and tested within the past 12 months (Art. 21(2)(c))

Ongoing

• Annual review of risk assessment (or after any significant change)
• Test the Virk.dk incident reporting path before you need it in a live event
• Monitor sector authority guidance for sector-specific supplementary requirements

Frequently Asked Questions

When did Danish NIS2 obligations become legally enforceable?

Cybersikkerhedsloven (Lov nr. 434 af 6. maj 2025) entered into force on 1 July 2025. Compliance with security measures is required from that date. The self-registration deadline via Virk.dk was 1 October 2025.

Is CFCS still the right name to use, or is it now SAMSIK?

CFCS (Centre for Cyber Security) has been integrated into Styrelsen for Samfundssikkerhed (SAMSIK) — cfcs.dk now redirects to samsik.dk. For NIS2 purposes, CFCS/SAMSIK receives all significant incident notifications via Virk.dk and serves as Denmark’s EU point of contact for cybersecurity. Both names appear in official documents depending on publication date.

What if my organisation operates in both the energy and finance sectors?

Both Lov nr. 258 (Energy Act) and the Financial Business Act amendments apply simultaneously. Register via Virk.dk selecting both sectors — the portal distributes to the Danish Energy Agency and Finanstilsynet in a single submission. Compliance obligations are additive; the stricter of the two requirements applies wherever frameworks overlap.

Do NIS2 obligations apply to non-EU companies operating in Denmark?

Yes. Any entity providing services or operating infrastructure in Denmark within the covered sectors and above the size thresholds is in scope, regardless of where it is headquartered. Foreign entities face the practical MitID Erhverv registration barrier and must use the alternative pathways described above [3].

How does NIS2 incident reporting interact with GDPR personal data breach notification?

NIS2 and GDPR are separate obligations. A single security incident may trigger both: NIS2 incident notification goes to CFCS/SAMSIK via Virk.dk (24h early warning, 72h update, 1-month final); a personal data breach under GDPR goes to the Danish Data Protection Authority (Datatilsynet) within 72 hours. The two notifications flow to different authorities and require different content. Maintaining a single internal incident record that feeds both output channels is the most efficient approach.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Directive (EU) 2022/2555 (NIS2 Directive) — EUR-Lex: eur-lex.europa.eu
2. Registration Obligation and Incident Reporting — Danish Agency for Digital Government: en.digst.dk
3. Information for Foreign Entities on Registration and Reporting — Styrelsen for Samfundssikkerhed: samsik.dk/nis2/information-for-foreign-entities-on-registration-and-reporting/ (already linked in body)
4. NIS2 Directive Implementation in Denmark — European Commission Digital Strategy: digital-strategy.ec.europa.eu/en/policies/nis2-directive-denmark (already linked in body)
5. NIS2 Transposition in Denmark — nis-2-directive.com: nis-2-directive.com
6. NotPetya Ransomware Attack on Maersk — LRQA: lrqa.com
7. NIS2 Denmark: Authority, CSIRT, and Sector Guidance — ISMS.online: isms.online
8. What is Cybersikkerhedsloven? — Cyberday.ai: cyberday.ai