Database-enforced tenancy
Every tenant-owned table uses forced PostgreSQL row-level security. Tenant and actor context is transaction-scoped rather than carried in a reusable connection.
Security and trust
Security that can be explained, tested, and evidenced.
Estate planning contains identity, family, and financial information that deserves a deliberately unexciting architecture: bounded access, encrypted content, explicit state changes, and evidence that survives the workflow.
Privacy by architecture
Each firm’s data is separated at the database boundary. Sensitive records are encrypted with tenant-bound context, and searchable workflow facts are kept deliberately narrow.
Human accountability
Role-aware permissions, step-up staff assurance, immutable review evidence and auditable sharing decisions keep responsibility visible throughout a matter.
Defence in depth
More than one control has to fail before tenant data crosses a boundary.
Role-aware application checks
Client, adviser, firm-admin, and reviewer operations have separate server-side permissions. Staff operations require an assurance level representing step-up MFA.
Application-layer encryption
Identity fields, will and LPA payloads, matter notes, messages and notification content are encrypted with tenant-bound authenticated context.
Evidence and immutability
Audit events, immutable review snapshots, mirror-document provenance, life-event resolutions, vault tombstones, and delivery events preserve the decisions that moved data or documents forward.
The data path
Sensitive documents are not intended to travel through public marketing or ordinary application pages.
- 01
Browser session
HTTP-only, strict same-site session credentials; unsafe requests are origin-checked.
- 02
Application boundary
Authenticated operations set tenant and actor context inside one database transaction.
- 03
Encrypted persistence
Sensitive content is encrypted before storage; searchable facts are deliberately minimized.
- 04
Private object delivery
The storage contract uses short-lived audited URLs and never serves documents from the app origin.
Due-diligence view
Controls a compliance team can examine in plain English.
Testament’s model joins technical controls to the decisions people make: who can see a client, when private work becomes reviewable, and how access can be revoked.
Control areaPurpose
Hardened sessions, rotation, revocation, rate limits and staff assuranceProtect account access
Database-enforced tenancy and restricted application/worker rolesContain every request
Tenant-bound encryption for sensitive contentLimit exposure at rest
Append-only audit, review and delivery evidenceMake decisions traceable
Short-lived private document delivery and explicit grantsKeep sharing bounded
Content-minimised reporting and operational logsAvoid analytics overreach
Data minimisation
Store the substance encrypted; promote only the facts the workflow must query.
A will draft or LPA instruction set is treated as an encrypted document rather than a convenient analytics dataset. Status, bounded triage categories, version references, and operational timestamps are separated because the service needs to query them.
Operational reports, application logs, and delivery records are designed to keep names, addresses, will wording, LPA instructions, adviser notes, and raw credentials out. Retention, deletion and subject-access handling follow the responsibilities agreed with each firm.
Due diligence