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

> Source: https://netray.co/tools/pharma-gxp-audit-trail-entry-json-generator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Build a structured audit trail record with user, time, change, reason and signature meaning for a regulated integration.

## Category

developer

## Industry

Pharma and Life Sciences

## Audience

- Developer
- Computer system validation
- Quality assurance

## Tool

**Kind:** template

**Output:** code

**Language:** json

**Fields:**

#### System name

**Key:** system

**Type:** text

**Default:** MES-PharmaLine2

#### Record type

**Key:** record_type

**Type:** select

**Options:**

- Batch record
- Test result
- Master recipe
- Deviation
- Material master

**Default:** Batch record

#### Record identifier

**Key:** record_id

**Type:** text

**Default:** BR-2026-004217

#### User ID

**Key:** user_id

**Type:** text

**Default:** jmehta

#### Action

**Key:** action

**Type:** select

**Options:**

- CREATE
- UPDATE
- DELETE
- APPROVE
- REVIEW

**Default:** UPDATE

#### Field changed

**Key:** field

**Type:** text

**Default:** granulation_time_min

#### Old value

**Key:** old_value

**Type:** text

**Default:** 18

#### New value

**Key:** new_value

**Type:** text

**Default:** 20

#### Reason for change

**Key:** reason

**Type:** textarea

**Default:** Corrected transcription error after verifying against the equipment printout.

#### Timestamp (UTC)

**Key:** timestamp

**Type:** text

**Default:** 2026-10-19T09:42:17Z

#### Signature meaning

**Key:** meaning

**Type:** select

**Options:**

- Authored
- Reviewed
- Approved
- Responsibility
- None

**Default:** Authored

**Blocks:**

#### Audit trail entry

**Body:** {
  "system": "{{system}}",
  "recordType": "{{record_type}}",
  "recordId": "{{record_id}}",
  "event": {
    "action": "{{action}}",
    "timestampUtc": "{{timestamp}}",
    "userId": "{{user_id}}",
    "field": "{{field}}",
    "oldValue": "{{old_value}}",
    "newValue": "{{new_value}}",
    "reason": "{{reason}}"
  },
  "signature": {
    "meaning": "{{meaning}}",
    "userId": "{{user_id}}",
    "timestampUtc": "{{timestamp}}"
  },
  "integrity": {
    "previousEntryHash": "<hash of previous entry>",
    "entryHash": "<hash of this entry>"
  }
}

#### Validation notes for this record

**Body:** {
  "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"
  ]
}

**Notes:** 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.

## Content

**Intro:** 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.

**Sections:**

#### How to use the generator

**Body:** 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

**Body:** 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

**Body:** 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.

**Bullets:**

- 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

**Body:** 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.

**Cta:** 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.

**Faq:**

#### Is this record enough for Part 11 compliance?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

audit trail json schema, 21 cfr part 11 audit trail fields, gxp audit trail record example, electronic record audit trail design, who what when why audit trail, audit trail old value new value, electronic signature meaning json

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json