EU Compliancy Cloud Framework-ish Smackdown

EU Compliancy Cloud Framework-ish Smackdown

Speakers: Rich Mogull, Chief Analyst, Cloud Security Alliance

Conference: fwd:cloudsec Europe 2025

YouTube: https://www.youtube.com/watch?v=nuQE2zmJ4jo

Overview

Rich Mogull — a 25-year security veteran and newly appointed chief analyst at the Cloud Security Alliance (CSA) — delivered a practitioner-oriented guide to navigating the chaotic landscape of EU cloud compliance regulations. With multiple overlapping regulations (DORA, NIS 2, GDPR) hitting simultaneously, member states missing their own enforcement deadlines, and existing frameworks like ISO 27001 woefully outdated for cloud, Mogull presented a pragmatic system for organizing security programs that satisfies compliance requirements without drowning in checkbox exercises. His core thesis: do good security, then document it in a way auditors can understand.

Background

▶ Watch: Setting the stage: multiple EU regulations hitting cloud simultaneously with ... (1:30)

EU-based cloud security practitioners face an unprecedented convergence of regulatory pressure. At least five major regulations either exist or are incoming, all affecting cloud infrastructure. DORA targets financial services and their service providers. NIS 2 covers critical sectors based on size and industry. GDPR has been in effect for years but continues to evolve in its cloud implications. These regulations share common themes — cloud as a critical supply chain component, data sovereignty requirements, incident reporting obligations, and resilience mandates — but each has different sector scopes, timelines, and enforcement mechanisms.

The situation is compounded by three factors. First, over half of the EU's 27 member states have missed their own deadlines for defining how they will assess and enforce NIS 2 compliance. Second, the dominant cloud providers are all US-based, introducing Cloud Act risks where the US government can compel data disclosure even from EU-operated infrastructure. Third, the available security frameworks are badly outdated: ISO 27001 was last updated in 2022 with minimal cloud additions, ISO 27017 (the cloud add-on) hasn't been updated since 2015, and the European Cybersecurity Certification Scheme for Cloud Services (EUCS) has been stalled entirely due to sovereignty debates. France's SecNumCloud requires that cloud providers be owned by no more than 39% foreign capital — effectively excluding AWS, Azure, and GCP.

Key Findings

▶ Watch: NIS 2 demands 'state-of-the-art' security while 80% of breaches come from sta... (6:00)

Mogull identified consistent requirements across EU regulations that practitioners can leverage as a unified compliance baseline:

• Cloud is now treated as a critical supply chain component. Nearly every regulation requires risk assessment of cloud providers, understanding of data location and processing, and documentation of supply chain dependencies.

• Incident response requirements are expanding. DORA and NIS 2 both impose stricter incident detection, response, and reporting obligations, typically requiring major incident notification within 48-72 hours.

• Management accountability is increasing. Regulations are pushing responsibility upward to executive management, which Mogull noted with dry approval: "We shouldn't be management. Hopefully blame somebody else."

• Resilience requirements are growing. Particularly under DORA, organizations must demonstrate backup, recovery, and operational resilience capabilities.

• "State-of-the-art" security mandates are unrealistic. NIS 2 requires use of "state-of-the-art security," but as Mogull pointed out, 80% of breaches still come from static credentials and publicly exposed resources. The industry hasn't mastered the basics, yet regulations demand adoption of emerging technologies.

• Frameworks haven't kept up. The most commonly referenced framework for NIS 2 compliance — ISO 27001 — contains only a few generic lines about cloud encryption that provide no actionable guidance for preventing actual breaches.

Technical Deep Dive

▶ Watch: The cloud provider registry: your minimum viable compliance artifact (10:00)

The Two Registries

Mogull recommends establishing two foundational registries:

1. Cloud Provider Registry: A spreadsheet documenting which cloud providers are approved, what risk assessment has been performed, what data types are permitted in each provider, and any constraints (e.g., "AWS EU sovereign region only for PII and financial data"). This single document satisfies the risk assessment requirements present in virtually every EU regulation. The regulations don't demand perfect risk assessment — they require that you've done one and documented it.

1. Cloud Deployment Registry: A mapping of specific application stacks to their cloud deployment locations, including business owner and technical lead contacts. This feeds both risk assessment documentation (demonstrating knowledge of where data resides) and incident response processes (knowing who to contact when something breaks). It directly addresses the timely reporting requirements of DORA and NIS 2.

The Governance Hierarchy

Mogull's governance hierarchy provides a layered control framework from high-level compliance mapping down to automated technical assessments:

Layer 1 — Cloud Security Framework: A top-level organizational structure for cloud-specific security domains. Mogull recommends the Cloud Security Maturity Model (which he authored), containing 100+ control objectives organized as key performance indicators. The purpose is to give cloud security teams a cloud-centric view of what they need to focus on, stripped of irrelevant ISO domains like facilities access and BYOD.

Layer 2 — Control Objectives: Platform-agnostic statements of desired security outcomes (e.g., "All human access should use SSO with JIT"). Mogull starts with the CSA Cloud Controls Matrix (CCM) and customizes from there. The CCM's critical advantage is its pre-built mappings to ISO 27001, ISO 27017, and other regulatory frameworks. When a new regulation arrives, you simply add a column mapping your existing control objectives to the new requirements — the gap analysis becomes incremental rather than starting from scratch.

Layer 3 — Control Specifications: Platform-specific technical implementations of each control objective. One control objective maps to multiple specifications (e.g., how JIT is implemented in AWS IAM Identity Center vs. GCP). These specifications ideally map directly to CSPM/CNAPP tool checks for automated, continuous assessment. Mogull emphasizes that practitioners should use professional judgment when selecting which tool-generated findings matter, rather than blindly accepting vendor severity ratings.

Practical Implementation Approach

Mogull emphasized that the governance hierarchy is not meant to be implemented all at once. Organizations should start with the core set of cloud services they actually use — most organizations rely on a relatively small number of services for the majority of their workloads — and expand coverage over time. When using CSPM or CNAPP tooling, Mogull strongly recommends applying professional judgment rather than blindly accepting vendor severity ratings. The tool-generated findings should map back to your control specifications, and those specifications should map to your control objectives. This ensures that what you're measuring is actually what you've decided matters for your organization's security posture, not what a vendor's default policy thinks is important.

For practitioners dealing with multiple compliance regimes simultaneously, the key insight is to look for consistencies across regulations first. Requirements around access management, incident reporting, supply chain risk assessment, and continuous monitoring appear in virtually every EU regulation. If your control objectives address these common themes well, the regulation-specific gaps become manageable additions rather than separate compliance programs.

The Sovereignty Problem

Mogull briefly addressed the elephant in the room: data sovereignty under the Cloud Act. Even when a US cloud provider operates with entirely European employees in EU data centers, the US-based parent company is legally compelled to comply with US government data requests. AWS is "probably closest" to meeting data sovereignty requirements, but there are no complete answers yet. The EUCS framework — which was supposed to provide a European certification standard — has been stalled by sovereignty debates.

Demo / Proof of Concept

▶ Watch: The governance hierarchy: framework to control objectives to platform-specifi... (14:00)

No live demo was performed. Mogull's presentation was a strategy and framework talk, delivered with slides covering the registry templates and governance hierarchy structure. He noted that his cat, named AP1337, was supposed to appear in the closing slides but was lost to display issues.

Defensive Implications

▶ Watch: The sovereignty problem: Cloud Act, stalled EUCS, and no complete answers (22:00)

• Build a cloud provider registry immediately. This is the minimum viable compliance artifact for risk assessment requirements across DORA, NIS 2, and GDPR. Document which providers you've approved, for what data types, with what constraints.
• Build a deployment registry. Map every application stack to its cloud location, business owner, and technical lead. This is critical for both sovereignty compliance and incident response.
• Start with the CCM for control objectives. Customize and extend it, but leverage its pre-built regulatory mappings to avoid reinventing cross-framework analysis.
• Use CSPM tooling for control specifications, but apply professional judgment. Don't blindly trust tool severity ratings — select findings that map to your control objectives.
• Focus on consistent regulatory requirements first. Supply chain risk assessment, incident reporting, and access management are common across all EU regulations. Handle those, then address regulation-specific gaps.
• Don't wait for perfect frameworks. The regulatory landscape will continue to evolve. Build an extensible system (the governance hierarchy) that can absorb new requirements incrementally.

Key Takeaways

• Multiple EU regulations are converging on cloud simultaneously, and half the member states have missed their own enforcement deadlines — creating chaos for practitioners.
• Existing frameworks (ISO 27001, ISO 27017) are badly outdated for cloud and provide no actionable guidance for preventing actual breaches.
• Two registries — cloud provider and deployment — satisfy most risk assessment and sovereignty documentation requirements across all major EU regulations.
• The governance hierarchy (framework → objectives → specifications) makes compliance extensible: when a new regulation arrives, you add a mapping column rather than starting over.
• The CCM is the best available starting point for cloud control objectives, despite its gaps, because of its pre-built regulatory framework mappings.
• Data sovereignty under the Cloud Act remains unresolved — there are no complete answers, and the EUCS framework has stalled.

About the Speaker(s)

Rich Mogull is the newly appointed chief analyst at the Cloud Security Alliance, bringing 25 years in security and 15 years in cloud security to the role. He has worked extensively with the European Commission on compliance frameworks and cloud maturity, authored the Cloud Security Maturity Model, and teaches cloud incident response at Black Hat. He is a long-standing speaker at fwd:cloudsec and a prolific analyst in the cloud security space.