Pharma and GxP Cybersecurity Guide: Data Integrity, Validated Systems and Part 11

In pharmaceutical manufacturing and laboratories, a cyber attack is also a data integrity and patient safety problem, because the records that release a batch must be trustworthy for the whole retention period. GxP regulation (GMP, GLP, GCP, GDP) does not use the word "cybersecurity" much, but 21 CFR Part 11, EU GMP Annex 11 and the FDA and MHRA data integrity guidance already demand unique user identity, protected audit trails, controlled change and tested backups. This guide explains how those requirements translate into security controls for validated systems, lab instruments and manufacturing OT, how to patch without breaking validation, and where shared accounts and machine identities cause most of the findings. It is written for security teams supporting pharma, biotech and contract manufacturers, and for quality and CSV (computerised system validation) specialists who need a common language with them.

Key takeaways

• Data integrity and security are the same controls seen from two sides. Unique accounts, access control, audit trails and backups appear in Part 11, Annex 11 and every security framework.
• Shared logins on GxP systems are a regulatory finding, not only a security weakness. FDA and MHRA guidance both say generic accounts break attributability for any action that creates or changes GxP data.
• Validation is not a reason to stop patching. Annex 11 and GAMP 5 expect risk-based change control, so build a patch qualification path rather than freezing systems for years.
• Lab instruments and their PCs are the weakest point. Standalone chromatography, spectroscopy and balance workstations often run old operating systems, local admin accounts and no central logging.
• The rulebook is moving. The EU consulted on a revised Annex 11 and a new Annex 22 on AI in 2025; as of October 2026 the European Commission still lists the January 2011 Annex 11 as current and Annex 22 has not been published as final.

What makes GxP security different

In most IT environments a security control is judged by whether it reduces risk. In a GxP environment it must also be shown not to undermine the validated state of the system and the integrity of the records it produces. That changes the operating model in four ways.

• Records must survive and stay readable: batch records, chromatography raw data and stability results must be retrievable and accurate for the full retention period. Ransomware that encrypts a chromatography data system is therefore a loss of regulated evidence, not just downtime.
• Every change is controlled: Annex 11 clause 10 requires all changes, including configuration changes, to follow a defined procedure. An EDR agent, a firewall rule or an operating system patch is a change to a validated system.
• Attribution is a legal requirement: Part 11 links electronic signatures to a unique individual (11.100) and requires secure, time-stamped audit trails (11.10(e)). Security logs that cannot name a person are weak evidence in both worlds.
• Integrity matters more than confidentiality: the most damaging outcome is quiet manipulation of results (ATT&CK T1565.001 Stored Data Manipulation), which can lead to a bad batch being released. Detection must look for changed data, not only stolen data.

The environment spans enterprise IT (ERP, QMS, LIMS, document management), laboratory systems (CDS, ELN, instrument PCs), manufacturing OT (DCS, PLCs, SCADA, MES, building management for cleanrooms) and a growing set of SaaS and cloud platforms. Manufacturing OT follows the same zone and conduit logic as any plant: see the OT Security Guide and the IEC 62443 Guide.

The regulatory baseline: Part 11, Annex 11 and data integrity guidance

The table maps the security-relevant requirements. Clause numbers are from the eCFR text of 21 CFR Part 11 (last amended in 2023 per the eCFR timeline, checked October 2026) and the January 2011 Annex 11 PDF on the European Commission EudraLex site.

Data integrity guidance: ALCOA and ALCOA+

• FDA (December 2018): the Q&A guidance on data integrity and CGMP defines complete, consistent and accurate data as attributable, legible, contemporaneously recorded, original or a true copy, and accurate (ALCOA). It says that when login credentials are shared a unique individual cannot be identified, that system administrator roles should go to people independent of those responsible for record content, and that backup under 21 CFR 211.68 means a true copy kept securely through the retention period, not a temporary crash-recovery copy.
• MHRA (March 2018, updated September 2021): the GXP data integrity guidance extends ALCOA with complete, consistent, enduring and available (ALCOA+) and states there is no difference in expectation between the two. Section 6.16 says shared logins or generic user access should not be used on systems that generate, amend or store GXP data, that administrator rights to delete data or change configuration should not go to people with a direct interest in the data, and that the generic administrator account should not be used for routine work.
• Audit trail review: FDA ties the review frequency to the frequency set for the underlying data, or to a documented risk assessment where none is set. MHRA accepts exception reporting and says logon and logoff events do not need routine review.

GAMP 5 and computer software assurance

ISPE GAMP 5 Second Edition (July 2022) is the industry method for validating computerised systems. It emphasises critical thinking by subject matter experts, iterative and incremental specification and verification, leveraging supplier documentation, and adds appendices on cloud, AI/ML, blockchain and open-source software. FDA's final guidance on Computer Software Assurance (September 2025, CDRH and CBER) applies a risk-based assurance approach to production and quality system software for medical devices under 21 CFR Part 820; many drug manufacturers use the same thinking, but the guidance itself is scoped to devices. Both support the security argument that low-risk changes such as monthly operating system patches deserve proportionate, not exhaustive, testing.

What is changing in the EU

The European Commission ran a stakeholder consultation from 7 July to 7 October 2025 on a revised GMP Chapter 4 (Documentation), a revised Annex 11 and a new Annex 22 (Artificial Intelligence), drafted by the EMA GMDP Inspectors Working Group with PIC/S. The draft Annex 11 strengthens lifecycle and quality risk management, supplier and service provider oversight, audit trails, electronic signatures and system security. The draft Annex 22 covers AI and machine learning models used in the manufacture of active substances and medicinal products: intended use, performance metrics, training and test data quality, change control, performance monitoring and human review. On 24 October 2026 the EudraLex Volume 4 page still listed Annex 11 at its January 2011 revision and did not list Annex 22. Plan for the drafts, but cite the 2011 text in procedures until the final versions and their application dates are published.

Validated systems and patching

The most common security exception in pharma is "the system is validated, so we cannot patch it". Annex 11 does not say that. It requires controlled change and periodic evaluation, and clause 11 explicitly lists security among the topics a periodic review may cover. The practical answer is a pre-qualified patch path.

• Agree categories with Quality first: a standard change procedure approved by QA, listing which patch types qualify, is what removes the per-patch argument.
• Ask suppliers for patch qualification: major CDS and instrument vendors publish lists of validated operating system updates. Make that a contract term (Annex 11 clause 3).
• Track known exploited vulnerabilities: prioritise anything in the CISA KEV catalog on GxP systems reachable from the business network. See the Patch Management Guide and the Vulnerability Management Guide.

Shared accounts, lab instruments and machine identities

This is where security and data integrity findings overlap most often, and where non-human identity thinking helps.

• Shared operator logins: instrument PCs often have one Windows account such as "LabUser" used by a whole shift. Under the FDA and MHRA guidance that breaks attribution. Fix it with individual domain accounts, fast user switching or badge tap login, and, where the instrument software supports only one login, a version-controlled logbook with increased review as MHRA describes.
• Local administrator on instrument PCs: analysts with local admin can change the system clock, delete result folders or disable audit trails. Remove it, rotate the local administrator password per device (for example with Windows LAPS), and keep administration with a role independent of data generation.
• Service accounts between systems: CDS to LIMS, LIMS to ERP, MES to historian and instrument data capture services all run under service accounts or API credentials. They write GxP data, so they need named owners, least privilege, no interactive logon and rotation. See the Service Account Security Guide.
• Vendor support accounts: instrument and automation vendors often hold standing remote access with a shared vendor login. Replace it with brokered, time-bound, recorded sessions per named engineer. See the Third-Party Access Guide.
• Generic administrator and break-glass: keep the built-in admin account sealed, use it only through a documented break-glass procedure, and review every use. See the Break-Glass Account Guide.
• AI models and agents: where a model drives a GMP decision, the draft Annex 22 expects defined intended use, test data and human review. Any service identity the model uses to read or write records is in scope of the same access controls.

Architecture: zones for a pharma site

Time synchronisation is often overlooked: Part 11 audit trails depend on accurate timestamps, so analysts must not be able to change the clock, and instrument PCs should take time from a controlled source. See the Network Segmentation Guide.

How to implement: a phased approach

1. Inventory and classify (weeks 1-6): build one register of GxP computerised systems (Annex 11 clause 4.3 already requires an up-to-date inventory) and add the security attributes: OS version, support status, accounts used, network zone, vendor access, backup method.
2. Agree the joint procedure with Quality: write the standard change procedure for patches and security tooling, the rule that security incidents affecting GxP systems are raised under Annex 11 clause 13, and the audit trail review approach.
3. Remove shared and generic accounts: start with systems that generate release data (CDS, LIMS, MES). Pilot individual logins on one lab, measure the effect on analyst workflow, then roll out by instrument type.
4. Segment and broker access: put instrument PCs and OT in their own zones, block direct internet access, route vendor sessions through a recorded jump host.
5. Protect the evidence: forward application audit trails and Windows security logs to a central store that system administrators cannot alter; test restore of a CDS project and a LIMS database from backup under change control.
6. Patch on cadence: run the pre-qualified path monthly, starting with a pilot ring of one system per type. Roll back by restoring the pre-change image or snapshot, which the change record must reference.
7. Exercise ransomware recovery: run a tabletop that includes QA: which batches cannot be released without the system, what manual fallback Annex 11 clause 16 provides, how data integrity is confirmed after restore. See the Ransomware Response and Recovery Guide.

Decision guidance

• Individual logins vs logbook controls: choose individual accounts whenever the software supports them, even if extra licences are needed (MHRA says this explicitly). Logbooks with enhanced review are a fallback for single-login systems, not a design choice.
• Patch vs isolate: patch where the vendor supports the update; isolate and allowlist where it does not, with a retirement date. Never leave an unsupported, unpatched system on a flat network.
• Central SIEM vs local audit trail: the application audit trail remains the GxP record; the SIEM copy is a security control. Both are needed because administrators of the application can often reach its local logs.
• Small sites and CDMOs: a small contract manufacturer may not run a SOC, but it can still remove shared logins, segment the lab, use a managed backup with restore testing and agree incident notification terms with sponsors. Large groups should standardise the patch procedure across sites so inspectors see one approach.

Detection and measurement

• Audit trail events to alert on: audit trail disabled or configuration changed, results deleted or reprocessed outside normal patterns, user accounts created on instrument software, system clock changes (Windows event ID 4616), and new local administrators (event ID 4732 for additions to a local security group).
• Account events: interactive logons by service accounts (event ID 4624 with the service account name and a logon type 2 or 10), failed logons on signature components (Part 11 section 11.300(d) expects attempted unauthorised use to be detected and reported).
• Network: any traffic from the instrument or OT zones to the internet, and new remote access sessions to OT outside the brokered path.

Common failure patterns

• Validation used as a reason not to patch: systems left on unsupported operating systems for years because no one owns the patch procedure. The 2017 NotPetya outbreak, which spread through the Ukrainian M.E.Doc accounting software update (ATT&CK T1195.002), disrupted Merck's manufacturing among many other companies; flat networks and unpatched Windows let it spread.
• One login per instrument: a shared "Analyst" account means no one can prove who ran or reprocessed a sample, and a stolen password gives access to every result on that PC.
• Administrators who also generate data: lab supervisors with admin rights to the CDS can delete or reprocess data with little chance of detection, which both MHRA and FDA warn against.
• Backups never restored: CDS projects backed up to a share on the same domain, encrypted with everything else, or restorable only to a software version no longer installed.
• Standing vendor access: always-on remote desktop or VPN accounts for instrument or automation vendors, shared between engineers, with no session recording (ATT&CK T1133 External Remote Services, T1078 Valid Accounts).
• Security incidents kept out of the quality system: a malware infection on a lab PC handled only by IT, with no assessment of whether GxP data was affected, leaves a gap an inspector will find.

Framework mapping

Practitioner checklist

• Add security attributes (OS support, accounts, zone, vendor access, backup) to the Annex 11 system inventory.
• Agree a QA-approved standard change procedure for OS patches and security agent updates on validated systems.
• Remove shared and generic user logins from every system that generates, amends or stores GxP data.
• Remove local administrator rights from analysts and give administration to a role independent of data generation.
• Inventory service accounts and API credentials between GxP systems, assign owners and block interactive logon.
• Place instrument PCs and manufacturing OT in separate zones with no direct internet access.
• Broker and record all vendor remote access per named engineer.
• Forward audit trails and security logs to a store administrators cannot alter, and alert on audit trail and clock changes.
• Test restore of critical GxP systems at least annually and record it under change control.
• Track the revised Annex 11 and Annex 22 and update procedures when final texts and dates are published.

Standards and references

• eCFR: 21 CFR Part 11, Electronic Records; Electronic Signatures
• European Commission: EudraLex Volume 4, Annex 11 Computerised Systems
• European Commission: Stakeholders consultation on GMP Chapter 4, Annex 11 and new Annex 22
• FDA: Data Integrity and Compliance With Drug CGMP, Questions and Answers
• MHRA: GXP Data Integrity Guidance and Definitions
• ISPE: GAMP 5 Guide, Second Edition
• FDA: Computer Software Assurance for Production and Quality System Software
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: OT Security Guide · IEC 62443 Guide · Software Supply Chain Security Guide · Service Account Security Guide · HITRUST CSF Guide. This guide summarises 21 CFR Part 11, EU GMP Annex 11 and related data integrity guidance and is not legal advice.