See what a validation package looks like when it builds itself
A short walkthrough of how GxPForge keeps traceability current as your team works, instead of reconstructing it before a release.
Book a demoTamper evidence means that if a GxP record were altered outside the normal, controlled process, that alteration would be detectable. A checksum, a mathematical fingerprint of a record's content, is one common way to implement this, flagging a mismatch if the underlying data changed without going through the audit trail.
A checksum computed from a record's content changes if even a single character in that record changes. Comparing the stored checksum against a freshly computed one reveals whether the record matches what was originally saved, or whether something altered it outside the normal, logged process.
An audit trail proves what changes were made through the normal application workflow. Tamper evidence, including checksum based approaches, addresses a different question, whether the underlying data was altered some other way entirely, bypassing the application and its audit trail altogether, for example through direct access to underlying storage.
Ask specifically how the platform would detect, not just prevent, an unauthorized change made outside its normal interface. Prevention and detection are different guarantees, and a strong Part 11 implementation needs both, not just one.
A short walkthrough of how GxPForge keeps traceability current as your team works, instead of reconstructing it before a release.
Book a demo