Security posture

Summary of how KONDWIT protects customer data and the platform. The full encryption posture document is released by email under NDA — request it via Documents.

Every statement on this page describes infrastructure that is deployed today, verified directly against the production Azure subscription and database on 11 August 2026. Controls that are planned but not in place are labelled roadmap and say so; nothing here is stated as operating unless it operates.

Encryption

At rest: AES-256 storage encryption on Azure Database for PostgreSQL, Azure Cache for Redis, and Azure Key Vault, applied by the platform and not disableable. PII columns (email, name) are additionally protected by application-layer AES-GCM-256 or AES-SIV-256 envelope encryption applied before write. Neo4j Aura at-rest encryption is stated by the vendor and has not been independently verified by KONDWIT.
Object storage: KONDWIT operates no object-storage account. Uploaded procedure files, chat attachments, org logos and audit-anchor files are written to the application container’s own filesystem, which is ephemeral and does not survive a container revision replacement. Blob-level customer-managed keys, geo-redundant replication, soft-delete and immutability policies therefore do not apply and are not available.
In transit: TLS 1.2+ enforced on every public-facing endpoint and service-to-service hop where TLS is terminated. Public TLS terminates at Azure Container Apps ingress; plaintext ingress is disabled on every app. There is no web application firewall and no CDN or reverse proxy in front of the application, and the container environment is not integrated with a virtual network, so there is no network-layer segmentation between the application and data planes.
Keys: All keys (DEKs, KEKs, signing keys, application secrets) live in Azure Key Vault, on the Standard SKU with soft-delete and purge protection enabled. HSM-backed keys require the Premium SKU, which is not provisioned. Application compute authenticates by managed identity and holds no secret material. One long-lived credential does exist: the CI/CD service principal used by the deployment pipeline, which holds a client secret expiring 19 April 2027. Migrating it to OIDC workload-identity federation is roadmap, with no committed date.
Key rotation: Rotation cadences are documented targets, not an automated control. Rotation is performed by hand; there is no scheduled rotation job, and as of 11 August 2026 two secret classes are past their target cadence. Every rotation performed through the rotation endpoint emits an audit-chain event, so the chain is the canonical record where a rotation has occurred.
Customer-managed keys (BYOK): Roadmap. No customer-managed key is configured on any resource today; every service uses platform-managed keys. Do not plan around BYOK availability.

Identity

SSO: Multi-tenant Microsoft Entra ID. Users sign in against your tenant; KONDWIT verifies the token.
MFA: Configurable per org: OFF, OPTIONAL, REQUIRED, IDP_ENFORCED. TOTP authenticators and WebAuthn passkeys supported.
SCIM: SCIM 2.0 inbound provisioning for automated user lifecycle from your IdP.
Sessions: Short-lived JWTs + refresh-on-use; per-org revocation for instant break-glass.

Authorization

RBAC: Org-scoped permission matrix (OWNER, ADMIN, BILLING_ADMIN, MEMBER, VIEWER) enforced at every API endpoint via NestJS guards.
Tenant isolation: Per-org JWT scope plus row-level org binding, applied at the data layer by a fail-closed query fence: every tenant-owned table is listed on a scoped registry, queries against those tables have the organization filter injected automatically, and a query carrying no organization context is rejected rather than served. A dedicated CI gate runs tenant isolation tests on every PR and binds that registry to the database schema, so a new table carrying an organization identifier cannot ship without being classified: either inside the fence, or excluded with a recorded reason.
Documented exclusions: A small number of tables sit outside the automatic fence, each recorded in source alongside the reason and each covered by the same CI gate. First, tables that must be readable before an organization context exists: single sign-on and domain lookup, session refresh, SCIM provisioning, pending invitations, and the unauthenticated forms on this Trust Center. These hold identity and configuration records rather than compliance work product. Second, the audit log, which is filtered by organization explicitly at every read and readable only by that organization’s owners and administrators; it is excluded from the automatic fence so that its tamper-evidence verification can run across the whole chain. Third, per-person records that belong to a user rather than to an organization, such as a user’s own email and alert preferences. These are keyed by user identifier and follow the person across organizations by design.

Audit

Hash-chained, append-only audit log covering every security-relevant action (authentication, authorization decisions, membership changes, data exports, secret rotations, deploys). Each row carries the hash of its predecessor, so a removed or altered row breaks the chain.
A daily anchor row is written and cryptographically signed. As of 11 August 2026 there are 103 anchors, all signed, covering 80 distinct days across an 87-day span — a daily cron, not an unbroken daily record. The anchor file is written to the container’s ephemeral filesystem, not to durable external storage, so the anchor does not currently leave the system it attests. Read it as tamper-evidence within the platform, not as an external or immutable anchor.
Trusted-timestamp-authority (TSA) timestamping is not implemented. Zero of the 103 anchors carry a TSA signature. It is roadmap, with no committed date.
Org admins can read and export their org’s slice via the admin console.
Retention: seven years is our retention policy target. Today the only copy of the chain is the primary PostgreSQL database, covered by its 35-day point-in-time restore window. There is no cold-storage archive and no mechanism enforcing a seven-year floor.

Resilience

Deployment topology: Azure Container Apps in a single region (Central US). The container environment is not zone-redundant. The API runs a single replica; the web surface autoscales between one and three. Multi-zone and multi-region deployment are on the roadmap and are not deployed.
Canary deploys: API changes ramp 0% → 10% → 50% → 100%, with an error-rate and p95-latency check against a pre-deploy baseline at each traffic-bearing stage and automatic rollback on regression. Web changes ramp on the same schedule with a timed bake at each stage but no SLO gate; they roll back on pipeline failure rather than on a measured regression.
Backups: PostgreSQL automatic backups with point-in-time restore across a 35-day window. Geo-redundant backup is disabled — every copy of the database is in Central US. There is no read replica and no database high-availability pairing. Migrating to a geo-redundant-backup server is approved and not yet executed.
Disaster recovery: documented targets are RTO under two hours and RPO in minutes, by restoring to a new server from point-in-time backup. No restore drill and no DR tabletop exercise have been performed to date, so treat both targets as untested. A scripted attended drill exists and its first run is scheduled work.

Want the full document?

Request the encryption posture (NDA-gated)