SOP: Time Synchronization and System Clock Control for GxP Systems

This is a ready-to-use SOP for keeping time trustworthy across GxP computerized systems: accurate through synchronization, immutable through access control, and interpretable through a defined time-zone strategy. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template. Verify each cited regulation against the current source. This is general guidance to adapt, not legal or regulatory advice.

Document control header

1. Purpose

This procedure defines how <<FILL: COMPANY NAME>> ensures that time stamps on GxP records are accurate, protected from unauthorized change, and unambiguous across sites, so that contemporaneousness, sequencing, and cross-system correlation hold up under inspection.

2. Scope

This procedure applies to all GxP computerized systems that create, modify, or store records with time stamps, including laboratory systems, manufacturing execution and automation systems, historians, quality systems, and networked instruments, at the sites in the header. It covers server and workstation clocks, the network time hierarchy, application-level time display, and standalone instruments handled by a manual time-check where they cannot join the network time service.

3. Responsibilities

4. Definitions

• NTP: Network Time Protocol, the mechanism that keeps computer clocks synchronized to a reference time source over a network.
• Slew vs step: slewing adjusts a clock gradually so it converges without jumping; stepping sets it instantly. A backward step can create duplicate or out-of-order time stamps.
• UTC: Coordinated Universal Time, a single global reference with no daylight-saving discontinuity.
• Naive local time: a stored local time with no zone or offset; ambiguous across daylight-saving transitions and prohibited by this procedure.
• tz database: the IANA time-zone database of local-time and daylight-saving rules used to convert between UTC and local time.

5. Procedure

5.1 Accuracy: synchronize to a controlled time hierarchy

1. Define the authoritative reference (for example a GPS-disciplined NTP appliance) and at least two internal NTP servers in the configuration or infrastructure qualification document.
2. Point every GxP host at the internal NTP servers, not at an uncontrolled external source and not at no source.
3. Set the maximum acceptable offset (tolerance) and the poll interval; use a tighter tolerance where systems must correlate to the second.
4. Configure routine correction to slew, not step; permit large steps only at controlled startup and log them.
5. For a virtual machine, choose one time authority (guest NTP or host injection) and disable the other so the two do not fight.
6. Verify synchronization during qualification and record the measured offset.

5.2 Immutability: lock down who can change time

1. Remove the “change the system time” and “change the time zone” rights from ordinary users at the OS level; grant them only to a named, controlled administrative role.
2. Make NTP the only routine mechanism that moves the clock.
3. Enable OS/security auditing for clock and time-zone changes.
4. Any manual clock correction is performed only by the controlled role, under a change record, and captured in a secure, non-editable log with who, old value, new value, and when.
5. Control physical and console access so the hardware clock cannot be changed outside the OS.

5.3 Interpretation: storage and display strategy

1. Store time in UTC, or in local time with an explicit UTC offset, never naive local time.
2. Display time with the zone always labelled (for example 14:32 EDT or 18:32 UTC). Reports for the batch record or trial master file state the zone explicitly.
3. Define cross-site display rules so a reviewer at one site correctly interprets a record created at another.
4. Keep the tz database current under change control; apply tz updates on a controlled schedule because governments change DST rules with little notice.

5.4 Ongoing monitoring and review

1. Monitor clock offset against the reference on a defined basis; alert if a host drifts beyond tolerance or loses its time source.
2. Bring clock-change and time-zone-change events into the audit-trail review so a change is actually noticed and questioned.
3. Confirm at periodic review that synchronization, access restriction, and tz currency remain in place.

5.5 Standalone instruments that cannot join NTP

1. Where an instrument cannot use the network time service, define a periodic manual time-check with a tight tolerance and a logged record each time (see the paired manual time-check log).
2. Treat any residual risk in the system risk assessment and tighten audit-trail review accordingly.

6. Acceptance criteria

• Every GxP host syncs to the defined internal NTP source with redundancy; measured offset stays within tolerance.
• Ordinary users cannot change the clock or time zone (demonstrated by a negative test); the right exists only for a named controlled role.
• Every clock or time-zone change is recorded in a secure, attributable, non-editable log and is reviewed.
• Time is stored as UTC or local-plus-offset, never naive local time; displayed time always shows its zone.
• The tz database is current under change control, and synchronization is monitored on an ongoing basis, not only at go-live.

7. References

21 CFR Part 11.10(e) (computer-generated, time-stamped audit trails), 11.10(d) (limiting system access). 21 CFR 211.68 (automatic, mechanical, and electronic equipment). EU GMP Annex 11 (computerised systems), sections on data and audit trails. MHRA GxP Data Integrity Guidance and Definitions (2018). FDA guidance, Data Integrity and Compliance With Drug CGMP (2018). PIC/S PI 041, Good Practices for Data Management and Integrity (network time synchronization and clock control).

Confirm the current version and clause numbers of each reference before issue.

8. Record generated: clock-change record

9. Revision history

10. Approvals

Filled specimen

A completed clock-change record for a manufacturing application server, illustrative only.

The change is attributable to a named person, tied to a change request, and reviewed the same day. A clock change with no change control and no review is exactly what gets cited.

Common inspection findings this SOP prevents

• Standalone instruments left on drifting internal clocks, never checked.
• The “change system time” right left at default so ordinary users can move the clock.
• Clock manipulation used to backdate a result, then never noticed because the change was logged but not reviewed.
• Naive local time producing out-of-sequence audit trails across a daylight-saving change.
• NTP configured once at go-live, then a time source fails and clocks drift for months.

How to adapt this SOP

1. Set your document number, owner, and effective date.
2. Name your actual authoritative reference, internal NTP servers, and per-system tolerances.
3. Point the cross-references to your real change-control, audit-trail-review, and risk-assessment procedures.
4. Decide and state your storage/display strategy (UTC storage recommended for multi-site).
5. Confirm every regulation in section 7 against the current published version before issue.