A SCADA record shows that a setpoint changed, but the entry carries a shared account, a local timestamp that occurs twice during a daylight-saving transition, and no connection to the active recipe. The value is present; the evidence is ambiguous. Data integrity by design addresses these weaknesses in the engineering of acquisition, actions, interfaces and retained records.
The practical objective is to preserve trustworthy information throughout its lifecycle. This article focuses on automation design decisions rather than reproducing a general CSV or Annex 11 guide. It asks what must be captured, protected, understood and reconstructed when the process behaves normally and when it does not.
Map the data lifecycle around actual decisions
Identify the information used to control the process, review production, investigate deviations and support disposition. Trace it from creation through processing, transfer, review, retention and eventual deletion. Include intermediate services, manual exports and spreadsheets if they are part of the real workflow. A system boundary drawn around the main application can miss consequential transformations outside it.
For each decision, determine the necessary original data and metadata. An instrument observation may require unit, source, quality status and time context. A recipe change may require identity, previous and new values, reason and version. A calculation may require inputs and logic sufficient to understand its result. The required evidence depends on intended use and applicable requirements.
[GUIDANCE] Data integrity guidance from FDA, PIC/S and MHRA supports lifecycle attention to attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring and available information. These concepts guide assessment; simply placing an ALCOA+ label on a system does not demonstrate that its configured workflows preserve those qualities.
Identify original records and necessary metadata
Determine where information first becomes a record and which transformations follow. A displayed value, stored observation and printed report may represent different levels of information. A static export may omit metadata or dynamic relationships needed to interpret the original. Define whether a copy preserves the relevant content and meaning for its intended purpose.
Record ownership should resolve which system retains the authoritative evidence. Where a record is distributed across controller, historian and MES, define stable relationships and retrieval responsibilities. A link that opens the current default trend is weaker than a controlled reference to the correct equipment, interval and context.
Consider configuration as part of interpretation. Scaling, units, tag assignment, calculation logic and recipe versions can change the meaning of stored values. Preserve the relevant configuration history or references. Reusing an identifier for a different sensor without retaining the transition can make old observations misleading even when their numbers remain unchanged.
Design audit trails for consequential changes
Identify which creation, modification and deletion events require secure retained history under the applicable framework and intended use. Define the event content, protection, review and retrieval. A technical event log may record service restarts but omit the old and new values of a recipe change. An audit trail must be assessed against its actual purpose.
Challenge the full action path: operator screen, engineering tool, API, database administration and imported configuration. A protected user interface is insufficient if another authorized route can alter relevant records without equivalent control. Restrict unnecessary routes and establish oversight for privileged activity that remains necessary.
Audit trail configuration itself requires control. Identify who can enable, disable or change it, how those actions are detected and what happens if storage or collection fails. Do not assume that selecting an “audit enabled” checkbox establishes complete coverage. Test representative changes, failed attempts and retrieval of the resulting history.
Separate events, alarms and audit evidence
Events describe occurrences; alarms call for defined operator attention; audit evidence supports reconstruction of relevant actions and changes. One occurrence can appear in several records, but their purposes differ. Alarm acknowledgement does not establish that a condition was resolved, and a security login log does not necessarily explain a manufacturing parameter change.
Define how related records can be correlated. Equipment identity, batch context, user identity and time information should support reconstruction without forcing reviewers to guess. Preserve enough context when records are exported for investigation, while controlling copies and access appropriately.
[GUIDEGXP RECOMMENDATION] Test an investigation scenario during design review. Ask a reviewer to explain a known parameter change using the available records. If the explanation depends on the developer's memory, identify the missing information and improve the design before release.
Engineer time as a shared system dependency
Define approved time sources and how controllers, servers, workstations and acquisition services obtain time. NTP or another synchronization mechanism can support consistency, but configuration, network reachability and failure detection still require engineering. Specify what happens when synchronization is lost and how excessive drift is detected according to assessed need.
Distinguish source time from collection and processing time. A buffered observation recovered after an outage should retain the event time needed for interpretation rather than appearing as a new observation at recovery. Where several timestamps are retained, label their meaning clearly.
Control time-zone presentation and daylight-saving changes. Preserve sufficient context to distinguish repeated local times. Assess the effect of clock corrections on sequence reconstruction, calculations and certificates. Derive acceptable time behaviour from process and record needs; do not invent a universal GMP clock-drift limit or synchronization frequency.
Make access attributable and proportionate
Define roles around operational responsibilities: production, supervision, maintenance, engineering, administration and review. Assign permissions according to required functions and segregation needs. Unique user accountability is essential where actions must be attributable. Shared human accounts undermine that accountability unless the intended use has a justified, controlled arrangement that preserves it through other reliable means.
Manage service accounts separately from human access. Identify their owner, purpose, permitted functions and credential lifecycle. Prevent routine operators from using privileged maintenance identities as a convenience. Review account creation, modification and removal through controlled processes, including personnel changes and supplier access.
Emergency access needs a practical design. Define authorization, duration, monitoring and subsequent review while considering the operational consequences of unavailable identity services. Avoid controls that are impossible to use during a credible incident; they encourage uncontrolled workarounds. Session behaviour and authentication settings should be justified for the system, not copied as universal numerical rules.
Protect meaning across interfaces and calculations
Information can lose integrity without being maliciously changed. Units can be converted incorrectly, messages duplicated, identifiers truncated or bad-quality values treated as valid. Define interface semantics and verify the complete transaction. A secure transport channel protects the exchange but does not prove that the receiver interpreted the payload correctly.
Control calculations and derived results. Preserve the input scope, relevant version and handling of missing or excluded values where required for reconstruction. Verify known examples and boundary cases. A report that silently ignores gaps can produce a plausible result while obscuring an incomplete record.
See GMP system integration for duplicate handling, confirmation and reconciliation. Data integrity requirements should be explicit in the interface contract and acceptance evidence, rather than appearing only in a general project policy.
Distinguish backup, archive and controlled deletion
A backup supports recovery from loss; an archive supports retained access over a defined period. Determine the data, configuration, metadata and dependencies needed for each. A database backup without application configuration or necessary keys may not support restoration of an interpretable record.
Derive retention from the applicable record obligations and approved site policy. Coordinate deletion across related systems so that supporting observations or audit information are not removed while dependent records remain in use. Restrict deletion rights and preserve evidence of authorized disposal where required. Storage capacity planning must account for the retained population and realistic growth.
Test recovery and archive retrieval using representative records, including historical versions. Verify content, relationships, access and interpretation. A successful job status is not equivalent to a successful restore. The MES and historian architecture article develops distributed record ownership and completeness.
Design review as an operational capability
Define who reviews which information, for what purpose and with what escalation route. The appropriate scope and timing depend on the records, process risk and applicable requirements. Avoid asserting one universal audit-trail review interval. Review should be practical enough to detect meaningful issues rather than generating an unmanageable volume of undifferentiated entries.
Provide search and filtering that preserve context and do not conceal relevant events. Where exception reports support review, verify their rules and completeness. Distinguish “no relevant event found” from “data unavailable” or “query not executed.” Record reviewer decisions and link unresolved findings to the site's investigation process.
Training should explain the engineering meaning of entries. Reviewers need to distinguish a rejected command, a completed action, a configuration change and a recovered delayed observation. The system should support those distinctions with clear data rather than requiring undocumented technical interpretation.
Build targeted acceptance evidence
| Design concern | Challenge | Evidence sought |
|---|---|---|
| Attribution | Two authorized users perform distinct changes | Correct identity and action context in protected history |
| Time interpretation | Buffered data arrive after interruption | Original event time remains distinguishable from receipt time |
| Audit coverage | Relevant change through an alternate permitted route | Equivalent required history or prevention of the route |
| Completeness | Acquisition or audit storage becomes unavailable | Detected failure, controlled response and visible record limitation |
| Retention | Historical record retrieved after configuration change | Readable values, metadata and interpretation context |
Choose tests according to the assessed functions and failure modes. Retain configuration identity and actual observations. Do not infer complete data integrity from a generic supplier certificate or a successful login demonstration.
Worked example: a recipe adjustment during a hold
An illustrative process permits a supervisor to adjust a specified parameter within approved bounds during a hold. The first design records only the final value in the batch report. It cannot distinguish the approved initial value from the subsequent adjustment or identify the person responsible.
The revised design retains the recipe version, previous and new values, authorized identity, time, reason and batch association. It shows the pending change clearly before acceptance and preserves the actual controller response. If communication is lost, the interface does not claim that the adjustment succeeded until the defined confirmation is received.
Acceptance includes an allowed adjustment, an out-of-range attempt, an unauthorized attempt and an interrupted exchange. A reviewer reconstructs each outcome from the retained evidence. The controls are derived from this process's intended use; the example does not imply that every parameter change universally needs the same approval workflow.
Close gaps in legacy and supplier-managed equipment
Packaged equipment may have limited identity, audit or export capabilities. Assess the actual limitations against the intended records and actions rather than assuming that a modern supervisory layer repairs them. A central historian cannot reconstruct an unrecorded local change merely by collecting the resulting process value.
Identify compensating controls that are practical, documented and proportionate, and determine whether they adequately address the risk. Some limitations may require technical modification or replacement. Assign ownership and a lifecycle plan instead of allowing temporary manual practices to become permanent without review.
Supplier-managed services need clear responsibilities for access, configuration, retention, incident notification and retrieval. Confirm that the site can obtain its records and necessary context if the service changes or ends. Contractual ownership of data is useful only when supported by a workable extraction and interpretation method. Demonstrate that method with representative records before relying on it for long-term continuity.
Regulatory status and lifecycle responsibility
[REGULATORY REQUIREMENT] Apply relevant GMP computerized-system and documentation requirements to the configured system. At the review date, EU GMP Annex 11 and Chapter 4 remained the operative 2011 texts; the 2025 proposals remained consultation drafts. US Part 11 scope depends on the electronic records and signatures and their predicate-rule context. Guidance documents help interpretation but should not be presented as interchangeable legislation.
[GEP] Maintain controls through change, incidents, supplier support and retirement. Reassess affected records when acquisition settings, identity services, interface mappings or report logic change. Connect this work with Environmental Monitoring Systems, where monitoring records can carry important context, and the Automation & Digital Systems hub.
Primary references
Reviewed 23 September 2026: EudraLex Volume 4; 21 CFR Part 11; FDA drug CGMP data integrity guidance, final December 2018; PIC/S PI 041-1, effective July 2021; MHRA GxP data integrity guidance, March 2018. The MHRA page's later OECD precedence note concerns GLP; it is not a wholesale withdrawal of the GMP guidance.
