GDPR, BSI C5, DORA: Why Your Cloud Strategy Needs a Compliance Foundation
GDPR, BSI C5, and DORA set clear requirements for cloud infrastructure. Here's how to build a solid compliance foundation.
European enterprises face an increasingly complex regulatory landscape. GDPR continues to define data protection standards across the continent. The BSI C5 catalog establishes security baseline requirements for German public administrations and enterprises handling sensitive data. And DORA—the Digital Operational Resilience Act—introduces rigorous requirements for operational resilience, third-party dependencies, and incident reporting for financial institutions and systemically important enterprises. These three frameworks are no longer optional considerations; they have become strategic imperatives that fundamentally shape infrastructure decisions for any organization serious about operating in the European market.
Yet many enterprises still approach these regulations reactively, implementing controls only when required or after incidents occur. This approach is not only risky—it is also expensive. When compliance is treated as an afterthought, it typically requires painful retrofits to existing infrastructure, expensive consultant hours to document controls, and sometimes complete redesigns when fundamental architectural assumptions prove incompatible with regulatory requirements. Forward-thinking organizations instead build compliance into their infrastructure foundation, making compliance a natural outcome of sound architectural decisions rather than a separate layer of controls added later.
GDPR: The Foundation of European Data Protection
The General Data Protection Regulation fundamentally changed how organizations must think about personal data. GDPR applies to any organization handling the personal data of EU residents, regardless of where the organization itself is located. The regulation is principle-based rather than prescriptive, meaning it defines objectives and requirements without mandating specific technical implementations. However, within these principles lie significant implications for cloud infrastructure.
GDPR requires organizations to demonstrate accountability for personal data processing. This means maintaining detailed records of what personal data is processed, for what purposes, how long it is retained, and who has access to it. Organizations must be able to provide these records to regulators or data subjects on demand. For many organizations, the cloud providers they use have inadequate documentation and audit capabilities to support this accountability. Public cloud providers that host thousands of customers simply cannot provide the granular visibility that European enterprises need to prove GDPR compliance for their specific data handling practices.
The regulation also establishes the concept of data processing locations. Personal data of EU residents is subject to GDPR requirements regardless of where it is stored, but many organizations prefer to keep this data within EU borders for legal certainty and reduced latency. GDPR does not mandate EU-only storage, but the practical application of rights like data portability and deletion becomes simpler when data is under organizational control rather than distributed across cloud provider infrastructure in multiple jurisdictions.
GDPR imposes strict requirements for lawful data processing. Organizations must document the legal basis for each data processing activity, whether consent, contract, legal obligation, vital interests, public task, or legitimate interests. When using cloud services, organizations must ensure that data sharing with the cloud provider is lawfully permissible and that the cloud provider does not process the data for purposes beyond what the organization authorized. This is frequently violated in practice, where cloud providers use infrastructure data for their own machine learning, analytics, or security purposes.
Perhaps most significantly, GDPR establishes rigorous breach notification requirements. Data breaches involving personal data must be reported to regulators within 72 hours and to affected individuals without undue delay. For organizations using shared cloud infrastructure where they cannot audit the security controls, understanding whether a breach occurred and when it was discovered becomes problematic. Many public cloud outages have affected millions of users, yet enterprises have limited visibility into whether their specific data was affected or what security measures exist to prevent unauthorized access.
BSI C5: Germany's Security Baseline for Critical Data
While GDPR applies across the EU, Germany has established more specific security requirements through the BSI C5 catalog. Developed by the German Federal Office for Information Security (Bundesamt für Informationssicherheit, or BSI), the C5 catalog defines security requirements for cloud services used by German public administrations and increasingly by private sector enterprises handling sensitive data.
The C5 catalog addresses specific concerns about cloud infrastructure security that GDPR alone does not fully define. It requires organizations to establish clear information security management systems, define security responsibilities, implement multi-factor authentication for privileged accounts, and maintain detailed logging and audit trails. These are not theoretical controls; they are operational requirements that must be demonstrated during audits and assessments.
One of the most significant C5 requirements addresses subcontracting and third-party dependencies. Cloud providers must ensure that any subcontractors—including infrastructure providers, data center operators, and security service providers—meet the same security requirements as the primary service provider. For many public cloud providers, this creates a documentation nightmare. When your compute infrastructure is virtualized across multiple data centers, your storage is replicated across multiple regions, and your security monitoring is provided by third-party integrated services, comprehensively documenting every third-party relationship and their security practices becomes extremely difficult.
The C5 catalog also specifies requirements for data location and jurisdiction. Organizations must understand exactly where their data is stored, which jurisdictions govern access to that data, and what happens to that data if the cloud provider is acquired or goes out of business. For multinational cloud providers storing data across global regions, providing this clarity is challenging. Organizations may not even know whether their data is currently stored in France, Germany, Ireland, or elsewhere, or whether it might be moved to comply with load balancing or disaster recovery procedures.
C5 compliance requires detailed information security risk assessments, documentation of security controls, and regular independent audits. Organizations must maintain audit trails showing who accessed what data and when. They must demonstrate that encryption keys are properly managed and that unauthorized access is prevented. These are all achievable with public cloud platforms, but require significant additional configuration, monitoring, and third-party auditing beyond the basic cloud service offerings.
DORA: Operational Resilience for Financial and Critical Services
The Digital Operational Resilience Act takes a different approach than GDPR and BSI C5. Rather than focusing primarily on data protection and security controls, DORA addresses operational resilience—the ability of financial institutions and other systemically important enterprises to continue operations despite disruptions. Enacted in 2022 and fully applicable from January 2025, DORA has profound implications for infrastructure decisions.
DORA requires organizations to establish incident management frameworks that include rapid detection of incidents, swift response protocols, and timely reporting to regulators. Financial institutions must be able to demonstrate that they detect significant incidents—defined as incidents affecting more than 1000 natural persons or causing losses exceeding EUR 100,000—within 15 minutes and report them to regulators within 72 hours. This level of monitoring capability requires infrastructure with comprehensive logging, real-time alerting, and sophisticated incident classification systems.
The regulation also addresses the concentration risk posed by third-party dependencies. DORA requires organizations to identify critical third-party service providers, particularly cloud providers, and establish detailed service level agreements with clear consequences for failures. Organizations must regularly test their ability to switch providers or implement backup systems. For many enterprises, DORA effectively requires redundancy—either multiple cloud providers or hybrid approaches combining cloud with on-premise infrastructure capable of continuing operations if the cloud provider becomes unavailable.
DORA extends to cybersecurity testing through mandatory "digital operational resilience testing"—commonly called DORA testing or threat-led penetration testing. Organizations must conduct regular penetration tests and cybersecurity exercises to validate their ability to withstand attacks. These tests must be comprehensive and realistic, simulating actual attack scenarios that threat actors would use. The results must be reported to regulators, creating both accountability and significant compliance costs.
Perhaps most relevant for infrastructure decisions, DORA requires organizations to establish clear accountability for third-party risk management. If your cloud provider suffers a breach or outage that impacts your operations, regulatory responsibility falls on your organization, not on the cloud provider. DORA treats third-party risk as operational risk that institutions must manage proactively rather than outsource completely.
The Public Cloud Paradox: Choosing Managed Services Without Abdicating Responsibility
A fundamental challenge exists in reconciling GDPR, BSI C5, and DORA requirements with the operational model of public cloud providers. Public cloud providers achieve efficiency and cost benefits by managing thousands of customers on shared infrastructure. This sharing is valuable for customers with non-critical workloads that can tolerate occasional disruptions. However, it inherently creates challenges for compliance.
Public cloud providers cannot provide the detailed per-customer audit trails and security visibility that many regulated enterprises require. When you run infrastructure on a public cloud provider's shared platform, you cannot definitively answer questions like: exactly which employees have access to my data? Precisely which data resides in which data centers? What happens to my data if I terminate the service? These questions are not theoretical—regulators ask them, and organizations must be able to answer them or face regulatory findings and fines.
Public cloud providers also operate across multiple jurisdictions and frequently transfer data between regions. While they provide options to constrain data locations, these constraints are often additional paid services and may not be binding in all circumstances. For organizations subject to strict data residency requirements, the practical ability of public cloud providers to meet these requirements is limited.
The responsibility allocation problem is acute. Regulations like DORA assign responsibility to the regulated institution, not to the cloud provider. If your cloud provider has an outage, your organization is responsible for regulatory reporting, even though you cannot control the provider's infrastructure. This creates misaligned incentives—your organization is regulated on outcomes that you cannot fully control through the contract terms with your cloud provider.
On-Premise OpenStack: Control Aligned with Responsibility
This is where on-premise infrastructure becomes strategically valuable for regulated enterprises. An organization running OpenStack infrastructure on its own hardware, in facilities it controls or that are managed under strict SLAs, maintains direct control over the infrastructure components relevant to compliance. This alignment of control and responsibility significantly simplifies meeting regulatory requirements.
With on-premise OpenStack infrastructure managed by Clouditiv, an organization knows exactly where its data resides. The infrastructure is located in facilities in Germany or other specified jurisdictions. Access logs are complete and readily available for audit. Backup and disaster recovery procedures are under organizational control and can be tested on demand. Encryption keys are managed by the organization itself or via transparent key management appliances under organizational control.
Clouditiv's expertise in GDPR and BSI C5 compliance ensures that the OpenStack infrastructure is configured correctly from the beginning. Rather than deploying infrastructure first and then retrofitting controls, compliance is built in. The result is infrastructure that naturally produces the audit trails, access controls, and operational visibility that regulators expect to see.
For organizations subject to DORA, on-premise infrastructure can be combined with strategic public cloud usage. The on-premise infrastructure serves as the primary production environment where critical business functions reside and where operational control is absolute. Public cloud services are used for non-critical workloads, development environments, and backup services that do not threaten core operational resilience. This hybrid approach meets DORA's requirement for third-party redundancy while ensuring that critical functions remain under direct organizational control.
Building the Compliance Foundation: Practical Steps
Organizations that must comply with GDPR, BSI C5, and DORA should follow a strategic approach to infrastructure decisions. First, conduct a comprehensive regulatory impact assessment. Understand specifically which regulations apply to your organization and which data handling activities are subject to each regulation. Not all data requires the same level of protection; personal data subject to GDPR has different requirements than operational data.
Second, evaluate your current infrastructure against regulatory requirements. Do you have adequate audit trails? Can you prove data location? Can you demonstrate how access is controlled? For many organizations, this assessment reveals significant gaps in current cloud deployments.
Third, develop a hybrid architecture strategy. Designate which workloads must remain on-premise or in highly controlled environments and which can safely reside in public cloud. For many enterprises, critical business logic, core data processing, and personal data processing remain on-premise, while development, testing, and non-critical analytics move to public cloud.
Fourth, establish service level agreements and audit procedures for any third-party dependencies, including cloud providers. These agreements should specify incident notification timelines, breach reporting procedures, and performance commitments aligned with regulatory requirements.
Finally, implement comprehensive monitoring and logging across the entire infrastructure. Regulatory compliance is increasingly demonstrated through data—audit logs showing proper access controls, monitoring dashboards showing performance commitments met, alerts showing that incidents were detected within required timeframes. Investing in infrastructure logging and monitoring is not just about security; it is about building the evidence that regulators will examine.
Conclusion: Compliance as Strategic Infrastructure Foundation
GDPR, BSI C5, and DORA represent a fundamental shift in how European regulators expect enterprises to manage data and infrastructure. These frameworks cannot be addressed through pure public cloud services alone. Organizations serious about compliance must make strategic infrastructure decisions that align control with responsibility.
This does not mean abandoning public cloud entirely. Rather, it means making deliberate choices about which workloads and data reside where, ensuring that critical and sensitive data are handled through infrastructure that provides the visibility and control that regulators expect. For many European enterprises, this means a hybrid model with on-premise OpenStack infrastructure for sensitive workloads and selective public cloud usage for appropriate applications.
Clouditiv's expertise in building GDPR and BSI C5-compliant OpenStack infrastructure provides a pathway for organizations to gain the benefits of cloud computing—elasticity, self-service provisioning, automation—while maintaining the control and visibility necessary for regulatory compliance. In an increasingly regulated environment, this combination of cloud benefits with governance assurance is not a luxury; it is a competitive necessity.