Why is approval a statutory duty in Denmark and not a recommendation?
The NIS 2-loven, LOV nr 434 af 06/05/2025, came into force on 1 July 2025. Under § 7 the management body must approve the measures the entity takes under § 6 and supervise their implementation. Its members must in addition attend relevant training in the management of cybersecurity risks.
§ 32 gives the provision teeth: fines and criminal liability for legal persons under chapter 5 of the Danish Criminal Code — and in relation to væsentlige enheder (essential entities) the supervisory authority may temporarily prohibit an individual from exercising management functions. Supervision is sector-based, under Styrelsen for Samfundssikkerhed.
| 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 |
The consequence is straightforward. Once an agent can move money, change master data or delete records, the question of when a human has to be involved is not an architectural choice made by whoever built the integration. It is part of what management has signed for. The full framework is set out under the NIS 2-loven § 7 duty.
Which entity in a group is actually caught?
This is where a group reader has to be more careful than a domestic Danish filer, because three things sit differently.
The duty is addressed to the management body of the entity, not of the group. Section 7 speaks of the measures the entity takes and of its management body. A threshold policy written by a parent company in London, New York or Frankfurt is perfectly capable of being the measure that gets approved — but the act of approving it, the supervision of its implementation and the training obligation attach to the individuals sitting on the Danish company's board and direktion. A group minute recording that the global policy was adopted at group level is not the same document as a Danish board minute recording that this entity's management body approved these measures on this date under this version.
The supervisor follows the Danish entity's sector. Supervision is sector-based under Styrelsen for Samfundssikkerhed, so which authority asks the questions is determined by what the Danish entity does, not by what the group is classified as elsewhere in Europe. Two entities in the same group can end up in front of different Danish sector authorities.
Whether size is measured on the entity or on the group is a question for Danish advice. The categories above are stated in employee and turnover terms; how they are applied to a Danish subsidiary of a large foreign group is not settled by the figures on their face, and it is worth getting a Danish answer rather than assuming the group number. In practice the size test is the less interesting half of the problem: once the entity is in scope at all, § 7 attaches to its own management body, and that is the part that has to be built into the approval design.
Why does an amount threshold alone miss what goes wrong?
Because most of the actions that do damage look normal on the amount. Four dimensions are needed, and each catches a different failure.
Amount — set from the distribution, not from instinct
Extract twelve months of actual action values and look at the distribution. Place the threshold so that a few per cent of actions fall above it, and so that those few per cent account for the bulk of the total value. The queue then stays workable while the exposure above the line is still most of what is at stake. A figure chosen on intuition either holds everything back or holds nothing back — and you find out which only in production.
Counterparty — what the amount does not reveal
New counterparties, changed bank details, unfamiliar jurisdictions. These cases slip past an amount threshold precisely because the amounts look normal. A payment of DKK 4,000 to a supplier you have paid for six years and a payment of DKK 4,000 to a counterparty whose account details changed yesterday are not the same animal.
Operation type — the least exercised code paths
Corrections, credits, deletions and permission changes belong on the list regardless of amount. Rare operations are the worst-tested paths, both in the agent and in the receiving system. The bogføringslov points the same way: posted transactions must not be capable of being changed, backdated or deleted, and corrections are made by new entries. A correction is therefore itself an entry that somebody has to stand behind, and the material has to be kept for five years from the end of the financial year it relates to.
Behaviour — the only dimension that catches the failure in flight
Rate deviations. Forty actions in ten minutes, from an agent that normally takes four an hour, exposes a malformed input dozens of actions before an amount threshold would react — precisely because each individual action sits below the line. The other three dimensions assess the individual action. This one assesses the series.
What should happen when a threshold fires?
| Response level | What happens | When it fits |
|---|---|---|
| Let through and record | The action executes. The trail is written before execution. | Routine actions inside all four dimensions. |
| Let through and flag | The action executes but is marked for later review or raises a notification. | Deviations with low individual consequence — and everything you want to see but not stop. |
| Hold for approval | The action does not execute until a named person has decided. | High value, new counterparty, changed bank details, deletions and permission changes. |
The middle level is what makes the design survive operations. Without it every deviation lands in the hold queue. The queue grows, approvers clear it in batches, and the control stops working while continuing to exist on paper. That state is worse than no control. It manufactures documentation of approvals that contained no assessment — and that documentation is later read as though they did.
What must the approver actually see?
A dialogue box with a tool name and a block of JSON does not produce an informed decision. Five fields have to be recorded for every approval:
- Who approved — a named person, not a role and not a service account.
- What that person was shown at the moment of the decision.
- When.
- Which policy version caused the hold.
- The decision, with any reason given.
The second field is the decisive one. Approved at 14.32 says nothing. Approved at 14.32, having seen these five fields is evidence. It is the same logic as the Danish audit-trail requirements: the basis of a decision has to be stored while the decision is being taken, because it cannot be recreated afterwards.
Two group-specific traps sit in this list. The first is that a shared identity fails the first field. If approvals arrive under a group service account, a shared functional mailbox or an SSO group rather than a person, the record satisfies the system and not the requirement. The second is time zones. A hold queue that is only cleared during working hours in the parent's time zone will be cleared at three in the morning Copenhagen time by whoever is awake — which is how a named approver quietly becomes whoever holds the on-call phone. Decide who the Danish approvers are and how long a hold may sit before it escalates, and write both into the policy.
Where should the threshold be enforced?
Outside the agent. If the model itself decides whether its action requires approval, then anything that reaches its context can move the threshold — including content the agent reads along the way. An instruction inside a document, an email or an API response thereby becomes a potential change to the control.
Enforcement has to sit in a layer the agent passes through and cannot reconfigure. That has a practical dividend: the threshold survives a change of model. Swap the model and the policy does not have to be set up again. The general form of this argument, without the Danish statute, is under approving AI actions before execution and human in the loop.
How do you set a threshold that survives production?
- Extract twelve months of actual action values — the real numbers, not an estimate.
- Set the amount threshold from the distribution, so that a few per cent of actions carry most of the value.
- Define the counterparty rules: new counterparties, changed bank details, unfamiliar jurisdictions, regardless of amount.
- List the operation types explicitly: corrections, credits, deletions, permission changes.
- Set a normal action rate and a limit on deviation from it.
- Assign each rule to one of the three response levels, and make sure the middle one is populated.
- Fix the approver view, and record that view alongside the decision.
- Move enforcement into a layer the agent cannot reconfigure.
- Have the Danish entity's management body adopt the policy, with a version number and a date.
How does Denmark compare with the UK, Switzerland, California and Colorado?
Four other jurisdictions ask what is in substance the same question in four different vocabularies.
| Jurisdiction | The test | From |
|---|---|---|
| Denmark | The management body must approve the measures and supervise implementation (NIS 2-loven § 7). | 1 July 2025 |
| United Kingdom | UK GDPR Article 22A (Data (Use and Access) Act 2025, s. 80): meaningful human involvement. Where the involvement is real, the rules do not apply at all. | 5 February 2026 |
| Switzerland | DSG Article 21: a right to review by a natural person. The contract exception applies only where the data subject's request is granted. | In force |
| California | The CPPA's ADMT rules bite on technology that replaces or substantially replaces human decision-making. Rights: prior notice, opt-out, access to the logic, and a route to complain. | 1 January 2027 |
| Colorado | SB 26-189: real human review, prior notice, and notice of an adverse outcome within 30 days. | 1 January 2027 |
Denmark stands apart on one point, and it is the point that changes how a group has to build. The other frameworks express the requirement as a right belonging to the data subject. The Danish provision places the duty on the management body. It is not triggered by anyone exercising a right, and it exists independently of whether personal data is being processed at all. A group that has built its approval controls to answer Article 22A or the CPPA rules has built something that switches on when a person objects. Section 7 is already on.
Note at the same time that the deferral in Regulation (EU) 2026/1744, the Digital Omnibus on AI, in force 27 July 2026, is not a reason to wait. The high-risk obligations were deferred to 2 December 2027 (Annex III) and 2 August 2028 (Annex I), but the transparency obligations were not deferred — they have applied since 2 August 2026. And § 7 applies already. Where Danish AI Act supervision itself has got to is covered under AI Act supervision in Denmark.
What has to be maintained after go-live?
Thresholds are configuration with a change history, not constants in code. A limit that exists only in a source file can neither be adjusted by the person accountable for it nor evidenced to a supervisor. For a group this is also the difference between one policy with per-entity values and a hard-coded number that quietly differs in every country.
Build a documented emergency route. Otherwise one gets improvised at month-end — typically by someone switching the control off temporarily, and just as typically without switching it back on.
Review the hold rate monthly. A rising rate means one of two things: the threshold is set wrongly, or the agent's behaviour has shifted. Both are things you need to know, and the second is the one that does not announce itself. The same review is the natural place to check the queue-clearing pattern, because batch approvals show up in the timestamps long before anyone reports them.
In practice
BarzelVault applies policy and approval thresholds in a layer ahead of execution that the agent passes through and cannot reconfigure, and issues a signed audit receipt for each decision. The record covers which policy version caused the hold, who decided and what they were shown.
Frequently asked questions
Why is an amount threshold on its own not enough?
Because most harmful actions look normal on the amount. A payment to a counterparty whose bank details changed yesterday sits below any sensible limit. The threshold needs four dimensions: amount, counterparty, operation type and behaviour.
How do you set the amount threshold correctly?
From the distribution of twelve months of actual action values. Place it so that a few per cent of actions fall above the line and account for the bulk of the total value. A figure chosen on instinct holds back either everything or nothing.
Why are two response levels not enough?
Because every deviation then lands in the hold queue. The queue grows, approvers clear it in batches, and the control stops working while still existing on paper — which is worse than no control, because it produces approvals without assessment.
What has to be recorded when an action is approved?
Who approved as a named person, what they were shown, when, which policy version caused the hold, and the decision with any reason. The field recording what was shown is what separates a durable approval from a click.
Can the agent decide for itself when to ask for approval?
No. Anything reaching the agent's context — including what it reads — could then move the threshold. Enforcement has to sit in a layer the agent passes through and cannot reconfigure.
Does a group-level approval policy satisfy § 7?
Not on its own. The parent's policy can be the measure that is approved, but the approval, the supervision and the training attach to the Danish entity's own management body. Record the local adoption with a version and a date.
Related reading
- NIS 2-loven § 7: the management body's personal duty
- AI audit trails in Denmark: three requirements, not one
- AI Act supervision in Denmark: who oversees what
- Denmark's digital bookkeeping system requirements
- Approving AI actions before execution — the general case
- Human in the loop: when a person has to be involved
- Approval checkpoints in automated workflows
- Glossary of Danish and EU terms
- Corrections
In practice
Permission before the action. Evidence after it.
The duties on this page attach to the moment an automated system acts: who permitted it, on which data, under which policy version, and what a person saw before approving. Barzel enforces that decision before execution and writes the record an auditor, a regulator or a data subject can be shown.
430 days leftEU AI Act high-risk obligations (Annex III) apply from 2 December 2027
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.
- Lov om bogføring (bogføringsloven), LOV nr 700 af 24/05/2022 — retsinformation.dk.
- Datatilsynet, Katalog over foranstaltninger: logning af brugernes anvendelser af personoplysninger.
- Regulation (EU) 2026/1744 (Digital Omnibus on AI) — in force 27 July 2026.
- Digitaliseringsstyrelsen, Tilsyn med AI-forordningen.
- UK Data (Use and Access) Act 2025, s. 80 — UK GDPR Article 22A, in force 5 February 2026.
- Switzerland, Bundesgesetz über den Datenschutz (DSG), Article 21. Left unlinked: the Fedlex page could not be retrieved for verification.
- California Privacy Protection Agency, CCPA updates and ADMT regulations — obligations from 1 January 2027.
- Colorado SB 26-189, Automated Decision-Making Technology — in force 1 January 2027.
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.