DORA and PCI DSS require the same: a mapped IT landscape
In 2024, 93.5% of financial institutions failed the EBA's dry run for the DORA Register of Information. Simultaneously, PCI DSS 4.0.1 is now fully enforced. The final requirements came into effect on March 31, 2025, and auditors are still identifying the same deficiencies.
This is no coincidence. The two regulations essentially pose the same question: Can you continuously and accurately document which systems, data, and suppliers support critical business operations? Most organizations cannot answer this, and the underlying cause remains identical, regardless of the regulation in question.
This article is the second installment in a series examining the shared foundation of NIS2, DORA/PCI DSS, and the AI Act. If you have already read the article on NIS2, a significant portion of the foundation detailed below has already been established.
What the Two Regulations Require, in Brief
DORA mandates a register of all ICT third-party service providers, classified by their level of criticality to the business. PCI DSS requires a corresponding scope document for everything that touches cardholder data, as well as an inventory of service providers with access to it. While this may sound like a documentation exercise, in practice, it is an exercise in knowing what assets you have and who is accountable for them. And this is precisely where most organizations fall short.
Why Implementation is Challenging in Practice
The obstacle is rarely a lack of commitment. Rather, the challenge lies in the fact that the answers to what assets exist and who owns them are not centralized. IT is familiar with the systems but not always the specific business processes they support. Procurement manages the contracts but may not understand how critical those suppliers actually are to daily operations. The business units know what is critical but rarely which underlying systems and suppliers support them. None of these three functions are tasked with maintaining a unified, updated overview, and when a key employee leaves, a portion of that institutional knowledge departs with them.
Simultaneously, the data itself is fragmented across a CMDB, various spreadsheets, a contract database, and outdated slides from the last audit. Consolidating this into a single document becomes a manual task. It is typically initiated as deadlines loom and becomes obsolete within months of submission.
💡 The same fundamental questions recur in both regulations. Which systems and suppliers support a critical function? Where does the data reside? And is that information up to date, or was it merely prepared for the last audit? |
Same Pattern, Two Regulations
Comparing the most frequent errors from the EBA's DORA dry run with the most common findings in PCI DSS audits reveals a clear, recurring pattern:
DORA Register of Information | PCI DSS 4.0.1 | Shared Gap |
CIF classification of critical functions | Scope of Cardholder Data Environment (Requirement 12.5.2) | Without mapped capabilities, both processes rely on guesswork |
Supplier and subcontractor supply chain | Third-party management (Requirement 12.8) | No systematic mapping of the supply chain |
Geographical data location | Data flow and storage mapping (Requirements 3, 4, and 12.5.2) | Unknown where data is actually processed and stored |
Continuous updates | Annual scope review and change management | Static documentation, obsolete before the next audit |
The Status of the Danish Market
Danmarks Nationalbank closely monitors the resilience of the financial sector, and the indicators suggest growing vulnerability. In the latest survey, based on responses from 19 key market participants, the proportion of banks experiencing cyberattacks that led to significant incidents rose from 25% in the first half of 2024 to 35% in the second half of 2024:
Several key players lack viable exit strategies—meaning a realistic path to transition to alternative suppliers—which is particularly challenging when trying to avoid dependency on suppliers from a single geographical region.
Business continuity and contingency plans are not always robust enough to ensure operations during extreme scenarios.
FSOR, the Financial Sector Forum under Nationalbanken, has identified 29 risks spanning cyberattacks, data protection, and business continuity.
Many Danish organizations struggled to meet the March 31, 2025, deadline for Register of Information reporting.
In August 2025, a telecommunications provider serving the pan-European payment infrastructure TARGET Services was hit by a ransomware attack. While it did not disrupt actual settlement operations, it serves as a concrete example of the supply chain risks that DORA’s register is designed to expose.
💡 The fundamental issue is not a lack of regulation. Rather, it is that none of the 19 major players possess the mapped foundation required to verify whether their controls actually protect what is business-critical. |
How Clariox Delivers Value
We do not address this challenge with another one-off document destined to become obsolete by the next audit. Instead, we build a dynamic, living architecture in Ardoq, where capabilities, applications, ownership, suppliers, and data are interconnected and updated automatically as the organization evolves. This single source of truth is leveraged for both registers, preventing DORA and PCI DSS from being managed as separate, diverging lists. This is achieved in three phases:
Phase 1: Application and Capability Mapping
Just as we establish the foundation for NIS2 compliance, our approach for DORA and PCI DSS begins by mapping applications, the business capabilities they support, and their respective owners. Securing these fundamental links between IT and the business is critical before addressing supplier management. We detail this methodology in our article on NIS2. If this architecture is already defined and maintained, it can be imported directly into DORA’s CIF classification and the PCI DSS CDE scope, eliminating redundant efforts.
Phase 2: Supplier and Data Mapping via API Integrations and Ardoq Surveys
With capabilities and applications mapped, ICT services, direct suppliers, subcontractors, and data flows are integrated into the foundation. The majority of this integration is automated. API connectors extract data directly from existing systems—such as CMDBs, procurement systems, cloud tenants, and contract databases—obviating the need for manual spreadsheet exports. Where data gaps exist in existing systems, Ardoq Surveys are automatically routed to the relevant process or supplier owner with targeted questions. The responses populate directly into the model, removing administrative intermediaries. This efficiently addresses both DORA's supply chain requirements and PCI DSS' third-party and data-flow compliance mandates.
Phase 3: Structuring and Continuous Updates
Data is structured to align precisely with the EBA format for the Register of Information and the specific documentation required by QSAs or auditors for PCI DSS. Because this mapping is integrated with APIs and automated surveys, both reports update dynamically as systems, suppliers, or contracts change, rather than requiring manual reconstruction before audit deadlines.
💡 Operational Benefit: This identical map can be leveraged for NIS2 supply chain management and AI Act documentation. Additionally, it provides a solid foundation for commercial contract optimization, typically reducing IT overhead costs by 15% to 30%. |
Ready to Unify Your Compliance Foundation?
📅 Schedule a introductory consultation at clariox.dk/contact
Clariox Advisory is an independent IT advisory firm and Ardoq partner, serving as the only Ardoq-focused partner in Denmark. This article is for informational purposes and does not constitute legal or regulatory advice.
Danish market data referenced in this article is sourced from Danmarks Nationalbank, including the 'Oversight of the financial infrastructure 2025' report, as well as FSOR (Financial Sector Forum) and the Danish FSA.
Troels Rendbæk Sørensen - CEO & Founder