Pillar Guide · Regulatory Compliance

Global Regulatory Compliance Hub: The Enterprise Guide for 2026

A comprehensive framework for navigating cross-jurisdictional compliance obligations — covering financial services, data privacy, AI regulation, ESG, and third-party risk across every major regulatory zone.

Updated October 2026
·
Compliance · Risk · Governance
·
Crest.Digital

In this guide

Why Global Compliance Has Become Operationally Critical
The Regulatory Landscape: What Has Changed
Compliance by Region: Key Obligations
Regulatory Convergence: Where Frameworks Overlap
Designing a Cross-Jurisdictional Compliance Program
Third-Party Compliance Risk
Key Resources in This Guide
Crest Perspective
Risk programmes that treat third-party governance as a compliance checkbox are consistently underprepared when a material vendor incident occurs. The programmes that withstand regulatory scrutiny are not necessarily the most technologically sophisticated — they are the ones where risk tiering is documented, escalation paths are tested before they are needed, and the board receives accurate, timely information about the organisation’s most critical vendor dependencies.
Frequently Asked Questions

Global regulatory compliance is no longer a legal department function. It is an operational requirement that touches procurement, vendor management, product development, data infrastructure, and finance. Enterprises operating across multiple jurisdictions face a compounding set of obligations — many of which apply extraterritorially, penalise third-party non-compliance, and change on timescales that outpace annual review cycles. This guide maps the current landscape, identifies where obligations converge, and provides a framework for building compliance programmes that hold under audit.

Why Global Compliance Has Become Operationally Critical

The regulatory environment enterprises face in 2026 is categorically different from five years ago. Three forces have driven this change: extraterritorial reach, third-party liability, and the arrival of AI regulation.

Extraterritorial reach is now the default

GDPR established the principle that data protection law follows the data subject, not the controller’s jurisdiction. That principle has now been adopted across data privacy, AI regulation, financial crime, and supply chain due diligence. An enterprise headquartered outside the EU that processes EU residents’ personal data, deploys a high-risk AI system in the EU market, or sources goods from a supply chain with forced labour exposure can face enforcement regardless of where it is incorporated.

Third-party non-compliance creates first-party liability

Regulations including the EU Corporate Sustainability Due Diligence Directive (CSDDD), the UK Modern Slavery Act, the German Supply Chain Act (LkSG), the EU AI Act, and the US Dodd-Frank conflict minerals rules all create direct obligations on the enterprise for its suppliers’ conduct. Compliance programmes that stop at the enterprise perimeter are insufficient. See: Federal TPRM: Managing Vendor Risk in Government Contracts.

AI regulation has arrived

The EU AI Act applies from August 2026. It creates binding obligations for high-risk AI systems — including conformity assessments, audit trails, and human oversight mechanisms — and applies to any enterprise deploying such systems into the EU market. Combined with the White House AI Accord, ISO 42001, and sector-specific AI guidance from the FCA, ACRA, and banking regulators, AI governance has become a compliance requirement, not a best-practice aspiration.

The defining characteristic of the current compliance environment is simultaneity: enterprises must manage multiple overlapping frameworks at the same time, across multiple jurisdictions, with shared infrastructure — procurement, data, vendors, AI systems — touching all of them at once.

The Regulatory Landscape: What Has Changed

The following table maps the major regulatory frameworks enterprises face in 2026, their jurisdictional scope, their third-party provisions, and their enforcement posture.

Framework	Domain	Jurisdiction	Extraterritorial	Third-Party Obligations	Type
EU AI Act	AI risk	EU / EEA	Yes	Conformity requirements on providers and deployers	Binding
GDPR / UK GDPR	Data privacy	EU, UK	Yes	Processor agreements, DPIAs on vendors	Binding
DPDP Act (India)	Data privacy	India	Yes	Data fiduciary obligations extend to data processors	Binding
PDPA (Singapore)	Data privacy	Singapore	Yes	Mandatory data protection by design, transfer controls	Binding
CCPA / CPRA	Data privacy	California / US	Partial	Service provider contracts, data sharing agreements	Binding
CSDDD	ESG / supply chain	EU	Yes	Direct due diligence obligations on value chain	Binding
LkSG (Germany)	Supply chain	Germany	Yes	Mandatory risk analysis of direct and indirect suppliers	Binding
UK Modern Slavery Act	Human rights	UK	Yes	Statement covers entire supply chain	Binding
6AMLD / FATF	Financial crime / AML	EU + global	Yes	Beneficial ownership verification, enhanced due diligence	Binding
UAE CBUAE ORM	Operational risk	UAE	No	Mandatory TPRM programme for regulated entities	Binding
DORA (EU)	Digital resilience	EU	Yes	ICT third-party risk management, register of contracts	Binding
ISO 27001 / SOC 2	Information security	Global	—	Vendor security assessments	Voluntary
ISO 42001	AI management	Global	—	AI governance requirements across supply chain	Voluntary
NIST AI RMF	AI risk	US	—	Third-party AI risk baseline	Voluntary
ACRA APG (Singapore)	Audit / AI	Singapore	No	AI systems in financial reporting must be assessed	Sector
FCA AI Guidance (UK)	Financial services	UK	No	Senior manager accountability for vendor AI	Sector
SEBI / RBI AI (India)	Financial services	India	No	AI risk disclosures; model governance for regulated entities	Sector

For AI-specific regulatory obligations, see our Enterprise AI Governance Guide. For financial crime obligations including beneficial ownership: AML Beneficial Ownership: Beyond Customer Identity.

Compliance by Region: Key Obligations

Regional obligations are not simply national versions of global frameworks. Each jurisdiction has its own enforcement posture, threshold criteria, and sector-specific rules. The following covers the major regions an internationally operating enterprise must manage.

European Union & United Kingdom

The EU is the most prolific regulatory jurisdiction for enterprise compliance. The GDPR has been in force since 2018 and continues to generate enforcement decisions that clarify obligations — including around vendor data processing, cross-border transfers, and automated decision-making. The EU AI Act adds a new layer from August 2026, with high-risk AI systems (credit scoring, recruitment, biometrics, critical infrastructure) requiring conformity assessments, audit trails, and human oversight.

DORA (Digital Operational Resilience Act) applies to financial services entities and imposes mandatory ICT third-party risk management, including register-of-contracts requirements for critical providers. CSDDD creates supply chain due diligence obligations for large enterprises, requiring risk identification and mitigation across the value chain.

The UK post-Brexit has maintained GDPR equivalence through the UK GDPR but has diverged in AI regulation — taking a sector-led, principles-based approach rather than the EU’s horizontal legislative model. FCA guidance on AI in financial services creates specific obligations for senior managers and vendor AI governance.

For the UK AI supply chain framework: UK AI Supply Chain Regulation: The TPRM Module.

United States

The US regulatory environment is fragmented across federal and state levels. No single federal data privacy law applies, but sector-specific regulation (HIPAA for health data, GLBA for financial data, FERPA for education data) creates binding obligations in each sector. CCPA / CPRA is the most comprehensive state law and applies to enterprises processing California residents’ data at relevant scale — regardless of where the enterprise is incorporated.

Financial crime regulation is comprehensive: BSA / AML obligations, OFAC sanctions compliance, and the Corporate Transparency Act’s beneficial ownership reporting requirements apply to US entities and, in the case of sanctions, to non-US entities transacting in USD. The White House AI Accord creates assurance expectations for AI systems, including independent third-party audits before high-impact deployment.

For federal contracting: Federal TPRM: Managing Vendor Risk in Government Contracts. For AI independent audits: AI Independent Audits and the White House Accord.

India

India’s Digital Personal Data Protection Act (DPDP Act) applies to the processing of digital personal data within India and to data processed outside India in connection with offering goods or services to data principals in India. Data fiduciaries (controllers) must implement reasonable security safeguards and ensure data processors (vendors) comply with the Act’s requirements.

SEBI and RBI have issued sector-specific guidance on AI risk in financial services. SEBI requires algorithmic trading systems to have audit trails and pre-deployment testing. RBI guidance covers model risk management for AI systems used in credit, fraud detection, and customer-facing applications.

For India-specific AI governance: India AI Governance: Build Before Regulation.

Singapore

Singapore’s PDPA (Personal Data Protection Act) applies to organisations collecting, using, or disclosing personal data in Singapore. It imposes mandatory data breach notification obligations and data protection by design requirements. The PDPC (Personal Data Protection Commission) has issued sector-specific guidance for fintech, healthcare, and AI.

ACRA’s Audit Practice Guidance on AI requires auditors to assess AI systems used in financial reporting processes — creating new obligations for both auditors and the enterprises whose systems they audit. MAS (Monetary Authority of Singapore) has issued detailed guidance on technology and cyber risk management, including third-party risk management requirements for financial institutions.

For ACRA AI audit requirements: ACRA Audit Practice Guidance: The AI Audit Rulebook.

UAE & GCC

The UAE Central Bank’s Operational Risk Management framework mandates formal TPRM programmes for regulated financial institutions, including written policies, risk-tiered due diligence, and ongoing monitoring of critical service providers. The Abu Dhabi Global Market (ADGM) and Dubai International Financial Centre (DIFC) each maintain their own data protection regimes aligned with GDPR principles.

Saudi Arabia’s PDPL (Personal Data Protection Law) applies to organisations processing Saudi residents’ personal data, with cross-border transfer restrictions and data localisation requirements for certain categories. The UAE’s AI Strategy 2031 is creating a regulatory framework for AI in government and regulated sectors.

For UAE operational risk regulation in detail: UAE Banks: New Operational Risk Rulebook.

Regulatory Convergence: Where Frameworks Overlap

The most operationally significant feature of the current compliance landscape is convergence. Multiple frameworks impose overlapping obligations on the same enterprise infrastructure. Managing these as separate workstreams creates duplication, inconsistency, and audit risk. Effective compliance programmes identify convergence points and build shared controls.

Data privacy convergence

GDPR, UK GDPR, DPDP Act, PDPA, CCPA, and sector-specific data rules all require: data inventory, lawful basis documentation, data subject rights processes, vendor data processing agreements, and breach notification. A single data governance infrastructure can satisfy all of these if designed to the highest common denominator (GDPR) while accommodating jurisdiction-specific variations (e.g., India’s consent model, California’s opt-out right).

Third-party risk convergence

DORA, GDPR Article 28, CSDDD, LkSG, UAE CBUAE ORM, MAS TRM, and FCA supplier risk guidance all require: vendor inventory, risk-tiered assessment, contractual controls, and ongoing monitoring. A single TPRM programme designed to the most demanding of these frameworks (currently DORA for financial services) provides the evidence base for all of them.

The enterprise that builds one comprehensive vendor inventory — covering operational risk, data processing, AI use, ESG risk, and financial crime exposure — satisfies the evidence requirements of ten or more frameworks simultaneously. The enterprise that maintains ten separate vendor lists for ten frameworks satisfies none of them well.

AI governance convergence

EU AI Act, ISO 42001, NIST AI RMF, FCA AI guidance, ACRA APG, and White House AI Accord all require overlapping elements: AI inventory, risk classification, audit trails, human oversight, and third-party AI due diligence. See the full convergence analysis in our Enterprise AI Governance Guide.

Financial crime convergence

6AMLD, FATF recommendations, FinCEN beneficial ownership rules, and sector-specific AML regulations all require: customer due diligence, beneficial ownership verification, transaction monitoring, and sanctions screening. AML compliance infrastructure that addresses FATF standards satisfies the requirements of most national implementations. For beneficial ownership in detail: AML Beneficial Ownership: Beyond Customer Identity.

Designing a Cross-Jurisdictional Compliance Programme

A cross-jurisdictional compliance programme is not a collection of national compliance programmes. It is a single programme with a shared infrastructure, designed to the highest common denominator of applicable frameworks, with jurisdiction-specific modules that address local variations. The following structure is designed to work under audit across all major jurisdictions.

Step 1: Regulatory inventory and applicability analysis

Before designing controls, document which frameworks apply and why. This requires: a map of every jurisdiction where the enterprise operates, offers products, processes data, or deploys AI; a framework inventory for each jurisdiction; and an applicability analysis that accounts for extraterritorial reach. Most enterprises underestimate their regulatory perimeter — they map where they have offices, not where their data goes, their AI is deployed, or their supply chain operates.

Step 2: Obligations registry

For each applicable framework, document the specific obligations that require operational controls. An obligations registry translates regulatory text into testable requirements: what must be in place, by whom, by when, and evidenced how. Without an obligations registry, compliance programmes produce policies that cannot be mapped to controls, and controls that cannot be mapped to regulatory requirements.

Regulatory perimeter mapping

Document every jurisdiction, framework, and extraterritorial obligation that applies to the enterprise.

Obligations registry

Translate each applicable regulatory requirement into a testable obligation with an owner and evidence requirement.

Control mapping

Map each obligation to an existing or or nequired control. Identify convergence points where one control satisfies multiple obligations.

Gap analysis

Identify obligations with no mapped control — these are the compliance gaps requiring remediation.

Evidence library

For each control, define the evidence that demonstrates it operates effectively and can be produced under regulatory examination.

Continuous monitoring

Compliance is not a point-in-time state. Controls must be monitored continuously and their evidence refreshed on a schedule that matches the regulatory review cycle.

Regulatory change management

The compliance programme must track regulatory change. In 2026, relevant changes include: EU AI Act high-risk provisions coming into force (August 2026), CSDDD implementation across member states, DPDP Act secondary legislation in India, and evolving MAS and ACRA guidance. A regulatory horizon scanning process — i not an annual review — is required to maintain compliance programme currency.

For supply chain due diligence specifically: Supply Chain Due Diligence: From Data to Answers. For vendor access recertification as a continuous compliance control: Permission Reviews Are Becoming Continuous Controls.

Third-Party Compliance Risk

Third-party compliance risk is the exposure an enterprise inherits from its vendors, suppliers, and service providers’ regulatory non-compliance. It is distinct from third-party operational risk (vendor failure) and third-party cyber risk (vendor breach), though all three are increasingly addressed within the same TPRM programme.

Where third-party compliance risk arises

A data processor (vendor) processing personal data in violation of GDPR Article 28 requirements — creating liability for the controller (enterprise)
A supply chain participant using forced labour or failing to meet environmental standards — creating liability under CSDDD, LkSG, or UK Modern Slavery Act
A vendor’s AI system processing the enterprise’s customer data without adequate governance — creating liability under the EU AI Act
A financial services vendor failing AML / sanctions screening requirements – creating correspondent bank liability or regulatory censure
A cloud provider failing DORA ICT third-party requirements — creating operational resilience liability for the regulated financial entity using them

Third-party compliance due diligence

Effective third-party compliance due diligence requires more than a questionnaire. It requires: documentary evidence of the vendor’s compliance posture (certifications, audit reports, regulatory approvals), contractual obligations that flow down compliance requirements, monitoring that detects compliance status changes, and incident notification provisions that satisfy the enterprise’s own regulatory reporting obligations.

For the full TPRM framework: Enterprise TPRM Guide. For vendor questionnaire evolution: Vendor Questionnaires Meet Continuous Risk Intelligence. For agentic vendor risk assessment: Agentic Vendor Risk Assessment: How It Works.

The enterprise’s compliance programme is only as strong as its least compliant critical vendor. A vendor that processes regulated data, provides critical infrastructure, or operates in a regulated sector carries compliance risk that the enterprise cannot disclaim by contract alone — regulators increasingly hold the enterprise accountable for its vendors’ compliance failures.

Continuous compliance monitoring

Point-in-time assessments are insufficient for compliance-critical vendors. Continuous monitoring — tracking regulatory filings, enforcement actions, certification renewals, and news signals — provides real-time awareness of vendor compliance status changes. For the technical architecture: Continuous Monitoring Is an AI Governance Requirement. For the broader TPRM monitoring programme: Vendor Questionnaires Meet Continuous Risk Intelligence.

Key Resources in This Guide

AI Governance for Enterprise: The Definitive GuideAI Regulation
Enterprise TPRM GuideTPRM
AML Beneficial Ownership: Beyond Customer IdentityFinancial Crime
UAE Banks: New Operational Risk RulebookUAE / GCC
Federal TPRM: Vendor Risk in Government ContractsUS
ACRA AI Audit RulebookSingapore
India AI Governance: Build Before RegulationIndia
UK AI Supply Chain Regulation: The TPRM ModuleUK
AI Independent Audits and the White House AccordUS
Supply Chain Due Diligence: From Data to AnswersSupply Chain
Vendor Questionnaires Meet Continuous Risk IntelligenceTPRM
Agentic Vendor Risk Assessment: How It WorksTPRM
Permission Reviews Are Becoming Continuous ControlsAccess Governance
Why Mid-Market Suppliers Are Your Cyber Weak LinkSupply Chain
Continuous Monitoring Is an AI Governance RequirementMonitoring
AI Compliance: From Documentation to EvidenceControls

Frequently Asked Questions

Which global compliance frameworks apply to a non-EU enterprise?

Extraterritoriality is now the default for major frameworks. GDPR applies to any enterprise processing EU residents’ personal data, regardless of where it is based. The EU AI Act applies to any enterprise deploying high-risk AI systems into the EU market. CSDDD applies to large non-EU enterprises with EU turnover above threshold. US sanctions apply to any entity transacting in USD or with US persons. The starting point is mapping where customers, data, and operations intersect with each jurisdiction — i not where the enterprise is incorporated.

What is the relationship between DORA and GDPR for vendor risk?

DORA (Digital Operational Resilience Act) applies to financial services entities in the EU and imposes ICT third-party risk management requirements — including a register of ICT contracts, risk assessment of critical providers, and contractual provisions covering audit rights, exit strategies, and incident reporting. GDPR’s Article 28 requirements apply to vendors processing personal data. The two frameworks overlap for any vendor that is both an ICT provider and a data processor — which describes most SaaS platforms. Compliance programmes that address both create data processing agreements and ICT contracts that satisfy both sets of requirements, avoiding duplication.

How should a compliance programme handle regulatory divergence (e.g., UK vs EU post-Brexit)?

Design to the higher standard and document jurisdiction-specific variations. For data privacy, GDPR is more demanding than UK GDPR in most practical respects — a GDPR-compliant programme requires minimal adjustment for UK GDPR, provided transfer mechanisms (UK adequacy decisions or SCCs) are correctly implemented. For AI regulation, the EU AI Act is more prescriptive than the UK’s sector-led approach — EU AI Act compliance provides a strong basis for UK FCA AI guidance compliance. The divergence risk is not failing the harder standard but failing to document how the softer standard is satisfied by the existing programme.

What is the minimum viable TPRM programme for compliance purposes?

A compliance-grade TPRM programme requires: a complete vendor inventory (including data processors, ICT providers, and supply chain participants), risk-tiered due diligence (proportionate to criticality and regulatory exposure), contractual provisions that flow down compliance obligations, and ongoing monitoring that detects compliance status changes. The minimum threshold is set by the most demanding applicable framework — for EU-regulated financial entities, DORA; for any entity processing EU personal data, GDPR Article 28; for entities covered by CSDDD, the value-chain due diligence requirements.

How does the EU Corporate Sustainability Due Diligence Directive (CSDDD) differ from existing supply chain laws?

CSDDD creates a positive obligation to identify, prevent, mitigate, and account for adverse human rights and environmental impacts in the value chain — going beyond the disclosure and reporting requirements of earlier laws like the UK Modern Slavery Act. It applies to large EU companies and large non-EU companies with EU turnover above threshold, and it includes civil liability provisions that allow affected parties to sue for damages. The German LkSG is a national precursor to CSDDD — enterprises already compliant with LkSG have a strong foundation but will need to extend their due diligence programme to the full value chain (not just direct suppliers) to meet CSDDD(r8equirements.

Sources & References

Third-Party Compliance Gap: A TPRM Workflow Problem→Continuous Compliance: Why GRC Now Asks What Changed Today→Regulatory Compliance Agents for AI Governance→Manufacturing Supply Chain Compliance, Not Just Management→Regulatory Compliance Agents for Multi-Framework Risk→AI Compliance Is Moving From Documentation to Evidence→

Global Regulatory
Compliance Hub: The Enterprise Guide for 2026