What is the NIS 2-loven, and when did it take effect?
The Danish transposition is called lov om foranstaltninger til sikring af et højt cybersikkerhedsniveau (act on measures for a high level of cybersecurity) — in everyday use, the NIS 2-loven. It was adopted on 29 April 2025, signed on 6 May, and came into force on 1 July 2025.
Denmark was late. The EU deadline for transposing the NIS2 directive was 17 October 2024, so the Act landed roughly eight and a half months afterwards. It arrived as one of a package of three acts that all took effect the same day: the NIS 2-loven, the CER act and an act for the telecommunications sector.
Portfolio responsibility sits with Ministeriet for Samfundssikkerhed og Beredskab (the Ministry for Societal Security and Emergency Management), and Styrelsen for Samfundssikkerhed is the central agency. Supervision, however, is sector-based: competent authorities are designated for each sector, and in practice it is the sector authority — not one central body — that you deal with. That is the first thing a group used to a single national cyber regulator gets wrong; it looks for one counterpart and there is not one.
Which entities in a group are actually caught?
Two questions decide it: which sector, and what size.
Annex 1 — sectors of particularly critical importance: energy, transport, banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure, ICT service management (B2B), public administration and space.
Annex 2 — other critical sectors: postal and courier services, waste management, chemicals, food, manufacturing, digital providers and research.
| Category | Threshold |
|---|---|
| Væsentlige enheder (essential entities) | At least 250 employees or turnover above EUR 50 million |
| Vigtige enheder (important entities) | At least 50 employees or turnover above EUR 10 million |
Note the ICT service management (B2B) category in Annex 1. It catches managed service providers and managed security service providers — that is, a set of suppliers who do not regard themselves as critical infrastructure but are so in the meaning of the Act. If your group runs a shared service centre that provides managed IT to the operating companies, ask whether it falls in there before assuming it does not. The same category is why a vendor selling managed services into Denmark can be in scope on its own account and not only through its customers.
Styrelsen for Samfundssikkerhed provides a self-assessment tool at nis2tjek.sikkerdigital.dk. The registration duties appear in §§ 9–10 with short deadlines — the exact deadlines should be read directly in the Act, because they differ between the two provisions.
One caution for a group compliance lead, and it is a genuine uncertainty rather than a drafting quibble. The thresholds are expressed in employee numbers and turnover. How those figures are counted for a Danish subsidiary that sits inside a much larger group is precisely the question to put to Danish counsel, because it decides between væsentlig and vigtig — and, as the next section shows, that classification decides whether the sanction that reaches an individual is available at all. Do not assume group consolidation in either direction on the strength of an English summary.
What exactly does § 7 require of the management body?
Section 7 is short, and it is drafted as a duty rather than an expectation. Two things follow from it:
- Approval and supervision. The measures the entity adopts under § 6 must be approved by the entity's management body, which must also supervise their implementation.
- Training. The members of the management body must attend relevant training on the management of cybersecurity risks.
The sanctions in § 32 cover fines and criminal liability for legal persons under chapter 5 of the Danish Criminal Code. The supervisory authority's administrative powers include binding orders and suspension of certifications — and, in relation to væsentlige enheder, the power to prohibit an individual temporarily from exercising management functions.
That is the provision that changes the conversation in the boardroom. Cybersecurity is no longer only an operational matter with a budget; it is a matter with personal consequences for the people who approve.
What must a foreign parent's Danish subsidiary do differently?
A domestic Danish company and a Danish subsidiary of a foreign group face the same statute and very different operational problems. Six differences are worth planning for.
The approval has to be the Danish entity's, and it has to be a decision. A group information security policy approved by a parent board, cascaded down and noted by the Danish directors, is not a § 7 approval. The measures adopted under § 6 have to go in front of the Danish ledelsesorgan as a decision item, and the minutes have to show that it approved them rather than received them.
The training obligation is personal to those members. It is not discharged by a group CISO's certificate, by a security awareness module completed by staff, or by a parent-company programme that the Danish directors did not attend. Record attendance by name and date.
Find the sector authority, not the national regulator. Because supervision is sector-based, a group compliance map that lists one Danish cyber regulator per country will point at the wrong body. Identify the competent authority for your sector, and identify it before an incident rather than during one.
The 24-hour clock runs on the Danish entity. A group SOC in another time zone, escalating through a global incident process to a group legal function, can consume most of the early-warning window before the Danish entity even knows it has a notification duty. The Danish deadline does not pause for a group process. Decide in advance who in Denmark can trigger a notification without waiting for group sign-off.
Outsourcing does not move the responsibility, including inside the group. The supply chain requirements mean the obligation stays with the entity in scope. That is true where the supplier sits outside the EU, and it is equally true where the supplier is the group's own shared service centre. The requirements travel by contract, whether or not the supplier is itself in scope.
The Danish text governs. A group policy drafted in English, however carefully, is a translation of the obligation and not the obligation. Where this page and the Danish statute differ, the statute wins; where your Danish adviser and this page differ, your adviser wins.
What does approval mean when the system acts on its own?
Section 7 assumes implicitly that the management body can understand and approve what it is approving. That is unproblematic for access control, backup and patching policy. It becomes harder when part of day-to-day operations is carried out by systems that act autonomously: integrations with write permissions in finance systems, automated workflows that initiate payments or change master data, and AI agents that interpret an input and act on it.
Four questions are worth being able to answer before signing.
Which actions may the system perform, and who bounded that?
An integration with permissions in a system rarely has them bounded by amount, counterparty or action type. The permissions are typically inherited from the user account the integration was set up under. That is a boundary nobody decided, and therefore a boundary nobody has approved.
What happens before the action executes?
Monitoring and logging tell you what happened. They do not stop it happening. Where an action has financial or legal consequences, the question is whether a control sits before execution — a policy that refuses the action, or a requirement for human approval at defined thresholds. This is the general case covered under approving AI actions and approval checkpoints.
Can you reconstruct a single action six months later?
Application logs rotate. If the documentation of what an automated system did exists only in log files with thirty days' retention, it does not exist by the time it is asked for. Datatilsynet states the equivalent requirement for personal data plainly: log all uses of personal data by users, including reading, adding, searching, changing, extracting and deleting, with logging activated no later than when the IT system is put into operation. Retention is set by purpose and weighed against the data minimisation principle.
Who is responsible when the vendor operates the system?
Responsibility does not disappear on outsourcing. That holds where the supplier sits outside the EU as well: the requirements arrive by contract, whether or not the supplier is itself covered by the directive.
What are the incident reporting deadlines?
| Stage | Deadline |
|---|---|
| Early warning | Within 24 hours at the latest |
| Incident notification | Within 72 hours |
| Final report | No later than 1 month after the incident notification |
Providers of trust services are subject to a stricter 24-hour rule under § 13(2).
The deadlines have a practical consequence that is often missed: 24 hours is not long to establish what has happened. If an automated system has performed a series of actions and you cannot determine within the first day which of them were authorised, you notify on an uncertain basis. The quality of the early warning depends directly on how quickly you can reconstruct a sequence of events.
Where does the bogføringslov come in?
Companies that automate financial processes meet a parallel documentation requirement from an entirely different direction. The requirements for digital bookkeeping systems under the bogføringslov (Bookkeeping Act) mean that posted transactions cannot be changed, backdated or deleted; each entry receives a sequential transaction number, a registration date and initials for the user or program. Corrections are made by new entries, not by altering the old ones.
Two Danish technical terms are worth keeping apart, because translated material routinely merges them into the single English phrase audit trail:
- Transaktionsspor — transaction trail: the connection between the individual posted entries and the company's annual accounts.
- Kontrolspor — control trail: the information that documents the correctness of those entries.
The retention period is five years from the end of the financial year the material relates to. An automated system whose only documentation is application logs does not meet that requirement, however thorough the logging. The full treatment is in building an AI audit trail a Danish auditor will accept.
One clarification, because it is often misread and it belongs in every group e-invoicing roadmap: the Danish bookkeeping rules require the system to be able to send and receive e-invoices via Nemhandel (OIOUBL) and Peppol BIS. They do not require businesses to exchange e-invoices with each other. Denmark has no B2B e-invoicing mandate. Only B2G invoicing is compulsory.
How do you document a § 7 approval that survives an inspection?
- Fix the entity and its category — sector under Annex 1 or 2, and size. The category decides whether the ban on exercising management functions is available against an individual.
- Identify your sector authority. Supervision is sector-based, not central.
- Put the § 6 measures to the Danish management body as a decision item, not an information item.
- Minute the specific measures approved and the version approved, so a later inspection can tell what was in front of the body on the day.
- Minute the supervision arrangement — how implementation is overseen, and on what cadence.
- Record training by member and date. Individually, by name.
- Store all of it where log rotation cannot reach it and it can be produced years later.
Two further items belong on the same list even though they are not § 7 duties: map every automated process and integration that can take an action with business consequence, including AI agents and supplier integrations; and rehearse the 24-hour early warning to see whether you can establish the scope of an incident within the deadline.
What about the AI Act in Denmark?
Worth knowing if you are planning AI governance in a Danish context, because the contrast with the cyber regime is stark. Denmark adopted a supplementary act to the AI Regulation in May 2025 which came into force on 2 August 2025. It designates Digitaliseringsstyrelsen, Datatilsynet and Domstolsstyrelsen as national competent authorities — but only for the prohibited AI practices under Article 5. The complete framework bill, L 111, was tabled on 18 February 2026, reached first reading on 17 March 2026 and lapsed at the general election of 24 March 2026. As at 3 September 2026 it had not been reintroduced. Check it on ft.dk before relying on it; the detail is in AI Act supervision in Denmark.
In practice
BarzelVault applies policy and approval thresholds before an automated or AI-driven action executes and issues signed audit receipts recording the input data and the model and policy version. That is the record a management body needs in order to show what it approved and that the approved limits held.
Frequently asked questions
When did the Danish NIS 2-loven take effect?
1 July 2025. The Act was adopted on 29 April 2025 and signed on 6 May 2025. The EU transposition deadline was 17 October 2024, so Denmark was some eight and a half months late.
What is the difference between væsentlige and vigtige enheder?
Essential entities have at least 250 employees or turnover above EUR 50 million; important entities at least 50 employees or turnover above EUR 10 million. Only in relation to an essential entity may the supervisory authority temporarily prohibit an individual from exercising management functions.
Can the management body delegate the § 7 approval?
No. The provision places the approval with the ledelsesorgan, and the training duty is personal to its members. The practical work can be done by others, but the approval and the supervision cannot be moved — including to a parent board.
What are the incident reporting deadlines?
Three stages under § 13: early warning within 24 hours, incident notification within 72 hours, final report no later than one month after the incident notification. Trust service providers have a stricter 24-hour rule.
Does the NIS 2-loven reach our suppliers outside the EU?
Responsibility for supply chain security stays with the entity in scope. In practice you impose the requirements contractually and the supplier must be able to evidence compliance — including where the supplier is not itself covered, and including an intra-group shared service centre.
Is e-invoicing mandatory between Danish businesses?
No. The bookkeeping rules require the system to be capable of sending and receiving e-invoices via Nemhandel and Peppol BIS. They do not oblige businesses to use e-invoicing in B2B. Only invoicing to the public sector is mandatory.
Where this goes next
The core of § 7 is that someone must be able to stand behind what the company's systems are permitted to do. Where the systems act autonomously, that presupposes two things monitoring alone does not give you: a control that operates before the action executes, and documentation that can still be produced when somebody asks. Errors we have found and corrected in published material — including the claim that Denmark has a full national AI framework in force — are listed under corrections.
Related reading
- An AI audit trail a Danish auditor will accept
- AI Act supervision in Denmark: who oversees what
- Human in the loop: where a person still has to decide
- Governed workflow automation
- Glossary of Danish and EU terms
In practice
Contain the incident first, prove what happened second — inside the reporting window.
Reporting clocks run in hours, and management liability turns on whether controls were implemented and supervised, not merely approved. Barzel isolates credentials, cuts an agent off in one action and keeps signed receipts of what ran — the material a notification and a board report are written from.
In forceNIS 2-loven in force since 1 July 2025
BarzelVault
The AI action firewall: decide what an agent may do before it does it.
- Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
- Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
- Credential isolation, spend and action limits, and an emergency kill switch.
Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize
Barzel Central Gateway
The AI governance control plane: one inventory and one policy layer across every MCP server and agent.
- Registers and synchronises every tool; enforces identity, policy, region, cost and health per tool.
- Identity mapping through OIDC, Entra ID, Okta, SAML and SPIFFE, with credential brokerage.
- Trace and SIEM export (W3C trace context, OTLP) for the security team and the regulator.
Free tier: 1,000 calls a monthPaid plans from $10 a monthLive on MCPize
Enterprise: written quote by email within two business days. No sales call.
Sources
- Lov om foranstaltninger til sikring af et højt cybersikkerhedsniveau (NIS 2-loven), LOV nr 434 af 06/05/2025 — retsinformation.dk. In force 1 July 2025.
- Lov om bogføring (bogføringsloven), LOV nr 700 af 24/05/2022 — retsinformation.dk.
- Lov om supplerende bestemmelser til forordningen om kunstig intelligens, LOV nr 467 af 14/05/2025 — retsinformation.dk.
- Folketinget, bill L 111 (2025/1) — ft.dk. Lapsed at the general election of 24 March 2026.
- Regulation (EU) 2026/1744 (Digital Omnibus on AI) — in force 27 July 2026.
- Datatilsynet, Katalog over foranstaltninger: logning af brugernes anvendelser af personoplysninger.
- Erhvervsstyrelsen, Vejledning om bogføringsloven.
This article is for information and does not constitute legal advice. The Danish text of the instruments cited is the binding one. Position as at 3 September 2026.