Security & architecture
A compliance tool asking to hold GxP records has to be specific about how it’s actually built, not just what it claims. Here’s the real mechanism behind each trust claim we make elsewhere on this site.
Organization isolation
Every record is scoped to your organization and enforced at the database layer with Postgres row-level security, in addition to the application’s own access checks. No other organization on the platform can see your data.
Append-only, hash-chained audit trail
Material actions across the tools are written to an audit log where each row is hash-chained to the one before it, so a tampered or deleted entry breaks the chain and is detectable. A second database-level control blocks updates and deletes on that log outright — even a request made with elevated service credentials is refused, not just requests made through the normal application.
We’re direct about the limit of this: a true database superuser could still disable the controls themselves. The design defends against ordinary tampering and accidental edits, not a fully compromised database host.
Electronic signatures
Closing out a deviation and its CAPA requires a real electronic-signature step: re-entering your password, capturing what the signature means (e.g. “reviewed and approved”), and binding the signature to a hash of the record at that exact moment. The resulting signature record is itself append-only and cannot be edited afterward. Today this signature mechanic covers deviation/CAPA closure; extending it to other tools is on our roadmap, not shipped yet.
Deployment: cloud or self-hosted
Run Plumely in our cloud, or self-hosted on your own Postgres instance if your organization has data-residency or internal-hosting requirements. Both options run the same application and the same audit-trail and access controls described above.
On compliance claims
Using Plumely supports common practices expected under frameworks like 21 CFR Part 11 and GxP recordkeeping, but we don’t claim the software itself is “compliant” or “validated” — compliance is a shared responsibility, and your organization is still responsible for validating its own procedures. We’d rather be upfront about that distinction than oversell it.
Read the full detail in our Privacy Policy, or ask us directly.