Per-tenant data isolation
Every record carries a tenant identifier and every query is tenant-scoped — one customer's records are never returned in another tenant's queries. See the tenancy model.
Regulated buyers deserve specifics, not badges. This page lists what Azora actually does today — and separates it clearly from what is operational practice and what is roadmap. Questions? Email us.
The platform is multi-tenant PostgreSQL with isolation enforced in the data layer, served over HTTPS.
Every record carries a tenant identifier and every query is tenant-scoped — one customer's records are never returned in another tenant's queries. See the tenancy model.
Passwords are stored only as salted PBKDF2/bcrypt hashes. Azora never stores or logs a plaintext password.
TOTP-based 2FA, with a per-tenant policy that lets an administrator enforce 2FA for every user in the tenant.
Stored secrets such as TOTP seeds and API keys are encrypted at rest with AES-256-GCM.
All traffic to the hosted platform runs over HTTPS.
The full posture, no NDA: security overview and architecture brief.
Records that carry regulatory weight are designed around 21 CFR Part 11 expectations for electronic records and signatures.
Signing a controlled record requires the signer to re-authenticate at the moment of signature — a session alone is not enough.
Each signature is rendered with the signer's name, the date and time, and the meaning of the signature (such as authorship, review, or approval).
Regulated records keep an append-only history of changes, actors, and transitions, designed so alteration of past entries is detectable.
Timestamps on signatures and audit entries are set by the server, not by the client machine, so a workstation clock cannot rewrite history.
Deletion of regulated records is gated by retention rules — signed and quality-relevant records cannot be silently removed.
Change control with e-signatures is part of the QMS module; the QMS hub maps every quality discipline.
Regulated customers need to validate the software for their intended use. We make that work smaller, not something you start from a blank page.
A validation package aligned with GAMP 5 practice — user requirements specification (URS), IQ/OQ protocols, and a traceability matrix — is available to customers as part of onboarding.
The package is a starting point for your own validation file: you execute and adapt it against your configuration and procedures, and we support that work during implementation.
Evaluating Azora and want to review the package structure first? Email us.
Stated plainly as our operational practice and commitment — not a certification.
The production database is backed up daily as our standing operational practice.
Restore and recovery steps are documented and maintained as part of our operations runbooks, so recovery is a procedure — not an improvisation.
Enterprise customers can run the same codebase on their own infrastructure and hold the database and keys themselves.
We label roadmap items as roadmap. If a claim is not in the sections above, don't buy on it.
SOC 2 readiness work is on the roadmap. Azora does not hold a SOC 2 report today and does not claim one.
Single sign-on via SAML (with SCIM provisioning) is on the roadmap for enterprise tenants. See the changelog and roadmap for status.
An educational playbook — explicitly not a customer case study — walking a 30-person device startup from gap assessment to MDSAP readiness, and showing which Azora modules carry each stage.
Security review, validation walkthrough, or architecture deep-dive — you'll talk to the engineers who built it.