GxP data integrity and cyber security: why a validated estate makes ordinary security harder

Every security programme in a regulated life sciences business eventually runs into the same sentence: "we cannot patch that, it is validated." The person saying it is usually right about the constraint and wrong about the conclusion. Validation does not forbid change, it governs it. But the governance is real, it is deliberately slow, and it means the security playbook that works in a professional services firm fails quietly in a GxP estate. This piece sets out where data integrity and cyber security actually meet, what the MHRA, Annex 11, Part 11 and GAMP 5 each ask for, and what a defensible answer looks like when you genuinely cannot patch on a Tuesday.

Two audiences, one set of records

Most organisations run data integrity and cyber security as separate programmes with separate owners, separate committees and separate evidence. Quality owns validation, change control and audit-trail review. IT owns identity, patching, monitoring and backup. The two meet at a steering group once a quarter and otherwise leave each other alone.

That split is convenient and wrong, because both disciplines are making claims about the same records. A GxP inspector asks whether a batch record or a chromatography result can be trusted: was it created by the person the system says created it, at the time the system says, and has it survived unaltered since? A security reviewer asks whether the same record could have been read, changed or destroyed by someone who should not have been able to. Those are the same question approached from two sides, and the controls that answer them are largely the same controls.

Where the two programmes stay separate, the failure mode is predictable. The validated estate accumulates exceptions that quality has formally accepted and IT has never seen. The security estate accumulates controls that IT has deployed and quality has never assessed, which means the first inspection question about an unvalidated agent writing to a GxP system becomes a very uncomfortable afternoon. Joining them up is not a reorganisation, it is a shared control set with one risk register and one set of evidence, described in both vocabularies. That is the work we do with pharma and life sciences clients, and it is usually cheaper than running two programmes badly.

What the MHRA actually expects on data integrity

The MHRA publishes GxP data integrity guidance that applies across the good practice disciplines: manufacturing, distribution, laboratory, clinical and pharmacovigilance. It is guidance rather than a rulebook of discrete clauses, and its character matters more than any individual sentence in it.

Three themes run through it. First, data integrity expectations are risk-based and proportionate: the effort you put into controlling a record should reflect the risk that record carries to product quality and patient safety, so a manual temperature log on a non-critical store is not treated like a release-critical analytical result. Second, the expectation covers the whole data lifecycle, from generation and processing through review, reporting, retention and eventual destruction, not just the moment of capture. Third, it is a governance expectation as much as a technical one: the guidance looks for a data governance system, an organisational culture in which raising a data problem is safe, and management that understands where its critical data sits.

The last point is the one security teams underestimate. A large share of real data integrity findings are not clever attacks, they are ordinary behaviour under pressure: a shared login because the second licence never arrived, a result reprocessed without the original retained, a clock that drifted on an instrument because nobody owned time synchronisation on the lab network. Those are process and ownership failures with technical fingerprints, and they are exactly the kind of thing continuous evidence collection catches early and an annual audit catches late.

The ALCOA+ principles, spelled out

ALCOA+ is the shorthand for what trustworthy GxP data looks like. It is worth writing out in full, because each element maps onto a control someone in your organisation already owns.

Attributable. You can tell who created or changed the record, and when. This is identity and access management, and it is the element a shared account destroys outright.

Legible. The record is readable and remains readable, including any changes to it. For electronic records this is as much about format longevity and the ability to render an audit trail in an intelligible form as it is about handwriting.

Contemporaneous. The record was made at the time the activity happened. Technically this rests on reliable, synchronised time across systems and instruments, and on preventing retrospective entry without it being visible.

Original. The record is the first capture of the data, or a verified true copy of it. This drives decisions about where raw data lives, whether an instrument's local store is the original, and how copies are verified.

Accurate. The record reflects what actually happened, supported by calculation checks, calibration, and review by someone competent to spot an error.

Complete. Nothing has been quietly left out, including repeat tests, aborted runs and the metadata needed to make sense of the result. Selective reporting is one of the sharpest findings an inspector can make.

Consistent. The sequence of events holds together, with date and time stamps in the expected order across the systems involved. Inconsistent sequencing between an instrument, a LIMS and a document management system is a classic trigger for a deeper look.

Enduring. The record survives for its full retention period, which in this sector can run to decades. That is a backup, archive, media and format-migration question, and it is frequently the weakest link in an otherwise well-controlled estate.

Available. The record can be retrieved for review or inspection throughout that period, not just restored in principle. A tape nobody has test-restored in four years is not available in any sense an inspector will accept.

Read that list as a security architecture brief and it is remarkably familiar: identity, time, logging and log protection, encryption and integrity, backup and archive, retention, and tested retrieval. Nobody needs a new control framework. What they need is for the existing controls to be specified, evidenced and reviewed to the standard a regulated record demands.

Annex 11 and 21 CFR Part 11: what the computerised-systems rules ask for

Two instruments do most of the work on computerised systems, and which of them reaches you depends on your markets rather than your head office.

EU GMP Annex 11 is the annex on computerised systems in EudraLex Volume 4. It applies where you manufacture for the EU market, and the MHRA publishes equivalent expectations for the UK in its Rules and Guidance for Pharmaceutical Manufacturers and Distributors, commonly called the Orange Guide. Annex 11 is short and principles-based, and it covers the ground a security architect would recognise: risk management proportionate to the system's impact, supplier and service-provider agreements where you rely on a third party, validation across the system lifecycle, controls over data entry and transfer, physical and logical security limiting access to authorised persons, audit trails for changes and deletions of regulated data, change and configuration management, periodic evaluation of systems in use, incident management, business continuity, and archiving with a readability check. It is also worth knowing that Annex 11 has been under review, with revised text in circulation, so an estate being designed now should be designed to the principles rather than to a particular clause number.

FDA 21 CFR Part 11 governs electronic records and electronic signatures kept or submitted under FDA predicate rules, and so reaches you where you supply or seek approval in the US. It is more prescriptive than Annex 11 and, for a security reader, more immediately recognisable. In broad terms Part 11 expects closed systems holding electronic records to be validated; to be capable of producing accurate and complete copies in a form suitable for inspection; to protect records so they remain retrievable for their retention period; to limit system access to authorised individuals; to maintain secure, computer-generated, time-stamped audit trails recording actions that create, modify or delete records, in a way that does not obscure previously recorded information; to apply authority checks so that only the right people can use the system, sign records or perform operations; and to hold individuals accountable for actions taken under their electronic signatures through written policy and training.

On signatures specifically, Part 11 expects each electronic signature to be unique to one individual and not reused or reassigned, expects non-biometric signatures to be built from at least two distinct identification components such as an identifier and a password, expects the signed record to show the signer's printed name, the date and time of signing and the meaning of the signature (authored, reviewed, approved), and expects signature and record to be linked so a signature cannot be excised and reapplied elsewhere.

One nuance saves a great deal of wasted effort: FDA has for many years applied a narrow interpretation of Part 11's scope, set out in its scope and application guidance, and exercised enforcement discretion over parts of the rule. So the first question in a Part 11 assessment is not "how do we comply with all of it" but "which records here are actually Part 11 records under a predicate rule, and which systems hold them". Scoping that honestly, with quality and regulatory affairs in the room, typically shrinks the problem substantially.

Two cautions are worth stating plainly. A security control does not deliver regulatory compliance: multi-factor authentication on a LIMS does not make the LIMS Part 11 compliant, it supports one of the things Part 11 asks for, and the compliance conclusion belongs to your quality system. And compliance is not a static property of a product. Software marketed as "Part 11 compliant" is, at best, capable of being configured and validated in a compliant way. The configuration, the procedures and the evidence are yours.

GAMP 5, and what risk-based categorisation means in practice

GAMP 5 is the ISPE guidance that most of the industry uses to decide how much validation effort a computerised system deserves. Its second edition, published in 2022, put a heavier emphasis on critical thinking, on leveraging supplier documentation rather than recreating it, and on modern delivery including cloud and iterative development.

The core idea is simple and, applied properly, liberating: effort should be proportionate to risk, and risk here means risk to patient safety, product quality and data integrity. Two mechanisms carry it.

The first is software categorisation. You classify a system by how much of it you are responsible for specifying: infrastructure software such as operating systems and database engines; non-configured commercial products used as supplied; configured commercial products where you have set up workflows, calculations or roles; and bespoke or custom applications written for you. Documentation and testing depth rises across that range. An instrument control package used out of the box does not need the specification set a custom-built electronic batch record needs.

The second is functional risk assessment. Within a system, you identify the functions whose failure could affect product quality, patient safety or data integrity, and you concentrate testing there. A LIMS calculation that determines a release decision is a critical function. The colour scheme on the login page is not.

What this means for a security team is specific and useful. Changes at the infrastructure and non-configured layers, which is where the great majority of security patching lives, can usually be handled with lighter, pre-approved documentation and standing regression scripts, provided the categorisation and the risk rationale were written down in advance. The organisations that struggle are the ones that never did that work, so every patch is argued from first principles under time pressure. The organisations that cope wrote the rationale once, agreed it with quality, and now execute it.

A deliberate caution: GAMP 5 is industry guidance, not law. It is widely accepted by regulators as a sound approach and is the lingua franca of validation teams, but an inspector assesses you against the regulatory expectations, not against a GAMP chapter. Say "GAMP-aligned", not "GAMP compliant".

The patching problem, stated honestly

Here is the real operational tension, without the comfortable version.

In an ordinary estate, vulnerability management is a cadence. Patches land monthly, criticals get an emergency route, and the measure of a good programme is how fast the window closes. In a validated estate, every one of those patches is a change to a system whose qualified state you have attested to. It has to pass through change control: raised, impact-assessed, risk-assessed, tested to a degree proportionate to that risk, approved, implemented, verified, and documented. Depending on what it touches, it may require regression testing of critical functions or, less often, requalification.

That process exists for good reasons and it is not going away. It also means a critical vulnerability disclosed on the fifteenth does not get fixed on the sixteenth. And it sits on top of a harder structural problem: a significant share of the GxP estate cannot be patched at all. Instrument controllers still running operating systems the vendor abandoned years ago. A chromatography data system whose supported version requires a hardware refresh the capital plan does not fund until next year. A manufacturing execution module whose vendor will not support the current platform. These are not negligence, they are the consequence of a twenty-year equipment life meeting a five-year software life.

The wrong responses are familiar. One is to patch anyway, quietly, outside change control, which trades a security risk for a regulatory one and loses the trade. The other is to do nothing and let "it is validated" stand as a complete answer, which is how an unsupported instrument PC becomes the beachhead for an incident that stops production. Neither is defensible, and an inspector or an underwriter will recognise both.

What compensating controls actually look like

The defensible answer is a documented, risk-assessed set of compensating controls, reviewed on a schedule, with any residual risk formally accepted by someone with the authority to accept it. In practice that means five things working together.

Segmentation, done properly. Unpatchable systems belong in their own network zones with controlled conduits between them, not on a flat site network with the finance team. For manufacturing and laboratory environments the zone and conduit model in IEC 62443 is a sound organising idea even where the standard is not formally adopted: define the zones, define what is allowed to cross and in which direction, and enforce it at a device you control rather than by convention. The test of segmentation is not a diagram, it is whether someone can demonstrate that the traffic they claim is blocked is actually blocked. Network security work in this sector is mostly this, patiently.

Tightly controlled access. Named individual accounts, least privilege, and no standing administrative rights on validated systems. Administrative and vendor access brokered through a jump host with session recording, enabled for a defined window against a change record and disabled after. Multi-factor authentication wherever the system or its access path can carry it, which is often at the remote access and jump host layer rather than on the instrument itself. This is the single highest-value area to invest in, because it serves attributability and security simultaneously. It is the core of the identity security work we do in validated estates.

Monitoring that does not require an agent. If you cannot install an endpoint agent on a validated host without triggering a change, monitor around it: network telemetry at the zone boundary, authentication and directory logs, jump host session logs, and alerting on the small set of behaviours that matter for these assets, such as an instrument PC suddenly talking to the internet or to a server it has no business reaching. A fully managed detection capability earns its place here precisely because the assets are quiet and predictable, so anomalies stand out. That is the shape of our managed detection and response work on this kind of estate.

Patching inside planned change windows. Rather than treating each patch as an event, pre-agree a taxonomy with quality: which classes of update follow a fast documented route with standing test scripts, which need targeted regression testing of critical functions, and which need a full change project. Then align patch deployment to planned maintenance and shutdown windows, so the estate moves forward predictably instead of drifting. Most organisations find they can bring a large majority of their security updates into the fast route once the rationale is written down.

Documented risk acceptance, with an expiry date. Where an asset genuinely cannot be remediated, write the risk down: the vulnerability, the compensating controls, the residual risk, the owner who accepts it, the review date, and the plan that eventually removes it. A risk acceptance with no end date is a decision to live with the problem forever, and both inspectors and underwriters read it that way. A risk acceptance tied to a capital replacement in a named year is a credible position.

Taken together, that is a position you can defend in a GxP inspection, in a partner audit and at an insurance renewal, which is the only kind of position worth building.

Access control and audit-trail integrity: one requirement, two auditors

If you only fix one thing in a validated estate, fix accounts.

The shared laboratory login is the canonical example because it fails both tests at once. Three analysts signing in as "lab1" means the audit trail can tell you a result was reprocessed but not by whom, so the record is no longer attributable and the ALCOA+ case collapses. On the security side, the same account cannot be revoked for one leaver, cannot be meaningfully baselined for unusual behaviour, and is almost certainly written on something near the instrument. Generic and shared accounts in GxP systems remain one of the most common findings in this area.

The same logic runs through the rest of access control. Administrative rights held by the people who also generate and approve regulated data break segregation of duties, which is a quality concern, and concentrate the blast radius of a compromised credential, which is a security concern. A system administrator who can edit data and also edit the audit trail has made the audit trail decorative. Leaver and mover processes that run promptly in the corporate directory but not in the laboratory systems leave accounts behind, and an inspector finding an active account for someone who left eighteen months ago will draw conclusions about the whole control environment.

Audit trails deserve the same scrutiny as the data they describe. Three questions settle most of it. Is the trail switched on, for everything that matters, with no option for a user to disable it for their own session? Is it protected, so that the people who generate data cannot alter or delete the record of what they did, which usually means privilege separation and often means forwarding a copy to storage outside the application? And is it reviewed, by someone competent, on a defined basis and with the review itself evidenced? Audit trail review is the step organisations most often own on paper and least often do in practice, and it is also where a security monitoring capability can genuinely help: the same events that matter to a quality reviewer, failed logins, out-of-hours access, deletions, changes to configuration, are events a monitoring service can surface continuously instead of monthly.

Where an instrument cannot support individual accounts at all, which still happens with older bench equipment, be honest about it. The workable compensating pattern is an access-controlled workstation with individually authenticated operating-system sessions, a contemporaneous logbook tying operator to run, physical access control to the room, and a documented risk acceptance that says why the limitation exists and when the instrument will be replaced. That is a defensible answer. "The team knows who was on it" is not.

The supply chain: CROs, CDMOs and the vendor with a remote connection

Very little of a modern life sciences operation sits inside its own perimeter. Analytical work goes to contract research organisations. Manufacturing and packaging go to contract development and manufacturing organisations. Instruments arrive with maintenance contracts that assume the vendor can connect in to diagnose a fault at short notice. Trial data moves between sponsor, sites, central laboratories and data management providers. Each of those relationships is a route into your regulated data, and under both quality and data protection law the accountability for that data does not transfer with the work.

Three practical disciplines carry most of the weight.

Know what you have delegated, and to whom. Build one register of the third parties that touch GxP data or systems, with what each one does, what data it holds or can reach, how it connects, which of your systems it can affect, and who owns the relationship. Most organisations hold fragments of this in procurement records, in quality agreements and in the IT access list, and the fragments disagree. A single register is the foundation for everything else, and it is also what partner and investor due diligence asks for first.

Make the agreements say something. Quality and technical agreements with CROs and CDMOs should address data integrity and security explicitly: who holds the original records, how raw data and metadata are transferred and verified, audit and inspection rights, incident notification with a realistic clock, subcontracting transparency, data retention and return or destruction at exit, and what happens to your data if the relationship ends badly. Annex 11 expects agreements where a third party provides or operates a computerised system, and the agreement is the only lever you have once something goes wrong.

Govern vendor remote access as a privileged pathway, not a convenience. The instrument engineer who needs to connect occasionally should not have a standing account, a permanent tunnel or a tool of their own choosing. The pattern that works: access requested against a ticket or change record, granted for a defined window, brokered through your jump host with multi-factor authentication, session recorded, activity reviewed, access removed at the end. It is slightly more friction for the vendor and dramatically less risk for you, and it produces an evidence trail that answers both the quality question and the security question about who touched the system.

Supplier security requirements increasingly come back the other way too. Partners, licensors and large customers now send their own security questionnaires, often asking for ISO 27001 or an equivalent framework, and often during a deal when the deadline is not yours to set. Holding a maintained evidence pack turns that from a fortnight of scrambling into an afternoon. Certification, where you decide you want it, is delivered through certified assessment partners, with us as your single point of accountability for the work behind it.

Clinical trial data and UK GDPR

Health data is special category data under UK GDPR, and clinical trial datasets are largely built from it. That raises the bar in several concrete ways.

You need a lawful basis for the processing and, separately, a condition for processing special category data. Pseudonymisation and key-coding reduce risk and are expected good practice, but they do not take the data outside UK GDPR for as long as anyone holds the key that could re-identify it, so treating a key-coded dataset as anonymous is a common and serious error. Most trial processing will need a data protection impact assessment, and where you rely on the research provisions you need the safeguards that come with them. International transfers matter more in this sector than most, because sites, laboratories, CROs and sponsors are rarely all in one jurisdiction, so transfer mechanisms and the supporting assessments need to be live documents rather than something signed once.

Breach handling deserves its own rehearsal. If a laptop with trial data goes missing or a research share is found to have been accessible, you are assessing reportability against the 72-hour window for notifying the ICO, with a parallel judgement about notifying affected participants, while simultaneously working out whether the event has implications for the integrity of trial data and therefore for your regulatory submissions. Those two trains of thought run at different speeds and need different people. Organisations that have walked through the scenario once, with quality, data protection, clinical and IT in the same room, handle it far better than those meeting the question for the first time at eight in the evening.

Data protection obligations sit alongside your clinical trial regulatory obligations rather than inside them. The UK framework for clinical trials is itself being reformed, and the detail is worth confirming with your regulatory affairs function rather than assuming last year's position still holds.

What a joined-up programme looks like

Pulling the threads together, the organisations that handle this well tend to have done six things.

One asset and data inventory covering GxP systems and the regulated data they hold, with each system's GAMP categorisation, its criticality, its support status, and its owner. This is dull and it is the foundation of everything else, including any honest answer to "are we exposed to that vulnerability".

One risk register that quality and IT both read, in which a data integrity risk and a security risk about the same system appear next to each other rather than in two documents that never meet.

A pre-agreed change route for security work, with a patch taxonomy, standing test scripts for the common cases, and planned windows, so routine protective work is routine rather than exceptional.

Segmentation and privileged-access architecture designed around what cannot be patched, with vendor and administrative access brokered, time-bound and recorded.

Continuous monitoring and continuous evidence, so that the control environment is demonstrably working between audits rather than reconstructed before them. This is the whole premise of continuous compliance: the evidence accumulates month by month, so an inspection or a partner audit is a retrieval exercise rather than a project.

A named senior advisor who can sit in a quality council and a board meeting and use the right vocabulary in each, because most of the friction in this work is translation rather than technology. That is what our vCISO engagements are for in this sector.

None of that is exotic. What makes it hard is that it has to be built by people who understand both halves of the problem, and those people are genuinely scarce. The common failure is a strong security programme that quality cannot accept, or a strong validation programme with a security posture a decade out of date.

Where to start

If you are early, start with the inventory and the honest unsupported-asset list. You cannot make risk decisions about an estate you have not described, and the list is almost always worse than the first estimate and more tractable than the fear.

If you have the inventory, start with accounts: individual named access, no standing administrative rights, brokered vendor access, and audit trails that the people generating data cannot alter. That work serves attributability and security at the same time, which makes it the best-value thing you can do in a validated estate.

If you have both, the next step is usually the change route. Sit down with quality and write the patch taxonomy and the risk rationale before the next critical vulnerability lands, so the answer is a procedure rather than an argument.

If you would like to talk it through with someone who has done this in a GxP estate, book a call. We will look at your actual systems, your markets and your inspection history, and tell you where the genuine exposure is rather than selling you the full programme. You can also see how we work with pharma and life sciences more broadly, or test your own position against the compliance readiness self-assessment first.