Trust Center

Encryption

Last reviewed: 2026-07-14

This page describes how customer data is encrypted at rest in the database and object storage and in transit on the wire, and the design that governs PWA offline drafting before that feature ships.

At rest

• Database (Supabase managed Postgres, Sydney). Storage volumes are encrypted with AES-256 by the platform provider. Managed key rotation is handled by the platform.
• Object storage (Supabase Storage, Sydney). Server-side encryption is enabled by default. All buckets are private and access is mediated by signed URLs scoped to the requesting tenant via Row-Level Security.
• Backups. Supabase point-in-time recovery is enabled. Backups inherit the underlying storage encryption and remain in the Sydney region.
• Planned — audit-log mirror (AWS S3 Sydney with Object Lock). When the mirror ships (see hosting): SSE-S3 (AES-256), Object Lock in compliance mode with a 7-year retention period, no public access, write permission held by a single mirror role with no delete capability.

In transit

• External traffic. TLS 1.2 or above is enforced for every request to compliancecare.com.au and to the authenticated app. HSTS is enabled with a one-year max-age and includeSubDomains.
• Internal traffic. Application-to-database traffic uses TLS through the Supabase connection pooler.
• Webhooks. Inbound webhooks (e.g. Stripe) are verified by signature before any side-effect is taken.

Application layer — offline drafting design (PWA)

The Pocket PWA currently ships an offline app shell only: the service worker is scoped to the Pocket app, uses network-first navigation with a cached fallback shell, and does not deliberately cache responses containing participant data. No participant data is drafted or stored offline today.

Offline drafting (incident-report draft, observation, photo capture) for frontline workers who lose connectivity is a planned feature. Because offline drafts may contain participant information written to IndexedDB on the device, the following design is a condition of shipping it:

• AES-GCM with a 256-bit key. All draft objects are encrypted before being written to IndexedDB.
• Session-derived key. The encryption key is derived from the authenticated session and is held only in the in-memory page context. The key is not persisted to disk and is discarded when the session ends or the device is locked.
• Scoped Service Worker. The Service Worker scope is limited to the authenticated app origin and does not cache responses containing participant data.
• Server-enforced session timeout. A short session lifetime is enforced server-side. When the session expires, the key is no longer available, and existing encrypted drafts can no longer be opened on the device.
• One-click session revoke. A user (or their tenant admin) can revoke all sessions for an account, which immediately invalidates the key on every device.
• Post-upload removal. Photos taken offline are uploaded directly to Supabase Storage (Sydney, private, RLS-scoped). The browser-temp copy is removed from device storage as soon as the upload is confirmed.

Keys and secrets

• Managed encryption keys (Supabase, AWS) are held by the platform provider and rotated on the provider's schedule.
• Application secrets (API keys, webhook signing secrets) are stored in the hosting platform's secret configuration (AWS App Runner / deployment-pipeline secrets) and are not committed to the repository.
• Operator credentials require multi-factor authentication on every administrative role.

Algorithms we have chosen against

• We do not use roll-your-own encryption schemes. All algorithms are platform-provided (AES-256, TLS 1.2+) or use the Web Crypto API standard implementation (AES-GCM).
• We do not store any participant data in localStorage or in unencrypted IndexedDB stores.

Change log

← Back to the Trust Center