NIS2 in practice: 6,000 Danish companies are affected, only 16% are ready

The NIS2 Act entered into force in Denmark on July 1, 2025, with a registration deadline of October 1, 2025, via Vi. The law increases the number of covered Danish organizations sixfold compared to the previous NIS1 directive, from approximately 1,000 to around 6,000. Nevertheless, only 16% of organizations feel fully prepared, and 11% remain uncertain about what NIS2 actually requires of them.

This is not because the requirements are unclear. It is because they presume something most organizations do not possess: an updated overview of their own systems, processes, and suppliers, interconnected in a manner that can be documented and maintained.

This article is the first part of a series on the common foundation underlying NIS2, DORA/PCI DSS, and the AI Act. NIS2 has the broadest impact, covering approximately 15 sectors, and is therefore the natural starting point. The foundation we build here is directly reused in the next two articles in the series.

What NIS2 Requires, in Brief

The law mandates ten specific risk management measures under Article 21, including risk analysis, incident handling, business continuity, supply chain security, and access control. Upon detecting a significant security incident, organizations must submit an early warning within 24 hours, an intermediate notification within 72 hours, and a final report within one month. The board of directors and executive management must formally approve the measures and undergo cybersecurity training, and non-compliance can result in administrative fines of up to 10 million euros or 2% of the global annual turnover for essential entities.

Why It Is Difficult in Practice

The requirement for supply chain security is typically where organizations encounter difficulties. It demands not just a list of suppliers, but an overview of which suppliers support which critical processes, what data they have access to, and where the vulnerabilities lie within that chain. In most organizations, these answers are scattered across a CMDB, various spreadsheets, a procurement department, and an IT department that rarely align on the same picture. Vendor agreements are established in one area, operational responsibility resides in another, and no one is tasked with maintaining the link between the two when a supplier changes, a contract is renewed, or an employee departs.

Without mapping the connections between business processes, systems, and suppliers, it is impossible to document whether risk management measures actually cover critical areas. This is the exact same exercise that underpins DORA's register of information and communication technology (ICT) third-party service providers, PCI DSS's third-party management requirements, and the AI Act's requirements for AI systems linked to data and suppliers. Different names, same fundamental gap.

How Clariox Helps

We do not map suppliers in isolation from the rest of the IT landscape. We construct a dynamic model in Ardoq, where business capabilities, applications, ownership, and suppliers are interconnected in a single repository and updated as the organization evolves, rather than being manually refreshed every time a regulatory authority or audit inquires. This process is executed in three stages:

Phase 1: Application and Capability Mapping

We recommend starting with the applications, the business capabilities they support, and the ownership of each component—establishing the foundational links between IT and the business—before evaluating suppliers. The outcome is a reference architecture that can be reused the next time regulators, auditors, or new colleagues ask what is critical and who is responsible. Today, these answers are typically scattered across CMDBs, spreadsheets, and meetings that must be reconstituted every time. Once this landscape is mapped and maintained, the effort applies to all regulations simultaneously, rather than starting from scratch each time.

Phase 2: Supplier and System Mapping via API Integrations and Ardoq Surveys

With capabilities, applications, and ownership established, direct suppliers and service providers are mapped and linked to the processes and systems they support. The majority of this work does not need to be manual. API integrations retrieve contract data and security postures directly from existing procurement systems and supplier registries, eliminating the need for manual spreadsheet collection. Where data is missing, an Ardoq Survey automatically sends targeted questions to the supplier relationship owner, with responses flowing directly into the model without manual data entry. This is the core of Article 21's supply chain security requirements.

Phase 3: Documentation and Incident Response Readiness

Data is structured to document risk management measures for regulatory authorities, ensuring incident reporting within 24 hours, 72 hours, and one month can be executed swiftly because the overview is already established. Because the mapping is maintained by the same API integrations and surveys, the model updates automatically when a supplier changes or a system is modified, rather than requiring manual recreation when an audit occurs.

If your organization also interacts with the financial sector or develops and uses AI, the foundation detailed above is reusable for both DORA/PCI DSS and the AI Act. The next two articles in the series will explore how.

Are you part of the 6,000, but not part of the 16%?

📅 Book a non-committal consultation at clariox.dk/contact

Clariox Advisory is an independent IT advisory firm and Ardoq partner, and the only Ardoq-focused partner in Denmark. This article is for informational purposes and does not constitute legal or regulatory advice.

Figures and dates in this article originate from the Danish Agency for National Security and Emergency Management (SAMSIK) and an analysis of NIS2 readiness in Denmark conducted by Shattered.io.