Developer ToolsFree generatorPDF, Excel, Word exportPharma and Life Sciences

GxP Audit Trail Entry JSON Generator (21 CFR Part 11 Style)

21 CFR Part 11 expects secure, computer generated, time stamped audit trails that record who changed what, when and why, without obscuring earlier entries. This generator produces a clean JSON audit record you can use as a starting point for an integration or a custom GxP application.

Fill in

Generated code
Download:

Audit trail entry

{
  "system": "MES-PharmaLine2",
  "recordType": "Batch record",
  "recordId": "BR-2026-004217",
  "event": {
    "action": "UPDATE",
    "timestampUtc": "2026-10-19T09:42:17Z",
    "userId": "jmehta",
    "field": "granulation_time_min",
    "oldValue": "18",
    "newValue": "20",
    "reason": "Corrected transcription error after verifying against the equipment printout."
  },
  "signature": {
    "meaning": "Authored",
    "userId": "jmehta",
    "timestampUtc": "2026-10-19T09:42:17Z"
  },
  "integrity": {
    "previousEntryHash": "<hash of previous entry>",
    "entryHash": "<hash of this entry>"
  }
}

Validation notes for this record

{
  "requirements": [
    "Entries are computer generated and time stamped",
    "Old values are not overwritten or obscured",
    "Entries cannot be edited or deleted by users",
    "Reason is mandatory for UPDATE and DELETE",
    "Audit trail is retained as long as the record"
  ]
}

This is a design sketch, not a validated implementation. Your own URS, risk assessment and computer system validation decide the final fields. Store the trail in an append only store, protect it from edits, and make it readable for inspection. Hashing fields are an optional design choice, not a Part 11 requirement.

Review your integration audit design

An optional expert review of audit trail and write-back design for ERP, MES and LIMS integrations.

Optional. The tool and every export work without this. No spam.

How to use the generator

Fill in the system, the record, the user and the change, and the JSON updates immediately. Copy it into your design document or into a test fixture for an API. Change the action to see how the record looks for creation, approval or review events. Keep field names consistent with the rest of your interfaces so reports and inspections can read the trail without translation.

What the record has to show

Part 11 section 11.10(e) calls for secure, computer generated, time stamped audit trails that independently record operator entries and actions that create, modify or delete electronic records. Record changes shall not obscure previously recorded information. In practice, that means user identity, date and time, the old and new values, and for GxP use a reason for change. Electronic signatures add the printed name, date and time and the meaning of the signature.

Design choices to settle

Decide where the trail is written, who can read it and how long it is kept. Time should come from a controlled server clock in UTC, not from the user device. A separate append only table or service is easier to protect than columns on the data table. Reviewers should be able to filter by record, user and date to carry out audit trail review as part of batch release.

  • Write the entry in the same transaction as the data change.
  • Block updates and deletes on the audit table for all users.
  • Expose a read-only view for reviewers and inspectors.

Common mistakes

A frequent mistake is logging only the new value, which loses the history. Another is making the reason optional, so the trail shows a change but not the justification. Teams also forget system-initiated changes, such as interface loads and scheduled jobs, which need their own service identity rather than a shared user account.

Frequently Asked Questions

Is this record enough for Part 11 compliance?

No. It covers the core audit trail content, but compliance depends on your whole validated system: access controls, signatures, record retention, procedures and training. Use the sketch as an input to your own requirements and validation.

Should the reason for change be mandatory?

Part 11 itself does not mandate a reason field, but EU Annex 11 and many predicate rules and company procedures expect one for GxP data changes. Making it mandatory for updates and deletes is a common and sensible design.

Why record time in UTC?

UTC avoids ambiguity across time zones and daylight saving changes, and makes it simple to order events from different systems. The user interface can show local time while the stored value remains in UTC with a clear offset or Z suffix.

Do hash fields matter?

They are optional. Chaining hashes makes tampering easier to detect, which can support your risk assessment, but the main protections are access control, append only storage and review. Part 11 does not require hashing.

If you are connecting an ERP, MES and LIMS in a regulated plant, Netray can help design private integrations where every read and write-back is logged with the user, the reason and the approval.