Customer-Hosted GRC Inside Your Azure Tenant
Customer-hosted GRC is a deployment model where the compliance platform runs inside the customer's own cloud subscription rather than in the vendor's multi-tenant SaaS. Kyūdō supports a customer-hosted Azure deployment model where governance data, AI inference, secrets, application services, and telemetry remain inside the customer's Azure subscription.
There is no cross-tenant data plane: the platform is delivered through Azure Managed Applications, and every service is reached through private endpoints. This page describes the model in detail; the architecture brief covers the operating philosophy behind it.
Why regulated buyers ask where the platform runs
For regulated organizations, a GRC platform concentrates the most sensitive picture of the enterprise: every control gap, every risk, every piece of evidence. Where that picture lives is a diligence question before it is a feature question.
Data residency as a control requirement
Many frameworks treat the location and custody of governance data as a control in its own right. When the platform runs in your subscription, residency is a property of the deployment, not a clause in a vendor contract.
Procurement and DPA review
A platform with no vendor-held compliance data shortens data processing agreement review: there is no subprocessor chain for governance data to trace, because the data never leaves the subscription the customer already governs.
CUI and regulated boundaries
Organizations handling Controlled Unclassified Information or operating under strict regulatory boundaries can keep the GRC platform inside the boundary they already defend, instead of extending that boundary to a vendor's cloud.
How the deployment works
Kyūdō uses standard Azure building blocks, so the deployment can be reviewed with the same tooling the customer already applies to its own workloads.
Azure Managed Application
The platform installs as an Azure Managed Application: a defined, inspectable resource group inside the customer's subscription, with a clear boundary between what the publisher maintains and what the customer owns.
Containerized services
Application services run as containers inside the deployment. There is no shared runtime with other customers, because there are no other customers in the environment.
Private endpoints only
Application services, storage, Key Vault, SQL, identity, and AI inference are reached exclusively through private endpoints. No service in the deployment listens on the public internet.
Managed identities
Services authenticate to each other with Azure managed identities rather than stored credentials, and secrets that must exist live in the customer's own Key Vault.
Everything inside one boundary
The diagram below shows the deployment topology. Every service sits inside the customer's Azure tenant and communicates over private endpoints. The vendor's only relationship to the environment is publishing Managed Application updates.
Kyudo, Inc. publishes Managed Application updates. No compliance data crosses this line, because no data plane exists on the vendor side.
No vendor-owned compliance data plane
This is an architectural claim, not a policy promise. In a multi-tenant SaaS, the vendor operates a data plane that holds every customer's compliance data, and access to it is constrained by policy. In Kyūdō's model there is no such plane: the Compliance Graph, evidence store, and telemetry exist only inside the customer's subscription, so no path exists in the architecture through which the vendor could reach the data.
The identity and security boundary follows the same principle. Access to the deployed environment is governed by the customer's Microsoft Entra ID, encryption keys and secrets live in the customer's Key Vault, and AI inference runs on Azure OpenAI Service or customer-chosen endpoints in the tenant. Prompts, retrieved context, and responses never leave the customer data boundary. Commitments and audit posture are documented on the trust page.
Updates work without weakening this boundary. Under the Azure Managed Application model, Kyūdō publishes new application versions and maintains the application resources, while data, identity, and network controls stay with the customer. The customer gets managed software without granting the vendor a data plane, and without taking on day-to-day operation of the platform. Teams evaluating this model for regulated workloads can start with the sovereign GRC solution overview.
Related reading: Microsoft-native GRC explains what the platform does with the signals inside this boundary, and the FAQ answers common procurement questions.
Questions, answered
Yes. Kyūdō deploys through Azure Managed Applications into the customer's own Azure subscription. Application services, governance data, secrets, telemetry, and AI inference all run inside that subscription, with private endpoints only on application services, storage, Key Vault, SQL, identity, and AI inference.
The architecture provides no path to it. There is no vendor-owned compliance data plane and no cross-tenant SaaS layer, so there is no route through which compliance data leaves the customer's subscription. Access to the deployed environment is governed by the customer's own Microsoft Entra ID, and secrets remain in the customer's Key Vault.
Kyūdō deploys as an Azure Managed Application: containerized services installed into the customer's Azure subscription, connected exclusively through private endpoints and authenticated with managed identities. The Managed Application model gives the deployment a defined resource boundary that the customer can inspect.
No. Under the Azure Managed Application model, Kyūdō publishes updates and maintains the application resources while the deployment stays inside the customer's subscription. The customer keeps ownership of the data, identity, and network boundary without taking on day-to-day operation of the software.
AI operations run on Azure OpenAI Service or customer-chosen endpoints inside the customer's tenant. Prompts, retrieved context, and responses never leave the customer data boundary, and inference endpoints are reached through private endpoints like every other application service.
Looking for more? See all frequently asked questions.
Review the architecture with your own team
Bring your cloud, security, and procurement stakeholders. The deployment is inspectable because it lives in your subscription.