European organisations now face three overlapping regulatory frameworks — GDPR (enforceable since 2018), NIS2 (transposition ongoing, with obligations enforceable in most Member States), and DORA (fully applicable since 17 January 2025). Each carries its own risk management, incident reporting, and governance requirements. Each has its own supervisory authority. Each can impose significant penalties independently.

The conventional approach — treating each as a separate compliance project with its own consultant, its own documentation, and its own audit trail — is expensive, duplicative, and increasingly untenable. Organisations that run three parallel programmes will spend roughly three times the effort to achieve outcomes that overlap by 60–70%. More critically, the siloed approach creates gaps: inconsistent risk assessments, conflicting incident response procedures, and governance structures that satisfy the letter of one regulation while violating the spirit of another.

This guide explains how to design cloud architecture and governance that satisfies all three simultaneously, using an integrated approach rather than parallel checklists. The target audience is organisations operating in regulated European sectors — particularly financial services, where all three frameworks apply concurrently — but the architecture principles are relevant to any entity caught in the overlap.

Where the Three Frameworks Overlap

Before designing an integrated architecture, you need to understand precisely where GDPR, NIS2, and DORA converge. The overlap is more substantial than most compliance teams recognise, and it is growing as regulators coordinate their expectations.

Incident Reporting — The Most Visible Overlap

Incident reporting is where the regulatory collision becomes most tangible. A single ransomware attack at a financial institution can trigger all three reporting obligations simultaneously, each with different timelines, different recipients, and different content requirements:

• GDPR: Personal data breach notification to the relevant Data Protection Authority within 72 hours of becoming aware of the breach. Notification to affected data subjects "without undue delay" where the breach poses high risk. The proposed Digital Fairness Omnibus Directive would extend the DPA notification window to 96 hours and add CSIRT notification, but this remains in legislative process as of early 2026.
• NIS2: Significant incident reporting to the designated CSIRT or competent authority — 24-hour early warning, 72-hour incident notification with initial assessment, and a final report within one month. "Significant" means substantial operational disruption or financial loss, or the incident has affected or could affect other entities.
• DORA: Major ICT-related incident reporting to the relevant financial supervisor — initial notification within 4 hours of classification, initial report within 24 hours, intermediate report within 72 hours, and final report within one month. Classification criteria are defined in the RTS on incident classification (severity, duration, geographical spread, data losses, criticality of services affected).

The critical nuance: DORA takes precedence over NIS2 for financial entities under the lex specialis principle — Article 4 of NIS2 explicitly defers to sector-specific legislation that imposes at least equivalent cybersecurity obligations. But GDPR runs in parallel regardless. A financial institution experiencing a ransomware attack that encrypts client data must file DORA reports to its financial regulator and GDPR notifications to the DPA. These are not interchangeable. The DORA report focuses on operational impact and ICT risk; the GDPR notification focuses on personal data compromise and data subject rights.

The practical implication for architecture: your monitoring and detection systems must be capable of classifying incidents against all three frameworks' criteria within hours, not days. A SIEM alert that takes 48 hours to triage will blow your DORA 4-hour classification window before anyone has opened a laptop.

Risk Management — Documented, Systematic, and Continuous

All three frameworks require documented, systematic risk management. The approaches are complementary, but the level of prescriptiveness varies significantly:

• GDPR Article 32: Requires "appropriate technical and organisational measures" based on the state of the art, implementation costs, nature/scope/context/purposes of processing, and risk to data subjects. Data Protection Impact Assessments (DPIAs) for high-risk processing. Relatively principles-based — the regulation tells you what to achieve, not how.
• NIS2 Article 21: Specifies ten categories of cybersecurity risk management measures: incident handling, business continuity, supply chain security, network and information systems security, policies on cryptography and encryption, human resources security, access control, asset management, multi-factor authentication, and secure communications. More prescriptive than GDPR but still allows proportional implementation.
• DORA Articles 6–16: The most prescriptive of the three. Requires a comprehensive ICT risk management framework with explicit components: identification of ICT assets and risks, protection and prevention measures, detection capabilities, response and recovery procedures, and learning and evolving processes. Includes specific requirements for ICT change management, patching, data integrity testing, and resilience testing.

The core overlap across all three: a risk-based approach, documented policies and procedures, regular testing of those measures, and continuous improvement based on findings. An organisation that builds a mature risk management programme aligned to DORA's prescriptive requirements will, by definition, satisfy the less prescriptive GDPR and NIS2 risk management obligations — provided the scope explicitly includes personal data processing (GDPR) and network and information system security (NIS2).

Governance and Board Responsibility

This is where the convergence is strongest — and where many organisations are furthest behind.

• GDPR: Requires appointment of a Data Protection Officer (where applicable), establishes controller accountability, and mandates demonstrable compliance ("accountability principle"). Governance requirements exist but are primarily focused on data protection.
• NIS2 Article 20: Management bodies of essential and important entities must approve cybersecurity risk management measures, oversee their implementation, and can be held personally liable for infringements. Management must undergo regular cybersecurity training. This is not a suggestion — it is a legal obligation with personal consequences.
• DORA Article 5: The management body has "ultimate responsibility" for the ICT risk management framework. Must define, approve, oversee, and be accountable for the implementation of the ICT risk management framework. Must ensure adequate budget allocation and approve the digital operational resilience strategy.

Both NIS2 and DORA explicitly make cybersecurity a board-level accountability obligation with personal liability provisions. This transforms cybersecurity from an IT department concern to a governance requirement on par with financial reporting. Boards that delegate cybersecurity to a CISO without active oversight are no longer merely negligent — they are potentially non-compliant with two separate European regulations.

Supply Chain and Third-Party Risk

Third-party risk management requirements escalate sharply from GDPR to NIS2 to DORA:

• GDPR Article 28: Processor agreements with specified contractual terms, sub-processor due diligence and authorisation, data processing records. Focused on personal data flows.
• NIS2 Article 21: Supply chain security including security-related aspects of relationships between entities and their direct suppliers or service providers. Broader scope than GDPR but less prescriptive than DORA.
• DORA Articles 28–30: By far the most prescriptive. Requires a Register of Information (RoI) for all ICT third-party arrangements, concentration risk assessments, mandatory contractual minimum provisions (including audit rights, exit strategies, data location requirements, and security obligations), notification to regulators before contracting with critical ICT third-party providers, and documented exit strategies for every critical arrangement.

For financial entities, DORA's third-party requirements effectively subsume GDPR and NIS2 supply chain obligations — but only for ICT third parties. Non-ICT suppliers (facilities management, physical security, professional services) still fall under NIS2's broader supply chain assessment requirement.

The Integration Strategy

Understanding the overlap is necessary but insufficient. What follows is a practical integration methodology that produces one compliance programme satisfying three frameworks.

Step 1 — Anchor on ISO 27001

ISO 27001:2022 covers approximately 80% of NIS2's Article 21 requirements and provides significant coverage of DORA's ICT risk management framework. It is the most efficient structural foundation for an integrated programme because it provides a recognised, auditable Information Security Management System (ISMS) that regulators already accept as evidence of systematic security governance.

This is not theoretical: ENISA's guidance on NIS2 implementation explicitly references ISO 27001 as a suitable baseline. Several national transpositions (including Germany's NIS2UmsuCG) acknowledge ISO 27001 certification as a compliance indicator. For organisations that already hold certification, the gap analysis to NIS2 and DORA compliance is substantially smaller than starting from scratch.

If you do not have ISO 27001, implementing it now serves triple duty. If you do, your existing ISMS becomes the skeleton onto which framework-specific requirements are grafted.

Step 2 — Build a Unified Control Matrix

Create a single control matrix that maps each control to its source obligations across all applicable frameworks. The structure should be: ISO 27001 Annex A control → NIS2 Article 21 requirement → DORA Chapter II requirement → GDPR Article 32 requirement. Each row in the matrix represents one control that may satisfy one, two, three, or all four sources.

The critical benefit: you perform risk analysis once, implement controls once, and produce evidence once — then map that evidence to multiple regulatory requirements. A penetration test report simultaneously satisfies ISO 27001 A.8.8, NIS2 Article 21(e), DORA Article 25, and GDPR Article 32(1)(d). One test, four compliance obligations addressed.

At IWH, we have found that organisations adopting unified control matrices reduce total compliance effort by 40–60% compared to those running parallel programmes, with the additional benefit of eliminating contradictory controls that arise when separate teams interpret similar requirements differently.

Step 3 — Layer Framework-Specific Requirements

ISO 27001 does not cover everything. After building the unified matrix, identify and address the gaps:

DORA-specific requirements not covered by ISO 27001:

• Register of Information (RoI) for all ICT third-party service arrangements — a structured inventory with specific data fields defined in the RTS
• Threat-Led Penetration Testing (TLPT) for significant financial entities — based on the TIBER-EU framework, requiring independent red team exercises
• ICT third-party contractual minimums — specific clauses that must appear in every ICT outsourcing agreement
• Digital operational resilience testing programme — beyond standard penetration testing, including scenario-based testing of critical business processes
• Concentration risk assessment — evaluating dependency on individual ICT providers across the entire supply chain

NIS2-specific requirements beyond DORA scope:

• Sector-specific CSIRT reporting — each Member State's transposition may define specific reporting channels and additional requirements
• Supply chain security measures for non-ICT suppliers — NIS2's scope extends beyond the ICT supply chain that DORA focuses on
• Coordinated vulnerability disclosure — participation in national or sectoral vulnerability disclosure frameworks

GDPR-specific requirements:

• Data subject rights — access, rectification, erasure, portability, objection — require specific technical implementation in cloud architecture
• Data Protection Impact Assessments — structured methodology for high-risk processing activities
• Lawful basis documentation — legal basis for each processing activity must be established and recorded
• Cross-border transfer mechanisms — Standard Contractual Clauses, adequacy decisions, or Binding Corporate Rules for data leaving the EEA

Step 4 — Unified Governance

Integration at the control level is necessary but not sufficient. The governance layer must also be unified:

• Single risk register covering all three frameworks. Each risk entry tagged with applicable regulations. Risk appetite defined once, applied consistently. One risk committee reviewing one register, not three committees reviewing three registers that occasionally contradict each other.
• One incident response procedure with a branching decision tree at the classification stage: Does the incident involve personal data? → GDPR 72-hour reporting. Does it cause significant operational disruption? → NIS2 24-hour early warning. Is it a major ICT incident at a financial entity? → DORA 4-hour classification and reporting. The investigation runs once; the reporting branches.
• Board reporting pack covering all three governance obligations in a single document. Board members should not receive three separate compliance reports — they should receive one integrated risk and compliance report that maps current posture against all applicable obligations.
• Single audit calendar with mapped evidence requirements. An internal audit of access controls produces evidence for ISO 27001 (A.5.15, A.8.2-8.5), NIS2 (Article 21(i)), DORA (Article 9(4)), and GDPR (Article 32(1)(b)). Schedule the audit once, produce the evidence once, file it against four frameworks.

Cloud Architecture for Triple Compliance

With the governance and control framework established, the following architectural decisions implement it technically.

Data Layer

Storage location: EEA-resident storage for personal data, financial data, and operationally critical data. This is not strictly required by any single regulation, but the combined effect of GDPR transfer restrictions, NIS2 supply chain risk assessment, and DORA concentration risk provisions makes EEA residency the path of least regulatory resistance for regulated sectors.

Encryption: At rest (AES-256 minimum) and in transit (TLS 1.2+, preferably 1.3). Critically: customer-managed key material stored in EU-based Hardware Security Modules. Provider-managed encryption satisfies the technical requirement but creates a key escrow risk under the US CLOUD Act if the provider is US-headquartered. Customer-managed keys in EU HSMs eliminate this exposure.

Data classification: A single classification scheme that simultaneously addresses GDPR data categories (personal, special category, children's data), NIS2 criticality (essential service data vs. supporting data), and DORA business impact (critical or important functions vs. non-critical). Four classification tiers typically suffice: Public, Internal, Confidential (covers most personal data and operationally important data), and Restricted (special category personal data, critical financial data, core ICT configurations).

Retention: Define retention policies that satisfy the most demanding applicable requirement for each data class. GDPR's storage limitation principle sets the ceiling; DORA's audit trail requirements and NIS2's incident analysis needs set the floor. Document the justification for each retention period explicitly — "we keep it because we always have" is not a lawful basis under any framework.

Identity, Access, and Monitoring

Centralised IAM: Single identity provider with multi-factor authentication enforced for all access to systems processing regulated data. Conditional access policies based on risk signals (location, device compliance, behaviour anomalies). This satisfies NIS2 Article 21(j) (MFA requirement), DORA Article 9(4)(c) (strong authentication), and GDPR Article 32(1)(b) (access control as a security measure).

SIEM and SOC: Real-time security information and event management with 24/7 monitoring capability. The architecture must support DORA's 4-hour incident classification requirement — which means automated alerting, pre-defined classification criteria, and on-call personnel authorised to initiate the reporting cascade. A SIEM that generates alerts reviewed the next business day is architecturally non-compliant with DORA.

Log retention: 12–24 months of security event logs, stored immutably, accessible for regulatory investigation. DORA does not specify a retention period, but financial supervisors routinely request 12+ months of evidence during examinations. NIS2 incident reports require detailed timelines that depend on historical log data. Shorter retention creates an evidence gap that becomes visible during the first supervisory inquiry.

Privileged access management: Just-in-time elevation, session recording for administrative access, and quarterly access reviews. DORA Article 9(4) requires "strict" access control policies for ICT assets; NIS2 Article 21(i) requires access control policies. "Strict" means demonstrably restricted — permanent standing privileges for administrators are increasingly difficult to justify under either framework.

Resilience and Recovery

Business continuity: Tested annually at minimum — NIS2 Article 21(c) and DORA Article 11 both require business continuity management with regular testing. DORA goes further: financial entities must test their ICT business continuity plans at least annually, and significant entities must conduct advanced testing including scenario-based exercises and, where applicable, TLPT.

Deployment architecture: Multi-Availability Zone within the EEA as baseline. For critical or important functions under DORA, consider multi-region deployment within the EEA. Recovery Time Objectives and Recovery Point Objectives must be defined, documented, and — crucially — tested. A documented RTO of 4 hours that has never been validated in a real recovery exercise is a compliance artefact, not a resilience measure.

TLPT: Significant financial entities must conduct Threat-Led Penetration Testing at least every three years, using independent testers following the TIBER-EU framework. The cloud architecture must support this: isolated test environments, network segmentation that allows controlled red team operations, and monitoring systems capable of detecting (and not automatically blocking) authorised attack simulations.

Exit strategies: DORA Article 28 requires documented exit strategies for every critical ICT third-party provider. In cloud architecture terms, this means: documented migration procedures, data portability guarantees, tested data export processes, and identified alternative providers. An exit strategy that exists only as a Word document and has never been tested is insufficient — DORA expects operational readiness, not theoretical planning.

The Data Sovereignty Question

None of the three regulations impose an absolute EU-only data residency requirement. GDPR permits transfers with appropriate safeguards. NIS2 does not mandate data localisation. DORA requires that data location be documented and that concentration risks be assessed, but does not prohibit non-EU hosting.

However, the combined regulatory effect has made EU-based infrastructure effectively mandatory for most regulated sectors. The post-Schrems II transfer landscape, NIS2's supply chain risk assessment requirement (which must address the legal regime applicable to the provider), and DORA's concentration risk provisions create a practical reality where using non-EU-headquartered providers requires extensive additional documentation, risk assessment, and supplementary measures that often cost more than simply choosing an EU-resident solution.

The specific concern with US-headquartered providers is the CLOUD Act, which compels disclosure of data regardless of storage location. This is not hypothetical — it is a documented legal obligation of every US-headquartered company. Using such a provider is not automatically non-compliant, but it is a risk factor that must be explicitly addressed in your NIS2 supply chain assessment, your DORA concentration risk evaluation, and your GDPR Transfer Impact Assessment.

European alternatives exist — OVHcloud, Open Telekom Cloud, Hetzner, IONOS, Scaleway — but may lack the service breadth or global reach of AWS, Azure, or Google Cloud. The pragmatic approach for most organisations: deploy on EU regions of a hyperscaler, implement customer-managed encryption with EU-based key management, and produce a documented risk assessment that explicitly acknowledges the CLOUD Act exposure and identifies the mitigating controls. This is defensible. Running workloads on US-region infrastructure with provider-managed keys and no documented risk assessment is not.

DORA Enforcement Reality

Understanding the current enforcement landscape is essential for prioritisation. DORA has been fully applicable since 17 January 2025 with no transitional period — unlike GDPR, which provided a two-year implementation window. Financial entities were expected to be compliant on day one.

The reality is different. Industry surveys consistently indicated that approximately 50% of financial institutions achieved full compliance by the end of 2025, with the remainder at varying stages of implementation. The most common gaps: incomplete Registers of Information, untested ICT business continuity plans, and ICT third-party contracts that lack DORA-mandated minimum provisions.

In November 2025, the European Supervisory Authorities designated 19 Critical ICT Third-Party Providers (CTPPs) subject to direct oversight — a list that includes AWS, Microsoft Azure, Google Cloud, Oracle, and SAP, among others. These providers are now subject to direct examination by the Lead Overseer, with potential penalties of up to 1% of average daily worldwide turnover for non-compliance. This designation has practical implications for every financial entity using these providers: your CTPP's compliance posture is now your regulatory concern, and supervisors will ask what due diligence you performed.

First Register of Information submissions began in Q1 2026, providing regulators with unprecedented visibility into the ICT supply chain dependencies of the financial sector. No published enforcement actions have emerged yet, but supervisory scrutiny is intensifying. National competent authorities across the EU are building DORA-specific examination programmes, and the first wave of focused inspections is expected throughout 2026.

The penalty regime is substantial: up to 2% of total annual worldwide turnover for financial entities, up to €1 million in personal fines for management body members, and up to €5 million for critical ICT third-party providers. These are maximums, but they signal regulatory intent. DORA is not a soft-law aspiration — it is a regulation with teeth.

Common Mistakes to Avoid

Based on implementation experience across regulated European organisations, these are the most frequent and most damaging errors:

• Running three separate compliance programmes. This is the single most expensive mistake. Three project teams, three risk assessments, three sets of policies, three audit cycles — producing work that overlaps by 60% or more. The integrated approach described above costs less and produces better outcomes.
• Treating DORA as "just another IT project." DORA is a board-level governance obligation with personal liability for management body members. Delegating it entirely to the IT department without board-level oversight is itself a compliance failure under Article 5. The CTO cannot own DORA alone — the board must.
• Assuming your cloud provider's compliance covers yours. Shared responsibility means precisely what it says. Your provider's ISO 27001 certificate covers their infrastructure management. Your configuration, your access controls, your data classification, your incident response, your evidence — all of this is your responsibility. A provider's SOC 2 report does not demonstrate your compliance; it demonstrates theirs.
• Ignoring concentration risk. If your entire operation runs on a single cloud provider, with a single identity provider, and a single SaaS productivity suite from the same vendor, you have a DORA concentration risk problem. Article 29 requires financial entities to assess whether their ICT third-party arrangements create undue concentration. "We chose the market leader" is not a concentration risk assessment.
• Waiting for NIS2 amendments or simplification. Several Member States are still finalising transposition, and the European Commission's proposed amendments (including aligning incident reporting across frameworks) are in early legislative stages. But current NIS2 obligations are already enforceable in Member States that have transposed. Waiting for simplification that may arrive in 2027 or 2028 while current obligations go unaddressed is a quantifiable regulatory risk.
• Treating compliance as a point-in-time achievement. All three frameworks require continuous processes — ongoing risk assessment, regular testing, periodic review. An organisation that achieves compliance in Q1 and does not reassess until the following year has, by Q3, likely drifted out of compliance. Build compliance into operational cadence, not project timelines.

What Comes Next

The regulatory trajectory is toward greater integration, not less. The European Commission's proposed simplification measures — including a potential single incident reporting channel and aligned reporting timelines — acknowledge that the current multi-framework landscape imposes disproportionate burden. The Digital Fairness Omnibus Directive proposes aligning GDPR breach notification with NIS2 by extending the timeline to 96 hours and routing through CSIRTs.

But these simplifications are legislative proposals, not current law. Organisations that wait for them will find themselves building parallel programmes under pressure, while those that adopt the integrated approach now will be positioned to simplify further as the regulatory landscape consolidates.

The organisations that will navigate this successfully are not the ones with the biggest compliance budgets or the most consultants. They are the ones that recognise these three frameworks are asking fundamentally the same question — can you demonstrate that your systems, processes, and governance are resilient? — and build one coherent answer instead of three separate ones. The architecture described in this guide is not the only way to achieve that integration, but the underlying principle is non-negotiable: unify the foundation, layer the specifics, and govern it as one programme. Everything else is implementation detail.