The standard GRC SaaS assumes two things that stop being true in sovereign environments: your data can be processed in a cloud the vendor controls, and your systems can reach the public internet. For a meaningful and growing class of organizations — European defense, national healthcare, certain categories of public-sector finance, critical infrastructure operators under NIS 2 — neither assumption is permitted.

These teams still need to prove compliance. The frameworks they answer to are no less demanding — often more so. But the category of tooling they are sold does not work in their environment, and the category of tooling that does work is, charitably, from another decade.

This is solvable. It is not solved by porting a SaaS into a VPC. It is solved by treating the sovereignty constraint as a design primitive, not a deployment afterthought.

What sovereignty actually constrains

"Sovereign" is a loaded word. Different regulators mean different things. For the purpose of this post, we are talking about the union of four concrete constraints that show up, in various combinations, across real engagements:

Data residency. Data — including evidence artifacts and their metadata — must remain within a defined jurisdiction. Not "the provider operates an EU region"; jurisdictional control over the operator itself. GAIA-X, SecNumCloud, the French "Cloud de Confiance" qualification, BSI C5 in Germany, the Italian ACN cloud framework — each formalizes this in its own way.
Air-gap or restricted egress. The systems being audited cannot initiate connections to external services. Outbound traffic is allowlisted at a layer-7 egress, or there is no egress at all. Any tool that assumes it can POST to api.vendor.com is out.
Restricted ingress for auditors. The auditor cannot receive a VPN credential and browse a SaaS dashboard. Assessment happens on-site, or through a formally-approved evidence exchange process, or via a government- issued reviewer workstation.
Jurisdictional control of the control plane. The software performing the audit — the mapping engine, the evidence parser — must itself be subject to the same jurisdictional control as the data. This rules out most US-incorporated GRC vendors regardless of where their servers run, under the extraterritorial reach of CLOUD Act and analogous provisions.

Any one of these four is annoying. The combination is what breaks the standard toolchain. A SaaS-model GRC platform fails at constraints 1–4 simultaneously. An on-premise GRC install fails at 1 (metadata leakage) and 4 (US-vendor provenance). A spreadsheet-based process satisfies all four and delivers approximately zero of the value.

Why the "install the SaaS in our VPC" answer is wrong

Every GRC vendor with a sovereign customer pipeline now offers a "private deployment." This is not the answer people hope it is.

A private deployment of a SaaS product is a SaaS product running somewhere else. The control plane — the update channel, the telemetry, the support access — remains with the vendor. You have moved the bytes; you have not moved the control.

From a regulatory standpoint the relevant question is not "where does the storage happen?" It is "who has administrative access to the running process, and under whose law do they operate?" A US-headquartered vendor that SSHes into your private deployment to debug is, under most sovereignty regimes, disqualifying. And every SaaS vendor that ships private deployments does SSH in; that is the support model.

The honest framing: a private deployment is the same sovereignty hole with a longer commute for the attacker.

What actually works

A sovereignty-native GRC system has three properties that the SaaS model structurally cannot provide.

1. A pipeline, not a platform

The audit is produced by a program, not a service. The program accepts evidence inputs on disk, produces reports on disk, and exits. It does not need a database it owns. It does not need a queue. It does not need a scheduler. It is invoked by the operator's existing infrastructure — a CronJob, an Ansible play, a systemd timer — on a schedule the operator sets.

A pipeline's sovereignty story is simple because there is almost nothing to tell: it runs where you run it, with the privileges you grant it, against the bytes you feed it, and then it exits. There is no control plane. The sovereignty question becomes trivial.

2. Reproducibility as a sovereignty property

In a sovereign context, reproducibility is not a quality-of-life feature. It is the mechanism that allows the auditor to verify the report without direct system access.

The workflow: the operator runs the pipeline on their side of the air gap. The output is an evidence bundle — signed inputs, engine commit SHA, mapping version, report. The bundle is transferred out via the formal process (sometimes a physical courier with a signed USB, unironically). The auditor, on their workstation, re-runs the same pipeline version against the same inputs and obtains the same report byte-for-byte. If the hashes match, the evidence is authentic and the finding is verified.

This is structurally identical to how reproducible builds solve supply-chain integrity for air-gapped software distributions. Reproducibility is not technically difficult once it is a goal; most GRC toolchains simply do not have it as a goal, because they were designed for a world where the auditor could log in.

3. Offline-first framework data

The mapping — SOC 2 controls, NIS 2 measures, ISO 27001 Annex A, whatever applies — is versioned content, shipped with the pipeline as a static asset. Not fetched. Not updated live. When a framework changes, you get a new pipeline version with a new mapping version. You deploy it deliberately, under change control, like you would any other offline-distributed software.

This sounds obviously correct and it still trips up most vendors, because their business model depends on shipping mapping updates continuously as a service. A sovereign customer neither needs nor wants that.

An air-gapped audit, in concrete terms

Here is what one looks like end to end, for a hypothetical NIS 2 evaluation of a critical infrastructure operator.

On the operator side, inside the enclave:

# 1. Capture the evidence bundle — a typed snapshot of the systems in scope.
#    No network calls. Pure filesystem + local API reads.
cplt-capture \
    --scope /etc/cplt/scope.yaml \
    --out   /mnt/evidence/nis2-2026Q2.tar.zst
 
# 2. Run the deterministic evaluator. Mapping is embedded in the binary.
cplt-evaluate \
    --framework nis2 \
    --mapping-version 2024.3 \
    --evidence /mnt/evidence/nis2-2026Q2.tar.zst \
    --out      /mnt/reports/nis2-2026Q2.report.json
 
# 3. Sign the bundle with the operator's sovereign HSM-backed key.
cplt-sign \
    --bundle  /mnt/reports/nis2-2026Q2.report.json \
    --key     hsm://slot-0/cplt-audit \
    --out     /mnt/reports/nis2-2026Q2.report.signed

No outbound network. No control plane. Every input and output is a file on a filesystem that never leaves the enclave, except through the formal evidence exchange.

On the auditor side, outside the enclave:

# Auditor receives the signed bundle via the approved channel.
# They have their own copy of the pipeline, pinned to the same version.
cplt-verify \
    --bundle   received/nis2-2026Q2.report.signed \
    --expected-mapping 2024.3
 
# Output:
# ✓ signature valid (operator public key: a3:c2:…)
# ✓ mapping version 2024.3 matches pipeline build
# ✓ report deterministically reproduced from evidence inputs
# → findings: 142 controls evaluated, 9 failing, 3 partial

The auditor never touched the operator's systems. They did not browse a dashboard. They did not request a screenshot. The report they are reviewing is the same bytes the operator produced, and they have mechanically verified that it was produced correctly.

That is what sovereign compliance tooling should look like, and almost nothing on the market looks like it.

Where the industry is heading

The shape of the EU regulatory environment — NIS 2, DORA, the AI Act, the Cyber Resilience Act — makes this category non-optional on a five-year view. The regulations increasingly specify evidence obligations rather than control obligations, and they increasingly reference reproducibility and data sovereignty by name.

The vendors who will matter in that future are the ones who treat the constraints as the design brief. Not "cloud-native with a sovereign option." Not "SaaS, private deployment available." Something closer to a signed binary, a versioned mapping, a deterministic engine, and no phone home.

We have been building towards that design for some time, because the customers who need it are the ones whose compliance posture most genuinely matters — not the ones shopping for a badge to put in a vendor portal.

If you are running systems where the bytes do not leave the jurisdiction, you already know your options are narrow. The good news is that the narrow set is also the one that works.