Trust & security
Compliance buyers buy trust. Here’s what we ship by default.
The data model, the access model and the audit log are all built on Postgres primitives — no clever application code stands between your data and a regulator.
Controls
Security built into the architecture
Row-level security per tenant
Organisation isolation is enforced by Postgres, not by hopeful application code. A query that forgets to scope itself fails at runtime rather than leaking data.
In-transaction audit log
Every mutation writes a record-change row in the same database transaction. No background queue, no chance of an action without its evidence.
Granular permissions
Three orthogonal axes — role × per-module access × capabilities such as approver, auditor and manager — so access maps to responsibility.
Separation of duties
Document approvals are a first-class workflow: uploaders cannot approve their own documents.
Encryption in transit & at rest
TLS everywhere, encryption at rest on the database and object storage, and strong password hashing (argon2id) with session invalidation.
AI bound by the same rules
Embedded AI is off by default, reads only within your row-level-security context, and never trains on your data. It drafts; a human saves.
Public Trust Center
Show your posture — don’t email it around
Turn your workspace into a branded, public trust page so prospects and customers can self-serve your security posture. Publishing is a per-workspace toggle; nothing is exposed until you switch it on.
A branded public page
Publish your posture, certifications and downloadable policies at a shareable URL (yourcompany on /trust) — send a link instead of emailing PDFs around.
Gated document access
Keep sensitive documents behind a request-and-approve gate; approved visitors get a tokenised, expiring link — you control who sees what.
AI trust assistant
Prospects ask security questions and get answers drawn only from your published trust content — grounded, never invented claims.
Security questionnaires
Field inbound security questionnaires from the same place your evidence already lives, instead of rebuilding answers in a spreadsheet each time.
Hosting & residency
Run it where your data needs to live
Managed SaaS with UK or EU data residency for most, and a self-host option for the most data-sensitive deployments.
SaaS by default, self-host optional
Run it as managed SaaS, or self-host on-prem or in your own cloud for the most data-sensitive deployments.
UK / EU data residency
Keep regulated data in the UK or EU. Residency is a deployment choice, not an upsell afterthought.
SSO / SAML
Single sign-on via SAML so access follows your existing identity provider and joiner/leaver process.
Custom branding
Upload your logo and set theme tokens so the workspace looks like yours, not ours.
Sub-processors
Who we rely on
Illustrative for managed SaaS — the definitive list is confirmed per deployment. Self-hosted deployments use none of these by default: you control hosting and can disable AI entirely.
| Sub-processor | Purpose | Region |
|---|---|---|
| Cloud hosting provider | Application & database hosting | UK / EU |
| Transactional email | Account & notification emails | EU |
| AI provider (OpenAI / OpenRouter) | Embedded AI — only if enabled, zero-retention | US / EU |
Independent testing
The platform undergoes independent penetration testing. A summary of the most recent test is available to prospective customers under NDA — ask during your security review.
Vulnerability disclosure
Found a security issue? We welcome responsible disclosure. Email security@obligara.com with details and steps to reproduce. Please don’t access other tenants’ data or run disruptive tests; act in good faith and we’ll work with you and won’t pursue legal action for good-faith research.
Running a security review?
We’ll walk your team through the architecture, share our sub-processor list and pen-test summary, and answer the hard questions.