Multi-Layer Tenant Isolation
Genplify enforces tenant isolation through five independent defence layers. Each layer catches a different class of mistake:
Layer 1 — Static Analysis. ESLint rules detect any database query against tenant-scoped tables that omits the organisation filter, blocking such code at build time.
Layer 2 — Runtime Query Guard. Every database operation is inspected at execution time by a Prisma extension. Queries missing the organisation filter throw before reaching the database. Any deliberate exemption requires an explicit bypass flag with documented justification.
Layer 3 — Authentication Guards. Every authenticated route resolves the user's organisation context through a typed guard before any data access. Routes without a guard cannot compile.
Layer 4 — Database Row Level Security. Postgres Row Level Security policies are deployed on 39 tenant-scoped tables. Each policy verifies row ownership against the active organisation context.
Layer 5 — Session-Scoped Tenant Context. On every authenticated request, the active organisation ID is bound to the database session via SET LOCAL. This binding is what activates the Layer 4 policies, deployed across 89 code paths in the application (routes, background jobs, and external webhooks).
No single layer is a guarantee. Together, they ensure that a bug in one layer is intercepted by the others before tenant data can leak across organisations.
Encryption
All data encrypted in transit (TLS 1.3). Sensitive personal data encrypted at rest with AES-256-GCM at the application layer, with provider-managed disk encryption protecting the underlying database storage.
For data retained beyond account deletion in support of psychometric calibration (anonymised for research and quality improvement under GDPR Recital 26), Genplify uses HMAC-SHA256 blind indexes with a dedicated cryptographic key separate from the encryption key. Blind indexes are cryptographically irreversible — given a blind index, there is no computational procedure to recover the original identifier — and the key separation prevents a compromise of one key from unlocking the other. Retained data is grouped by month rather than by date or user, further reducing re-identification risk.
What Genplify Staff Can Access
Genplify staff cannot directly view your organisation's assessment responses, scoring detail, or identifying user data in normal operation. Database access is restricted to encrypted personal data, scoped by tenant context. For product development and assessment quality work, Genplify staff work only with anonymised statistical data — pseudonymised responses grouped by month, with no direct or indirect link to user identity, organisation identity, or exact assessment date.
Genuine production support (such as investigating a customer-reported bug) requires explicit administrator authorisation, an audited access window, and a recorded business justification. All such access is logged in the tamper-evident audit chain described below.
Data Residency
Primary infrastructure hosted on AWS (ap-southeast-1, Singapore). Data residency controls available for organisations with jurisdiction-specific requirements. Primary database infrastructure is hosted in your specified region. Some processing sub-processors operate in other jurisdictions as disclosed in our sub-processor list, with appropriate transfer safeguards (Standard Contractual Clauses and EU-US Data Privacy Framework) in place.
Access Control
Role-based access control (RBAC) with three levels: employee, manager, and administrator. SSO via SAML 2.0 and OpenID Connect — available for Enterprise tier on request, provisioned through our authentication partner Clerk. Setup requires a configuration session with our team. Multi-factor authentication supported. All access events logged for audit.
Audit Logging
Comprehensive audit trail for all administrative actions, data exports, and access events. Audit logs retained for 24 months. Available for export on request.
Each audit log entry is linked to its predecessor through a SHA-256 hash chain. Modifying any historical entry would require recomputing every subsequent hash — a property that makes silent tampering cryptographically detectable. The chain is enforced at the database level by a trigger that runs on every insert.
After 24 months, audit log entries are not deleted but are cryptographically anonymised — actor and target user identifiers are replaced with non-reversible hashes while the action timestamp, type, and resource are preserved. This ensures legitimate audit trail integrity while honouring the data minimisation principle of GDPR Article 5(1)(c).
Business Continuity
Automated daily backups with 30-day retention. Documented disaster recovery plan with defined recovery objectives. Business continuity procedures tested and updated on a regular schedule.
AI Data Handling
Your assessment data is never used to train AI models. Prompt-writing responses are scored via the Anthropic API with a dedicated, isolated processing pipeline. Anthropic's data retention policy confirms that customer API data is not used for model training. No assessment data is shared with any third-party AI provider for training purposes.