GxP-compliant and still usable: why compliance is not a data problem
In regulated production, the first reflex is to lock data away. Yet the goal is not less data flow — it is traceable data flow. How data leaves the validated plant without touching it, and why that is a question of architecture.
An example from almost every plant: a process engineer wants to analyse the last 90 days of a critical temperature and pressure tag on a validated packaging line, to understand recurring micro-stops. Quality Assurance and Validation react with justified caution — hands off the validated system, every change triggers re-qualification. So the values get exported to Excel once, by hand. And the analysis dies in the formatting.
The data was there. The obstacle was the assumption that you have to touch the validated system to get to it.
Because locking data away is not the same as protecting it. Locking it away solves no compliance problem — it only shifts it into manual analyses, media breaks and reports that no one can trace. The very data integrity that is meant to be protected suffers most from the manual detour.
Do you know this moment from your own plant? Then it is worth asking whether the caution really applies to the validated system — or to an assumption about how you get to your data.
What the regulations actually require
GxP (Good x Practice — the umbrella term for good practice in manufacturing, the laboratory and the clinic) and 21 CFR Part 11 (the FDA rule for electronic records and signatures) do not require data silence. They require traceable, attributable and auditable records.
The core question of 21 CFR Part 11 is the trustworthiness of electronic records: who changed what, when, and can it be proven without gaps? Compliance is therefore a question of provenance and accountability — not of isolation.
The real mistake is to play “compliant” off against “usable.” The regulations require traceability, not standstill. Once provenance, audit trail and accountability are anchored in the data layer itself, the supposed trade-off disappears.
How data leaves the validated plant without touching it
The key is a layer that sits alongside OT (Operational Technology, the technology of production) and IT (Information Technology) — not inside them. Tools like AspenTech inmation are one such connectivity layer. It forms a foundation between IT and OT, but it is no process control system, no SCADA (Supervisory Control and Data Acquisition) and no MES (Manufacturing Execution System) — and replaces none of them. Which tool is used in the end depends on the installed base; what matters is the principle, not the product.
The principle is read-only and out-of-band. The layer subscribes to data instead of intervening in control: it reads tag values, taps the historian, listens for messages — but it sends no control commands back to the PLC or control system. The validated logic and its configuration stay byte-for-byte unchanged. No trigger for re-validation is created.
Connection runs over the established industrial interfaces — OPC UA and OPC DA where available, plus historian interfaces and message brokers. Where a source lacks a native standard interface, a custom driver reads it without changing the source. And where raw values are to be normalised or enriched at the edge, a lightweight script runs directly on the component (for example in Lua) — instead of extra middleware on top.
Data integrity is engineering, not paperwork
Traceability is not an add-on function; it is a property of the capture itself. The regulators’ recognised data integrity principles — ALCOA (attributable, legible, contemporaneous, original, accurate) — map directly onto concrete mechanisms of the data layer, instead of being pieced together later across system boundaries.
| ALCOA principle | Technical mechanism |
|---|---|
| Attributable | Every value carries its source tag identifier; every configuration change is logged with user and time. |
| Legible | Audit-ready, machine- and human-readable logging of all system and configuration changes. |
| Contemporaneous | The timestamp is created at capture, at the source — not only on import into the target system. |
| Original | Store-and-forward buffers during network interruptions; the source’s raw value is preserved — no gaps, no later interpolation. |
| Accurate | One reliable source (single source of truth) for historical and incoming tag data — no conflicting copies. |
The audit trail runs across all of this: it captures every system and configuration change traceably and immutably — accountability by design, not a bolted-on log. [SUBJECT-MATTER REVIEW: have Florian Seidl confirm the ALCOA mapping and the store-and-forward wording — editorial technical framing, not verbatim from the interview.]
Context turns a value into an auditable record
Data integrity does not end with clean capture. A raw value like TT_1042 = 21.4
is worthless on its own — and cannot be defended in an audit. Only the link to equipment, batch, process step and site turns it into a statement: this value, from this asset, in this batch, at this process step.
This is where a clean data model along ISA-95 helps (the ANSI/ISA-95 and IEC 62264 standard for structuring manufacturing data across the levels of enterprise, site, area, line and equipment). The connectivity layer places the raw data into this hierarchy — a number becomes a record with provenance. That is where “usable” and “auditable” converge instead of contradicting each other.
Local compliance, central data — the architecture
The real difference is architectural. It is not a global rollout in which the same software is installed at every site and runs in isolation.
Instead, each site runs its own autonomous instance of the data layer: technically self-sufficient, independently operable. All instances connect into one central, global level. One system, enterprise-wide — instead of many isolated single installations.
The norm is a separate historian and a separate MES per site — each island on its own, each compliance discussion from scratch. The data stays locally trapped, or you duplicate infrastructure to bring it together.
In the model described, compliance stays locally intact while the data still flows centrally. Regulation and site autonomy stay where they belong — and the enterprise-wide view emerges on top of that, not against it.
Why compliance is a context problem, not a data problem
The data was never the obstacle. The obstacle was an architecture that forced a choice: compliant or usable. Once provenance, audit trail and accountability are part of the connectivity layer, that choice disappears. Compliance becomes a property of the architecture — not a reason to lock data away.
Whether this holds in your regulatory environment depends on your systems and your validation strategy — there is no blanket answer here. We would rather look at cases like these concretely at Pharma MES Europe than generalise them in a blog post.
From experience: in 18 years of OT integration I have met the re-validation objection a hundred times — and it is a fair one. That is exactly why “read, don’t write” and the single, documented intervention matter: the validated system stays as it is — the data layer sits alongside it, not inside it.
Why MES projects fail — and why it usually has nothing to do with the MES
When technology is not the problem: where data projects in pharma really fail — from a project-leadership perspective.
Read the post →We will be discussing this at Pharma MES Europe 2026
In Berlin, cts Group and Xenium AG show how GxP data becomes usable without putting validation at risk — from the architecture to the running plant.
Book a meeting at the stand
