Trust & Security
Last updated: August 14, 2026
1. Overview
SecureTenant is built for European organizations that need to prove, not just claim, their compliance posture. Security and EU data sovereignty are not features we added, they are the reason the product exists. This page describes how we protect your data technically and organizationally.
2. Data residency and infrastructure
SecureTenant runs entirely on Microsoft Azure, primarily in the North Europe region, with some long-lived control-plane resources in West Europe. We do not use infrastructure outside the EU for hosting or processing your data.
- Compute runs on Azure Container Apps behind Azure Front Door, with header-based validation that rejects direct-hostname requests bypassing Front Door.
- Our PostgreSQL database and AI inference service (Azure AI Foundry) have no public network access at all, they are reachable only over private endpoints inside our own virtual network.
- Multi-tenancy is enforced at the application layer: every query for customer data is scoped to that customer's organization, checked on every request against a cryptographically verified session, never a client-supplied value.
3. Encryption and credential handling
Data in transit is encrypted with TLS. Data at rest is encrypted using Azure's platform-level encryption, and customer cloud credentials get an additional application-level layer on top of that.
- OAuth tokens and any other connected-cloud credentials are encrypted with AES-256-GCM before they are ever written to our database, never stored in plaintext.
- For AWS specifically, we never store a permanent access key at all. We use a cross-account IAM role and request short-lived, one-hour STS credentials for each individual scan.
- All application secrets (API keys, database credentials, encryption keys) live in Azure Key Vault, never as plain environment variables.
4. Access control
Authentication and organization membership are managed by Clerk. Every organization-wide mutating action is checked server-side against an admin role, never only hidden in the interface. A role or organization claim used for an authorization decision always comes from a cryptographically verified source (a Clerk session or a verified token), never from a query parameter or an unverified value.
5. Cloud connector scopes
Every cloud or SaaS integration we support requests read-only access by default. A write scope is never requested unless it has been explicitly reviewed and approved for a specific, narrow purpose. We follow each provider's own recommended integration pattern rather than asking customers to paste a long-lived API key: Microsoft Entra admin consent for Microsoft 365/Azure, real OAuth2 for DigitalOcean, and a temporary cross-account IAM role with short-lived STS credentials for AWS.
6. Sub-processors
We keep a full, current list of every sub-processor we use, what each one does, where they are located, and what data they touch. See our Sub-processors page for the complete list and how we notify customers before adding a new one.
7. What SecureTenant monitors, and what that does and does not mean
SecureTenant continuously scans a connected cloud environment against NIS2, ISO 27001, and DORA control benchmarks and reports gaps and remediation guidance. This means we help you build and demonstrate your own compliance posture. It does not mean SecureTenant itself holds a NIS2, ISO 27001, or DORA certification, we are not stating or implying that we do. If and when SecureTenant obtains a formal certification of its own, that will be announced here with the actual certificate, not asserted in advance.
8. Vulnerability disclosure
If you believe you have found a security vulnerability in SecureTenant, please report it to us privately before any public disclosure so we can investigate and fix it. We follow the RFC 9116 security.txt convention, published at /.well-known/security.txt, and commit to acknowledging a good-faith report promptly.
- Email: contact@secure-tenant.com
- Please include enough detail to reproduce the issue and, if possible, its potential impact.
- Do not access, modify, or exfiltrate another customer's data as part of testing, report the finding instead.
9. Incident response
We maintain an internal process for detecting, triaging, and responding to security incidents. Where an incident affects customer data, we notify affected customers without undue delay, consistent with our Data Processing Agreement and applicable law (including NIS2's own reporting obligations, which we are subject to as a provider of essential services to our customers).
10. Questions
For any security question not answered here, including requests for more detail as part of your own vendor security review, email us at contact@secure-tenant.com.
