An organisation can have access controls, authorised users and contractual safeguards in place and still suffer a serious security failure. Denmark's recent CPR incident shows why.

According to the Danish authorities, for about ten days in September 2026 unauthorised parties used a small private Danish company's legitimate access to the national Central Person Register (CPR) to retrieve records. On 5 October the Danish authorities disclosed that the activity reached about 8.8 million living and deceased people, a provisional figure, and that the data included names, addresses and CPR numbers (The Irish Times, The Copenhagen Post). The same reports put the number of lookups at more than 14 million. Denmark's Digitalisation Minister, Christina Egelund, was reported as saying that the security around the company's access had been inadequate. How the unauthorised parties gained use of the company's access had not been made public at the time of writing.

On what has been reported, the activity ran through access the company legitimately held, rather than through a permission granted in error. According to press reports, the scale of the activity came to light through billing: companies pay per lookup, and the activity surfaced when the CPR administration billed the company for its searches.

That distinction matters.

Access legitimacy is not access safety

Traditional access governance often asks a narrow question: is this person, supplier or system authorised to access the data?

That remains necessary. It is no longer sufficient. The more important operational question is whether the way authorised access is being exercised is still consistent with the purpose, volume, frequency, geography and behaviour the organisation expects.

The Danish incident shows why the two questions must be kept apart. A supplier may be legitimately connected to a system. Its credentials may be valid. The contract may still be in force. The account may pass authentication. And the resulting activity may still be entirely abnormal. An organisation can remain formally aligned with its own access-governance model while the actual use of that access has become unsafe.

From access control to access behaviour

For organisations that manage sensitive datasets, third-party access governance therefore has to extend beyond provisioning and authentication. Five control questions matter.

  • What is the expected access pattern? A provider that ordinarily performs hundreds of lookups should not be able to perform millions without attracting attention.
  • What activity should trigger intervention? Volume, frequency, unusual query patterns, geography, time of access and changes in behaviour may all be relevant, depending on the system.
  • How quickly can access be revoked? The measure is not whether revocation exists, but how long it takes to become effective across credentials, sessions, APIs and delegated access.
  • What happens to activity already in flight? If searches, API calls or queued actions continue after access is withdrawn, nominal revocation may not contain anything.
  • Who watches the relationship after access is granted? Third-party due diligence is often concentrated at onboarding and contract review. The risk continues for the life of the relationship.

The real control question is effectiveness

Organisations often record whether a control exists. They may record that access is role-based, that authentication is required, that suppliers are assessed, that logging is enabled, that contractual restrictions apply and that termination rights exist.

Those statements describe control existence. They do not necessarily describe control effectiveness. A control can exist and still fail in operation. The better governance question is whether the control remains effective under the conditions in which the system actually operates.

For access governance, that means thinking in terms of detection latency, containment latency, revocation completeness, behavioural monitoring and failure-domain isolation. A supplier account that can be disabled eventually is not the same thing as an access path that can be contained before serious harm accumulates.

The consequences continue after the access is closed

According to the same reports, the CPR administration has cut off the company's access and the matter has been reported to Datatilsynet, the Danish data protection authority. The risk does not end there. Names, addresses and identification numbers can make phishing and impersonation considerably more convincing, and the authorities were reported to have warned the public accordingly. The Copenhagen Post reported that nearly one million people added credit warnings in the days after disclosure (The Copenhagen Post).

The minister was also reported to have asked for a security review of the CPR system as a whole. That response is significant. After an incident the question is not only which control failed. It is also whether the control architecture was adequate for the kind of access being permitted.

What organisations should take from this

Third-party access governance is an operating model, not only a contractual one. Access to important systems should be continuously understood in terms of:

  • who has access, and why;
  • which systems and datasets are reachable;
  • what normal behaviour looks like, and what thresholds trigger investigation;
  • how fast access can be suspended, and whether revocation reaches credentials, sessions and queued actions;
  • whether suppliers themselves monitor anomalous use of the access they hold;
  • and what evidence shows that these controls still operate.

For organisations subject to several regimes, these questions sit across cybersecurity, data protection, operational resilience and third-party risk at the same time. That is why they should not be managed as isolated checklists. They should be traceable from the applicable requirement to the control, from the control to the evidence, and from the evidence to whether the control is working as intended.

A compliance record should tell you more than whether a safeguard was documented. It should tell you whether the safeguard still works when it matters.

This is the first of two articles on control effectiveness. The second looks at the same question for AI agents: When an AI Agent Reaches Data It Was Not Meant To.

How Priventia helps

Priventia connects the regulatory obligations that apply to an organisation to the controls that carry them and the evidence that shows they operated. The Controls Library links controls, including role-based access and third-party governance controls, to the legal obligations they support, with an owner and status recorded for each. For third-party access, that means the organisation's expected-use thresholds, intervention triggers and revocation steps can be documented against those controls and traced to the provisions that require them. Priventia does not watch access traffic itself: the access logs stay in the systems that produce them, and Priventia governs what they must show.