Documentation / Security & Compliance

Compliance & Shared Responsibility

How Nexus fits your compliance boundary — data residency and sovereignty follow your Azure region and policy, isolation is defined by your subscription and network rather than shared vendor infrastructure, Nexus inherits the underlying Azure services' certifications, and a proven path to government cloud exists.

This page is for compliance and GRC reviewers deciding whether Nexus fits inside an existing regulatory boundary. The core message is structural: because Nexus runs inside your Azure subscription with no Stingray-hosted data plane, most compliance questions reduce to questions about your Azure environment, which you already govern and can already attest to. This page is precise about what that inherits, what remains your responsibility, and — importantly — what Stingray does not claim.

Data residency and sovereignty follow your Azure choices

Nexus stores and processes your data in the Azure region you deploy into, governed by your Azure Policy. There is no Stingray-side copy, cache, or replica of your data in some other region. Consequently:

Data residency is wherever you place the deployment. If your policy requires data to stay in a specific geography, deploy Nexus there and it stays there.
Data sovereignty follows your subscription's tenancy and your policy controls; Nexus does not introduce a cross-border data flow, because your data never leaves your tenant.
The only cross-tenant flow is the metadata-only control-plane channel (updates, catalog, licensing, optional telemetry), which carries no business data. See Security Architecture for the data-flow inventory.

This is a stronger residency story than a typical SaaS, where you must trust a vendor's regional handling. Here, residency is an attribute of your own subscription.

Isolation is defined by your subscription, not shared vendor infrastructure

For a compliance reviewer, "how are we isolated from other customers?" is central. In Nexus the answer is not "trust our multi-tenant partitioning" — it is "you are isolated the way two Azure subscriptions are isolated," because that is literally the boundary. Per-tenant Container App, PostgreSQL, Key Vault, and VNet mean there is no shared data store whose partitioning you would need to audit. Your isolation controls are your own subscription boundary, your network policy, and your identity configuration. See Tenant Isolation & Data Custody.

Nexus inherits the underlying Azure services' certifications

Nexus is built on Azure-native services — Container Apps, Azure Database for PostgreSQL Flexible Server, Key Vault, Azure Files, Azure Functions (control plane). Those services carry Microsoft's own broad certification portfolio. When Nexus runs on them inside your subscription, your deployment sits atop that certified service posture.

Be precise about what this means and does not mean:

What it means: the platform components run on Azure services that Microsoft attests to, and your deployment inherits that underlying posture within your compliance boundary.
What it does not mean: it does not mean Nexus itself holds those certifications. An Azure service being certified is not a Stingray certification. Stingray does not represent that Nexus is independently certified.

What Stingray does and does not claim

Stingray describes its posture honestly. To be unambiguous:

Stingray does not claim to hold SOC 2, ISO 27001, FedRAMP, or any other certification of its own.
Stingray does not claim a third-party penetration test.
Stingray does operate a real, documented security program — a tracked findings register, gated security reviews, and red-team exercises — with detailed evidence available under NDA (see Secure Development & Vulnerability Management).
Stingray does rely on, and inherit the posture of, the Azure services Nexus runs on.

For the current attestation status relevant to your specific deployment and industry, contact your Stingray representative. Compliance status changes over time; the representative is the authoritative source, and this documentation deliberately does not freeze a claim that could go stale.

A proven path to government cloud

Nexus has a demonstrated path to regulated government-cloud deployment, not merely a theoretical one:

The Delva tenant runs on Azure Government (GCC-High), a live deployment in the government cloud.
A cross-cloud image pull — the commercial-cloud registry serving the government-cloud tenant — has been confirmed in practice, which is the operationally hard part of a single-publisher, multi-cloud model.
Government-cloud deployments use government identity endpoints (for example login.microsoftonline.us) and government-appropriate configuration.

This matters to a public-sector or defense-adjacent evaluator because it shows the tenant-owned model already operates under the constraints of a sovereign cloud, rather than being a commercial-only product with a "we could probably do gov" promise. See Deployment for how a managed-application deployment is provisioned.

Your compliance responsibilities

Because the model is shared, some compliance obligations are structurally yours:

Subscription and identity governance — your Entra configuration, conditional access, MFA, and who holds Azure RBAC over the deployment.
Network policy — your VNet, NSG rules, and private-endpoint configuration.
Data classification and retention — you control retention on the in-tenant audit trail and the underlying database.
Regulatory mapping — mapping Nexus's controls to your specific framework (the architecture is designed to align with enterprise frameworks, but the mapping to your obligations is yours to perform, with evidence Stingray can supply under NDA).

Nexus is designed to keep this boundary small and honest — to operate inside your compliance boundary rather than asking you to extend trust to an external vendor's infrastructure — but it does not remove your responsibility for the subscription you run it in.

What this does and does not do

It does: keep residency and sovereignty aligned to your Azure region and policy; make isolation an attribute of your own subscription; inherit the underlying Azure services' posture; and offer a proven government-cloud path.

It does not: confer any Stingray-held certification, substitute for your own regulatory mapping, or replace your customer agreement as the source of contractual and compliance commitments. For current attestations, ask your representative.