Running a compliance check in your own cloud: who controls what

Some organisations are comfortable with cloud but not with a vendor’s cloud. Their policy is specific: anything that touches customer data runs inside our own tenant, under our own subscription, our own keys, our own region. They are not rejecting cloud computing. They are rejecting the idea that a third party’s environment sits in the data path. For those firms the question about a compliance tool is not “where is your cloud”, it is “can it run in ours”.

That is what a sovereign deployment answers. The detection engine runs inside the customer’s own cloud boundary, in their tenant, rather than in the vendor’s environment. The data never leaves the organisation’s control plane. It is the middle option between a shared cloud service and a fully on-premise install, and it exists because “cloud or not” was never the real axis. The real axis is whose cloud, and who controls the parts.

Why “your own tenant” changes the legal shape

In an ordinary cloud service the vendor is your processor under Article 28 of the GDPR: they handle personal data on your behalf, and the contract has to bind them to act only on your instructions, keep it confidential, and help with your obligations. That model works, but it means a third party is processing your data in their environment, and your governance of that processing is contractual, exercised through a document rather than through control of the infrastructure.

A sovereign deployment shifts where the processing physically happens without removing the vendor’s role in the software. The data is processed inside your tenant, on infrastructure you control, under your own access management and logging. The vendor still provides and supports the engine, but they are not hosting your data in their environment. For a regulated firm that distinction is the whole point: the difference between “we trust the vendor’s controls” and “we apply our own controls, to our own infrastructure, and the vendor’s software runs within them”.

The responsibility split, written down

The single most useful thing to settle before a sovereign deployment is who owns which layer. Ambiguity here is where both security gaps and finger-pointing come from. The split is stable enough to put in a table and attach to the contract.

Read down the owner column and the pattern is clear: you own the environment and everything about where the data sits, the vendor owns the thing that does the analysis. That is exactly the split a firm wanted when it said “it has to run in our cloud”. It also means the operational load is real on your side: a sovereign deployment is infrastructure you run, not a URL you log into. That is the trade, and it is worth naming before procurement, because the team that will carry it should agree before the contract, not discover it after.

What a security review should verify

Because a sovereign deployment lives in your environment, the security review is yours to run, and it should check the things the vendor can no longer control on your behalf. Five checks cover most of it.

• Key custody. Confirm the encryption keys for data at rest sit in your key vault, under your rotation policy, and that the vendor’s software has no path to export them.
• Subscription access. List who can reach the tenant and the resource group the engine runs in. A sovereign deployment is only as controlled as the access to the account it lives in.
• Egress rules. The engine runs analysis locally, but verify what it is allowed to reach outbound: licence checks, update endpoints, telemetry. Decide each one deliberately and block the rest.
• Update provenance. When the vendor ships an engine update, how do you know it is theirs and unmodified? Ask for signed artifacts and verify the signature before you deploy, the same way you would for any third-party code entering your environment.
• Logging ownership. Confirm the access and processing logs land in your logging stack, not only the vendor’s, so an audit later reads from your own records.

Update provenance is the one teams forget, and it is the one that matters most over time. A sovereign deployment moves the data into your control but also moves a piece of third-party software inside your boundary, where it will be updated repeatedly. Treating each update as untrusted code until its signature is verified is what keeps the control plane you fought for from quietly becoming a supply-chain path. The vendor should expect this check and make it easy; if signed, verifiable updates are not on offer, that is itself a finding.

When sovereign is the right call, and when it is not

Sovereign is the right edition in a specific band. Above it and below it, other editions fit better.

• If the vendor’s EU cloud is acceptable, as long as the text is not retained and not used for training, you do not need sovereign. The standard cloud edition is simpler, faster to stand up, and carries less operational load on your side. Choosing sovereign here is paying in effort for control you did not require.
• If your policy is “our cloud only”, but the data can still live in a cloud tenant, sovereign is the fit. You get your control plane and your keys, and the vendor’s environment is out of the data path.
• If the text cannot touch any cloud at all, or cannot leave the network, sovereign is not enough, because it is still cloud. That requirement points to an in-network deployment where the model runs on your own hardware, a different deployment edition.

The mistake to avoid is treating sovereign as automatically “more secure” and defaulting to it. It is not more secure, it is more controlled by you, which is only an advantage if your policy actually requires that control. For a firm whose requirement is met by the cloud edition, sovereign adds operational burden without adding compliance value. Match the edition to the policy, not to the instinct that on-your-side always sounds safer.

Where the pre-send check fits

The job does not change with the deployment. VerbaPulse is a pre-send check for accidental risk: it reads a draft before it is sent and returns the sentences that create legal exposure, with the reason and a safer version. In a sovereign deployment that same check runs inside your tenant, so the drafts it reads never enter a vendor environment. It complements your archiving and supervision stack and is not an adversarial boundary. What sovereign changes is the control plane around the check, not the check itself.

The takeaway

Before you ask for a sovereign deployment, write your actual data policy in one sentence and test it. If the sentence is “it can be cloud, but only our cloud, under our keys”, sovereign is the fit and the responsibility table above is your starting contract. If the sentence is “cloud is fine as long as the text is not kept”, you want the simpler cloud edition and sovereign is effort you do not need. If the sentence is “the text cannot touch cloud”, you have already moved past sovereign, and the next conversation is about running the model in your own network.