Security & Compliance
How Indelio meets 21 CFR Part 11 and GAMP 5 — the controls your auditor will ask about, and how each is enforced.
The records controls live in the database itself: our own application cannot update or delete a signature or an audit-trail entry, and the audit trail's hash chain is re-checked every night, so an edit made any other way would show.
- ✓ Immutable, hash-chained audit trail: every create, change, and signature is time-stamped and linked to the previous entry. Update and delete are blocked at the database, so nothing can be quietly altered or removed.
- ✓ Two-component electronic signatures: identity plus password, re-verified at the moment of signing — you can only sign as yourself.
- ✓ Segregation of duties, enforced server-side: the author of a document cannot approve it (they may review it; release needs a second person), and in most modules whoever signs one step of a record cannot sign the next — the reviewer of a risk assessment cannot approve it, and whoever approves a change cannot close it.
- ✓ Content-hash binding: each signature is bound to the exact record it signed, so any edit afterward visibly breaks the seal.
Only authorized, authenticated members of your organization reach your data.
- ✓ Role-based access control, enforced on the server: creating or changing a quality record needs the author, reviewer, approver or QA role; approvals and closures need the approver or QA role; administration needs the admin role; and an implementer can view records and bring them in by import or migration, for QA to verify, but cannot change or sign them.
- ✓ Two-factor authentication (TOTP) with step-up at login — mandatory on administrator accounts, and available to every user.
- ✓ Password complexity policy, failed-login lockout, periodic password aging, and idle-session auto-logout (21 CFR 11.300).
Your organization's data is walled off from every other tenant at the database layer.
- ✓ Row-level security scopes every table to your organization — enforced by the database, not just the application.
- ✓ Any tenant secrets (e.g., your own AI key, if you bring one) are encrypted at rest with AES-256-GCM and only decrypted server-side at use.
- ✓ Private file storage with per-record access checks; uploaded files are hashed so their integrity can be verified.
- ✓ Migration happens inside your own tenant: you upload your documents there yourself and we guide you remotely, so you never send us your files. Your records are stored in the database and file storage we operate for Indelio, walled off from every other tenant. Where you use the AI features, document text is sent to our AI sub-processor (Anthropic) to produce a draft or proposed metadata — you can supply your own AI key so this runs under your own agreement with them, or leave the AI features switched off.
- ✓ Runs on established, industry-standard cloud infrastructure — Postgres via Supabase, hosting via Vercel, and Anthropic for the AI features.
A risk-based GAMP 5 validation approach, with much of the operational testing already automated and re-runnable.
- ✓ A validation package — Validation Plan, System Requirements Specification, requirements-to-Part-11 traceability, and an automated Operational Qualification, backed by a 4,500+-test suite mapped control-by-control to what it proves.
- ✓ IQ and PQ protocols ready to execute: Installation Qualification against your deployed instance, which we execute as its own hourly line, and Performance Qualification of your real processes under your own SOPs, which you execute and sign.
- ✓ A public release register: every release records what changed, which modules it touches, and our assessment of whether a controlled function was affected — so you can risk-assess a release against the state you qualified, rather than re-testing blind or not at all.
- ✓ If you want help running your Performance Qualification, we can introduce you to an independent validation consultant, billed at their rate and passed through at cost — no $20–50k implementation invoice.
- ✓ Indelio's own position, so you are not left to infer it: Installation Qualification is executed and signed — but by us rather than an independent party, and the signed record covers the automated checks only. The Operational Qualification evidence is compiled and unsigned. Performance Qualification is yours by definition and has not been executed. We do not describe Indelio as “validated”, and no vendor honestly can — validation is a statement about your intended use, on your instance, which only you can make.
Security is verified on every change, not once a year.
- ✓ An adversarial test suite that actively tries to forge a signature, inject an audit entry, tamper a record, or cross the tenant boundary — and asserts each is blocked.
- ✓ Static analysis (Semgrep) on every pull request and scheduled dynamic scanning (OWASP ZAP).
- ✓ Dependency vulnerability monitoring (Dependabot).
The Part 11 controls above are built and tested today. Operational Qualification evidence — the automated suite — ships with every plan; Installation Qualification we execute against your instance as its own line; Performance Qualification is yours to execute and sign, because it runs your processes under your SOPs — a system is only “validated” once that is executed against your instance. A SOC 2 program is on our roadmap and pursued when a customer requires it. We’d rather tell you exactly where we are than overstate it — happy to walk your quality team through any of this in detail.
Qualifying a system once is the easy half. The ongoing cost is deciding, every time the vendor ships, whether anything changed that touches what you qualified. Most SaaS vendors leave you to guess. Our release register is public and records, per change, what it was, which modules it affects, and whether a controlled function moved.
That classification is our assessment of what we changed — an input to your decision, never a statement that your system is still validated. That conclusion stays yours.
You should ask that. We’re a young company, and you’d be putting your controlled documents, signatures, and audit trail on us. Here is what actually protects you — none of it requires trusting us.
- ✓ You are never locked in. No multi-year contract. Month-to-month if you want it — so the most you ever have at risk is the time since your last invoice, not a three-year commitment.
- ✓ Your records are yours, and they are portable. Indelio runs on standard PostgreSQL. Your documents, signatures, and full audit history export in human-readable form whenever you ask — not as a favour, as a feature.
- ✓ No record is ever deleted, and nothing is removed without a trace. Signatures and the audit trail are append-only, enforced at the database against every application account, our own service account included, and the hash chain is re-checked every night. Working content can still be removed — a line item on a draft, a file attached to a record that has not been signed — and each removal is written to the audit trail with what was removed (for a file: its name, size and fingerprint, not its contents). There is no state in which your records quietly disappear.
- ✓ The validation package is yours to keep. The Validation Plan, SRS, traceability matrix, IQ and PQ protocols, and your executed records are documents in your possession. They do not stop existing if we do.
- ✓ Your SOPs are your own. The procedures you adopt are yours under your quality system, not licensed from us.
An established vendor answers this question with their size. We can’t, so we answer it with your exit: no lock-in, portable records, and an immutable history you own. If that isn’t enough for your risk assessment, tell us what would be — we’d rather have that conversation than have you not ask.