Trust & compliance

Security

Last reviewed: 20 June 2026

Data access model

VNet IQ reads network metadata from your clouds through read-only roles you create and grant. On Azure, a service principal with the built-in Reader role. On AWS, a read-only IAM role you deploy via our CloudFormation template. On Google Cloud, a read-only service account granted the Compute Network Viewer and Browser roles (or a custom role limited to listing networks and subnetworks). We request read-only permissions only, and we never modify your infrastructure.

What we read

• Virtual networks and VPCs (Azure VNets, AWS VPCs, Google Cloud VPC networks)
• Subnets, peerings, gateways, and gateway / transit connections
• Route tables and hub / transit attachments
• Subscription, account, and project metadata (ID, display name) needed to scope reads

What we don't read

• Virtual machine / instance contents, OS configuration, or running workloads
• Object and block storage contents (S3, Blob Storage, GCS, disks)
• Secrets, keys, or certificates (Key Vault, AWS Secrets Manager, GCP Secret Manager)
• Database contents (Azure SQL, RDS, Cloud SQL, Cosmos DB, Postgres, etc.)
• Identity / directory object data beyond the role we authenticate as
• Any resource type outside networking

We request the smallest read-only role each cloud offers for the listings we need. You can audit our access via each cloud's audit log — Azure Activity Log, AWS CloudTrail, or Google Cloud Audit Logs — and every read is attributable to the role you provided. Revoking access is a single change on your side.

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 (your cloud 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. Outbound calls to your clouds' management APIs use TLS by those providers' contract.
• Connection credentials: customer-provided cloud credentials 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: customers sign in with their Microsoft Entra (Azure AD) or Google accounts via OAuth 2.0 / OpenID Connect. We do not store passwords; we receive scoped access tokens.
• Roles: within a workspace, access is governed by owner, editor, and viewer roles, enforced on every mutating action.
• 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 cloud 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].