Security
Built to hold records an auditor will rely on
Quality records are evidence. Doctilla protects who can see them, who can change them, and that what was decided stays decided.
Hosting and infrastructure
- EU data residency
- Your organisation's records, files and accounts are held in a managed Postgres database and file storage on Supabase, in the EU (Ireland).
- Encryption
- All traffic uses HTTPS. Data at rest is encrypted by the hosting platform.
- Application hosting
- The Doctilla app is served from Vercel's network, and this website and the connector address from Cloudflare's. Neither holds your quality records.
- Sub-processors
- Listed in the privacy policy, with what each one does.
Access control
- Row-level security on every table
- Every query, from the app, the API or the connector, runs as the signed-in person and is checked by the database's own row-level security policies. Organisations can't see each other's data.
- Roles
- Owner, admin, user, auditor and viewer for quality management, and separate Product assurance roles such as technical approver and read-only. Controls only appear for people the database will let use them.
- Module permissions
- Someone with no Product assurance role can't read product records, or the links, history and conversations about them.
- Sign-in links that survive email scanners
- Sign-in and invitation emails land on a confirmation page and spend nothing until the person presses Continue, so a mail scanner can't use them up.
Record integrity
- Locks enforced by the database
- Locked audits, approved management review minutes, decided concessions, completed inspections and concluded technical reviews are refused changes by the database itself, not just hidden in the screens.
- Append-only history
- Record versions and AI conversations have no update or delete permission at all, so history can't be rewritten.
- Human decisions stamped by the database
- Approvals, acceptances and completions record who made them and when, taken from the signed-in session rather than anything the browser sends.
- Logged deletion
- Deleting goes through one controlled function that removes everything that referred to the record and writes a log entry.
API and connector
- Keys stored as hashes
- API keys are shown once and stored only as a SHA-256 hash. A key acts as the person who created it, under the same permissions, and stops working if they leave.
- OAuth 2.1 with PKCE
- AI assistants sign each person in with their own account. Only PKCE S256 is accepted, redirect addresses are matched exactly against an allowlist, and tokens are stored only as hashes and rotated.
- No AI decisions
- The connector can't delete anything or make the decisions reserved for people, such as approvals and closures.
- Rate limits and size limits
- Requests are rate-limited per key, failed sign-ins per address, and request bodies are capped.
Your data stays yours
- Export everything, always
- Every register exports to Excel or CSV and every record to PDF or Word. Exports keep working even if the organisation becomes read-only.
- Read-only, never locked out
- If a subscription lapses, nothing is deleted. Everyone can still sign in, read and export.
- Deletion on request
- An owner can remove all of an organisation's data for a module after seeing exactly what would go.
- Your standards stay private
- Text of a standard you import is stored only in your organisation, after you confirm you hold a licence for it.
Reporting a vulnerability
If you think you've found a security problem in Doctilla, email [email protected] with the details. Please don't access other people's data or disrupt the service while testing. We'll acknowledge your report and keep you informed while we fix it. See also security.txt.
See Doctilla with your own processes
Book a 30-minute demo. We'll walk through the parts that matter to you, using a fully populated demonstration company, and answer anything you want to ask.