Luca BertonEuropean enterprises operating cloud infrastructure face a compliance environment that has compounded significantly in the last three years. DORA came into force in January 2025 for financial services firms. The BSI C5 catalogue remains the baseline for cloud providers serving German public sector and increasingly private sector organizations. GDPR, now over six years old, continues to generate enforcement actions at a pace that makes it impossible to treat as a settled matter.
The problem is not that any of these frameworks is unreasonable. Each addresses a genuine risk category: operational resilience, cloud security controls, and personal data protection. The problem is that organizations treat them as three separate compliance programs — three governance tracks, three audit processes, three sets of documentation, three timelines running in parallel. The result is duplicated effort, inconsistent controls, and compliance teams that spend more time reconciling frameworks than improving security.
This guide is about building one compliance program that satisfies all three, using shared controls where the frameworks overlap, and only extending to framework-specific requirements where they don't.
Understanding the Three Frameworks
DORA — Digital Operational Resilience Act
DORA applies to financial entities — banks, insurance companies, investment firms, payment service providers, crypto asset service providers — and their critical ICT third-party service providers. It imposes requirements across five pillars:
DORA's Five Pillars
- ICT Risk Management: Documented risk management framework, asset inventory, risk appetite definition, control implementation
- ICT Incident Management: Incident classification, mandatory reporting to competent authorities for major incidents, post-incident review
- Digital Operational Resilience Testing: Vulnerability assessments, penetration testing, and for significant firms, Threat-Led Penetration Testing (TLPT)
- ICT Third-Party Risk: Due diligence on providers, contractual requirements including exit strategies, oversight of critical providers
- Information Sharing: Voluntary sharing of cyber threat intelligence with the financial sector ecosystem
C5 — Cloud Computing Compliance Controls Catalogue
Published by the German Federal Office for Information Security (BSI), C5 is a cloud-specific framework that defines security requirements for cloud service providers. It is structured around 17 control domains covering areas from organization and personnel security through to physical security, cryptography, and application security.
C5 operates on a shared responsibility model: the cloud provider demonstrates C5 compliance through attestation (Type 1 for design, Type 2 for operational effectiveness), and the cloud customer uses that attestation as evidence for their own compliance programs. For regulated organizations using German cloud providers, C5 attestations from your providers are foundational compliance evidence.
Critically, C5 2020 added specific requirements around software development security and supply chain — controls that have direct relevance to organizations building on cloud platforms, not just the platforms themselves.
GDPR — General Data Protection Regulation
GDPR applies to any organization processing personal data of EU residents, regardless of where the organization is established. Its compliance requirements for infrastructure and cloud are primarily concentrated in:
- Article 25 — Data Protection by Design and Default: Technical and organizational measures that implement data protection principles from the design stage
- Article 28 — Processor Obligations: Contractual requirements for processors (including cloud providers), data processing agreements, audit rights
- Article 32 — Security of Processing: Appropriate technical and organizational measures including encryption, pseudonymization, resilience of systems, and regular testing
- Articles 33-34 — Breach Notification: 72-hour notification to supervisory authority, notification to affected individuals when risk is high
- Chapter V — International Transfers: Requirements for transferring personal data outside the EEA
Where the Three Frameworks Overlap
The overlap is substantial, and that's the leverage point for an efficient compliance program.
Control Overlap Map
| Control Area | DORA | C5 | GDPR |
|---|---|---|---|
| Asset inventory & classification | ✓ | ✓ | ✓ (data assets) |
| Encryption at rest and in transit | ✓ | ✓ | ✓ (Art. 32) |
| Access control & identity management | ✓ | ✓ | ✓ (Art. 25) |
| Backup & recovery | ✓ | ✓ | ✓ (Art. 32) |
| Vulnerability management | ✓ | ✓ | ✓ (Art. 32) |
| Incident detection & response | ✓ (mandatory reporting) | ✓ | ✓ (Arts. 33-34) |
| Third-party / supplier risk | ✓ (detailed) | ✓ | ✓ (Art. 28) |
| Audit logging & monitoring | ✓ | ✓ | ✓ (accountability) |
| Business continuity & DR | ✓ | ✓ | ✓ (Art. 32 resilience) |
| Penetration testing | ✓ (TLPT for significant firms) | ✓ | ✓ (Art. 32 testing) |
The implication is direct: a control implemented to meet one framework's requirements almost always satisfies the corresponding requirement in the other two. The risk with three parallel compliance programs is that the same control gets implemented three times, in three slightly different ways, documented in three separate systems — creating inconsistency, audit overhead, and maintenance burden without adding any additional security.
Kubernetes Recipes
Practical guide for container orchestration and deployment — hands-on patterns you can use today.
View on Amazon →Where the Three Frameworks Diverge
The differences are where the three programs genuinely need to do separate work.
DORA-specific requirements
- Mandatory incident reporting timelines: DORA imposes specific notification deadlines to regulators (initial notification within 4 hours of classification, intermediate report within 72 hours, final report within one month) that GDPR and C5 don't replicate exactly
- TLPT programme: Threat-Led Penetration Testing for significant financial entities has a specific methodology (TIBER-EU) and scope requirements that go beyond standard penetration testing
- Critical ICT provider oversight: DORA creates a register of critical third-party providers subject to direct regulatory oversight — a concept that doesn't exist in C5 or GDPR
- Exit strategies: DORA requires documented and tested exit strategies for critical ICT providers, including cloud providers — specific to operational resilience rather than data protection or cloud security
C5-specific requirements
- Attestation model: C5 produces a formal attestation (Type 1 or Type 2) by an accredited auditor, with specific evidence requirements for each of the 17 control domains. DORA compliance is assessed by financial regulators; GDPR compliance is assessed by supervisory authorities. The C5 attestation process is distinct.
- Cloud-specific controls: C5 includes controls specific to cloud service delivery — multi-tenancy isolation, portability, interoperability — that don't have direct equivalents in DORA or GDPR
- Supply chain security: C5 2020's supply chain controls (OIS-08 through OIS-10) address software development lifecycle and third-party components in ways that are cloud-specific and go beyond the other frameworks
GDPR-specific requirements
- Data subject rights: Right of access, erasure, rectification, portability, and objection require specific technical capabilities — deletion pipelines, data export mechanisms, consent management — that have no equivalent in DORA or C5
- Legal basis for processing: GDPR requires a documented lawful basis for every processing activity. This is a governance and legal requirement rather than a technical control.
- Records of processing activities: Article 30 requires documented records of all processing operations — a data governance requirement with no direct parallel in operational resilience or cloud security frameworks
- Data Protection Impact Assessments: DPIAs for high-risk processing are a GDPR-specific obligation that requires a defined methodology and governance process
- International transfers: Standard Contractual Clauses, adequacy decisions, and Transfer Impact Assessments are GDPR-specific mechanisms for data flows outside the EEA
Building a Unified Compliance Program
Step 1: Start with a common control baseline
ISO 27001 is the most efficient starting point because it maps to all three frameworks and provides a governance structure — the Information Security Management System — that each framework's requirements can be added to rather than competing with. If you're already ISO 27001 certified, you have the foundation. If not, implementing ISO 27001 first and then extending for DORA, C5, and GDPR is more efficient than implementing each framework independently.
Common Control Baseline Implementation Order
- Asset inventory and classification: Every other control depends on knowing what assets you have and how sensitive they are. GDPR's data mapping, DORA's ICT asset register, and C5's asset management requirement all start here.
- Identity and access management: Least privilege, MFA, privileged access management. Implement once; document the mapping to each framework's requirements separately.
- Encryption: At rest and in transit, with key management. Satisfies DORA's confidentiality requirements, C5's CRY domain, and GDPR Article 32's encryption obligation simultaneously.
- Logging and monitoring: Centralized logging, SIEM, alerting thresholds. Provides the audit trail for DORA reporting, the monitoring evidence for C5, and the accountability mechanism for GDPR.
- Vulnerability management: Scanning, patching SLAs, exception process. Satisfies DORA's testing requirements, C5's vulnerability management controls, and GDPR's obligation to ensure ongoing security.
- Incident response: Detection, classification, response, and notification. Implement the process once; extend with DORA's specific notification timelines and GDPR's 72-hour breach notification as separate workflow branches.
- Backup and recovery: Regular backups, tested restoration, RTO/RPO targets. Satisfies DORA's resilience requirements, C5's availability controls, and GDPR's obligation to restore access to personal data.
Step 2: Collect cloud provider attestations as foundational evidence
Before extending your internal controls, collect the C5 attestations from all cloud providers in scope. These attestations cover the portion of the shared responsibility model that the provider owns — physical security, hypervisor isolation, network controls, and data center operations. You cannot audit these yourself; you depend on the provider's attestation.
The strategic value of C5 attestations is cross-framework: a C5 Type 2 attestation from your cloud provider is usable as evidence for DORA's third-party risk requirements (demonstrating that the provider meets required security standards) and for GDPR's Article 32 requirements (demonstrating that technical measures are in place). One attestation satisfies evidence requirements across all three frameworks.
Step 3: Build the GDPR data layer
GDPR requires data governance capabilities that neither DORA nor C5 require. These need to be built explicitly:
- Data mapping: Document what personal data you process, where it lives, who can access it, what it's used for, and what the legal basis is. This is the foundation for DPIAs, Data Processing Agreements, and subject access requests.
- Data Processing Agreements: Review and update DPAs with all processors — particularly cloud providers. Ensure they include the minimum required provisions (Article 28(3)) and that data transfer mechanisms are in place for non-EEA providers.
- Subject rights automation: Manual response to subject access requests, erasure requests, and portability requests doesn't scale. Invest in automated pipelines before the volume exceeds manual capacity.
- DPIA process: Define the triggers for a DPIA (high-risk processing, new technology, large-scale profiling), the methodology, and the governance path for review and approval.
Step 4: Extend for DORA's financial services requirements
DORA adds layers that have no equivalent in C5 or GDPR:
- ICT Risk Management Framework documentation: DORA requires a formal, board-approved ICT risk management framework. This is not just the controls — it is the governance structure, risk appetite statement, and oversight model. It maps to your ISMS but must be specifically articulated for DORA compliance.
- Incident classification taxonomy: DORA's incident reporting requirements depend on a classification taxonomy that distinguishes major incidents (reportable to regulators) from significant incidents (internal escalation) from standard incidents (operational response). Define this taxonomy explicitly, train your operations team on it, and test it before you need it.
- Third-party risk register: DORA requires a documented register of all ICT providers, with specific information about each including criticality assessment, concentration risk, and contractual status. This is more detailed than a standard vendor register.
- TLPT programme (if applicable): Significant financial entities must implement a Threat-Led Penetration Testing programme aligned with TIBER-EU. This requires engaging a qualified external tester, scoping the test with your competent authority, and managing a structured red-team exercise.
Step 5: Prepare for C5 attestation
If your organization is a cloud service provider — or if you're building internal platforms used by C5-scoped entities — C5 attestation requires engaging an accredited auditor and producing structured evidence across all 17 control domains.
For cloud customers (rather than providers), the objective is not to obtain C5 attestation but to:
- Verify that your cloud providers have current C5 Type 2 attestations and obtain the attestation reports
- Review the attestation scope to confirm it covers the services and regions you use
- Identify controls in the shared responsibility model that fall to you as the customer and verify your controls address them
- Document this analysis as evidence for DORA third-party risk assessments and GDPR processor due diligence
Evaluating RAG Solutions
Choose the right RAG model, configure, test, and optimise.
Start on Pluralsight →The Three Most Common Integration Mistakes
Mistake 1: Three Separate GRC Systems
Organizations that implement DORA, C5, and GDPR as three separate tracks in three separate Governance, Risk, and Compliance tools end up with three copies of every shared control in three slightly different states. When a control fails or needs updating, it must be updated in three places — and the inconsistencies become audit findings.
Fix: One GRC system with a single control library mapped to all three frameworks. Each framework gets its own view, but shared controls are represented once and mapped to all applicable requirements.
Mistake 2: Sequential Rather Than Parallel Implementation
"We'll do GDPR first, then DORA, then C5" sounds orderly but wastes the overlap. Organizations that implement sequentially build the shared controls three times — once for each framework — because they don't structure the first implementation with the other frameworks in mind.
Fix: Implement the common control baseline explicitly mapped to all three frameworks from the start. Add framework-specific extensions in parallel rather than sequencing the entire program.
Mistake 3: Confusing Compliance with Security
Organizations that design their compliance program around what auditors will check — rather than around what controls actually reduce risk — end up with impressive documentation and inadequate security. All three frameworks require "appropriate technical and organizational measures," which is deliberately undefined. Compliance teams that treat minimum compliance as the target consistently underinvest in the controls that would actually prevent the incidents the frameworks are designed to prevent.
Fix: Start from the threat model, implement controls that address real risks, and then document the mapping to framework requirements. Don't start from the framework requirements and work backward to the minimum control that technically satisfies them.
Practical Timeline for a Unified Program
12-Month Unified Compliance Roadmap
- Months 1-2 — Baseline and gap assessment: Asset inventory, data mapping, current-state control documentation, gap analysis against all three frameworks simultaneously using a unified control library
- Months 2-4 — Common controls implementation: IAM, encryption, logging, incident response, backup — the controls that satisfy all three frameworks. Collect cloud provider C5 attestations.
- Months 4-6 — GDPR data layer: DPAs with all processors, subject rights automation, DPIA process, records of processing activities
- Months 5-8 — DORA financial services layer: ICT risk framework documentation, incident classification taxonomy, third-party risk register, TLPT scoping (if applicable)
- Months 6-10 — Evidence and documentation: Control evidence collection, policy documentation, process documentation, GRC system population
- Months 10-12 — Testing and audit readiness: Internal audit, penetration testing, incident response exercise, regulatory mock assessment
The 12-month timeline is achievable for an organization starting from a reasonable security baseline. Organizations with significant gaps in foundational controls — incomplete asset inventories, inconsistent IAM, no centralized logging — should budget 18-24 months and prioritize the common controls before framework-specific extensions.
The argument for investing in a unified program rather than three separate tracks is ultimately an efficiency argument: the same security outcome, with less duplicated effort, and a more defensible compliance posture. Auditors and regulators increasingly expect organizations to demonstrate a coherent, integrated approach to information security rather than a collection of point solutions assembled for individual compliance checkboxes. Building the program once, properly, is both cheaper and more credible.
AI Readiness Assessment
Fixed-fee, 3-4 week infrastructure and compliance audit with a concrete roadmap. No big-consultancy overhead.
See Scope & Pricing →Related Solution
Need GDPR-compliant AI infrastructure? We design architectures that satisfy data residency, DPIAs, and right-to-erasure from day one.
Learn about our GDPR-compliant AI infrastructure →