# The Lighthouse Framework ## A Digital Sovereignty Assessment for Crown Dependencies and Associated Offshore Financial Centres --- **Published by:** The Lighthouse Framework Working Group **Version:** 0.1 — Working Draft **Status:** For consultation and review **Date:** April 2026 --- ## Foreword This document is a working draft published for consultation. Comments, corrections, and contributions from practitioners across Crown Dependencies and Associated Offshore Financial Centres are invited. The framework will be revised through a structured review process prior to the publication of version 1.0. --- ## 1. Introduction ### 1.1 The Regulatory Gap Crown Dependencies and Associated Offshore Financial Centres — including the Isle of Man, Jersey, Guernsey, the British Virgin Islands, the Cayman Islands, Bermuda, and Gibraltar — share a common characteristic: they operate sophisticated professional services sectors under their own legislative frameworks, outside both the United Kingdom and the European Union, while remaining deeply integrated with global financial and legal systems. This position creates a distinctive and underserved challenge. Existing cybersecurity and data governance frameworks were not designed with this jurisdictional complexity in mind. The UK's Cyber Essentials scheme addresses baseline technical hygiene but does not assess jurisdictional exposure. The EU's European Cybersecurity Certification Scheme for Cloud Services (EUCS) is geographically bounded and does not apply to these territories. NIST and ISO frameworks provide useful technical structure but offer no guidance on the specific legal reach instruments — the CLOUD Act, FISA Section 702, and their equivalents — that create the most acute sovereignty risks for firms in these jurisdictions. The result is a gap: no single instrument exists that allows a Crown Dependency professional services firm to assess, document, and communicate its digital sovereignty posture in a coherent and jurisdiction-appropriate way. The Lighthouse Framework is designed to fill that gap. ### 1.2 Scope The framework is designed for professional services organisations operating in Crown Dependencies and Associated Offshore Financial Centres, including: - Law firms and legal practitioners - Financial services firms and fiduciaries - Accountancy and tax advisory practices - Insurance and captive insurance managers - Corporate services providers and registered agents - Healthcare and healthcare-adjacent organisations - Government bodies and quasi-governmental organisations The framework is jurisdiction-agnostic in its structure. Dimension 7 (Regulatory Alignment) provides a mapping structure that organisations in any of the covered territories can populate with their applicable local requirements. ### 1.3 What the Framework Assesses The Lighthouse Framework assesses digital sovereignty across nine dimensions. Each dimension addresses a distinct layer of exposure that existing frameworks fail to cover adequately, or do not cover at all. The framework does not replace existing compliance obligations. Organisations holding Cyber Essentials certification, ISO 27001 accreditation, or equivalent will find that existing controls satisfy elements of several dimensions. The framework documents where existing certifications provide coverage and identifies the sovereignty-specific gaps that those certifications do not address. ### 1.4 Version and Revision This is version 0.1, a working draft. It does not constitute a final standard. Organisations should not present compliance with this version as equivalent to a mature certification. The working group anticipates revising the framework through structured consultation before publishing version 1.0. --- ## 2. The Nine Dimensions ### Dimension 1: Jurisdictional Exposure Crown Dependency professional services firms routinely handle data subject to overlapping and potentially conflicting legal regimes simultaneously. A trust administration firm managing US-connected structures may hold data subject to IoM data protection law, UK retained GDPR, EU GDPR reach through European beneficiaries, and US legal process through their cloud infrastructure provider — all at once. The CLOUD Act, FISA Section 702, and equivalent instruments create compellable disclosure obligations that operate silently, without notice to the data subject or the firm. Most existing compliance frameworks treat jurisdiction as a binary — in scope or out — rather than as a layered exposure map. This dimension assesses the full jurisdictional stack: vendor ultimate parent, applicable law, sub-processor chain, and the gap between contractual data residency commitments and actual legal exposure. **Assessment criteria:** - Vendor ownership and ultimate parent jurisdiction - Legal reach exposure — CLOUD Act, FISA Section 702, and equivalent instruments - Data residency — where data actually sits, verified against contractual commitments - Sub-processor chain and the jurisdictions in which sub-processors operate - Change of control protections and notification obligations --- ### Dimension 2: Data Governance Knowing where data sits is a precondition for protecting it. Crown Dependency firms frequently lack coherent data classification frameworks — not through negligence, but because the tooling they rely on was built for larger markets with different regulatory assumptions. Without classification, retention and deletion obligations become unenforceable in practice: data that is not categorised is not managed. This dimension assesses whether the organisation can answer, with evidence, the questions a regulator would ask following a breach: what data did you hold, where was it, who had access, and what did your retention policy require you to have deleted before the incident occurred. **Assessment criteria:** - Data classification framework — does one exist and is it operationally applied - Retention and deletion — contractual commitments and verified implementation - Portability — can data be extracted in a usable format - Cross-border transfer mechanisms and their legal basis - Breach notification obligations and timescales, mapped to applicable regulatory requirements --- ### Dimension 3: Infrastructure Sovereignty The hosting layer is the most visible component of sovereignty infrastructure, but visibility does not equal control. This dimension examines not just where infrastructure physically sits, but who holds the encryption keys, what jurisdiction governs key management, whether data transits infrastructure subject to foreign legal process in transit, and whether the organisation could maintain operations if a hosting provider became unavailable or legally compelled. For firms operating on-premises or with self-hosted infrastructure, this dimension also captures the operational security of that infrastructure — patch cadence, access controls, and backup integrity. **Assessment criteria:** - Hosting jurisdiction — physical location and governing law of data centre - Network routing — whether data transits infrastructure subject to foreign legal process - Encryption at rest and in transit — implementation and verification - Key management — who holds keys and under what jurisdictional framework - Operational security of self-hosted or on-premises infrastructure where applicable --- ### Dimension 4: SaaS and Application Layer This is the highest-risk and least-visible dimension for the majority of Crown Dependency professional services firms. A firm may maintain exemplary infrastructure sovereignty — hosted locally, encrypted correctly, Cyber Essentials certified — while simultaneously routing client data through a practice management platform, document management system, accounting package, and productivity suite, each with its own jurisdictional exposure, training data clauses, and AI feature defaults. The SaaS layer is where sovereignty frameworks have historically failed, because it requires per-application assessment rather than perimeter assessment. This dimension examines application inventory, data classification per application, vendor jurisdiction, terms of service analysis, shadow SaaS exposure, and the frequently overlooked question of what actually happens to data when a subscription is cancelled. **Assessment criteria:** - Application inventory — does the organisation have a complete and current register of SaaS in use - Data classification per application — what sensitivity of data is processed by each application - Vendor jurisdiction and ownership per application - Terms of service analysis — data ownership clauses, AI training data opt-outs, jurisdictional provisions - Integration and API exposure — what applications exchange data with what - Shadow SaaS — tooling in use without formal IT or governance approval - Authentication and SSO governance - Offboarding and data deletion verification — what contractually and practically occurs when a subscription ends, including statutory retention obligations that survive cancellation --- ### Dimension 5: AI Tooling AI capability is now embedded in tools that firms already use and trust — productivity suites, document management systems, CRM platforms — rather than arriving as explicitly adopted AI products. This creates a governance gap: firms that have made considered decisions about AI adoption may be exposed through AI features they did not consciously enable. This dimension assesses the jurisdictional provenance of AI models in use, the location of inference processing, whether AI features have access to client or regulated data, the contractual clarity of acceptable use boundaries, the scope of any autonomous action capability, and whether the organisation maintains an audit trail sufficient to reconstruct AI-assisted decisions. **Assessment criteria:** - AI model inventory — what models are in use, explicitly adopted or embedded in existing tooling - Training data provenance and jurisdiction - Model hosting and inference location - Access to client or regulated data — whether AI features can process sensitive data and under what conditions - Autonomous action scope — the extent to which AI tooling can act on data without human authorisation - Acceptable use contractual clarity - Audit trail for AI-assisted decisions --- ### Dimension 6: Operational Security Sovereignty frameworks that address jurisdictional exposure while neglecting operational security create a false assurance: data held in the right jurisdiction but inadequately protected remains at risk. This dimension addresses the operational hygiene that underpins all other sovereignty controls — vulnerability and patch management, identity and access control, incident response capability and tested plans, and supply chain security covering third-party software and service dependencies. For smaller firms, this dimension acknowledges that enterprise-grade tooling is rarely appropriate, and assesses proportionate controls relative to the firm's risk profile and regulatory obligations. **Assessment criteria:** - Vulnerability and patch management — cadence, coverage, and verification - Access control and identity management — least privilege, MFA, joiners/movers/leavers process - Incident response capability — documented plan, tested and current - Supply chain security — third-party software dependencies and their governance --- ### Dimension 7: Regulatory Alignment Crown Dependency firms operate within a layered regulatory environment that varies by sector and jurisdiction. This dimension maps the firm's sovereignty posture against applicable regulatory obligations — including data protection legislation, sector-specific requirements from financial services regulators, professional privilege obligations, and relevant certification frameworks. Critically, this dimension is jurisdiction-agnostic in its structure: Isle of Man, Jersey, Guernsey, BVI, Cayman, Bermuda, and Gibraltar each have distinct regulatory instruments, and the framework provides a mapping structure that firms in any of these jurisdictions can populate with their applicable requirements rather than a checklist built for a single regulator. **Assessment criteria:** - Applicable data protection legislation and compliance status - Sector-specific regulatory obligations — financial services regulation, legal professional privilege, AML/KYC requirements - Certification status — Cyber Essentials, ISO 27001, EUCS, and sector-specific schemes - Regulatory horizon — awareness of forthcoming legislative or regulatory changes affecting sovereignty posture --- ### Dimension 8: Contractual Protections Contractual terms are the mechanism through which sovereignty commitments become enforceable — or fail to. This dimension examines whether vendor agreements actually provide the protections that sovereignty requires: meaningful audit rights, sub-processor notification and veto, change of control protections, data return obligations, and breach notification timescales consistent with regulatory requirements. Standard vendor terms are frequently inadequate for Crown Dependency professional services firms, and negotiation leverage is limited for smaller organisations. This dimension identifies the gaps and, where renegotiation is not feasible, supports an informed risk acceptance decision rather than inadvertent exposure. **Assessment criteria:** - SLA and uptime commitments — and remedies where not met - Audit rights — whether the organisation can verify vendor claims - Sub-processor notification and veto rights - Change of control protections - Data return obligations — format, timeline, and enforceability - Breach notification timescales — contractual obligations mapped to regulatory requirements --- ### Dimension 9: Continuity and Exit Sovereignty is not only about where data sits today — it is about whether the organisation retains operational control under adverse conditions. This dimension addresses vendor dependency risk: what happens if a vendor is acquired, withdraws from a jurisdiction, becomes insolvent, or is compelled to restrict service? For Crown Dependency firms, which are frequently not priority markets for global SaaS vendors, this risk is not theoretical. The dimension examines exit planning, data portability commitments and their practical enforceability, transition runway, escrow arrangements for critical software, and the degree to which proprietary formats or APIs create lock-in that constrains future sovereignty decisions. **Assessment criteria:** - Exit plan — documented and tested process for transitioning away from critical vendors - Data portability — format, completeness, and timeline for data return - Transition runway — contractual notice periods and operational feasibility - Escrow arrangements — for critical software or proprietary systems - Lock-in assessment — proprietary formats, APIs, or integrations that constrain exit options - Business continuity — operational capability under adverse vendor conditions --- ## 3. Using the Framework ### 3.1 Assessment Approach Version 0.1 of the Lighthouse Framework is a qualitative assessment instrument. Organisations should work through each dimension systematically, documenting their current position against each assessment criterion. The output is a sovereignty posture statement — an honest account of where the organisation stands, where gaps exist, and what the material risks are. A scoring methodology will be developed for version 1.0 following consultation. ### 3.2 Existing Certifications Organisations holding existing certifications should map those certifications against the nine dimensions to identify coverage and gaps. As a general guide: - **Cyber Essentials** provides partial coverage of Dimension 6 (Operational Security) - **ISO 27001** provides partial coverage of Dimensions 2, 6, 8, and 9 - **Neither** addresses the sovereignty-specific elements of Dimensions 1, 3, 4, 5, or 7 in any meaningful way ### 3.3 Proportionality The framework is designed to be applicable across a range of organisation sizes. Not every criterion will be applicable to every organisation, and the appropriate depth of assessment will vary with the organisation's size, sector, and risk profile. Proportionate application is encouraged. The goal is an honest and useful sovereignty posture statement, not a compliance performance. A two-partner law firm and a fund administrator with fifty staff face different risk profiles, operate different tooling, and have different negotiating leverage with vendors. The framework should produce a useful output for both — not a document that only makes sense at enterprise scale. --- ## 4. Governance ### 4.1 The Working Group The Lighthouse Framework is published by The Lighthouse Framework Working Group. The working group administers the framework, manages the revision process, and coordinates consultation across Crown Dependencies and Associated Offshore Financial Centres. Practitioners from across the covered jurisdictions are invited to contribute to the development of the framework. Contributions may be made via [contact details to be confirmed]. ### 4.2 Revision Schedule | Version | Status | Notes | |---------|--------|-------| | 0.1 | Current — Working Draft | Published for consultation | | 0.2 | Planned | Incorporates consultation feedback | | 1.0 | Planned | Published standard with scoring methodology | ### 4.3 Licensing The Lighthouse Framework is published under a Creative Commons Attribution 4.0 International licence (CC BY 4.0). You are free to share and adapt the framework for any purpose, provided appropriate credit is given to The Lighthouse Framework Working Group. --- ## 5. Reference Material ### 5.1 Related Frameworks and Instruments The following frameworks and instruments informed the development of the Lighthouse Framework. None addresses the specific sovereignty assessment needs of Crown Dependency professional services firms in their entirety. - **Cyber Essentials** (NCSC / IASME) — UK baseline cybersecurity hygiene certification - **EUCS** — European Cybersecurity Certification Scheme for Cloud Services (ENISA) - **NIST Cybersecurity Framework** — US National Institute of Standards and Technology - **NIST AI Risk Management Framework** — AI-specific risk governance - **NCSC Cloud Security Principles** — 14 principles for cloud security assessment - **ISO/IEC 27001** — International standard for information security management ### 5.2 Key Legal Instruments - **CLOUD Act** (Clarifying Lawful Overseas Use of Data Act, USA, 2018) — enables US law enforcement to compel US-based technology companies to provide data regardless of where it is stored - **FISA Section 702** (Foreign Intelligence Surveillance Act, USA) — enables collection of communications of non-US persons located outside the United States - **UK Data Protection Act 2018** — UK implementation of GDPR principles post-Brexit - **Isle of Man Data Protection Act 2018** — IoM data protection legislation - **GDPR** (EU General Data Protection Regulation) — applicable to processing of EU residents' data regardless of where the processor is located --- *The Lighthouse Framework — Version 0.1 Working Draft* *Published by The Lighthouse Framework Working Group* *April 2026* *Licensed under CC BY 4.0*