EU data sovereignty: ask who can access the evidence

Compliance evidence can expose architecture, unresolved weaknesses, staff information, supplier dependencies, and incident history. Choosing where that evidence lives deserves the same care as choosing where customer data lives. In some cases, an evidence repository provides a more concentrated picture of the business than any individual production system.

For leadership, EU data sovereignty is therefore a purchasing and accountability question: who can access this information, under whose authority, and what happens if we need to leave?

A European hosting region is useful information. It is not a complete answer. The decision needs to cover the service chain, legal exposure, technical access, and the ability to preserve usable records outside the platform.

Start with the information you are entrusting

A compliance platform may contain network diagrams, access reviews, vulnerability reports, processing inventories, risk assessments, and incident investigations. Taken together, these records describe both how the organization operates and where its defenses need improvement.

They also contain different kinds of sensitivity. An employee access review involves personal data. A penetration-test report may reveal exploitable weaknesses. A management decision may record a commercial dependency or an accepted risk. These categories require different handling even when they sit in the same workspace.

Before comparing vendors, create a small evidence inventory. For each category, record its purpose, sensitivity, owner, intended readers, retention requirement, and whether the original document needs to be uploaded at all.

For example, a control review may need proof that remediation was completed, not the full technical report describing every vulnerability. A redacted extract can sometimes establish the required fact while reducing exposure. Redaction must not remove the context needed to evaluate the evidence.

This is a practical recommendation, not a universal requirement to replace originals with summaries. The objective is to make evidence handling deliberate rather than allowing every audit request to expand the repository indefinitely.

Separate residency, control, and legal compliance

Data residency concerns location. Sovereignty also concerns control, access, legal exposure, and the ability to move or continue using information. Neither term should be treated as a certificate of compliance.

These dimensions interact, but they are not interchangeable. An EU-hosted service may involve support personnel or processing outside the EU. An EU-owned vendor may depend on infrastructure, monitoring, or AI services operated by other entities. Ownership alone does not establish that every access path is acceptable.

Likewise, exposure to another jurisdiction does not mean disclosure is inevitable or that the service is automatically unlawful. Assess the relevant entities, applicable law, practical access, and safeguards. Where compulsory disclosure is material to the decision, obtain legal advice rather than relying on a nationality label or a sales assurance.

Understand which rules actually apply

The GDPR does not impose a general rule that all personal data must remain in the EU. It requires an appropriate legal basis and compliant processing, including security, processor arrangements, and international-transfer requirements where applicable.

For a compliance repository containing personal data, determine the parties' roles and examine the Article 28 processing terms where a processor relationship exists. Separately assess Chapter V transfer arrangements. Signing a processing agreement does not resolve the transfer question, and selecting an EU storage region does not eliminate the need to examine overseas access or onward processing.

Article 32 requires security appropriate to risk. Encryption may be an important measure, but the GDPR does not prescribe one blanket encryption design for every repository. Article 48 also addresses third-country court or administrative demands for transfer or disclosure; it should not be read as a universal shield against foreign access.

Other obligations depend on the organization. NIS2, implemented through national law, includes management oversight and supply-chain security measures for entities in scope. DORA establishes ICT third-party risk obligations for covered financial entities. Neither should be reduced to a generic instruction to buy European software.

European sovereignty policy and procurement discussions also need careful interpretation. Separate enacted obligations from proposals, political declarations, procurement criteria, and certification schemes. France's and Germany's requirements should not be treated as interchangeable, or automatically applicable to every private business across Europe.

Ask counsel and procurement to document the specific national, sectoral, and customer requirements that affect your purchase. A cloud assurance report can contribute evidence, but it does not settle sovereignty. For example, the BSI C5 catalogue concerns cloud controls and attestation; it is not a blanket sovereignty certification.

Map the complete service chain

The most useful purchasing document is an evidence-handling map. It shows how information enters the service, which systems process it, who may access it, and how it leaves.

Request answers for production storage, replicas, backups, disaster recovery, application logs, monitoring, support tickets, and temporary troubleshooting copies. Include exports and email notifications: a sensitive finding can escape the intended boundary through a notification even when its attachment remains inside the platform.

For each component, record:

• The operating entity and its role.
• The data categories it receives and the purpose of processing.
• Storage and processing locations, including remote access locations.
• Authorized access groups and any further providers involved.
• Retention, deletion, and backup treatment.
• The contractual terms governing the activity.

Distinguish a provider's infrastructure supplier from a support contractor or an AI processor. Their functions and access can differ substantially. A vendor logo list is not a substitute for this map.

Also examine change management. How will you learn about a new subprocessor, changed processing location, or revised support arrangement? What review or objection rights exist, and what happens if the proposed change conflicts with your requirements? A satisfactory assessment today needs a mechanism for detecting changes tomorrow.

Treat AI processing as a separate disclosure path

AI-assisted evidence review can introduce another provider and retention policy. A feature that summarizes an incident report may transmit the report, extracted text, prompts, metadata, or diagnostic information beyond the main application.

Ask what reaches the AI provider, for what purpose, and under which contractual terms. Confirm model-training use, retention, human access, processing locations, and onward processing in the current agreement. Do not assume that an enterprise account or a “no training” statement also means no retention or no support access.

Clarify whether AI functions are optional and whether restrictions can be applied to sensitive material. If the platform cannot enforce the required boundary, an internal instruction not to upload restricted documents may be too fragile for routine use.

A practical review should follow one representative document through the feature. Identify the source, transmitted content, output, retained records, and reviewers. Generated summaries can themselves contain sensitive information, so they belong in the handling map.

Human review remains necessary for evidence conclusions. It is a separate safeguard from processing restrictions: approving an AI-generated summary does not retrospectively authorize an unacceptable disclosure of its source.

Ask who can actually decrypt and administer

Encryption protects information only within the limits of its design and operation. Encryption in transit protects connections; encryption at rest protects stored data under particular threat assumptions. Neither automatically prevents an authorized application or privileged operator from reading the content.

Ask who controls the keys, who can invoke decryption, and whether administrators can change the permissions that govern that access. A customer-managed key arrangement may improve control, but its effect depends on the architecture. If the service routinely receives plaintext, key ownership alone does not remove provider access.

Have the technical team examine key separation, rotation, revocation, recovery, and the consequences of key loss. Leadership should understand any availability trade-off before approving it. A stronger access boundary that also makes essential evidence unrecoverable is not a complete continuity solution.

Support access deserves particular attention. Look for named identities, limited privileges, time-bounded authorization, customer approval where appropriate, and auditable actions. Ask how emergency access works and how it is reviewed afterward.

The purchasing question is not simply whether access is logged. It is whether the organization can obtain enough information to investigate an event: who accessed which records, when, for what reason, and under what authorization. Agree what evidence will be available before an incident makes the question urgent.

Make portability a tested requirement

Portability is part of sovereignty because control is weakened when leaving means losing the meaning of the evidence.

Test a representative export before committing. Files alone may not preserve relationships between controls, evidence, findings, owners, approvals, and decisions. A folder of PDFs can retain documents while losing the record of what they proved and who accepted the conclusion.

Choose a sample containing an attachment, its linked control, a review comment, an approval, an open finding, and relevant timestamps. Ask someone outside the implementation team to reconstruct the decision from the export. This tests usability rather than the mere existence of an export button.

OSCAL provides useful models for portable security information. Its published specifications can support structured exchange, but using an open format does not automatically establish completeness or compatibility. Check model versions, identifiers, attachments, extensions, and whether the receiving system can interpret the exported structure.

Contractual exit terms matter alongside formats. Establish when exports are available, what assistance is provided, whether charges apply, and how long access continues after termination. Address deletion of active records and the treatment of backup copies separately.

Worked example: deciding what may enter a repository

Consider an illustrative EU-based software company selecting an evidence platform. Assume its initial scope includes employee access reviews, redacted security-test findings, and incident decision records. Its internal policy requires EU storage for this scope and explicit assessment of any non-EU access. These are example assumptions, not universal legal requirements.

The vendor confirms EU production storage. Further review identifies a separate support-ticket service and an optional AI summarization provider. The team does not declare the platform acceptable or unacceptable from the hosting answer alone.

Instead, it documents three decisions:

The team then tests whether sensitive attachments enter support tickets, verifies the proposed access restrictions, and exports one complete review record.

Suppose the AI processing terms remain unclear. Leadership can approve a narrower rollout only if exclusion from that processing is dependable. If it cannot be enforced, the affected material stays outside the rollout. The unresolved issue receives an owner and a decision deadline rather than disappearing into a general vendor-risk score.

The deliverable is a bounded approval: defined evidence categories, permitted processing, restrictions, unresolved questions, and review triggers. It is more useful than an unqualified declaration that the vendor is “sovereign.”

Put the decision under leadership ownership

Procurement can gather documents, security can assess access controls, and legal can evaluate obligations. Leadership owns the business decision about acceptable exposure and dependency. Where a DPO is involved, preserve the role's independent advisory and monitoring responsibilities rather than making the DPO the owner of processing decisions.

Use explicit acceptance criteria. Unclear privileged access, unexplained processing locations, or an unusable exit path may be disqualifying for a sensitive scope. Other gaps may permit a restricted deployment with documented conditions. Record who can accept each residual risk and what would force reassessment.

Common mistakes are accepting “EU hosted” without a service-chain map, treating encryption as proof that nobody else can read the data, and postponing export testing until termination. Another is assuming a certification or audit report covers the exact service, processing path, and evidence categories being purchased. Check scope and limitations.

Turn the assessment into a repeatable workflow

Secani connects evidence to requirements, controls, target objects, and reviewed decisions, using open security-control models as a product foundation. A focused workflow can start with one service, named owners, its external-provider dependencies, and the documents supporting the purchasing decision. Missing answers become tasks; AI-assisted suggestions remain draft work subject to human review and source traceability.

Keep the selected service's hosting, processing, access, and export arrangements with the purchasing decision. Review that record when configurations, subprocessors, or contractual terms change. This gives the next reviewer a clear basis for checking whether the arrangement still meets the organization's requirements.

The practical next step is to select one sensitive evidence category and trace its full journey. Bring the resulting map, a tested export, and the unresolved access questions to the purchasing decision. That gives leadership a reviewable basis for deciding who may hold the evidence—and under what conditions.