Audit Trail

The Audit Logs module provides a comprehensive, immutable trail of every significant action taken within Study Setup — who did what, to which entity, and when. It supports regulatory compliance, operational traceability, and change investigation.

The stated requirement is:

A compliant audit trail should allow a reviewer to clearly determine who did what, when, and why, while preserving the integrity of the original record.

At a minimum, a compliant audit trail should:

• identify the specific user who performed the action
• capture the date and time of the activity using a system-generated, non-editable timestamp
• record the action taken (for example, create, modify, or delete)
• identify the record and field affected
• preserve both the original value and the new value
• include a reason for change where required, especially for GxP-critical data
• link to the electronic signature or approval when applicable

In addition, the audit trail should be automatically generated by the system, protected from alteration or deletion, and maintain full traceability of changes across the record lifecycle. It should also be human-readable, searchable, and retrievable for review.

Mockup

Audit Trail

/audit-trail – Read-only table listing audit entries with actor email, actor role, timestamp, IP address, and event name. Filterable by search, role, and event type.

Entities

Entity	Description
AuditEntry	A single immutable record describing one auditable event: actor identity, action type, target entity (study, changeset, review, material, user, etc.), before/after values, and timestamp.

Use Cases

• View the complete audit trail for the system, paginated and ordered by timestamp.
• Filter audit entries by entity type, entity ID, actor, action type, date range, or module.
• Inspect before/after values for any change to a governed entity (study model fields, changeset status, user roles, etc.).

Notes

• The audit trail must be append-only and tamper-evident; audit entries cannot be modified or deleted.
• Every state-changing command in the system (study creation, changeset approval, review routing, provisioning release, user role assignment, etc.) must produce a corresponding audit entry.
• Audit entries are distinct from application-level domain events, but are derived from them: each event that changes governed state should generate an audit entry.
• Access to the audit trail may itself be audited (i.e. querying audit logs may produce an access audit entry).