Why Timestamps Are a Part 11 Issue
21 CFR Part 11 requires that electronic records are trustworthy, reliable, and equivalent to paper records. A fundamental component of that is the timestamp. Every audit trail entry — every setpoint change, alarm acknowledgement, user login, mode change — must carry a timestamp that accurately reflects when the event occurred. If the clock is wrong by 20 minutes, or if it drifts over time without correction, the timestamps in your audit trail are inaccurate. That is a data integrity failure, regardless of whether the underlying process data is correct.
The same requirement flows through the EU GMP Annex 11 on the European side. Both frameworks treat timestamp accuracy as a precondition for audit trail validity, not an optional feature. On a pharma project, this means the PLC clock cannot just be set once during commissioning and left to drift. It must be continuously synchronised to a traceable time source.
NTP — Network Time Protocol — is the standard mechanism. But the implementation details matter: which NTP server, what sync interval, what happens when synchronisation is lost, and how you prove it is working during qualification. All of these need to be designed, documented, and verified.
The NTP Architecture for a Pharma OT System
The key architectural decision is that OT devices must not synchronise directly to internet NTP servers. Pharma OT networks are segmented precisely to prevent unsolicited traffic from the internet reaching the control layer. A PLC that punches through the firewall to reach pool.ntp.org is both a cybersecurity problem and an architectural inconsistency — it contradicts the network segmentation documented in your HDS.
The correct architecture has a dedicated OT NTP server sitting inside the OT network, synchronised to the site's GPS-based or stratum-1 time source. All OT devices — PLC, SCADA server, historian, HMI workstations — synchronise to this OT NTP server. The OT NTP server handles the external time source relationship; the OT devices never need to see beyond the OT network boundary.
Configuring the PLC SNTP Client
PLCs use SNTP (Simple Network Time Protocol) — a lightweight subset of NTP appropriate for devices that need time synchronisation but are not themselves time servers. The configuration approach differs by platform, but the required parameters are the same across all of them: server IP address, sync interval, and handling of sync failure.
In TIA Portal (Siemens S7), NTP synchronisation is configured in the CPU properties under the PROFINET interface settings. You add the site OT NTP server IP address and set the synchronisation interval. The built-in SNTP function block handles the periodic requests. The CPU system clock is updated on each successful sync. In FactoryTalk (Rockwell Studio 5000), the equivalent is configured in the controller properties. In Codesys-based platforms, it is typically a library function block with an NTP client function. The platform differs; the principle is identical.
The sync interval for a GMP system should be 60 seconds or less. This is not about network load — SNTP packets are tiny. It is about limiting the maximum drift window between sync events. A 60-second interval means the worst-case drift accumulation before the next correction is a few milliseconds on a stable system. A 3600-second interval means a drifting PLC clock could be off by seconds before the next sync corrects it.
A well-designed pharma PLC system does not simply alarm on NTP loss and continue accepting parameter changes. It locks parameter changes if the clock drift exceeds 30 seconds from the last confirmed NTP sync. The reasoning: if the clock is more than 30 seconds adrift, timestamps on any changes made during that window are inaccurate by a regulatory standard. The system should not create inaccurate audit trail entries — it should refuse to create them until the clock is corrected. This is not a standard requirement in most GMP guidance documents, but it is a defensible design decision that demonstrates a serious approach to data integrity. The lock releases automatically when NTP sync is restored.
What the SDS Must Specify
NTP configuration is a software design decision, so it lives in the Software Design Specification. The SDS must cover four things for the NTP implementation to be fully documented and verifiable:
- NTP server IP address — the specific site OT NTP server IP, not a generic placeholder. This is what the IQ verification step checks against the running configuration.
- Sync interval — the frequency of synchronisation requests from the PLC SNTP client. 60 seconds for GMP systems.
- Sync loss behaviour — what the system does when NTP sync is lost: alarm priority, alarm tag, and whether parameter changes are locked. This becomes an OQ test case.
- Manual time change controls — who can change the system clock, what role is required, what audit trail entry is generated, and whether an alarm fires. On a GMP system, manual clock changes should require Administrator role, generate a mandatory reason entry, and trigger a Critical alarm visible to all logged-in users.
The audit trail data structure also needs to reflect NTP synchronisation. Every audit trail record includes a timestamp field — the SDS UDT (User Defined Type) for an audit trail entry should explicitly note that the timestamp is NTP-synchronised. This is the design-level evidence that the timestamps in the audit trail are trustworthy.
IQ Verification — What Gets Checked
The IQ verifies the NTP configuration statically — confirming that the PLC and SCADA server are configured to use the site OT NTP server, not an internet server or the supplier's lab NTP server from the FAT. This is IQ-CYB-005 in the IQ protocol: run w32tm /query /status on the SCADA server and record the NTP source IP. It must match the site OT NTP server IP documented in the SDS. Record the actual IP in the IQ evidence.
This is a common but significant failure mode: the system leaves the supplier's factory synchronised to the supplier's lab NTP server. It passes the FAT. It arrives on site, is connected to the site OT network, and nobody reconfigures the NTP source. The IQ verification catches this — the recorded NTP source IP will not match the SDS specification, generating a deviation and requiring the configuration to be corrected before OQ can begin.
The IQ does not test whether the synchronisation is actually working end-to-end with site timestamps — that is the SAT. The IQ confirms the configuration is correct. The SAT confirms the behaviour is correct.
SAT Verification — Live Timestamp Confirmation
The SAT is where NTP gets its live test. SAT-021 specifically tests site OT NTP synchronisation: run w32tm /query /status on the SCADA server and confirm the NTP source shows the site OT NTP server IP, with a stratum level and time offset within the acceptable tolerance. The acceptance criterion is a time offset of less than 30 seconds from the site NTP server.
The SAT also tests NTP loss behaviour: disconnect the site OT NTP server (or disable the NTP service temporarily), wait 65 seconds, and confirm the SCADA generates a High alarm — typically tagged something like ALM-DATA-003 (NTP Synchronisation Lost) — within 60 seconds of NTP loss. Then reconnect and confirm the alarm clears and sync is restored. This is a live functional test of the alarm and recovery behaviour documented in the SDS.
The audit trail verification in the SAT ties directly to NTP. SAT-020 requires that the first live audit trail entries on the site system show the site NTP-synchronised timestamps — not the supplier lab timestamps from FAT. The verifier checks that an audit trail entry timestamp matches the site NTP server current time to within ±30 seconds, and records both values in the protocol as evidence. This is the end-to-end proof that the entire timestamp chain — from the site GPS time source, through the OT NTP server, through the PLC SNTP client, into the audit trail record — is working correctly.
The SDS (SDS-SYS-001) specifies the PLC NTP configuration under the communications protocol table: SNTP client to site OT NTP server, 60-second sync interval, parameter changes locked if drift exceeds 30 seconds from last confirmed sync, manual time change requires Administrator role plus mandatory reason entry plus Critical alarm. The audit trail UDT (typ_AuditEntry_GxP) explicitly marks the timestamp field as NTP-synchronised. The IQ protocol (IQ-SYS-001) includes IQ-CYB-005 — NTP source verification via w32tm — as part of Section 9 (Cybersecurity Installation Verification). The SAT protocol (SAT-SYS-001) includes SAT-020 (first live audit trail entries with site NTP timestamps, ±30 second tolerance check) and SAT-021 (NTP synchronisation live verification and NTP loss alarm test) in Section 9 (Live Data Integrity and Audit Trail Verification).
Common Mistakes
Beyond the factory NTP server issue already covered, the same errors appear on project after project:
- NTP configured on the SCADA server but not the PLC. The SCADA historian timestamps use the server clock, which is NTP-synchronised. But the PLC's internal clock, which stamps the audit trail buffer entries before they reach the historian, is free-running. The timestamps diverge over weeks and months, and the discrepancy becomes visible in historian queries that compare PLC-originated records with SCADA-originated records.
- Using the corporate IT NTP server. The corporate domain controller is often the path of least resistance. It is reachable, it works, the SCADA server is probably already pointing at it for Windows Time Service. The problem is that corporate IT NTP is on the IT network, not the OT network — and a dependency on the IT network violates the OT segmentation architecture. If IT takes the domain controller down for maintenance, the OT system loses NTP. The correct source is always a dedicated OT NTP server inside the OT segment.
- No alarm on NTP loss. If the NTP server goes away silently and no alarm fires, the system continues generating audit trail entries with a drifting clock. Hours or days of records may have inaccurate timestamps before anyone notices. The NTP loss alarm must be there, and it must be tested at the SAT.
- NTP not specified in the SDS. It gets configured during commissioning as a matter of practice, but it is never formally documented. The IQ verification step then has no specification to check against, so it cannot be formally verified. NTP is a software configuration item — it belongs in the SDS.