EMEA compliance frameworks: the complete guide to GDPR, NIS2, DORA, and 40+ regional mandates

EU GDPR

Any organisation worldwide that processes personal data of EU or EEA residents. No minimum size threshold. No sector restriction.

Organisations build a GDPR programme around documentation while leaving Article 32 technical security measures unquantified and untested. The programme satisfies auditors but would not survive an incident investigation.

Six lawful bases for processing, data subject rights (access, rectification, erasure, portability, objection), mandatory DPIAs for high-risk processing, breach notification to supervisory authorities within 72 hours and to affected individuals without undue delay, DPO appointment where required, and restrictions on cross-border data transfers outside the EEA unless adequacy, SCCs, or binding corporate rules apply.

National supervisory authorities enforce. Fines up to 20 million euros or 4% of global annual turnover for the most serious violations. Irish DPC, Italian Garante, Dutch AP, and German LfDI are consistently active enforcement authorities.

Foundation for all EU member state data protection frameworks. National laws supplement but cannot weaken GDPR. UK GDPR mirrors it post-Brexit. NIS2 security requirements partially overlap Article 32 obligations.

EU NIS2

Essential entities (Annex I: energy, transport, banking, financial market infrastructure, health, water, digital infrastructure, ICT service management, space, public administration) and important entities (Annex II: postal, waste, chemicals, food, manufacturing, digital providers, research). Medium enterprises (50+ employees, 10M+ euro turnover) as general floor.

The 24-hour notification window. Organisations have 72-hour breach notification ingrained from GDPR. NIS2 requires initial notification in 24 hours even before root cause is known. In our assessments, fewer than 20% of incident response procedures account for this distinction. (Vulnox assessment data, 2024)

Risk management measures across 10 areas including incident handling, supply chain security, access control, encryption, and vulnerability disclosure. Initial incident notification to national CSIRT within 24 hours of awareness. Full report within 72 hours. Management bodies must approve security measures and can be personally liable. Board-level cybersecurity training required.

Member states enforce through national competent authorities. Essential entities face fines up to 10 million euros or 2% of global turnover. Important entities up to 7 million euros or 1.4% of global turnover. Management liability is direct and personal.

Transposed into national law by each EU member state. DORA is lex specialis for financial entities and applies instead of NIS2 for entities in its scope.

EU NIS2 Annex

Any organisation assessing whether it falls within NIS2 scope. The Annexes define sector classifications determining essential or important entity status.

Mid-market manufacturers and food producers assuming they are out of scope. Annex II scope is broader than most organisations have mapped.

Annex I lists 11 highly critical sectors. Annex II lists 7 other critical sectors. Classification determines the applicable enforcement regime and fine tier. Organisations must self-assess against the Annexes to determine their NIS2 obligations.

No direct enforcement via the Annexes themselves. But misclassifying out of scope is itself an exposure: national authorities can compel registration and impose obligations retroactively.

Inseparable from NIS2 itself. Scope determination precedes all other NIS2 obligations.

EU DORA

Banks, investment firms, insurance companies, payment institutions, e-money institutions, crypto-asset service providers, and their critical ICT third-party service providers. Mandatory from January 2025.

Financial institutions that completed NIS2 gap analyses assuming DORA is covered. DORA is more prescriptive on ICT third-party contracts, penetration testing frequency, and incident classification than NIS2.

ICT risk management framework, incident classification and reporting, digital operational resilience testing including threat-led penetration testing for significant entities, ICT third-party risk management, and contractual requirements for ICT providers covering exit strategies and audit rights.

National financial regulators enforce. The ESAs oversee critical ICT third-party providers directly. Management bodies bear individual accountability.

Lex specialis relative to NIS2 for financial entities. Builds on EBA GL/2019/04 and supersedes it in significant areas. SAMA CSF and Germany BAIT serve analogous functions in their respective jurisdictions.

EU AI Act

AI system providers, deployers, importers, and distributors placing AI systems on the EU market or using them in the EU. Phased implementation 2024-2027.

Organisations using third-party AI tools in HR processes (automated CV screening, performance assessment) not recognising these as high-risk AI deployments requiring conformity assessment. The classification applies to deployers, not only developers.

Risk-based classification into prohibited, high-risk, limited risk, and minimal risk categories. High-risk AI systems require conformity assessment, technical documentation, human oversight mechanisms, and registration in an EU database. General-purpose AI models face transparency and systemic risk obligations.

National market surveillance authorities enforce. Fines up to 35 million euros or 7% of global turnover for prohibited AI violations. Up to 15 million euros or 3% for high-risk failures.

Intersects with GDPR automated decision-making provisions (Article 22) and NIS2 security requirements. CRA security-by-design requirements apply to AI systems embedded in products with digital elements.

EU Cyber Resilience Act

Manufacturers, importers, and distributors of products with digital elements sold in the EU — including hardware with embedded software, standalone software, and connected devices.

SaaS providers assuming the CRA does not apply to them. Remote data processing services are excluded — but SaaS providers that also distribute downloadable software components, SDKs, or on-premise versions fall within CRA scope for those components.

Security by design across the product lifecycle, free security updates for the product''s support period, vulnerability disclosure to ENISA within 24 hours of awareness of an actively exploited vulnerability, and conformity assessment resulting in CE marking for cybersecurity.

National market surveillance authorities enforce. Fines up to 15 million euros or 2.5% of global turnover for serious violations. Products failing conformity can be withdrawn from the EU market.

Complements NIS2: NIS2 governs how critical infrastructure operators secure their systems; CRA governs the security of the products they purchase. The CRA Annexes define specific product categories and conformity routes.

EU Cyber Resilience Act Annexes

Manufacturers determining specific CRA obligations. The Annexes define essential cybersecurity requirements and product classifications.

Manufacturers of Class II products (browsers, password managers, network management software, industrial firewalls) underestimating third-party conformity assessment lead times.

Annex I specifies essential cybersecurity requirements. Annex II and III classify critical products into Class I (enhanced self-assessment) and Class II (third-party conformity assessment) categories.

The Annexes determine conformity route: self-assessment versus third-party audit. Class II products require notified body involvement, with significant cost and timeline implications.

Technical specification layer for the CRA. Cannot be read in isolation from the main regulation.

EU PSD2

Payment institutions, e-money institutions, banks offering payment services, AISPs, and PISPs operating in the EU.

E-commerce businesses assuming their payment gateway handles all PSD2/SCA compliance. SCA exemptions require active implementation by merchants, not just passive reliance on acquirers.

Strong Customer Authentication for electronic payments. Open banking APIs enabling licensed TPP access to payment account data. Major security incident reporting to national financial regulators. EBA Regulatory Technical Standards specify SCA implementation.

National financial regulators enforce. Enforcement has focused heavily on SCA implementation failures.

Overlaps with DORA for regulated payment institutions. Forthcoming PSD3 will tighten requirements. Intersects with GDPR on processing of payment account data by TPPs.

EU EBA GL/2019/04

Banks, investment firms, and payment institutions regulated under EU banking legislation.

Organisations that achieved EBA GL/2019/04 compliance assuming it constituted DORA readiness. DORA is more prescriptive particularly on third-party risk and resilience testing.

ICT governance framework, information risk assessments, security requirements covering access management and encryption, ICT operations management, and incident management. Precursor standard to DORA.

Enforced by national banking regulators as supervisory expectations under CRD IV. Substantially superseded by DORA for entities in DORA''s scope.

Direct predecessor to DORA. Germany BAIT operates in parallel for German BaFin-regulated institutions.

Germany C5:2020

Cloud service providers targeting German public sector or regulated industry customers. Third-party attestation by accredited auditors required.

Assuming ISO 27001 satisfies C5. The overlap is significant but incomplete. C5 includes transparency disclosure requirements and specific technical controls around multi-tenancy isolation that ISO 27001 does not address. An ISO 27001 certificate and a C5 attestation are different documents serving different purposes.

17 control domains including organisation of information security, human resources, physical security, identity management, cryptography, communications, incident management, and business continuity. Attestation reports must disclose the system description and control testing results.

Functionally mandatory for German public sector and regulated industry market access. Without a current C5 attestation, cloud providers cannot realistically compete for German government contracts.

Aligns with ISO 27001 and SOC 2 but addresses German cloud procurement specifically. Structural parallel to Spain ENS for public sector market access.

Germany BAIT

Banks, savings banks, and financial institutions regulated by BaFin in Germany.

German financial institutions treating BAIT and DORA as sequential rather than simultaneous obligations. DORA is directly applicable from January 2025. BAIT continues as BaFin national guidance for DORA implementation.

IT governance with defined IT strategy, information risk management, information security management, IT operations, access management, outsourcing, and user-developed IT. BaFin expects demonstrable compliance through supervisory examinations.

BaFin supervisory examinations. Non-compliance can trigger capital add-ons, remediation orders, or management accountability actions.

National complement to EBA GL/2019/04 and DORA for German financial institutions.

Germany

Organisations operating in Germany subject to GDPR/BDSG, BSI Act and IT Security Act 2.0, and KRITIS regulations for critical infrastructure.

Foreign companies with German operations appointing a DPO for EU purposes and assuming it covers BDSG. BDSG''s mandatory DPO threshold (20+ employees processing personal data automatically) is lower than GDPR''s general threshold.

BDSG supplements GDPR with mandatory DPO appointment for organisations with 20+ employees regularly processing personal data automatically. KRITIS operators must implement state-of-the-art security measures and report significant incidents to BSI. NIS2UmsuCG extends obligations to a broader sector set.

State data protection authorities enforce GDPR/BDSG. BSI enforces cybersecurity obligations. Germany has some of Europe''s most active DPAs.

National layer on top of GDPR, NIS2, and DORA. German organisations also face C5 requirements for cloud procurement and BAIT for banking.

Austria

Organisations operating in Austria subject to GDPR/DSG and NIS2 via the Austrian NISG.

Assuming the DSB is the only relevant authority. Regulated sector organisations face parallel oversight from their sector regulator.

DSG supplements GDPR with Austrian provisions. NISG transposes NIS2 with RTR involvement in cybersecurity oversight for electronic communications.

Austrian Data Protection Authority (DSB) enforces GDPR/DSG. RTR and sector regulators enforce NISG. Co-enforcement model with multiple competent authorities across sectors.

Standard EU member state implementation. No significant national additions beyond the EU baseline outside of NISG procedural requirements.

Belgium

Organisations operating in Belgium subject to GDPR (Belgian DPA), NIS2 via national legislation, and voluntary CCB CyberFundamentals Framework guidance.

Treating CCB guidance as optional. For essential entities under NIS2, CCB implementing measures are binding requirements.

Belgian DPA enforces GDPR with an active track record particularly in direct marketing and cookie consent. CCB coordinates national incident response and publishes CyberFundamentals providing a practical four-tier security baseline.

Belgian DPA has been active against major platforms for cookie consent non-compliance. CCB issues binding cybersecurity measures for NIS2-scope essential entities.

Standard EU member state implementation. CCB CyberFundamentals is Belgium''s practical NIS2 implementation contribution.

Greece

Organisations operating in Greece subject to GDPR (HDPA) and NIS2 via national law with NCA coordination.

Underestimating the HDPA. Smaller member states'' authorities are systematically overlooked in multi-jurisdiction GDPR compliance programmes.

HDPA enforces GDPR with demonstrated willingness to impose significant fines. NCA coordinates cybersecurity for NIS2-scope entities.

HDPA enforcement is more active than its reputation suggests. A 1 million euro fine against a major telecom for direct marketing violations was issued in 2023.

Standard EU member state layer.

Hungary

Organisations operating in Hungary subject to GDPR (NAIH) and NIS2 via national law.

Employee monitoring deployments that comply with GDPR interpretations in Western Europe but fall afoul of NAIH''s proportionality requirements in workplace monitoring contexts.

NAIH enforces GDPR. Hungary has transposed NIS2 with sector competent authorities for energy, transport, water, and digital infrastructure.

NAIH enforcement has been active on CCTV, employee monitoring, and direct marketing.

Standard EU member state layer.

Ireland

Technology companies, financial services, and multinationals with EU headquarters in Ireland. DPC is lead GDPR supervisory authority for Irish-established organisations.

Multinationals with Irish EU headquarters treating DPC engagement as procedural. A DPC fine is not a local Irish issue.

DPC enforces GDPR as lead authority for many major US tech platforms. Ireland''s NCSC coordinates national cybersecurity. NIS2 transposed through national legislation.

DPC has imposed some of the largest GDPR fines on record: 1.2 billion euros against Meta in 2023, 405 million against Instagram, 265 million against Facebook. DPC outcomes bind all EU member states.

Ireland''s significance is disproportionate to its size because of its role as lead authority for major tech platforms.

Italy

Organisations operating in Italy subject to GDPR (Garante), NIS2 (coordinated by ACN), and the Golden Power framework for critical infrastructure.

AI and data-intensive platforms launching in the EU without Italy-specific DPA impact assessment. The Garante''s 30-day ChatGPT operational suspension was a concrete demonstration of the risk.

Garante is one of Europe''s most aggressive GDPR enforcement authorities. ACN oversees NIS2 compliance with detailed guidance for essential and important entities.

Garante fines are consistent and significant: 20 million euros against Clearview AI, temporary ChatGPT ban in March 2023, major actions against TikTok and Enel.

Garante enforcement risk and ACN cybersecurity oversight are distinct national layers. Golden Power creates additional deal-clearance obligations for M&A involving Italian critical infrastructure.

Netherlands

Organisations operating in the Netherlands subject to GDPR (AP), NIS2 (NCSC-NL), and sector-specific DNB requirements for financial institutions.

Financial institutions satisfying DORA at the EU level but not mapping against DNB national guidance, which goes beyond DORA''s baseline in outsourcing oversight.

Dutch AP is an active enforcer. DNB issues additional operational resilience requirements for financial institutions that layer on top of DORA.

AP fines have reached 750,000 euros in recent cases. DNB supervisory expectations for operational resilience are among the most detailed in the EU for the financial sector.

Standard EU member state layer with notably active DPA and above-average financial sector regulatory depth.

Norway

Organisations operating in Norway subject to GDPR via EEA membership (Datatilsynet) and NSM cybersecurity guidance. Norway is EEA but not EU.

Treating Norway as functionally equivalent to an EU member state. The GDPR one-stop-shop mechanism does not operate the same way for EEA-only states, and Norway has its own national cybersecurity governance track.

GDPR applies through EEA incorporation. NSM Basic Principles for ICT Security provides a practical security baseline. Financial sector faces FSA (Finanstilsynet) ICT requirements.

Datatilsynet enforces GDPR. NSM guidance informs regulatory expectations without direct enforcement authority.

EEA-adjacent to EU frameworks with distinct national cybersecurity governance. NSM guidance is more detailed than many EU member states'' NIS2 implementations.

Poland

Organisations operating in Poland subject to GDPR (UODO), NIS2 via the KSC Act, and KNF financial requirements.

Cookie consent implementations that satisfy DPC or German DPA standards but fail UODO requirements on consent granularity and pre-ticking.

UODO enforces GDPR with particular focus on cookie consent and direct marketing. KSC Act transposes NIS2 with CERT Polska as the national coordination infrastructure.

UODO enforcement has increased significantly since 2021. Polish UODO has taken stricter positions on consent granularity than some other EU authorities.

Standard EU member state layer with above-average UODO enforcement focus on consent mechanisms.

Serbia 87/2018

Organisations operating in Serbia or processing personal data of Serbian residents. GDPR-aligned but outside the EU enforcement architecture.

Organisations assuming pre-GDPR adequacy continues indefinitely. Serbia''s adequacy status for EU data transfers is contingent on ongoing framework alignment.

Rights of access, rectification, erasure, and restriction. Security measure obligations. Commissioner for Information of Public Importance enforces.

Lower enforcement intensity than EU member state DPAs currently, but EU accession trajectory means enforcement will increase.

GDPR-modelled but outside EU enforcement architecture. Useful for organisations mapping GDPR-plus-Serbia data flows.

Spain 1720/2007

Compliance professionals reviewing historical obligations or legacy system security baselines. Superseded by GDPR and LOPDGDD.

Organisations updating legacy compliance documentation carrying forward RD 1720/2007 references without updating to current LOPDGDD/GDPR language.

Established three security levels (basic, medium, high) for personal data based on sensitivity. The classification logic still informs Spanish DPA practice under GDPR.

Not independently enforced. Current framework is GDPR/LOPDGDD.

Historical precursor. Three-tier security level logic has parallels in ENS basic/medium/high classification.

Spain 311/2022 (ENS)

Spanish public administration bodies and technology vendors providing IT services or products to the Spanish public sector. ENS certification mandatory for public sector contracts.

Vendors pursuing ENS certification after contract award. ENS certification timelines of 6 to 18 months for first-time applicants mean the process must start before bidding, not after winning.

System classification into basic, medium, or high categories based on risk impact. Mandatory controls per category across five security dimensions. ENS certification from accredited auditors required for vendors.

CCN-CERT oversees ENS implementation. Vendors without ENS certification cannot contract with Spanish public administration. Market access control.

Spain''s equivalent of Germany C5 as a public sector market-access security standard. CCN-STIC 825 is the cloud-specific implementation guide.

Spain BOE-A-2022-7191

Legal reference for ENS obligations in Spanish public sector contracts. Same scope as Spain 311/2022.

Contract documentation referencing the BOE citation without mapping to the substantive requirements of RD 311/2022.

Official Spanish Official Gazette citation for Royal Decree 311/2022. Used as the formal legal reference for ENS compliance obligations.

Same as Spain 311/2022. Administrative layer on the substantive requirements.

Administrative citation layer for Spain 311/2022. No substantive difference.

Spain CCN-STIC 825

Cloud service providers seeking ENS certification for Spanish public sector customers and public administration bodies adopting cloud.

Cloud providers mapping ISO 27017 controls to CCN-STIC 825 without addressing Spain-specific data residency and sovereignty requirements.

Technical guidance for implementing ENS controls in cloud environments: shared responsibility models, data residency requirements, VM isolation, audit logging for cloud tenants, and identity federation.

Enforced through the ENS certification process. Required as part of ENS cloud certification.

Technical implementation companion to ENS. Read together with Spain 311/2022.

Sweden

Organisations operating in Sweden subject to GDPR (IMY), NIS2 via national law, MSB MSBFS regulations for public sector, and NATO obligations following 2024 accession.

Public authorities that implemented MSB MSBFS as a standalone framework without integrating NIS2 obligations from 2024.

IMY enforces GDPR. MSB MSBFS 2020:7 mandates structured information security management for public authorities. NIS2 transposed through national law.

IMY is increasingly active. MSB MSBFS compliance is mandatory for public sector with consequences documented in annual MSB reviews.

Standard EU member state layer with notable public sector depth and emerging NATO obligations.

Switzerland

Organisations operating in Switzerland or processing personal data of Swiss residents. Financial institutions face additional FINMA ICT requirements.

EU-based organisations treating revFADP as identical to GDPR without implementing Swiss-specific requirements, particularly the different breach notification structure and representative appointment.

Revised FADP (revFADP) effective September 2023 requires DPIAs for high-risk processing, privacy notices, breach notification, and Swiss representative appointment for foreign organisations processing Swiss data at scale.

FDPIC enforcement. Switzerland has EU adequacy status but is not in the EEA — parallel compliance obligations apply.

Adjacent to but outside the EU framework. Substantially aligned with GDPR but legally distinct.

Turkey

Organisations operating in Turkey or processing personal data of Turkish residents. KVKK Law No. 6698 applies.

Organisations with Turkish operations not registering with VERBİS. Registration is mandatory for data controllers processing Turkish personal data above minimal thresholds regardless of the controller''s location.

Data controller registration with the VERBİS registry, consent-based processing as default, cross-border transfer restrictions, and technical security measures. Turkey is pursuing EU adequacy.

KVKK Board enforcement is active for VERBİS non-registration and inadequate security measures.

Outside the EU but GDPR-modelled. Cross-border transfer restrictions create friction for EU-Turkey data flows.

UK DPA

Organisations operating in the UK or processing personal data of UK residents. UK GDPR and DPA 2018 together form the UK data protection framework post-Brexit.

Post-Brexit organisations maintaining a single EU GDPR programme and assuming it covers UK obligations. UK and EU frameworks have diverged in adequacy decisions and transfer mechanisms.

Substantively equivalent to EU GDPR with UK-specific adequacy decisions, UK International Data Transfer Agreements for cross-border transfers, and ICO-specific guidance. 72-hour breach notification to ICO.

ICO fining powers up to 17.5 million pounds or 4% of global turnover. Substantial fines against British Airways, Marriott, and DSG Retail.

UK-specific parallel to EU GDPR. Legally distinct parallel obligation for organisations with both EU and UK operations.

UK CAF v4.0

UK operators of essential services and digital service providers under UK NIS Regulations. Regulated by Ofcom, Ofgem, FCA, and sector regulators.

Operators completing CAF self-assessments as a documentation exercise without evidence-based control testing. UK regulators have stated clearly that assertions without evidence are not satisfactory.

14 cybersecurity principles across four objectives: managing security risk, protecting against cyberattack, detecting cybersecurity events, and minimising impact. Used by UK regulators to assess NIS compliance.

Regulators can impose fines up to 17 million pounds for serious NIS failures. CAF outcomes feed into regulatory risk ratings.

UK equivalent to EU NIS2 at the assessment level. More detailed than NIS2''s security requirements in its principle-level guidance. DEFSTAN 05-138 Issue 4 now aligns with CAF v4.0.

UK CAP 1850

UK-regulated aviation organisations including airlines, airports, air navigation service providers, and aviation maintenance and technology suppliers.

Aviation organisations treating IT security and OT/avionics security as separate programmes. CAP 1850 covers the full aviation environment.

Cybersecurity risk management processes consistent with ICAO and EASA requirements. CAP 1850 maps CAF principles to aviation-specific contexts covering aircraft systems, airport OT, and air traffic management.

CAA oversight. Aviation cybersecurity failures can result in Air Operator Certificate conditions and operational restrictions.

Sector-specific application of CAF principles to aviation. Works alongside UK DPA and CAF v4.0.

UK Cyber Essentials

UK organisations bidding for government contracts involving personal data or sensitive information. Mandatory since 2014.

ISO 27001-certified organisations assuming they qualify for government contracts without Cyber Essentials. ISO 27001 does not substitute for Cyber Essentials in UK government procurement.

Five controls: boundary firewalls, secure configuration, user access control, malware protection, and patch management (critical patches within 14 days). Cyber Essentials Plus adds independent technical verification. Annual renewal required.

Contract qualification requirement. No Cyber Essentials certification means no qualifying UK government contracts.

Entry-level UK cybersecurity baseline. Supply chain security gating mechanism that CAF does not provide.

UK DEFSTAN 05-138

UK MOD suppliers and subcontractors handling MOD information or operating on MOD networks. Mandatory for MOD contracts.

Defence suppliers who achieved DEFSTAN 05-138 compliance against an earlier issue and have not assessed the Issue 4 changes. Issue 4''s CAF alignment and tiered model are substantive changes.

Issue 4 (May 2024) introduced a tiered requirements model based on information sensitivity, aligning with NCSC CAF v4.0. Covers governance, risk management, access control, incident response, and supply chain security.

MOD contract requirement. Non-compliance results in contract termination or disqualification from defence procurement.

UK defence-specific standard alongside Cyber Essentials and CAF v4.0.

Israel

Organisations operating in Israel or transferring data to or from Israel. Israel has EU adequacy status.

Organisations relying on Israel''s EU adequacy status without maintaining the security measures that underpin that adequacy finding.

Privacy Protection Law (5741-1981) governs personal data with ongoing reform toward GDPR-level standards. INCD issues sector-specific cybersecurity directives.

Privacy Protection Authority enforces. INCD directives have sector-specific enforcement through licensing authorities.

CDMO v1.0 is the operational security layer. Privacy Protection Law is the data protection layer.

Israel CDMO v1.0

Israeli organisations using it as a structured self-assessment tool. Sector-specific mandatory requirements may reference CDMO.

Treating CDMO as a documentation exercise. The protection domain includes specific technical controls requiring evidence-based testing.

Controls across protection, detection, and response domains. Aligns with NIST CSF. Used by INCD as a baseline for sector-specific cybersecurity requirements.

Voluntary framework for most, mandatory-by-reference in several INCD sector directives for critical infrastructure.

Operational companion to Israel''s Privacy Protection Law. NIST CSF alignment makes it mappable to other frameworks.

UAE NIAF

UAE federal government entities, critical infrastructure operators, and technology vendors providing services to UAE government.

Vendors assuming ISO 27001 satisfies NIAF contractual requirements without verifying the specific NIAF control mapping their UAE government customer requires.

Information security controls across governance, operations, and technical domains aligned with international standards. Mandatory for UAE federal government entities.

TDRA oversight. Vendors providing services to UAE government face contractual NIAF requirements.

UAE federal government baseline. Structurally similar in function to Saudi Arabia''s national framework at the federal level.

Saudi Arabia ECC-1 2018

All Saudi government organisations, critical national infrastructure operators, and their ICT service providers.

Organisations achieving ECC-1 compliance and assuming it covers OTCC-1, CGIoT-1, or CSCC-1 obligations. ECC-1 is the floor. The sector-specific standards add requirements on top.

Five domains covering cybersecurity governance, defence, resilience, third-party and cloud cybersecurity, and industrial control systems. 114 controls. Mandatory baseline from which all other Saudi NCA frameworks derive.

NCA conducts assessments and audits. Non-compliant entities face formal remediation requirements.

Foundation layer of Saudi Arabia''s national cybersecurity stack. OTCC-1, CGIoT-1, CSCC-1, and SAMA CSF all reference ECC-1 as baseline.

Saudi Arabia OTCC-1 2022

Government entities and CNI operators with OT environments: energy, utilities, manufacturing, water, transportation.

IT security teams applying IT-based patch management processes to OT environments. OTCC-1 acknowledges OT patch constraints and requires compensating controls when patching is not feasible.

OT-specific security controls: ICS/SCADA asset inventory, IT/OT network segmentation, OT-specific access control, vulnerability management adapted for operationally constrained environments, and OT incident response.

NCA mandatory assessment for in-scope OT operators. Failures can trigger NCA intervention and operational restrictions.

Builds on ECC-1. Mandatory for OT environments alongside ECC-1.

Saudi Arabia CGIoT-1:2024

IoT device manufacturers, system integrators, and government or CNI operators deploying IoT in Saudi Arabia.

Consumer IoT manufacturers assuming CGIoT-1 applies only to enterprise-grade equipment. The scope includes connected consumer devices in government or CNI worker facility contexts.

Device security (secure boot, minimal default credentials, firmware signature), communications protection (encrypted transmission, certificate management), data security, and operational controls across IoT ecosystems.

NCA mandatory for in-scope IoT deployments in government or CNI contexts.

IoT-specific layer of the Saudi cybersecurity stack alongside ECC-1 and OTCC-1. More operationally specific than the EU CRA for IoT, though both address product-level security by design.

Saudi Arabia CSCC-1 2019

Cloud service providers operating in Saudi Arabia targeting government or regulated sector customers.

Multi-cloud providers hosting Saudi government data in UAE or Bahrain data centres assuming regional proximity satisfies Saudi data residency requirements. CSCC-1 requires data residency within Saudi Arabia itself.

Data residency in Saudi Arabia for government data, security controls across 14 domains, incident management, and third-party auditing.

CITC oversight. Required for Saudi government cloud procurement. Without CSCC-1 compliance, cloud providers cannot service Saudi government customers.

Cloud-specific layer of the Saudi compliance stack alongside ECC-1. Structural parallel to Germany C5.

Saudi Arabia SAMA CSF v1.0

Banks, insurance companies, finance companies, and payment service providers regulated by SAMA.

SAMA-regulated institutions submitting self-assessments scoring at Maturity Level 3 without operational evidence. SAMA examiners cross-check self-reported scores against actual system configurations and audit trails. The gap between self-reported and demonstrable maturity is the consistent finding in our Saudi financial sector assessments. (Vulnox assessment data, 2024)

Four domains: cybersecurity leadership and governance, risk management and compliance, operations and technology, and third-party cybersecurity. 140+ controls. Annual self-assessment submitted to SAMA. SAMA examination reviews self-assessment accuracy.

SAMA examinations assess compliance. Deficiencies result in findings requiring remediation. Repeated failures can result in regulatory sanctions.

Saudi Arabia''s equivalent of DORA/BAIT for financial institutions. Works on top of ECC-1.

Saudi Arabia SACS-002

Technology vendors, system integrators, and service providers seeking access to Saudi government systems and networks.

Vendors achieving ECC-1 compliance and assuming SACS-002 is covered. SACS-002 includes third-party-specific access management and secure remote access requirements not fully addressed by ECC-1.

Security controls commensurate with the sensitivity of government data the vendor will access: access management, secure development, system hardening, and security monitoring for vendor systems connecting to government infrastructure.

Prerequisite for government system access. Without SACS-002 compliance demonstration, vendors cannot connect to Saudi government networks.

Supply chain security layer for Saudi government system access. Works alongside ECC-1. Functional equivalent to UK DEFSTAN 05-138 in the supply chain context.

Saudi Arabia Personal Data Protection Law

Organisations operating in Saudi Arabia or processing personal data of Saudi residents. SDAIA enforces.

Multinationals extending GDPR programmes to Saudi Arabia without addressing the PDPL-specific provisions, particularly the cross-border transfer regime which is more restrictive than GDPR''s SCC mechanism.

Consent-based processing as default, data subject rights (access, correction, deletion), cross-border transfer restrictions requiring SDAIA approval or adequate protection finding, DPO appointment for high-volume processors, and mandatory breach notification.

SDAIA enforcement. Fines up to SAR 5 million. Saudi Arabia is in early enforcement phase with developing regulatory guidance.

Saudi Arabia''s data protection layer. PDPL and ECC-1 together form the baseline compliance obligation for most Saudi operations.

Qatar PDPPL

Organisations operating in Qatar or processing personal data of Qatari residents.

Treating PDPPL as a simplified GDPR without addressing the consent requirements, which are structured differently from GDPR''s multi-ground lawful basis model.

Consent for processing, data subject rights (access and correction), security measures appropriate to data sensitivity, and breach notification. Ministry of Transport and Communications administers.

Developing enforcement posture. Framework is in place but enforcement intensity is currently lower than EU equivalents.

Gulf state data protection framework. Less developed than Saudi Arabia''s PDPL. Organisations operating across the GCC face PDPPL, Saudi PDPL, and UAE data protection as distinct but thematically similar obligations.

Russia

Organisations operating in Russia or processing personal data of Russian citizens. Multinationals with Russian customers or employees.

Organisations assessing Russia as too complex and avoiding the jurisdiction without establishing whether they already process Russian citizen data through global platforms.

Federal Law 152-FZ requires personal data of Russian citizens to be stored on servers in Russia. Federal Law 187-FZ on Critical Information Infrastructure imposes security requirements and mandatory incident reporting for CII operators. Roskomnadzor enforces data protection. FSTEC oversees CII cybersecurity.

Roskomnadzor has blocked platforms that refused localisation requirements (LinkedIn blocked since 2016). Geopolitical context means enforcement unpredictability is higher than in other jurisdictions.

Structurally incompatible with GDPR cross-border transfer mechanisms. Russian data localisation requirements mean GDPR-compliant data flows cannot route Russian citizen data through EU infrastructure while satisfying both laws simultaneously.

South Africa POPIA

Public and private bodies processing personal information of South African data subjects. Information Officer appointment mandatory.

Organisations that registered an Information Officer but have not built the operational procedures for breach detection, data subject request handling, and notification workflows that POPIA requires.

Eight conditions for lawful processing. Breach notification to the Information Regulator and affected data subjects. Information Officers must be registered with the Information Regulator.

Information Regulator demonstrating enforcement willingness. Fines up to R10 million and imprisonment for serious violations.

Africa''s most developed data protection framework. Eight conditions map closely to GDPR principles, making dual-compliance relatively efficient for organisations already running GDPR programmes.

Kenya DPA 2019

Organisations operating in Kenya or processing personal data of Kenyan residents. ODPC registration required for data controllers.

Multinationals with Kenyan operations running GDPR programmes and assuming ODPC registration is not required because they are EU-established. Registration obligations apply regardless of controller establishment location.

GDPR-aligned principles with ODPC registration requirement. Data processors must operate under written agreements with controllers.

ODPC enforcement is developing. Registration compliance is being actively pursued.

East Africa''s primary data protection framework. Works alongside POPIA for organisations with pan-African operations.

Nigeria DPR 2019

Organisations operating in Nigeria or processing personal data of Nigerian residents. Now transitioning to the Nigeria Data Protection Act 2023 (NDPA).

Organisations complying with NDPR and not assessing NDPA 2023 obligations. The transition is not automatic — NDPA introduces expanded data subject rights and more structured DPIA obligations.

NDPR required lawful processing, data subject rights, security safeguards, mandatory DPIAs for high-volume processing, and annual audits submitted to NITDA. The NDPA 2023 establishes the Nigeria Data Protection Commission with broader enforcement powers.

NITDA has issued fines and enforcement notices. NDPC under NDPA has broader enforcement powers. Nigeria''s enforcement is among the more active in Africa.

West Africa''s primary data protection framework. The NDPA 2023 transition is the current operational priority for organisations with Nigerian operations.

The triggering criteria, notification destinations, and content requirements differ for each framework. A financial institution suffering a ransomware attack that does not expose personal data could trigger both NIS2 and DORA notifications but not a GDPR breach notification. The same team owns all three obligations but the processes cannot be unified without losing the distinctions each regulator requires.

Security incident detection and notification. All three require security measures and breach or incident reporting, but with different triggering criteria and timelines. GDPR: 72-hour breach notification for personal data breaches. NIS2: 24-hour initial notification for significant network and information system incidents regardless of personal data involvement. DORA: classification-triggered notification timelines for ICT incidents at financial entities.

DORA is lex specialis for financial entities — it applies instead of NIS2 rather than alongside it. But the boundary is not perfectly clean for financial entities that also operate NIS2-scope digital infrastructure. In practice, DORA-compliant financial entities that also qualify as NIS2 essential entities should map both frameworks and identify the deltas rather than assuming DORA coverage is complete.

ICT risk management, supply chain security, and resilience testing for financial entities.

NIS2 governs how operators of essential services secure their infrastructure. The CRA governs the security of the products they buy. A manufacturer of industrial control system software must comply with the CRA. An energy company using that software must comply with NIS2. The CRA''s 24-hour exploited vulnerability reporting to ENISA is stricter than NIS2''s significant incident notification timeline.

Vulnerability disclosure and security update obligations for digital products and services.

ECC-1 is the baseline. SAMA CSF adds financial-sector controls and a structured self-assessment mechanism. OTCC-1 adds OT-specific controls. A SAMA-regulated bank that also operates ICS for facility management is subject to all three simultaneously. The controls overlap in governance and access management but diverge in OT-specific and financial-sector-specific layers.

Governance, access control, incident response, and third-party risk management.

UK DPA governs personal data protection with ICO enforcement. CAF governs critical infrastructure cybersecurity with sector regulator enforcement. For UK operators of essential services that also process significant personal data, both apply simultaneously. ICO and the sector regulator may both investigate the same incident under their respective frameworks.

Security of personal data processing systems and incident detection and response.

Treating GDPR as the complete EMEA compliance answer

GDPR is the most prominent regulation in the group. Organisations with limited compliance resources focus where the noise is loudest. The EU-wide regulations that came after — NIS2, DORA, the AI Act, the CRA — are newer, less familiar, and genuinely more complex to scope. So organisations build a GDPR programme and file ''EMEA compliance'' as complete.

NIS2-scope organisations without NIS2 programmes face fines up to 2% of global turnover and personal management liability. Financial entities without DORA programmes have been in violation since January 2025. Manufacturers selling connected devices into the EU without CRA conformity assessment plans face CE marking revocation. None of these risks appear on a GDPR-only compliance register.

Assuming ISO 27001 satisfies national market-access security standards

ISO 27001 is globally recognised and consistently referenced. Compliance teams that have invested in ISO 27001 naturally assume it satisfies related security requirements. The assumption is partially correct — ISO 27001 informs C5, ENS, SAMA CSF, UAE NIAF, and others. But ''informs'' is not ''satisfies.'' The national standards include jurisdiction-specific requirements that ISO 27001 does not mandate.

Lost government contracts in Germany, Spain, and Saudi Arabia where C5, ENS, and CSCC-1 are prerequisites. The market access cost of the assumption is measured in contract losses, not compliance fines.

Missing the product-security dimension: manufacturers assuming security is the customer''s problem

Software and hardware manufacturers have historically viewed security as an enterprise IT concern where the customer is responsible for securing their environment. The EU Cyber Resilience Act fundamentally changes this by placing security obligations on the manufacturer throughout the product lifecycle, including vulnerability disclosure and update provision after sale. Most manufacturers'' legal teams have not yet internalised this shift.

A manufacturer of industrial automation software that does not implement the CRA''s vulnerability disclosure requirement faces fines up to 15 million euros and potential market withdrawal orders. The 2027 full applicability date feels distant — but attestation processes, product redesign for security by default, and vulnerability management programme builds take 18 to 36 months.

Running a single cross-border data transfer programme that does not account for jurisdiction-specific transfer restrictions

Multinational compliance teams build GDPR-centric transfer frameworks using SCCs and extend them globally as the default mechanism. This fails for Russia (localisation requirement makes SCCs irrelevant), Saudi Arabia (PDPL transfer regime requires separate SDAIA mechanisms), and Turkey (requires adequacy or explicit consent under KVKK, not SCCs in the EU sense).

A retail company with customers in Russia, Saudi Arabia, and the EU running a single GDPR-compliant data transfer programme is potentially non-compliant under Russian 152-FZ and Saudi PDPL simultaneously. These are operational exposures for organisations processing data in these jurisdictions.