Security

Last reviewed: 9 May 2026

Data access model

VNet IQ reads Azure resource metadata via a service principal you create in your tenant, granted the built-in Reader role on the subscriptions you choose. We never request write permissions, and we never modify your Azure infrastructure.

What we read

• Virtual Networks (Microsoft.Network/virtualNetworks)
• Subnets, peerings, gateways, gateway connections
• Virtual WAN hubs and spoke connections
• Subscription metadata (ID, display name) needed to scope reads

What we don't read

• Virtual machine contents, OS configuration, or running workloads
• Storage account contents (blobs, files, tables, queues)
• Key Vault secrets, keys, or certificates
• Database contents (Azure SQL, Cosmos DB, Postgres Flexible Server, etc.)
• Identity / Active Directory object data beyond the service principal we authenticate as
• Any resource type outside Microsoft.Network/*

The Reader role is the smallest Azure built-in role that grants the listings we need. You can audit our access via Azure Activity Log — every ARM call we make is attributable to the service principal you provided. Revoking access is a single Azure portal click on that role assignment.

Where your data lives

• Region: Azure West Europe (Netherlands) is primary for application data. North Europe (Ireland) is used for Postgres replicas and email delivery.
• Hosting: Azure Container Apps (Microsoft-managed) and Azure Database for PostgreSQL Flexible Server (Microsoft-managed). Both inside Microsoft's own EU data centres under the EU Data Boundary commitment.
• Data residency: core application data — your workspace, network metadata, conflict findings, sync history — is hosted in Azure West Europe and North Europe. Email and billing subprocessors process limited data as listed in the Subprocessors section below; Resend's account metadata and Paddle's billing flows may include US-resident data paths. Customer environment data (Azure resource metadata) does not flow to those subprocessors.

Encryption

• At rest: all customer data is encrypted via Azure-managed encryption (AES-256). The application database is Azure Database for PostgreSQL Flexible Server, with encryption at rest provided via Azure Storage server-side encryption. Logs and backups are encrypted by Azure Storage on the same basis.
• In transit: all client connections use TLS 1.2+. The API frontend (Azure Container Apps) terminates TLS at the edge. Azure ARM API calls (our outbound traffic) use TLS by Azure's contract.
• Service-principal credentials: customer-provided client secrets are encrypted with AES-256-GCM in our application layer before being written to the database. The application encryption key is supplied to the API from Azure Key Vault in production (loaded at process startup via a Container App secret reference); the database never sees the plaintext.

Authentication and tenant isolation

• Customer sign-in: Microsoft Entra (Azure AD) OAuth 2.0 + OpenID Connect. Customers sign in with their Microsoft accounts. We do not store passwords; we receive JWT access tokens scoped to our app registration.
• Tenant isolation: Postgres Row-Level Security (RLS) is enforced on every customer-data table. The runtime database role (vnetiq_app) is NOBYPASSRLS — application queries cannot bypass tenant scoping at the database layer. Every query sets a per-request app.current_org setting that policies key on. Cross-tenant queries (used by background jobs) are gated behind SECURITY DEFINER functions with explicit allowlists.

RLS materially reduces the risk of cross-tenant leakage by enforcing org scoping at the database layer, even if an application query omits a tenant filter or has a SQL bug. RLS is a defence-in-depth control, not a substitute for application-level review.

Subprocessors

We use three external services to operate VNet IQ. Each has signed Standard Contractual Clauses (SCCs) where applicable and processes customer data only as documented below.

We do not currently use any other third-party processor for customer data. Infrastructure tooling (CI, DNS, registry) does not handle customer data and is not listed.

GDPR posture

• Roles: VNet IQ acts as a data processor for customer environment data (the Azure resource metadata we read on your behalf). The customer is the data controller for that data.
• Data subject rights: customers can access, rectify, or delete workspace data via the in-app settings or by emailing support. Account deletion soft-deletes within 24 hours and hard-deletes after 30 days unless legal hold applies.
• Subprocessor changes: we'll notify customers via email of any new subprocessor at least 30 days before introduction.
• Data residency: the EU-region commitment above is contractual on Microsoft's side; we do not configure cross-region replication.
• DPO contact: data protection inquiries go to [email protected]. We do not currently have a DPO appointed (size threshold not yet met under GDPR Article 37).

Incident response

• Notification window: in the event of a personal-data breach affecting customer data, we will notify affected customers without undue delay and, where legally required, within 72 hours of becoming aware (aligned with GDPR Article 33).
• Reporting a vulnerability: send details to [email protected] with the subject prefix “Security:”. We will acknowledge within 2 business days.
• What we ask: please don't run automated scans against production without coordinating with us first; please don't access data that isn't yours; please don't publicly disclose before we've had a chance to respond.

Contact

For all security and data-protection matters: [email protected].