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 demoPart 11 expects a secure, computer generated, time stamped audit trail for any operator entry or action that creates, modifies, or deletes a GxP electronic record. The trail has to be tamper evident and has to persist for as long as the underlying record does.
Creating a record, changing a value, deleting an entry, all qualify. The trail needs to capture who took the action, when, and, critically, what the value was before and after, not just that a change happened.
An audit trail enforced only at the application layer can potentially be bypassed by someone with direct database access, an administrator, a support engineer, a script run during an emergency fix. An audit trail enforced at the database level, with no update or delete grants available to anyone, closes that gap regardless of how someone accesses the data.
An auditor will often ask how a record could theoretically be altered outside the normal application interface, and what would happen to the audit trail if that occurred. A vague answer, or a demonstration that a privileged user could edit history without leaving a trace, is one of the more serious findings a system can generate.
A short walkthrough of how GxPForge keeps traceability current as your team works, instead of reconstructing it before a release.
Book a demo