If your company has an integration, a support login or a recurring data feed into customers' systems, you hold lawful access into them, and your suppliers may hold lawful access into yours. CPR is Denmark's Central Person Register, the national civil registration system, and a CPR number is the Danish personal identification number. On 5 October the CPR administration said someone had misused a Danish company's lawful access to the register, and that data on about 8.8 million people registered in the CPR system was affected, including names, addresses and CPR numbers. According to the ministry, a very large invoiced amount drew attention to the activity. I was not involved in the case.

I have been on the other side myself and found a supplier with standing access into our systems, where we could show neither a review of that access nor any comparison of its usage with normal. The details are changed. So who at your company gets the alert before the invoice?

Was the CPR register hacked?

No. The public sources do not say that the CPR system itself was compromised. The CPR administration's notice of 5 October said that a Danish company's lawful access had been misused, that the company's access had been stopped, and that the police were investigating. The Danish Data Protection Agency said the same day that it had received the notification on 4 October. A department head at the ministry mentioned the invoice at the press briefing on 6 October, according to the Danish news agency Ritzau. That is what has been confirmed publicly, and I take no position on what the company did or did not do.

There is a fair debate about what the register itself should have caught, for example with a cap on the number of lookups. But your company cannot settle that debate. The part a company controls is its own side of the access: who may use it, what normal usage looks like, and who notices when usage is no longer normal. You control that side in both directions.

Evidence after the fact is not control in the moment

CPR's standard terms for data deliveries to private parties, dated 16 June 2026 and so in place before the leak, require in section 4, for system-to-system solutions, that the customer appoints a security officer, who keeps a register of authorised staff with start and end dates, and that every lookup is logged to the individual employee. The customer must also produce a monthly transaction statistic that the security officer has to check, and which the terms describe as a statistic to be used in cases where misuse is suspected. CPRWeb has its own terms, and public sources do not establish which access channel was misused.

After the leak, a formal reminder of the security rules was sent to 1,039 companies with access to the register. According to Ritzau, the letter listed among other things a security officer, ongoing control of employees' access and following the monthly transaction counts. The letter restated rules that already applied.

You can show a register and a monthly statistic afterwards, but neither is an alarm that reaches a person in time. A monthly statistic is a look back. Leadership's job is to make sure someone gets a signal while it is happening.

If you are in scope of the Danish NIS2 Act, management has specific duties under that Act. Outside NIS2, GDPR, sector rules and contracts may still impose duties; the exact position depends on the access and data involved. For management the question is simpler: which access paths lack an owner, a limit for normal use, or a named person who gets the alert?

Three things I would check this week

  1. Map the access paths. There are two directions, and one is the access you grant: suppliers, integrations, service accounts and former staff whose access was never closed. The other is the access you hold into your customers. Every path needs one accountable owner and an approved group of users and systems. The supplier I mentioned above had exactly such a path: standing access with no review we could show and no comparison with normal use.
  2. Define normal use and alert thresholds. For each path, write down what normal usage looks like and who gets an alert at which threshold. It can be lookups per day, data volume or time of day, but the alert has to reach a named person before finance sees a bill. At CPR it was the bill for the lookups that made someone react. At your company it might be a supplier invoice, a customer on the phone, or nothing at all. For each access, also write down the signal, who receives it, the response deadline and the first action, including who can suspend the access. Ask the supplier with access into your systems the same question, and expect your customers to ask it of you. Whether the supplier's incident is also yours is a separate question, and I have written earlier about who may declare a supplier incident your own.
  3. Stop using known details as proof of identity. If support or finance accepts a CPR number or other details a fraudster may know, the procedure has to change, because as DI Digital at the Confederation of Danish Industry put it, a CPR number identifies but proves nothing.

The same ownership question applies to customer-facing AI features you provide yourselves: Article 50 of the EU AI Act generally requires that users are told they are interacting with AI (unless that is obvious) and that synthetic output is marked in a machine-readable format, and for generative systems placed on the market before 2 August 2026, providers must under Regulation (EU) 2026/1744 take the necessary steps to comply with that marking duty by 2 December 2026. Who owns that at your company is a leadership decision, and I have written about who owns AI governance.

Management keeps the register. The board sees the exceptions.

The register has one row per system, supplier connection or access path to customer data, and a separate row for each customer-facing AI feature. Each access path has an accountable owner, the approved group, normal usage, who gets the alert, and when the path was last reviewed, while the row for an AI feature shows its owner and the status of the Article 50 requirements.

In PwC's Cybercrime Survey 2026of 326 top executives, security heads and specialists in Denmark, 84 percent have cyber security as a fixed item in the board's annual cycle, but only 37 percent address cyber risks at least once a quarter. The board gets a regular overview and the material exceptions: paths where nobody gets the alert, reviews that are overdue, and the decisions the board has to take itself. When a leadership team fills in the register for the first time, in my experience the column left empty is often the one for who gets the alert. Fill that one in first.

A name in a register is documentation. An alert that reaches that name before the invoice is control.