Audit Trail Software
A GxP audit trail is not a log file. It is inspection evidence — and inspectors know when it has been retrofitted. cGen's audit trail is designed from the first record as tamper-evident, cryptographically signed, and periodically reviewable, because that is what Part 11, Annex 11 and GAMP 5 all now require.
Every entry is signed with a hash chain; any tampering breaks the chain and is visible on the next verification pass.
Annex 11 §9 requires periodic audit-trail review by an authorised person. cGen produces the review queue, tracks the reviewers, and archives the sign-off.
Inspector Mode gives auditors a scoped, time-limited, watermarked view of the audit trail — filtered by system, user, date range, or record type.
The audit-trail requirement is deceptively simple: capture what changed, who changed it, when, and why. In practice, the failure mode is almost always the same — the "why" is missing because the software did not force a reason-for-change entry at the point of edit.
For every controlled record in a GxP system, the audit trail must record the create/modify/delete event, the identity of the actor (uniquely attributable), the timestamp (contemporaneous, synchronised to a trusted time source), the old value and new value for edits, and an operator-supplied reason for the change. Deletes should be logical (with retention) rather than physical.
How cGen fits
cGen's audit trail is not an afterthought or a downloadable log. It is the substrate of every controlled record in the platform, and it is one of the most-quoted reasons customers switched from legacy CSV tools where the audit trail was a feature bolted onto a document-management system.
FAQ
We value your privacy
We use analytics cookies to understand how you use our site. No advertising or tracking cookies.