SOP: Process Historian Data Integrity Governance

This is a ready-to-use SOP for bringing a process historian under data integrity control. 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. Verify each cited regulation against the current source before you rely on it. This SOP pairs with the Log: Process Historian GxP Tag Register and the Protocol: Process Historian Data Integrity Qualification.

Document control header

1. Purpose

This procedure defines how <<FILL: COMPANY NAME>> governs its process historian(s) as GxP computerized systems, so that time-series data used to support quality decisions is complete, accurate, attributable, and reconstructable. It addresses the traps specific to historians: compression, interpolation, quality flags, clock control, and retention versus backup.

2. Scope

Applies to every process historian that stores data used to make or support a GxP decision (batch disposition, deviation, continued process verification, environmental or utility assessment). Covers tag governance, configuration control, audit trail, time synchronization, retention and archive, report generation, and use of historian data at disposition. It does not cover the control-layer PLC/DCS/SCADA logic itself, governed by <<FILL: SOP-ID for automation systems>>.

3. Responsibilities

4. Definitions

• Tag / point: a single measured or calculated variable stored as a timestamped stream.
• Compression / deadband: the algorithm that decides which raw values to store; a wide deadband can smooth real excursions out of the record.
• Interpolated value: a calculated value for a timestamp that was never actually recorded.
• Retrieval mode: how the historian returns data (raw, interpolated, sampled, aggregated); different modes can return different numbers for the same window.
• Archive vs backup: an archive is the long-term retained record; a backup is a disaster-recovery copy overwritten on a cycle. They are not interchangeable.

5. Procedure

5.1 Maintain the tag register and classify tags

1. Keep a controlled tag register (see the paired Log) with GxP classification for every tag: GxP-critical, GxP-supporting, or non-GxP with documented rationale.
2. Classify by the decision test: a CPP/CQA or batch-record/control-strategy parameter is GxP-critical; a value used to support a quality decision is GxP-supporting; a purely engineering value with no product or compliance use is non-GxP with the rationale recorded.
3. QA approves the GxP-critical list. No tag is added, renamed, or deleted, and no compression, scan rate, engineering unit, retention, or security setting is changed, except under change control per <<FILL: SOP-ID for change control>>.

5.2 Control capture settings

1. For GxP-critical tags, disable compression (store every sample) unless storage genuinely forces a deadband; where a deadband is used, justify it numerically against the parameter’s alarm and control limits and record the justification in the register.
2. Set and lock scan rates appropriate to the parameter’s dynamics.
3. Restrict or disable any ability to insert or edit historical values for GxP tags; store-and-forward buffering with original timestamps is acceptable, manual backfilling is not.

5.3 Control retrieval and reports

1. Define one retrieval mode per standard GxP report and validate it. Use raw mode for batch records and investigations, or clearly label interpolated values.
2. Fix the aggregation method and interval boundaries for each standard report so two reports of the same parameter cannot silently disagree.
3. Reports must show quality flags and data gaps, not fill them, and export as true copies with metadata, not screenshots.

5.4 Control time

1. Synchronize all source devices and the historian server to a single controlled time reference.
2. Restrict the ability to change system time to administrators; log every time change in the audit trail.
3. Define handling of time zone and daylight saving; store timestamps unambiguously (for example UTC plus offset).

5.5 Enable and review the audit trail

1. Enable the audit trail for both configuration changes (tag add/delete/rename, compression, scan rate, retention, security) and data changes (any manual edit: who, old value, new value, timestamp, reason), plus system events (time changes, archive operations).
2. Ensure entries are attributable to unique individuals; no shared accounts on GxP functions.
3. Review the audit trail on a risk-based cycle: configuration changes to GxP-critical tags and any manual data edits are reviewed per <<FILL: frequency>>; underlying continuous data is reviewed through trend review at disposition. Document the review.

5.6 Control retention and archive

1. Set retention per tag in the register to satisfy the longest applicable requirement (predicate rule, marketing authorization, GMP chapter, local law).
2. Keep the archive separate from rolling backups. Down-sampling on archive is disabled for GxP-critical tags unless a justified, change-controlled decision documents otherwise.
3. Prove archived data is restorable and unchanged by an actual restore test on a defined cycle; maintain a migration plan so data stays readable if software or format is retired.
4. Control, authorize, and record disposal at end of retention.

5.7 Use at disposition

1. Trends used at disposition must be from validated, GxP-classified tags, in the specified retrieval mode, with quality flags and gaps shown, timestamps from the controlled clock, and exported as true copies.
2. Reviewers approving disposition confirm they understand the retrieval settings behind the trend.

6. Acceptance criteria

• A controlled tag register exists, every tag is classified, and the GxP-critical list is QA-approved.
• Compression and scan settings for critical tags are documented and justified so no excursion of concern can be hidden.
• The audit trail is enabled for configuration and data changes, attributable, and reviewed on a defined cycle with evidence.
• Time is synchronized and clock changes are restricted and logged.
• Retention per tag meets the longest requirement, archive is separate from backup, and a restore test has proven archived data complete and readable.
• GxP reports specify a validated retrieval mode, show flags and gaps, and export as true copies.

7. References

21 CFR 211.68 (automatic equipment, I/O checks), 211.180-211.188 (records), 211.194 (laboratory records where applicable). 21 CFR Part 11 (electronic records and signatures). EU GMP Annex 11 (computerised systems), clauses on validation, data accuracy, storage, audit trail, and security; EU GMP Chapter 4 (documentation and retention). A draft revision of Annex 11 and a new draft Annex 22 went to consultation in July 2025 (consultation closed 7 October 2025) and remain drafts as of mid-2026; confirm the final text and clause numbers before citing. MHRA GxP Data Integrity Guidance (2018); PIC/S PI 041 (2021); WHO TRS 1033 Annex 4 (2019); GAMP 5 (2nd ed., 2022).

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

8. Records generated

• Controlled tag register; change-control records for configuration changes.
• Audit trail review records; restore-test records; disposition trend true copies.

9. Revision history

10. Approvals

Filled specimen

Illustrative extract of an audit trail review record under this SOP, for a bioreactor historian.

The point: a compression-deadband change is a GxP-relevant configuration change because it alters what gets captured, so it goes through change control and appears in the audit trail review, not silently in an engineer’s session.

Common inspection findings this SOP prevents

• Historian holds GxP data but was never classified as a GxP system and has no tag register.
• Audit trail exists but was never enabled, or covers data only and not configuration changes such as compression.
• Compression deadbands set for storage efficiency smooth real excursions out of the record.
• “Retained” data lives only on a rolling backup that overwrites before the retention period ends.
• No one can name the system owner.

How to adapt this SOP

1. Set your document number and owner, and point the change-control and automation-systems cross-references to your real procedures.
2. Insert your audit-trail review frequency and retention basis.
3. Align the roles with your actual automation, IT, and QA split; a historian with no named owner is the first gap to close.
4. Confirm every regulation in section 7 against the current published version, including the pending Annex 11 revision, before issue.