Data Sovereignty Is a Question of Who Holds Control
Ask most executives where their sensitive data lives and they can name a region. Ask who can read it, copy it or switch it off, and the answer gets vaguer. That gap is the real subject of data sovereignty, and regulators have started to say so plainly. On November 5, 2026, Spain’s data protection authority, the AEPD, and its Greek counterpart published a joint guide on secure processing environments that treats control as a technical fact rather than a contract clause.
The same week brought two reminders of what happens when control exists on paper and nowhere else. A coalition of four state attorneys general announced a settlement with a company whose monitoring software recorded an intruder and told nobody. And a UK case showed how a spreadsheet published in good faith carried hidden data about roughly 8,000 employees out the door.
This post argues that sovereignty, privacy and security failures share one root. Somebody believed a control was in place, and nobody checked whether it held. The sections below cover what regulators now expect, why location and control are different questions, how supplier concentration quietly erodes both, what the recent enforcement and disclosure cases reveal, how AI assistants inherit every one of these problems, and how to review control on a schedule so that belief gets replaced by a check.
Key Takeaways
1. Regulators define sovereignty as control.
The AEPD and Hellenic guide says the provider must hold real and effective control even when a third party supplies the infrastructure, which moves the question from a contract to a technical fact.
2. Location answers where, control answers who.
A server inside the right border still leaves open who holds the keys, who administers the system and which subcontractors can reach the data.
3. Controls that never fire are worse than none.
A settlement over 13.3 million affected people turned on missing multifactor authentication, unencrypted files and monitoring software that was never set to alert.
4. Data leaves through channels people trust.
A routine public records release exposed hidden sickness absence data on roughly 8,000 employees because nobody tested what the spreadsheet contained.
5. AI assistants inherit the same gaps.
A banking regulator’s new guidance keeps banks responsible for third-party AI, so assistants must act within the user’s rights and under the same policy as people.
A European Guide Says the Quiet Part Out Loud
The AEPD and the Hellenic Data Protection Authority built their guide with input from Eurostat, Spain’s General Directorate of Data, Italy’s Garante and the UK Information Commissioner’s Office. That is a notable list of contributors for a document about infrastructure. It signals that supervisors across several jurisdictions agree on the point.
The point is that an organization responsible for personal data must keep real and effective control over the processing environment, even when a third party supplies the infrastructure. A certificate on a supplier’s website does not satisfy that. Neither does a clause in a contract. The guide also warns against depending on a single provider and notes that a data protection impact assessment will generally be mandatory for this kind of processing.
Read that as a shift in burden. For years, many organizations handled sovereignty by buying assurances. They collected certifications, signed the standard paperwork, and filed the supplier’s attestation with the privacy program. The guide implies a different test. Can you, as the responsible organization, demonstrate that you hold the levers? Can you decide who gets access, change the configuration, and move or delete the data without asking permission from someone else?
Most organizations cannot answer yes to all three. The levers usually sit with the cloud provider’s administrators, the managed service provider’s engineers, or a subcontractor three links down the chain. That is not a failure of intent. It is the natural result of buying infrastructure as a service and then treating the purchase as the control.
A fair caution applies. The guide is a supervisory publication on secure processing environments, and it does not create new law on its own. But supervisors write guides to describe how they will read existing law, and the direction is hard to miss. The responsible party must be able to show control, and a supplier’s promise is not a demonstration.
What Data Compliance Standards Matter?
Location Answers Where, Control Answers Who
Three terms get blurred in boardrooms. Data residency describes where data is stored. Data localization describes laws that require data to stay inside a territory. Sovereignty describes who holds authority over the data, including who can compel access to it. A system can satisfy the first two and fail the third.
Consider a hypothetical organization that stores customer records in a data center inside its home country, run by a subsidiary of a foreign provider. The residency box is checked, and a localization rule is satisfied. But if the provider’s home government can compel the provider to hand over data held by its subsidiaries, the organization’s control is conditional. That is the concern behind the debate over the US CLOUD Act, and it is the reason a postcode on a contract proves less than it appears to.
Three questions turn a location claim into a control claim. Who holds the encryption keys? If the supplier does, then the supplier’s staff or a legal order can unlock the data, whatever the geography. Customer-controlled encryption keys move that power to the organization, and double encryption adds a second layer so that no single party’s credentials unlock everything.
Who administers the environment? Administrators can see and change nearly everything, so the location of the administrators matters as much as the location of the disks. An organization that keeps data in-region but allows remote administration from elsewhere has moved the question, not answered it.
Which subcontractors touch the data? A supplier’s own assurances rarely extend to its suppliers. The chain is where sovereignty quietly leaks, and an honest third-party risk management program maps it to the last link.
None of this makes cross-border transfers impossible. Mechanisms such as standard contractual clauses remain a legitimate part of GDPR compliance. But a clause is only as strong as the organization’s ability to verify that the conditions it describes are being met, which brings the conversation back to control.
One Provider Is One Point of Failure
The AEPD guide warns against dependence on a single provider, and the Kiteworks research on the region where sovereignty pressure is growing fastest shows why the warning is practical rather than theoretical. In Kiteworks 2026 Data Security and Compliance Risk: Data Sovereignty in the Middle East, 44 percent of Middle East respondents reported a sovereignty-related incident, compared with 32 percent in Europe and 23 percent in Canada.
The mix of incidents is instructive. Regulatory investigations accounted for 22 percent, sovereignty-related breaches for 20 percent, third-party failures for 19 percent, government access requests for 15 percent and unauthorized transfers for 13 percent. Awareness was high, at 74 percent, and 93 percent said that sovereignty frameworks affect their operations. Knowing about the problem has not prevented it.
Look at how many of those categories trace back to a supplier. Third-party failures are the plain case, but government access requests, unauthorized transfers and even some breaches depend on what a provider can reach and who can compel it. Concentration multiplies the effect. If one provider holds the data, the keys and the administration, one failure, one legal order or one outage reaches everything.
The same survey found that 48 percent plan to increase regional cloud use, and 33 percent cite geopolitical instability as a driver. Moving workloads to a regional provider can reduce some exposure, and it can also create a new concentration if the organization simply swaps one dependency for another. Regional hosting changes the address of the risk. It does not remove the need to hold control.
Resilience belongs in the same conversation. An exit plan that has never been rehearsed is a hope. The test is whether the organization could move its data, its keys and its policies to another environment within an acceptable window, and whether it has ever tried. Supervisors who ask about single-provider dependence are asking about that rehearsal.
A Control That Exists but Does Not Fire
If the first failure mode is trusting a supplier’s assurance, the second is trusting your own tools without testing them. On November 6, 2026, New York’s Attorney General announced a settlement, reached with a coalition that also includes Connecticut, Michigan and New Jersey, with Perry Johnson & Associates and four related companies. The headline figure is up to $10 million, of which at least $300,000 is guaranteed and $9.7 million is contingent. The incident affected about 13.3 million people, including roughly 4.2 million New Yorkers.
The facts are plain. In March 2023, an intruder entered using an employee’s credentials. Remote access had no multifactor authentication. Files containing protected health information were unencrypted. One company’s software recorded the intruder’s activity but was not configured to alert anyone, and the intrusion came to light about two months later, when the hackers made contact.
Every control in that story existed in some form. The company had logging software. It had remote access. It had files. What it lacked was the configuration that would have made each control do its job. Multifactor authentication was absent from the door the intruder used. Encryption was absent from the files the intruder reached. And an alert was absent from the one tool that watched.
This is the failure that rarely appears on a compliance checklist, because a checklist asks whether a control is present. The settlement terms point to a different question, whether each control is configured to act. The required reforms include a security program and incident response protocol, multifactor authentication, password management, encryption and asset management, annual HIPAA risk assessments, and policies for collection, use, retention and disposal of data. Several of those are about operation, not ownership. They require someone to check on a schedule that the measures still work.
For regulated data, the stakes sit in the HIPAA Security Rule and its expectation of ongoing risk analysis. The practical lesson reaches beyond healthcare. An audit log that records everything and alerts on nothing is a diary. A monitoring tool is a control only when a named person receives its output and is expected to act on it.
Data Can Leave Through a Door Nobody Watched
Not every loss involves an attacker. A case reported in a Jackson Lewis analysis on December 9, 2025, described how Royal Cornwall published a spreadsheet in response to a 2023 freedom of information request. The file contained hidden data on sickness absence for roughly 8,000 current and former employees. After the problem surfaced, the file was removed, the disclosure log was suspended, and the organization adopted a rule that spreadsheets must be fully disabled before release.
The detail worth noticing is how ordinary the channel was. A public records release is a trusted, routine, approved route for data to leave. Nobody was trying to steal anything. The organization simply did not know what its own file contained, because the sensitive material sat in hidden sheets that the person publishing never saw.
That is a sovereignty problem as much as a privacy one. An organization that cannot say what a file contains cannot say where the file’s contents have gone, who can read them or which law applies. Data classification is the control that answers those questions, and data loss prevention is how classification gets enforced at the point where a file is about to leave. Both are dull until the day they are missing.
The fix in this case was a change to process, and it was a good one. But the better question is why a rule about hidden spreadsheets had to be learned from an incident. Any organization that releases documents, shares files with partners or sends data to regulators faces the same hazard. The test is simple to state and rarely run. Take a representative sample of outbound files and ask what each one contains that its sender did not intend to share.
For personal and health data, the answer carries weight under PII and PHI rules. A control that works only when the person releasing the file remembers to look is a habit, and habits fail on busy days.
AI Assistants Inherit Every One of These Problems
Everything above applies to AI assistants, and the bank supervisors have noticed. On November 5, 2026, American Banker reported that the OCC issued non-binding guidance on delegating tasks to AI agents, organized around six pillars covering purpose, potential risks, controls, human oversight, resilience and testing. Banks are expected to document each AI system’s purpose, authorized users, data permissions and authority. Banks remain responsible for third-party AI, and the intensity of controls rises with the autonomy the system is given.
Translate that into the sovereignty frame. An assistant that reads documents and takes actions is a new path by which data moves, and it inherits the control problems of whatever it touches. If it runs on a supplier’s infrastructure, the supplier question applies. If it reaches files that were never classified, the classification gap applies. If its activity is logged by a tool nobody watches, the alerting gap applies.
The answer is parity, not a separate program. Assistants should act within the rights of the person they serve, and they should be governed under the same policy and recorded in the same log as people. An organization that builds a second rule set for AI will find that its two sets of controls diverge, and that the gap between them is where a regulator’s questions land. Banks remain responsible for third-party AI, so the practical question is whether the bank can enforce its own policy on an assistant it did not build.
This is also why the zero trust data exchange approach fits. Verification happens at the point where data moves, for every actor, whether employee, partner or assistant, and the organization holds the policy rather than renting it. The same principle that answers the AEPD’s question about control answers the OCC’s question about delegation.
Two Wrong Answers on Sovereignty
The first wrong answer is to pull everything in-house. It feels like the strongest form of control, and for a small set of workloads it is appropriate. For most organizations it trades one weakness for another, because building and running every environment demands skills and funding that few can sustain, and weak operations produce exactly the missing alerts and unencrypted files the settlement described. Control is not the same as owning every server.
The second wrong answer is to buy assurances and call it done. Certifications, attestations and contract clauses have value, but the AEPD guide is clear that they do not substitute for real and effective control. An organization that stops at paperwork has a record of intent, and a regulator will ask for more.
The variable is whether the organization holds the levers that matter, wherever the infrastructure sits. That means holding the keys, setting the policy, seeing the log and being able to move the data. An organization can meet those four tests on a supplier’s infrastructure, and can fail them on its own.
Naming the failure helps. Call the paperwork-only pattern assurance theater, a program that collects comfort instead of testing control. Call the untested control a dormant control, one that is present and silent. Both are common, and neither shows up in a presence-based audit.
How Kiteworks Puts Control Where the Data Lives
The Kiteworks Control Plane is built around the four tests above. It runs single-tenant, so one customer’s data and keys are not mixed with another’s. It applies double encryption, and it includes geofencing and data sovereignty controls that let an organization decide where content can be accessed and exchanged. One policy engine and one audit log cover how sensitive content moves, whether the actor is an employee, a partner or an AI agent.
That last point answers the parity question. The Kiteworks Secure MCP Server lets AI assistants such as Claude and Copilot work with enterprise content while inheriting the permissions of the user they serve, with role-based and attribute-based controls applied to every AI operation. Credentials are held in the operating system’s keychain and are never exposed to the model, and the audit log feeds the organization’s SIEM. Kiteworks Compliant AI applies this governance for organizations that must show regulators how AI touches regulated data.
For organizations working through sovereignty requirements, data sovereignty compliance capabilities and a single data policy engine give the responsible party something concrete to show a supervisor. Humans and agents sit under one plane, so a change to a rule applies to every actor and appears in one record.
No product removes the need for the review described next. But a platform that puts the keys, the policy and the log under the customer’s authority makes the review answerable.
Review Control Every Quarter
A quarterly review can fit in a half day and answers the questions that regulators and settlements keep returning to. Start with keys. List every system holding sensitive data and record who holds the encryption keys for each. Any answer that reads “the supplier” is a finding.
Next, test alerts. Pick three controls your tools claim to provide, such as a failed multifactor challenge, a bulk download or a login from a new country, and trigger each in a test environment. Record whether a named person received a notification and how quickly. A control that fires into an unwatched inbox has not fired.
Then sample outbound files. Pull twenty documents that left the organization in the past quarter, through email, file sharing, public records or partner portals, and inspect each for hidden sheets, metadata and personal data that the sender did not intend to share.
Map the chain for your two most critical suppliers, down to subcontractors and administrators, and note where each has access. Ask whether you could exit within a stated window, and if the answer is unknown, schedule the rehearsal.
Finally, review AI assistants. For each one, write down whose permissions it uses, which systems it reaches and where its activity is logged. If the answers differ from what you would say about a human user with the same job, close the difference.
Write the results on one page and send it to the people who own privacy, security and procurement. Repeat in ninety days and compare. A finding that repeats is a signal that the organization is documenting a problem rather than fixing it.
To see how holding keys, policy and logs under your own authority can make sovereignty answerable, schedule a custom demo today.
Frequently Asked Questions
Data residency describes where data is stored, while sovereignty describes who holds authority over it, including who can compel access. A system can sit in the right country and still be subject to a foreign legal order through its provider. The AEPD and Hellenic guide, published November 5, 2026, frames the test as real and effective control. See the data sovereignty compliance overview and the explainer on data residency.
Show who holds the encryption keys, who administers the environment and which subcontractors can reach the data, then show that you can change policy, revoke access and move the data without the provider’s permission. Contracts and certifications support that case but do not replace it. Customer-controlled encryption keys are often the first and strongest lever, and a documented DPIA records the reasoning.
They are often present but not configured to act. In the settlement announced by New York’s Attorney General on November 6, 2026, remote access lacked multifactor authentication, files were unencrypted, and monitoring software recorded the intruder without alerting anyone. Test each control by triggering it, and confirm a named person receives the result. An audit log is useful only when someone reads it.
Apply one policy to both. Assistants should act within the permissions of the person they serve and be recorded in the same log as people, so no separate rule set develops. The OCC’s guidance, as reported by American Banker, keeps banks responsible for third-party AI and ties control intensity to autonomy. The AI data governance guide and role-based access control explain how to apply it.
The Kiteworks Control Plane is single-tenant and uses double encryption, with geofencing and data sovereignty controls and one policy engine and audit log for people and AI agents alike. The Kiteworks Secure MCP Server keeps credentials out of the model and applies the user’s permissions to every AI operation. Review the MCP server and the Control Plane overview, and confirm requirements with your counsel.
Additional Resources