The Sovereignty Question No GRC Vendor Wants You to Ask

You sign a three-year contract with a GRC vendor. You upload your control library, your risk register, your evidence artifacts, your policy documents. Within 90 days, the most sensitive description of your security posture that exists anywhere, more detailed than what you share with your board, more granular than what you give your auditor, lives on someone else's infrastructure.

Now ask the question: Where does my compliance data actually live, and who can access it?

Most vendors don't want you to think about this. They'd rather you evaluate features, pricing, and integration counts. Because the moment you ask the sovereignty question, their entire trust model comes under examination.

Why this matters now

Three regulatory shifts turned data sovereignty from an enterprise preference into a compliance requirement.

CMMC 2.0 enforcement. The final rule (32 CFR Part 170, effective December 2024) established explicit requirements for protecting Controlled Unclassified Information. CUI includes security assessment results, vulnerability scans, and compliance documentation. If your GRC platform stores CMMC compliance artifacts, those artifacts are themselves CUI. Storing CUI in a vendor's multi-tenant SaaS introduces a control requirement (NIST 800-171 3.1.3, 3.13.1) that most GRC vendors cannot satisfy because the data has left your authorization boundary.

GDPR Article 28 and Schrems II. Processing personal data (which compliance artifacts frequently contain: employee names in access reviews, individual risk owners, training records) requires documented data processing agreements and adequate transfer mechanisms. Every GRC vendor you send data to is a processor. Every sub-processor they use extends your supply chain. Each link requires contractual coverage and technical safeguards you can't independently verify when you don't control the infrastructure.

DORA (Digital Operational Resilience Act). Effective January 2025 for EU financial entities. Article 28 imposes concentration risk requirements for ICT third-party providers. Your GRC platform is an ICT provider. If it processes your operational resilience documentation alongside hundreds of other financial entities on shared infrastructure, you've introduced exactly the kind of concentration risk DORA is designed to prevent.

These aren't theoretical. They create audit findings. And the fix isn't a better DPA or an additional SOC 2 report from your vendor. The fix is architectural.

The trust model problem

Here's the logical structure of the problem.

Your GRC platform exists to prove you're managing risk. To do that, it stores your complete risk picture: every control gap, every failed assessment, every remediation timeline, every exception you've granted. This data is more sensitive than most of the data your security controls protect. An attacker who compromises your GRC vendor doesn't get your production database. They get the precise map of where your defenses are weakest.

Now consider the trust model of a typical vendor-hosted GRC platform:

The fundamental contradiction: the system that documents your security posture is itself a security risk you haven't fully assessed. You're trusting a vendor's security to protect the evidence of your own security. If they fail, the attacker doesn't just get data. They get the roadmap to everything else.

Sovereignty is not a deployment option

Most GRC vendors treat data residency as a premium tier. "Want your data in the EU? That's our enterprise plan." This frames sovereignty as a feature, something you pay extra for if your compliance program requires it.

That framing is wrong. Sovereignty is an architectural property of the trust model. Either the proof lives in the same boundary as the thing being proved, or it doesn't. Either you control the encryption keys, the access policies, the network boundaries, and the data lifecycle, or someone else does. There's no middle position.

Consider what happens when you separate the proof from the system it describes:

1. Your Azure tenant enforces a network security policy via NSG rules.
2. Evidence of that enforcement (Defender alerts, Azure Policy compliance state) is generated inside your tenant.
3. Your GRC platform collects that evidence and stores it outside your tenant.
4. An auditor asks to see the evidence. You pull it from the GRC platform.
5. The auditor now trusts that the evidence wasn't modified in transit, wasn't accessed by unauthorized parties, and maintains its provenance chain.

Step 3 introduces a trust gap. The evidence left your control boundary. You can't cryptographically prove it wasn't tampered with between generation and presentation. You're relying on the GRC vendor's integrity to vouch for evidence that's supposed to vouch for your integrity. That's circular trust.

When the proof and the data live in the same boundary, the chain is clean. The evidence is generated inside your tenant, stored inside your tenant, accessed only through your identity provider, and presented to your auditor without ever leaving your control. No trust gap. No circular dependency.

How Kyudo does this

Kyudo deploys inside the customer's Azure tenant. Not in a Kyudo-managed subscription. Not in a shared hosting environment with a dedicated database. Inside your tenant, on your infrastructure, behind your security controls.

Here's what that means concretely:

Compute: your AKS cluster. Kyudo runs as containers on an Azure Kubernetes Service cluster in your subscription. You control the node pool sizing, the network policies, the pod security standards. Kyudo's Helm charts deploy the application. Your cluster runs it.

Identity: your Entra ID. Every user authenticates through your existing Entra ID tenant. No separate identity provider. No vendor-managed user database. Your Conditional Access policies, your MFA requirements, your session controls apply to Kyudo access the same way they apply to everything else in your tenant.

Data: your storage boundary. Evidence artifacts, control mappings, risk assessments, policy documents: all stored in Azure resources inside your subscription. Your encryption keys (Azure Key Vault, customer-managed keys). Your backup policies. Your retention rules.

Network: private endpoints. The integrations layer connects to Microsoft Defender, Sentinel, Purview, and Entra ID through Azure Private Link. Traffic stays on the Microsoft backbone. Nothing traverses the public internet. No firewall exceptions for vendor IP ranges.

Vendor access: zero. Kyudo has no standing access to your environment. No support tunnel. No backdoor admin account. No "break glass" access that requires your approval. The software runs in your tenant. You operate it. If you need support, you grant temporary access through your own PAM process, and you revoke it when you're done.

This isn't a premium tier. It's the only deployment model. Every Kyudo customer gets the same architecture because sovereignty isn't a feature you add. It's a property of how the system is built.

The deployment takes 30 days through a structured workshop process. Helm charts, infrastructure-as-code templates, integration configuration, and validation testing. Not 6-12 months. Not a consulting engagement. A defined process with a defined timeline.

The counter-argument: "Our vendor's SOC 2 is enough"

The most common pushback: "Our GRC vendor has a SOC 2 Type II report. Their controls are audited annually. We've reviewed the report and we're comfortable with their security posture."

Three problems with this reasoning.

First, SOC 2 proves the vendor's controls are operating. It doesn't prove those controls are adequate for your specific data classification. If your compliance artifacts include CUI (CMMC), protected health information (HIPAA), or regulated financial data (GLBA, DORA), the vendor's SOC 2 wasn't scoped to cover your regulatory requirements. It was scoped to cover theirs.

Second, you're trusting their auditor. You didn't select the auditor. You didn't define the scope. You didn't review the testing methodology. You received a finished report and decided to trust it. That's a reasonable business decision for low-sensitivity data. For the single most sensitive description of your security posture, it's insufficient.

Third, SOC 2 is point-in-time evidence. The report covers a defined period. Between reports, the vendor could change hosting providers, add sub-processors, modify access controls, or experience a breach they haven't disclosed yet. Your trust decision is based on historical evidence about a dynamic environment.

None of this means vendor-hosted GRC is wrong for every organization. It means that treating the vendor's SOC 2 as the end of the trust analysis is wrong for organizations whose regulatory obligations require actual data sovereignty.

The question isn't whether your vendor has good security. It's whether "good security" is the same as "you control your own data." Those are different properties. They require different architectures.

What to do this week

1. Classify your compliance data. Apply the same data classification framework you use for production data to your GRC artifacts. Control gap analyses, risk assessments, evidence of security failures, remediation timelines: what sensitivity level do these carry under your own classification policy?

2. Map the trust chain. For your current GRC platform, document every entity that has access to your compliance data. Vendor employees (engineering, support, DevOps), sub-processors, hosting providers, monitoring tools. If you can't complete this list from the DPA alone, that's a finding.

3. Ask the encryption key question. Who holds the keys? If your vendor manages encryption, they have the technical capability to access your data regardless of contractual obligations. Customer-managed keys aren't a premium feature. They're the minimum for sensitive data.

4. Evaluate your regulatory position. If you're subject to CMMC, HIPAA, GDPR, DORA, or any regulation with explicit data residency or processing locality requirements, ask whether your current GRC deployment satisfies those requirements. Not whether your vendor claims it does. Whether you can prove it to an auditor.

5. Quantify the concentration risk. How many other organizations' compliance data sits on the same infrastructure as yours? A breach of your GRC vendor doesn't just expose your data. It exposes the security roadmaps of every customer on that platform. That's a target worth hitting.

Sovereignty isn't a procurement preference. It's a trust architecture decision. The proof should live in the same boundary as the thing being proved. If it doesn't, you've introduced a gap that no amount of vendor assurance can close.

Book a demo to see Kyudo deployed inside a customer Azure tenant. We'll walk through the architecture, show you the zero-access model, and explain exactly what lives where. Bring your security architect.