This is a ready-to-use operational qualification test script for the time controls on a GxP computerized system. It proves the three things time control must deliver: the clock is accurate (synchronized within tolerance), it cannot be changed by ordinary users, and stored/displayed time is unambiguous across sites and daylight-saving transitions. Replace every <<FILL: ...>> placeholder, set your document numbers and dates, and route it through document control and approval. A filled specimen of one executed test case follows. Verify each cited regulation against the current source. This is general guidance to adapt, not legal or regulatory advice.
Approval page
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (Validation / CSV) | <<FILL>> | ||
| Reviewer (IT / System Owner) | <<FILL>> | ||
| Approver (QA) | <<FILL>> |
| Field | Entry |
|---|---|
| Protocol number | <<FILL: PROT-ID, e.g. OQ-TIME-001>> |
| System / host | <<FILL: system name, version, host>> |
| Version | <<FILL: 1.0>> |
1. Objective
To verify that the time controls of <<FILL: SYSTEM>> meet the requirements for accurate, protected, and unambiguous time: NTP synchronization within tolerance, restriction of clock and time-zone change to a controlled role, UTC (or local-plus-offset) storage with zone-labelled display, and correct behaviour across daylight-saving transitions.
2. Scope
Server/workstation clock, network time synchronization, OS access controls over time, application-level time storage and display, and DST edge cases. Out of scope: <<FILL: e.g. instrument-side controls tested under the instrument OQ>>.
3. Prerequisites
- The system is installed and IQ is complete and approved.
- The NTP hierarchy and tolerance are defined in the configuration specification.
- A normal (non-privileged) test account and the controlled administrative role are available.
- The storage/display strategy (UTC recommended) is specified.
4. Roles
| Role | Responsibility |
|---|---|
| Tester | Executes each case, records actual results and evidence. |
| Reviewer (IT / system owner) | Confirms configuration and supports privileged steps. |
| QA | Reviews and approves executed protocol and any deviations. |
5. Acceptance criteria
All test cases pass as written, or any failure is captured as a deviation, resolved, and re-tested to a pass, before the OQ is approved.
6. Test cases
| ID | Test step | Expected result | Actual | Pass/Fail | Tester / date |
|---|---|---|---|---|---|
| TC-01 | Read the host’s configured time source | Host points at the defined internal NTP servers (redundant), not an uncontrolled source | <<FILL>> | <<FILL>> | <<FILL>> |
| TC-02 | Measure clock offset against the reference | Offset within the documented tolerance (<<FILL: e.g. within 2 s>>) | <<FILL>> | <<FILL>> | <<FILL>> |
| TC-03 | Observe a routine correction | Correction slews (gradual), does not step backward | <<FILL>> | <<FILL>> | <<FILL>> |
| TC-04 | Negative test: as an ordinary user, attempt to change the system clock | Change is denied; user has no “change system time” right | <<FILL>> | <<FILL>> | <<FILL>> |
| TC-05 | Negative test: as an ordinary user, attempt to change the time zone | Change is denied | <<FILL>> | <<FILL>> | <<FILL>> |
| TC-06 | As the controlled role, make a small clock correction | Change succeeds and is captured in the secure log with who/old/new/when | <<FILL>> | <<FILL>> | <<FILL>> |
| TC-07 | Inspect a stored record’s time value | Stored as UTC or local-plus-offset, never naive local time | <<FILL>> | <<FILL>> | <<FILL>> |
| TC-08 | View a record in the UI and on a printed report | Displayed time shows its zone label (e.g. UTC or EDT) | <<FILL>> | <<FILL>> | <<FILL>> |
| TC-09 | Cross-site: view the same event from two zones | Both see correct local time; underlying stored value identical | <<FILL>> | <<FILL>> | <<FILL>> |
| TC-10 | DST autumn: create records spanning the duplicated hour | Sequence is preserved (correct order in UTC); no ambiguous ordering | <<FILL>> | <<FILL>> | <<FILL>> |
| TC-11 | DST spring: create a record around the skipped hour | Time resolves correctly with no invalid or shifted stamp | <<FILL>> | <<FILL>> | <<FILL>> |
| TC-12 | Confirm tz database source and change control | System uses IANA tz data (or equivalent) maintained under change control | <<FILL>> | <<FILL>> | <<FILL>> |
7. Deviation handling
Record any failure as a deviation with the observed result and evidence, resolve it (configuration fix, access change), and re-execute the affected case to a pass. QA approves the resolution.
8. Summary and conclusion
State the number of cases executed, passed, and deviated, the disposition of each deviation, and the overall conclusion that time controls are, or are not, qualified. <<FILL: complete at execution>>.
9. Attachments
- NTP configuration evidence (source list, offset measurement).
- Screen captures of the denied clock/time-zone change (TC-04, TC-05).
- The controlled-change log entry (TC-06).
- Stored-value and display evidence (TC-07, TC-08).
10. References
21 CFR Part 11.10(e) (computer-generated, time-stamped audit trails), 11.10(d) (access control). EU GMP Annex 11 (computerised systems). MHRA GxP Data Integrity Guidance and Definitions (2018). PIC/S PI 041, Good Practices for Data Management and Integrity.
Confirm the current version of each reference before issue.
Filled specimen
One executed test case, illustrative only.
| ID | Test step | Expected result | Actual | Pass/Fail | Tester / date |
|---|---|---|---|---|---|
| TC-04 | As ordinary user “qc-analyst-3”, attempt to change the system clock from Control Panel and via command line | Both attempts denied; no “change system time” right held | Both attempts denied, access-denied message captured (screenshot A-04) | Pass | A. Patel, 2026-06-18 |
Here the negative test is the one inspectors care about most: an ordinary analyst genuinely cannot move the clock, evidenced by a captured access-denied result, not just an assertion that they cannot.
Common inspection findings this protocol prevents
- No evidence that the “cannot change the clock” control was ever tested (only asserted).
- Synchronization proven at go-live with no recorded tolerance or offset.
- DST behaviour never tested, so an out-of-sequence audit trail surprises everyone later.
- Naive local time storage never noticed because the stored value was never inspected.
How to adapt this protocol
- Set the system, host, and document numbers.
- Insert your real NTP source list and tolerance in TC-01 and TC-02.
- Add or remove cases to match the system (for example instrument time, database time zone).
- Attach the actual evidence for each case; a screenshot of the denied change is the strongest artifact.
- Confirm every regulation in section 10 against the current published version before issue.