Governance & Compliance draft

Organizational governance structures and compliance frameworks for digital sovereignty

L0 Unaware

No governance framework exists for digital sovereignty; compliance is reactive and ad-hoc with no organisational accountability

Criteria

GOV-L0-C1 The organisation has no governance framework, policy, or designated role addressing digital sovereignty or technology risk
GOV-L0-C2 Compliance with data protection and security regulations is handled reactively, with no proactive monitoring or assessment

Indicators

No board-level or executive discussion of digital sovereignty has ever taken place
Regulatory compliance is addressed only when auditors or regulators force the issue

Upgrade path

Appoint a responsible individual for digital sovereignty and compliance oversight. Conduct a baseline assessment of applicable regulations and the organisation's current compliance posture. Draft an initial sovereignty policy statement.

Risk if stagnant

Without governance, sovereignty decisions are made implicitly through technology choices without strategic oversight. The organisation accumulates regulatory exposure, vendor dependencies, and technical debt that become increasingly costly to address over time.

L1 Dependent

Compliance is managed through provider-supplied certifications and attestations with no independent organisational governance of sovereignty

Criteria

GOV-L1-C1 The organisation relies on provider certifications (e.g., ISO 27001, SOC 2) as its primary evidence of compliance, with no independent assessment
GOV-L1-C2 No internal governance body or process evaluates technology decisions through a sovereignty lens
GOV-L1-C3 AI A documented onboarding review covers any new SaaS tool with embedded AI features before it is enabled for production use, recording the AI feature scope, data classes the feature will see, and the responsible business owner

Evidence guidance

Request the AI tool onboarding log. Each entry should cover at minimum: the SaaS tool and the specific AI feature being enabled, the categories of data the feature will be exposed to (personal data, customer content, source code, internal documentation), the named business owner accountable for usage, and the date the review was completed. The review process itself can sit inside an existing procurement, change management, or vendor onboarding workflow; it does not need a dedicated committee at this level. Acceptable evidence is a populated review record per AI-enabled tool now in use, not the existence of a blank template. A blanket statement that 'all SaaS goes through procurement' without an AI-specific review step does not satisfy this criterion, because the AI feature surface routinely activates after the SaaS tool itself was onboarded.

Indicators

When asked about compliance, the organisation points to provider certifications rather than its own controls
Technology procurement decisions do not include sovereignty or lock-in risk as evaluation criteria
An AI tool onboarding review log exists with one populated entry per AI-enabled SaaS tool in current production use

Regulatory mappings

Regulation	Articles	Risk	Note
`AI-ACT`	art-4, art-26	medium	Art 4 AI literacy obligations require the deployer to ensure relevant staff have a sufficient level of awareness of the AI systems they use; an onboarding review per AI-enabled tool is the operational mechanism that makes that awareness traceable. Art 26 deployer obligations begin with the deployer being able to identify which AI systems are in operation under its control.
`NIS2`	art-21	medium	Art 21(2)(d) supply-chain risk management presumes the organisation knows which third-party services are in use. AI features inside SaaS tools are routinely activated after the SaaS itself was procured; an explicit AI onboarding review closes the gap that would otherwise leave the AI tier outside the supplier inventory.

Upgrade path

Establish a formal compliance programme with internal policies covering data protection, security, and sovereignty requirements. Create a governance body (committee or designated role) that reviews technology decisions for sovereignty implications.

Risk if stagnant

Relying on provider certifications gives the illusion of compliance without actual organisational control. Provider certifications demonstrate the provider's controls, not the organisation's. Regulators increasingly expect organisations to demonstrate their own governance, not merely point to suppliers. Without an AI-specific onboarding step, AI features activated inside already-procured SaaS tools accumulate outside any review record, and the organisation cannot tell a regulator which AI systems it operates.

L2 Contractual

A formal compliance programme exists with documented policies, regular assessments, and contractual compliance requirements for providers

Criteria

GOV-L2-C1 The organisation maintains a formal compliance programme with documented policies covering data protection, security, and sovereignty requirements
GOV-L2-C2 Provider contracts include compliance obligations, audit rights, and regular reporting requirements aligned with the organisation's governance framework
GOV-L2-C3 AI An AI usage policy defines permitted and prohibited AI tools and use cases, names the data classes that may and may not be submitted to AI features, and is enforced through a stated mechanism rather than expected goodwill

Evidence guidance

Request the AI usage policy and the description of how it is enforced. The policy text should at minimum enumerate approved AI tools, prohibited tools or categories (for example consumer-tier chat assistants for confidential data), the data classes that may flow to AI features and those that may not, and the consequences of breach. The enforcement description should name a mechanism: tenant-level allowlists at the identity provider or proxy, DLP rules that block submission of restricted data classes to AI endpoints, browser-extension governance, periodic attestation by line managers, or a documented disciplinary route. A policy that exists as a PDF on an intranet with no described enforcement path does not satisfy this criterion. Awareness training alone is awareness, not enforcement.
GOV-L2-C4 AI An AI Act risk-classification register lists each AI system the organisation deploys or develops with its provisional classification under the EU AI Act risk tiers (prohibited, high-risk, limited-risk, minimal-risk) and the rationale for that classification

Evidence guidance

Request the AI Act risk register. Each entry should name the AI system, its purpose in the organisation, the role the organisation plays under the AI Act (provider, deployer, importer, distributor), the provisional risk classification, the AI Act articles or Annex III categories used to reach that classification, and the date of the most recent classification review. Where the system is provisionally classified as high-risk, the register should reference the additional obligations triggered (Art 16 onwards for providers, Art 26 for deployers) even if the implementation work itself sits in other dimensions. A register that lists tools without rationale, or that classifies everything as minimal-risk by default, does not satisfy this criterion. Tools where classification is genuinely uncertain should be recorded as 'pending classification' with an owner and a target date, not omitted.

Indicators

A compliance register tracks applicable regulations and maps them to organisational controls and provider obligations
Regular compliance assessments are conducted internally, with findings reported to management
An AI usage policy exists, names an enforcement mechanism, and the enforcement mechanism can be demonstrated in operation (allowlist, DLP rule, attestation cycle)
An AI Act risk-classification register is maintained with one entry per AI system, including the rationale for the assigned risk tier and the date of the most recent review

Regulatory mappings

Regulation	Articles	Risk	Note
`AI-ACT`	art-4, art-6, art-26	medium	Art 4 AI literacy obligations are operationalised by an enforced usage policy that defines what staff may and may not do with AI tools. Art 6 (with Annex III) defines the high-risk classification rules; a maintained risk register is the deployer's primary record that those rules have been applied to each AI system in scope. Art 26 deployer obligations attach specifically to high-risk systems, which the deployer can only honour if it has identified them through a classification process.
`NIS2`	art-21	medium	Art 21(2)(g) basic cyber hygiene practices and security training cover AI usage at the policy level; an enforced AI usage policy is the governance artefact that operationalises this for the AI tool surface.
`GDPR`	art-5, art-32	medium	Where AI features process personal data, the usage policy is the controller's operational mechanism for keeping data flows aligned with Art 5 purpose limitation and Art 32 appropriate technical and organisational measures. The risk register flags AI systems likely to require a DPIA under Art 35, which is captured downstream.

Upgrade path

Integrate sovereignty considerations into all technology governance processes, including procurement, architecture review, and risk management. Establish a cross-functional sovereignty governance board with executive sponsorship.

Risk if stagnant

A formal compliance programme addresses regulatory requirements but may treat sovereignty as a checkbox exercise. Without embedding sovereignty into strategic decision-making, the organisation complies on paper while continuing to accumulate provider dependencies. An AI usage policy without a stated enforcement mechanism does not survive contact with shadow-AI behaviour, and a missing AI Act risk register leaves the organisation unable to demonstrate to a supervisory authority which obligations under the Act it has accepted as applying to it.

L3 Controlled

Integrated sovereignty governance with a cross-functional board, sovereignty-aware procurement, and continuous compliance monitoring across all dimensions

Criteria

GOV-L3-C1 A cross-functional sovereignty governance board with executive sponsorship reviews all significant technology decisions for sovereignty implications
GOV-L3-C2 Continuous compliance monitoring is in place across all sovereignty dimensions, with automated controls validation and real-time dashboards
GOV-L3-C3 AI Shadow-AI exposure is technically constrained: unmanaged consumer AI services, browser-extension AI features, and bring-your-own LLM usage are blocked, monitored, or routed through an approved gateway, and the control surface is reviewed against new AI features as they appear in already-approved tools

Evidence guidance

Request the shadow-AI control inventory. Acceptable mechanisms include identity-provider blocks on unsanctioned AI SaaS sign-ins, network egress controls or secure web gateway rules that prevent or log access to consumer AI endpoints, browser-extension governance through the managed browser policy, an enterprise AI gateway that all approved AI traffic is routed through, and DLP detections specific to AI submission patterns. Evidence is the configured rule set or policy plus a recent review log showing the control surface is updated when vendors add AI features to existing approved SaaS tools (a frequent gap, since the SaaS itself was approved before the AI feature existed). A statement that 'the AI usage policy prohibits this' without a corresponding technical control does not satisfy this criterion at Level 3, where contractual posture is expected to be backed by enforcement. Where blocking is not feasible for a category, monitoring with a defined review cadence is acceptable, and the residual risk should be recorded.

Indicators

Technology procurement includes mandatory sovereignty impact assessments as a gate in the approval process
A sovereignty dashboard provides real-time visibility into the organisation's maturity across all SCM dimensions
Shadow-AI controls (identity-provider allowlists, egress rules, browser-extension governance, AI gateway, or equivalent) are configured and demonstrable, with a review cadence that picks up newly added AI features in already-approved SaaS tools

Regulatory mappings

Regulation	Articles	Risk	Note
`AI-ACT`	art-4, art-26	low	Art 4 AI literacy obligations are reinforced by technical controls that ensure staff cannot route confidential data to AI services that the deployer has not assessed. Art 26 deployer obligations apply to AI systems the organisation 'uses under its authority'; bring-your-own LLM and browser-extension AI features expand that authority surface in ways the deployer cannot honour without technical visibility and constraint.
`NIS2`	art-21	low	Art 21(2)(d) supply-chain risk management and Art 21(2)(g) basic cyber hygiene cover the unmanaged AI tool surface. Technical shadow-AI controls are the operational counterpart to the policy work captured at Level 2.
`GDPR`	art-5, art-32	low	Where staff would otherwise submit personal data to consumer AI services, technical shadow-AI controls are the Art 32 technical and organisational measure that prevents the controller from losing visibility over Art 5 purpose-limited processing.

Upgrade path

Contribute to industry standards and regulatory frameworks for digital sovereignty. Establish the organisation as a reference model for sovereignty governance, sharing practices through industry groups and public commitments.

Risk if stagnant

Integrated governance requires sustained executive commitment and cross-functional cooperation. Without ongoing sponsorship, sovereignty governance can be sidelined by competing priorities, and the governance board's influence may erode over time. On the AI surface specifically, the rate at which vendors add AI features to existing tools (and the rate at which staff adopt browser-based AI assistants) means a control surface that is not actively reviewed becomes outdated within a single quarter; an organisation in that position has a Level 2 policy posture in practice regardless of what its dashboards report.

L4 Autonomous

Industry-leading sovereignty governance with active contribution to standards bodies, public transparency, and continuous improvement across all dimensions

Criteria

GOV-L4-C1 The organisation actively contributes to industry standards, regulatory frameworks, and best practices for digital sovereignty governance
GOV-L4-C2 Sovereignty governance is transparent, with public reporting on the organisation's sovereignty posture and continuous improvement commitments

Indicators

The organisation participates in sovereignty-related standards bodies, working groups, or industry consortia
Annual sovereignty reports are published, demonstrating maturity levels, improvement trajectories, and lessons learned

Risk if stagnant

Industry leadership in sovereignty governance requires ongoing investment in thought leadership, standards participation, and public transparency. Without sustained commitment, the organisation's governance model stagnates and loses relevance as regulations and technology evolve.