EU Annex 11 Revision: What Labs Need to Prepare (2026)
The draft revision published on 7 July 2025 is the most significant rewrite of Annex 11 since 2011 — expanding the guideline from 5 pages to 19, restructured into 17 chapters, and elevating computerised systems from supporting tools to GMP-controlled assets in their own right. For laboratories, four changes matter most: audit trails must now capture data creation, not only changes and deletions; audit trail review moves to a defined risk-based frequency; supplier and service management carries mandatory contract elements; and cybersecurity becomes a core GMP requirement with its own extensive chapter. A companion Annex 22 restricts AI in GMP-critical applications to static, deterministic models — explicitly excluding generative AI and large language models. The final text has not yet been published as of August 2026, and estimates for its arrival diverge. The gap assessment, however, should not wait. Where the revision actually stands Accuracy about status matters here, because a lot of published commentary states timelines with more confidence than the evidence supports. What is certain: On 7 July 2025, the European Commission published draft revisions to three interconnected parts of EudraLex Volume 4 — a comprehensive revision of Annex 11 (Computerised Systems), a brand-new Annex 22 (Artificial Intelligence), and an updated Chapter 4 (Documentation). The revision was drafted jointly with PIC/S. The public consultation closed on 7 October 2025. What is not certain: the publication date of the final text. Multiple sources published through mid-2026 anticipated the final version “mid-2026.” As of early August 2026 it has not appeared. One tracker notes that because the draft was released in July 2025 rather than the December 2024 originally scheduled in the EMA concept paper, implementation is now estimated for Q1 2027 — while also stating plainly that no renewed timetable has been published by EMA. The honest position is therefore: the final text is imminent but undated, and any article asserting a firm effective date is guessing. Since these are drafts, specific provisions may change before adoption — so treat the details below as the direction of travel rather than settled law, and verify against the final text when it lands. Anyone with EU market exposure should check the European Commission’s EudraLex Volume 4 pages directly for current status. That uncertainty is not a reason to wait. The consultation is closed, the direction is clear, and the remediation work most labs will need — audit trail reconfiguration, supplier contract renegotiation, security evidence — takes longer than the notice period will allow. Why the rewrite happened The current Annex 11 took effect on 30 June 2011, when it was itself a response to growing reliance on computerised systems. Fourteen years later, technological innovation has far outpaced those expectations. Cloud services, SaaS deployment models, machine learning, and a threat landscape that barely existed in 2011 all sat outside the guideline’s frame. The result is not a patch but a paradigm shift toward comprehensive digital governance, now explicitly covering all computerised systems including cloud services and AI/ML systems, with enhanced cybersecurity requirements. The draft is roughly four times the length of the version it replaces, organized into 17 chapters plus a glossary, built on eight overarching principles. The scope is broad and worth stating plainly for lab readers: any software touching a GMP, GDP or GLP process falls within it — ERP, LIMS, MES, batch release systems, temperature monitoring platforms. If your LIMS influences a batch outcome, a release decision, or a GMP record, Annex 11 applies to it. The changes that matter most for laboratories 1. Audit trails: creation events now in scope This is the change with the most immediate practical consequence for lab systems. Under the draft, audit trails must capture data creation events, not only changes and deletions. The draft devotes ten subsections to audit trails — a signal of how central they have become. Many LIMS and instrument systems were configured on the older assumption that logging modifications and deletions was sufficient. If yours was, this is a configuration gap that will need identifying, remediating, and revalidating. It is also, in our experience of what labs actually overlook, the single most likely place to find a gap. The draft also formalizes audit trail review frequency on a risk basis rather than leaving it to interpretation — reporting on the draft indicates monthly review for high-risk systems, quarterly for routine ones, and always before a batch release decision that the data supports. Labs that have treated audit trail review as an annual or ad-hoc exercise should expect to build a documented, recurring process. Our guides to ALCOA+ data integrity and 21 CFR Part 11 cover the underlying principles that both frameworks share. 2. Risk management across the full lifecycle Risk management remains the central pillar, but the emphasis shifts from broad guidance to a systemic, continuous approach across the entire system lifecycle. The draft acknowledges that risks are dynamic and requires proactive, documented, continuous assessment: at selection and design, through ongoing monitoring during operation, and in a final review when the system is taken out of use. That last point deserves attention because it is easy to miss — decommissioning is now part of the regulated lifecycle. Labs planning to replace a legacy system should build risk review into that project explicitly; our guide to migrating from one LIMS to another covers the surrounding data and retention obligations. 3. Supplier and service management with mandatory contract terms The draft introduces supplier and service management with nine mandatory contract elements. For laboratories running cloud or SaaS LIMS, this converts a commercial relationship into a documented compliance dependency. Practically, this means existing vendor agreements may need renegotiation, and vendor selection criteria should now include the supplier’s ability to evidence the controls the annex requires. Expect this to be one of the slowest remediation items, because it depends on a third party’s willingness and timeline, not only your own. 4. Cybersecurity as a core GMP requirement For the first time, cybersecurity is treated as a core GMP requirement rather than
ISO 17025 and LIMS: What Your Software Must Support
For testing and calibration laboratories seeking or maintaining accreditation, ISO/IEC 17025:2017 is the definitive benchmark. Published by the International Organization for Standardization, it sets out the requirements for competence, impartiality, and consistent operation that accreditation bodies — such as UKAS in the UK, A2LA in the US, and DAkkS in Germany — use to assess laboratories worldwide. What many lab managers underestimate is how deeply ISO 17025 shapes the functional requirements of a Laboratory Information Management System (LIMS). The standard does not mandate specific software, but its clauses on data integrity, traceability, document control, and measurement uncertainty translate directly into LIMS capabilities that your system must either provide natively or support through integration. This article maps the key ISO 17025 requirements to the LIMS features that satisfy them — giving you a clear framework for evaluating whether your current or prospective software is genuinely fit for purpose under accreditation. What ISO 17025 actually requires — and why software matters The 2017 revision of ISO 17025 introduced a more risk-based, process-oriented approach compared to its predecessor. It is organised around five major sections: general requirements, structural requirements, resource requirements, process requirements, and management system requirements. Software-relevant obligations appear throughout the standard, but cluster most heavily in: The standard explicitly addresses software in Clause 6.4.7, which requires that “software used for the collection, processing, recording, reporting, storage or retrieval of data” be validated for intended use. This single clause has significant implications: it means you cannot simply purchase any off-the-shelf LIMS and assume compliance. You must demonstrate, with documented evidence, that the software performs as required in your specific laboratory context. The full text of the standard is available from ISO.org. Accreditation bodies also publish their own interpretive guidance — the ILAC P10 policy on traceability is particularly relevant for laboratories managing calibration chains. The core LIMS requirements mapped to ISO 17025 clauses The table below maps the most software-relevant clauses of ISO 17025:2017 to the specific LIMS capabilities they demand. ISO 17025 clause Requirement LIMS must support 6.4.7 Software used for data handling must be validated for intended use Validation documentation (IQ/OQ/PQ), version-controlled releases, audit trail of software changes 6.6.2 Technical records must include original observations, derived data, and identification of the person responsible Immutable record creation, timestamped entries, user attribution on every record 6.6.3 Amendments to records must be traceable — who changed what, when, and why Full audit trail with before/after values, mandatory reason field for amendments 6.4.4 Equipment records including calibration status and calibration due dates Equipment register, calibration scheduling, automated alerts, integration with calibration certificates 6.5 Metrological traceability of measurements to SI units Traceability chain documentation, linkage of test results to certified reference materials and instrument calibration records 6.2 Method validation records and measurement uncertainty budgets Method and SOP library, structured uncertainty documentation linked to test results 6.7 Sampling records including date, sampler ID, environmental conditions Sample receipt, labelling, chain of custody, storage condition logging 8.3 Document control — current versions available, obsolete versions identified Version-controlled SOP/method library, document approval workflow, supersession management 8.7 Corrective action records linked to nonconformities Nonconformance management module or integration with quality management system 8.8 Internal audit records and management review inputs Audit scheduling, findings log, CAPA tracking Data integrity: the non-negotiable foundation Every ISO 17025 requirement around records ultimately rests on a single principle: data must be trustworthy. The standard aligns closely with the ALCOA+ framework widely used in pharmaceutical environments — data must be Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, and Available. For a LIMS to satisfy this, it must implement: Accreditation assessors will typically request a live demonstration of the audit trail during an on-site assessment. A LIMS that logs only top-level actions — “result approved” — without capturing field-level changes is unlikely to satisfy a rigorous assessor. Equipment and calibration management Clause 6.4 of ISO 17025 requires laboratories to maintain records for each piece of equipment significant to the results it produces. This is one of the areas where a LIMS provides the most tangible operational value — and where gaps are most commonly found during assessments. Your LIMS should provide or support: The ILAC G24 guideline on calibration intervals provides useful context for laboratories determining how to schedule and document calibration activities within their LIMS. Sample and chain of custody management Clause 6.7 of ISO 17025 sets out requirements for the handling, transport, storage, retention, and disposal of test items. For any laboratory receiving samples from external clients or handling samples with strict integrity requirements, the LIMS chain of custody capability is critical. Minimum requirements include: For laboratories handling biological samples, environmental samples, or materials with specific handling requirements, the LIMS should support conditional workflows — for example, flagging a sample for supervisor review if arrival conditions fall outside defined acceptance criteria, before any testing proceeds. Document control and method management ISO 17025 Clause 8.3 requires that the laboratory control documents — both internal and external — to ensure that only current, approved versions are in use. In practice, this means the LIMS must either include a document management module or integrate reliably with a Quality Management System (QMS) that provides this functionality. Key capabilities: Assessor focus During ISO 17025 assessments, document control is one of the most frequently cited areas of nonconformance. Assessors will verify that the version of a method referenced in a test record matches what was actually approved and available at the date of testing. Software validation: what “validated for intended use” means in practice Clause 6.4.7’s requirement for software validation is not prescriptive about how validation must be conducted, but accreditation bodies expect documented evidence of a structured approach. The GAMP 5 framework from ISPE — widely used in pharmaceutical environments — provides a practical and widely accepted methodology that is increasingly referenced in ISO 17025 laboratory contexts as well. At minimum, your LIMS validation documentation should include: Many LIMS vendors provide partial validation packages — typically IQ/OQ — for their standard software. However, PQ documentation must reflect your
FAIR Data Principles for Laboratories: A Practical Guide
This article is based on the original FAIR Guiding Principles published in Nature Scientific Data (Wilkinson et al., 2016), the GO FAIR Initiative framework, and the NIH Data Management and Sharing Policy (effective January 2023). It is for informational purposes only. What Are the FAIR Data Principles? FAIR stands for Findable, Accessible, Interoperable, and Reusable. Originally published in 2016 in the journal Scientific Data (Nature Publishing Group) by an international group of researchers representing academia, industry, funding agencies, and publishers, the FAIR Guiding Principles define a minimum standard for scientific data management and stewardship that enables data to be effectively discovered, accessed, and reused — by both humans and machines. The distinction between human and machine readability is deliberate and important. As the original authors noted, laboratories increasingly rely on computational systems to handle data at a scale, speed, and volume that exceeds what any human team can manage manually. A dataset that is findable by a researcher browsing a repository is not necessarily findable by an AI model or an automated pipeline. FAIR addresses both simultaneously. Since their publication, the principles have moved from academic guideline to regulatory expectation. The NIH Data Management and Sharing Policy (effective January 25, 2023) explicitly references FAIR as the framework guiding its requirements, making FAIR compliance a practical necessity for any laboratory receiving NIH funding. The European Commission’s Horizon Europe research programme applies FAIR standards by default to all funded research output. For regulated environments, FAIR principles align closely with ALCOA+ data integrity requirements and with the data governance expectations of 21 CFR Part 11 and EU GMP Annex 11. The Four Principles: What Each Means in Your Laboratory Each FAIR principle translates differently depending on whether your laboratory is primarily a research environment, a regulated QC lab, or a clinical or industrial setting. The following cards map each principle to concrete laboratory practice. F — Findable Data and metadata must be easy to locate for both humans and computational systems, using unique persistent identifiers and rich, machine-readable metadata registered in searchable resources.In the lab: Every experiment record, sample, and dataset is assigned a unique identifier (sample ID, assay ID, project code) that follows a consistent, documented naming convention across the lab. No record exists only as a file named “data_final_v3.xlsx” in a shared drive.In LIMS/ELN: LIMS and ELN platforms assign system-generated unique identifiers to every record automatically. These IDs persist even if records are archived or the system is migrated. Metadata schemas (who collected it, when, with which instrument, under which protocol version) are defined at the system level and enforced at the point of entry.Common gap: Data stored in files on personal drives or lab servers with inconsistent naming — common in labs without a LIMS — is effectively invisible to anyone who was not present when the file was created. A — Accessible Once found, data must be retrievable using a standardised, open communications protocol, with clear rules about authentication and authorisation. Metadata must remain accessible even if the data itself is no longer available.In the lab: Archived data from completed projects remains retrievable through a defined procedure (not “ask the person who left the lab”). Access control is documented: who can read, who can edit, who can delete. Data deposited in a repository has a persistent URL that does not break when lab websites change.In LIMS/ELN: Role-based access controls in LIMS ensure that every user’s access permissions are defined and logged. When records are archived, the metadata (when the experiment was run, by whom, under which conditions) remains searchable even if the raw data files are moved to cold storage. Cloud-based LIMS avoid the single-point-of-failure problem of a local server.Common gap: Data that lives exclusively on a departing researcher’s laptop, or in a proprietary system with no export capability, fails the Accessible principle entirely. “Accessible on request by email” does not meet the FAIR standard for publicly funded research. I — Interoperable Data must use formal, shared, broadly applicable languages and vocabularies for knowledge representation, enabling integration across different datasets, systems, and workflows.In the lab: Assay results are recorded using standardized units (SI where possible), controlled vocabularies (e.g., SNOMED, ChEBI for chemical entities, NCBI taxonomy for organisms), and open file formats (CSV, JSON, mzML for mass spectrometry) rather than proprietary formats readable only by one instrument’s software.In LIMS/ELN: Modern LIMS platforms support ontology-based metadata (ISA-TAB, MIAME standards), API-based data exchange with instruments and external systems, and export in standard formats. Instrument integration that pushes results directly into the LIMS in a structured format is the operational definition of interoperability for most QC labs.Common gap: Instrument data locked in proprietary software formats, result tables recorded in manually formatted Excel spreadsheets with inconsistent column names across users, or lab-specific abbreviations with no controlled vocabulary — these are the most common interoperability failures in practice. R — Reusable Data must be sufficiently described and documented so that it can be replicated and combined in different settings, with clear provenance, licensing, and domain-relevant community standards.In the lab: A dataset from three years ago can be understood and used by someone who was not part of the original experiment, because every record captures who performed it, with which reagents (lot numbers, expiry dates), with which instrument (model, calibration date), under which protocol version, and under what environmental conditions.In LIMS/ELN: ELN templates enforce the capture of complete experimental context at the time of recording — not as an optional field to fill in later. LIMS workflow definitions link results to the specific method version, sample preparation steps, and instrument configuration used. Change control processes version-control protocol documents so that historical data can always be matched to the exact procedure that generated it.Common gap: The most common reusability failure is “I can find the data but I cannot interpret it without talking to the person who ran it.” This happens when experimental context (reagent lots, protocol versions, instrument settings) is not captured in the record alongside the results. Why FAIR Matters for Your Laboratory Right
What is ALCOA+? Data Integrity in Laboratory Environments
This article is based on official regulatory sources: FDA’s 2018 Data Integrity and CGMP guidance, PIC/S PI 041, EMA’s 2010 Reflection Paper, MHRA’s GxP Data Integrity guidance, and WHO TRS Annex 5. It is for informational purposes only and does not constitute regulatory or legal advice. What Is ALCOA+? ALCOA+ is the universally recognized data integrity framework used in pharmaceutical, biotech, clinical, and laboratory environments regulated by the FDA, EMA, MHRA, WHO, and PIC/S. It defines the minimum quality attributes that every laboratory record — whether written on paper or generated by a LIMS, ELN, or instrument — must satisfy to be considered trustworthy and compliant. ALCOA stands for Attributable, Legible, Contemporaneous, Original, and Accurate. The original five attributes were introduced in the early 1990s by FDA compliance expert Dr. Stan Woollen as a training tool for GLP inspectors. In 2010, the European Medicines Agency (EMA) formally extended the framework by adding four qualities — Complete, Consistent, Enduring, and Available — creating ALCOA+. Today, ALCOA+ is referenced explicitly or implicitly in every major data integrity regulatory document globally: FDA’s CGMP guidance (21 CFR Parts 211 and 11), PIC/S PI 041, MHRA’s GxP Data Integrity Guide, WHO TRS Annex 5, and EU GMP Annex 11. It applies equally to paper systems and fully digital laboratory environments. ALCOA+ and 21 CFR Part 11 are complementary, not interchangeable. Part 11 defines the technical controls an electronic system must implement (audit trails, e-signatures, access controls). ALCOA+ defines the quality standard that every record — regardless of system — must achieve. A technically Part 11-compliant LIMS can still generate ALCOA+-non-compliant records if organizational processes are inadequate. The 9 ALCOA+ Attributes: What Each Means in Practice Each attribute is both a documentation standard and a practical compliance checkpoint. Regulators use them as the lens through which they evaluate records during inspections, Form 483 observations, and warning letter investigations. A — Attributable Regulatory anchor: 21 CFR 211.194(a) — initials/signatures required; EU GMP Annex 11 §12.4 — operator identity must be recordedPaper: Analyst initials and date on every manual entry; no blank lines in batch recordsElectronic: Unique user login in LIMS/ELN — system captures user ID and timestamp automatically; no shared accountsCommon violation: Shared login credentials (e.g., ‘lab1’ / ‘admin’) — one of the most common FDA 483 findings L — Legible Regulatory anchor: 21 CFR 211.180 — records legible and readily available; EU GMP Annex 11 §8.1 — human-readable throughout lifecyclePaper: Ink entries (not pencil), no overwriting; crossed-out errors signed and dated, original value still visibleElectronic: LIMS records displayed and exported in consistent, readable format across systems; font and encoding preservedCommon violation: Pencil entries, illegible handwriting, whiteout over errors — any of these can invalidate a record during inspection C — Contemporaneous Regulatory anchor: 21 CFR 211.100(b) — each step documented at the time performed; PIC/S PI-041 — contemporaneous recording is a critical ALCOA principlePaper: pH recorded directly onto the batch record during in-process testing, not transcribed later from a scrap noteElectronic: Instrument data auto-captured into LIMS with system timestamp at point of generation; no retroactive entryCommon violation: Backdating entries, recording results from memory after the fact, or pre-recording anticipated results O — Original Regulatory anchor: 21 CFR 211.194 — original record or true certified copy; FDA Data Integrity Q&A 2018 — ‘first capture of information’Paper: The handwritten batch record page is the original; a photocopy used as working document must be marked ‘true copy’ and verifiedElectronic: Raw instrument data file is the original; a PDF export is a secondary copy — both must be retained; data migration must preserve originalsCommon violation: Deleting raw chromatography files after generating a report, or presenting a printout as the original when the electronic record exists A — Accurate Regulatory anchor: 21 CFR 211.68 — automated systems must produce accurate results; FDA Data Integrity guidance: ‘data should reflect what actually occurred’Paper: Results transcribed exactly from instrument printout; calculations verified independently before entryElectronic: Instrument integration directly into LIMS eliminates manual transcription; validated calculation routines auditable in systemCommon violation: Entering assumed or expected values instead of actual measurements; selective reporting that omits out-of-specification results The ‘+’ Attributes — Added by EMA (2010) and adopted by PIC/S, MHRA, WHO The four ‘+’ attributes extend ALCOA from a point-in-time quality check to a lifecycle quality standard. They address what happens to a record after it is created — through its entire retention period. C+ — Complete Regulatory anchor: PIC/S PI-041 §7 — complete records include all raw data, metadata, and audit trails; FDA: ‘all data, including repeats and rejects’Paper: Batch record includes all in-process checks including failed ones; no pages removed or left blank without explanationElectronic: LIMS retains all instrument runs including failed sequences; audit trail captures all attempts, not just the final accepted resultCommon violation: Deleting or hiding failed test runs from the record; presenting only passing results to auditors C+ — Consistent Regulatory anchor: PIC/S PI-041 — data must be internally coherent and follow an expected, documented sequencePaper: Logbook entries in chronological order with no gaps; dates and times consistent across related documentsElectronic: LIMS timestamps synchronized to a validated, locked time server; no ability for users to manually override system timeCommon violation: Timestamps in audit trails that precede the login event; logbook entries that are out of sequence or have unexplained time gaps E — Enduring Regulatory anchor: 21 CFR 211.180(a) — records retained for required period; PIC/S PI-041 — records must remain accessible for their entire lifecyclePaper: Batch records stored in controlled, fire-proof archive for defined retention period (typically 1 year post-expiry or 5+ years)Electronic: LIMS/ELN data backed up with verified restore procedures; vendor contract includes post-subscription data portability clauseCommon violation: Data stored on obsolete media (CDs, old proprietary formats) that cannot be read; cloud subscription ends without data export plan A+ — Available Regulatory anchor: 21 CFR 211.180(c) — records readily available for inspection; EU GMP Annex 11 §17 — available during entire retention periodPaper: Archived paper records indexed and retrievable within a defined timeframe; location documented in SOPElectronic: LIMS
What is 21 CFR Part 11?
A Practical Guide for Lab Software in 2026 This guide is based on the official 21 CFR Part 11 regulatory text (eCFR), FDA’s Scope and Application Guidance (2003), FDA’s final Electronic Systems Q&A guidance (October 2024), and the finalized Computer Software Assurance (CSA) guidance (September 2025). It is for informational purposes and does not constitute legal or regulatory advice. What Is 21 CFR Part 11? 21 CFR Part 11 is the section of Title 21 of the United States Code of Federal Regulations that governs electronic records and electronic signatures in FDA-regulated environments. Published in final form in March 1997 and effective from August 1997, it establishes the criteria under which the FDA considers electronic records and electronic signatures to be trustworthy, reliable, and legally equivalent to paper records and handwritten signatures. In plain terms: if your laboratory is regulated by the FDA and you use software to create, manage, or store records that the FDA requires you to keep, those records and any digital signatures associated with them must meet Part 11’s requirements. Non-compliance exposes your organization to FDA observations, warning letters, and — in serious cases — injunctions or import bans. The full regulatory text is available at: eCFR.gov — 21 CFR Part 11 Who Does 21 CFR Part 11 Apply To? Part 11 applies to any organization regulated by the FDA that uses electronic systems to fulfill regulatory record-keeping or submission requirements. This includes: The key concept is the “predicate rule”: Part 11 activates when electronic records replace paper records that would otherwise be required by another FDA regulation — called the predicate rule. For example, 21 CFR Part 211 (pharmaceutical cGMP) requires certain manufacturing records. If those records are stored electronically, Part 11 governs how they are created, secured, and signed. Important: Part 11 does not apply to paper records. If your organization maintains authorized paper copies as the official record and only uses electronic systems for convenience (not as the authoritative record), Part 11’s scope may not fully apply. However, any system controlling a regulated process — even if it doesn’t store the authoritative record — may still require validation under predicate rules such as 21 CFR 820.70(i). The Core Requirements of 21 CFR Part 11 Part 11 is organized into two subparts that cover electronic records (Subpart B, §11.10) and electronic signatures (Subpart C, §§11.100–11.300). The table below summarizes every key requirement from the official regulatory text. Section Requirement What It Means in Practice §11.10(a) System validation Software must be validated to ensure accuracy, reliability, consistent performance, and ability to detect altered records §11.10(b) Accurate copies Ability to generate exact, human-readable and electronic copies for inspection §11.10(c) Record retention Records remain accessible and accurate throughout the required retention period §11.10(d) Audit trails Secure, computer-generated, time-stamped audit trails recording all creation, modification, and deletion — cannot be edited §11.10(e) Sequence controls System controls ensuring only authorized sequences of steps are executed §11.10(f) Authority checks System confirms user is authorized to perform the specific action before executing §11.10(g) Device checks Valid inputs at all entry points to ensure data integrity §11.10(h) Training Personnel trained to understand the development and use of computerized systems under their responsibility §11.10(i) Accountability Written policies covering sign-off responsibilities, training, and system protection consequences §11.10(j) Documentation System documentation: development, maintenance history, and change control records §11.50 Signed records Electronic records containing: the signature, meaning of signature, date and time — all permanently linked to the record §11.100 Signature uniqueness Each electronic signature unique to one individual, never reused or reassigned to another §11.200 Signature components Non-biometric signatures require at least two components (e.g., username + password); biometric signatures require unique biometric data §11.300 Safeguards Controls including unique combinations, periodic checks, forced password changes, loss management, and use by authorized holders only Source: eCFR — 21 CFR Part 11 (official text) Closed Systems vs Open Systems One of the most practically important distinctions in Part 11 is between closed and open systems, because the two have different compliance requirements. Closed system (§11.3(b)(4)): an environment in which system access is controlled by persons responsible for the content of electronic records. Most LIMS, ELN, and laboratory software platforms deployed under the vendor’s cloud infrastructure are closed systems — access is controlled by the vendor and the customer organization, not available to arbitrary external parties. Open system (§11.3(b)(9)): an environment in which system access is not controlled by the persons responsible for the content, such as public internet-facing systems or shared external data repositories. Open systems require all the closed-system controls plus additional measures including encryption and digital signatures to ensure record authenticity and confidentiality. In practice, virtually all commercial LIMS and ELN platforms operate as closed systems. When evaluating vendor Part 11 claims, confirm they are specifically addressing the closed-system requirements of §11.10 — not just making a general ‘Part 11 compliant’ claim. What 21 CFR Part 11 Means for LIMS and ELN Software For laboratories evaluating LIMS and ELN platforms, Part 11 translates into a concrete checklist of capabilities that the software must support and that the organization must implement correctly. Vendor claims and actual validated compliance are not the same thing. 1. System Validation The software must be validated for its intended use. Validation demonstrates that the system reliably does what it claims to do: accurately captures data, correctly controls access, preserves audit trails, and maintains record integrity. Validation is documented in an Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) — collectively called IQ/OQ/PQ. Reputable LIMS and ELN vendors provide validation documentation packages (VDPs) to support this process, but the validation itself must be performed and owned by your organization. Note on CSA (September 2025): The FDA’s finalized Computer Software Assurance (CSA) guidance — published September 24, 2025 — replaces the previous rigid documentation-heavy validation approach with a risk-based framework. Organizations can now focus validation effort on software functions that directly impact record integrity and product quality, rather than testing everything uniformly. Read the FDA CSA Guidance. 2. Audit
ELN Compliance and Data Integrity: A Practical Guide for Regulated Labs
Quick verdict: An electronic lab notebook is not compliant or non-compliant by itself. It becomes a compliance question the moment it holds records that a regulation requires you to keep: GLP study data, GMP development records, clinical investigation data. From that point, the ELN must meet the same expectations as any other GxP computerised system: validation for intended use, attributable and secure audit trails, controlled electronic signatures, and records that stay complete and readable for the full retention period. In research-only labs the drivers are different (IP, reproducibility, funder data policies), but the same controls are what make notebook records credible. When compliance applies to an ELN Most ELN compliance confusion comes from mixing two situations. 1. The ELN holds regulated records. Examples: a GLP test facility documenting a nonclinical safety study, a pharma development group producing data that will support a GMP filing, a lab generating data for a clinical investigation. Here the regulations apply directly: 2. The ELN is used for research that is not regulated. No GxP regulation applies, but three pressures remain: proving inventorship and dates for patents, reproducing results, and meeting funder or journal data policies. The NIH Data Management and Sharing Policy, in force since January 2023, is one example. Many organizations have both situations in one ELN. In that case, define in your procedures which projects or notebooks are regulated, and apply validated controls to those at minimum. Data integrity: what ALCOA+ means inside a notebook Regulators assess electronic records against the ALCOA+ principles: attributable, legible, contemporaneous, original, accurate, plus complete, consistent, enduring and available. Our ALCOA+ guide covers the framework. In an ELN, each principle turns into specific, testable behaviour: Principle What it means in an ELN What to check Attributable Every entry and change is linked to one named user No shared accounts; audit trail records user, date, time Legible Records readable for the full retention period Export formats, long-term readability of attachments Contemporaneous Data recorded when the work is done Server-side time stamps; clock synchronization; no editable entry dates Original The first capture of data is kept, or a verified true copy Raw instrument files attached, not only screenshots or retyped values Accurate Calculations and transcriptions are correct Validated templates and calculations; locked formulas Complete Nothing deleted or hidden, including metadata Deleted or abandoned experiments remain traceable Enduring and available Records survive system changes and can be retrieved for inspection Backup, archiving, vendor exit terms The technical controls that matter most Audit trails Part 11 §11.10(e) requires secure, computer-generated, time-stamped audit trails that record the date and time of operator entries and actions, without obscuring previously recorded information. GLP rules go further: 21 CFR 58.130(e) also requires the reason for each change. In practice, a usable ELN audit trail shows the old value, the new value, who changed it, when, and why. Two common weak points: Recording changes is only half of the requirement. The FDA’s data integrity Q&A and the draft Annex 11 revision both expect audit trails for critical data to be reviewed, at a risk-based frequency. Electronic signatures and witnessing Part 11 requires signatures to show the signer’s printed name, the date and time, and the meaning of the signature, such as authorship, review or approval (§11.50), and to be permanently linked to the record (§11.70). In an ELN, check: Access control Role-based permissions should prevent users from altering others’ entries, disabling audit trails, or changing system settings. Administrator rights should sit with people who do not generate the data they could modify. Templates and calculations Templates bring structure to ELN data, and they are also where errors spread. A calculation built into a template used by 40 scientists is a validated function, not a convenience. Lock formulas, version templates, and test critical calculations as part of validation. Records, copies and exports MHRA’s guidance distinguishes static records from dynamic records, where the user can reprocess or interact with data. A PDF export of a notebook page is a static copy: it can lose metadata, audit trail and the ability to re-examine the original data. Before relying on exports for archiving or for sharing with partners, confirm they qualify as complete, true copies for your purpose. Validation of an ELN An ELN that holds regulated records must be validated for its intended use, like a LIMS. The approach is the same risk-based lifecycle described in our LIMS validation guide: requirements, supplier assessment, risk assessment, testing proportionate to risk, and ongoing change control and periodic review. ELNs differ from LIMS in where the risk sits. A LIMS concentrates risk in workflows, specifications and result approval. An ELN concentrates it in: Cloud ELNs Most ELNs sold today are cloud or SaaS products. Regulators accept this, provided the lab keeps control. The OECD’s 2023 supplement on GLP and cloud computing states the principle clearly: test facility management keeps responsibility for GLP compliance even when operations are outsourced. In practice, the service agreement should cover roles and responsibilities, data location, security, backup and disaster recovery, change control, and your right to obtain all data and metadata, including audit trails, in a readable format when the contract ends. For the deployment choice itself, see cloud vs on-premise ELN. Common compliance gaps in ELN deployments What to ask ELN vendors Our how to choose an ELN checklist covers the non-compliance criteria, and ELN vs LIMS explains when a notebook is the wrong tool for regulated testing. Frequently asked questions Does every ELN need to be validated?Only when it holds records required by GxP regulations or supports accredited results. A research-only ELN has no validation obligation, although verifying templates and calculations is still good practice. Can a cloud ELN be used in a GLP or GMP environment?Yes, if the lab assesses the provider, defines responsibilities in the service agreement, validates the system for its intended use and keeps the ability to retrieve complete records. Are ELN electronic signatures legally equivalent to handwritten ones?For FDA-regulated records, Part 11 sets the conditions under which electronic signatures
LIMS Validation Explained: A Risk-Based Guide for Regulated Labs
Quick verdict: Validating a LIMS means producing documented evidence that your configured system, as your lab uses it, does what it is supposed to do and protects the integrity of your data. It is required wherever the LIMS holds regulated records: GMP, GLP, clinical or ISO/IEC 17025-accredited testing. The vendor can make it much easier, but cannot do it for you. The modern expectation is not more paperwork: regulators and industry guidance (GAMP 5 Second Edition, FDA’s Computer Software Assurance guidance) push towards risk-based effort: deep testing where errors would affect product quality, patient safety or reported results, and lighter assurance everywhere else. What LIMS validation is, and what it is not Validation answers one question: is this system fit for its intended use in this lab? Three consequences follow, and they are where most misunderstandings start. Terminology varies: pharma traditionally says computerized system validation (CSV), device manufacturers increasingly say computer software assurance (CSA), and ISO/IEC 17025 simply requires the system to be “validated for functionality”. The underlying idea is the same. Which rules require it Framework Applies to What it requires of a LIMS FDA 21 CFR Part 11 Electronic records required by FDA regulations §11.10(a): validation of systems to ensure accuracy, reliability, consistent intended performance and the ability to discern invalid or altered records; plus audit trails, access and authority checks FDA Data Integrity Q&A (2018) Drug CGMP Expects validated systems, controlled access and review of audit trails for critical data EU GMP Annex 11 (revision drafted July 2025) EU GMP manufacturers Treats computerised systems as GMP-controlled assets: risk-based validation, supplier contracts, audit trail review, periodic review, cybersecurity MHRA GxP Data Integrity Guidance (2018) UK GxP organizations Systems validated for intended purpose; oversight of IT and cloud service providers ISO/IEC 17025:2017, clause 7.11 Accredited testing and calibration labs Information management systems “validated for functionality”; configuration changes authorized and validated before use; external providers checked FDA CSA guidance (final Sept 2025, revised Feb 2026) Medical device production and quality management system software Risk-based assurance proportionate to process risk; less scripted testing for lower-risk functions Two nuances worth stating plainly: For the underlying record-keeping rules, see our guides to 21 CFR Part 11, ALCOA+ and ISO 17025 and LIMS. The risk-based approach in practice The most widely used framework is ISPE’s GAMP 5, whose Second Edition (2022) puts critical thinking at the centre: subject-matter experts decide where assurance effort is needed, instead of applying the same depth of testing everywhere. Start by classifying what you are validating. GAMP 5 describes software categories, now used as one input among others in the risk assessment: Then assess risk function by function. For each requirement, ask what happens if it fails: could a wrong result be reported, a batch released, a sample misidentified, or a record altered without trace? High-impact functions such as result calculations, specification checks, approvals and e-signatures, audit trails, instrument interfaces and certificate of analysis generation get detailed, documented testing. Low-impact functions such as cosmetic screens or convenience features can rely on vendor testing and lighter verification. Leverage the supplier. Both GAMP 5 and CSA encourage using supplier documentation and test evidence rather than repeating work, provided you have assessed the supplier’s quality system. That assessment is itself part of your validation file. The validation lifecycle, step by step Classic IQ/OQ/PQ terminology still appears in many validation plans and remains acceptable; what matters is that the evidence is proportionate to risk and traceable to requirements. Cloud and SaaS LIMS: what changes A cloud LIMS does not remove validation, it redistributes responsibility. If you are still choosing a deployment model, our LIMS pricing benchmark and how to choose a LIMS checklist cover the commercial side. Common mistakes (and how to avoid them) What to ask vendors about validation Validation effort is a large part of implementation time: our LIMS implementation timeline guide shows how regulated projects extend schedules, and our pharmaceutical QC LIMS guide compares how much validation support vendors offer. Frequently asked questions Is LIMS validation required for every lab?It is required when the LIMS holds records subject to GxP regulations or supports ISO/IEC 17025-accredited results. A non-regulated research lab has no legal obligation, although verifying calculations and data transfers remains good practice. Can the vendor validate the LIMS for us?The vendor can provide documentation, test evidence and services that reduce your effort. Responsibility for validating the system for your intended use stays with your organization. Is a cloud LIMS easier to validate?It removes infrastructure qualification from your scope, but adds supplier oversight and the need to assess frequent vendor releases. Does CSA replace CSV for pharma labs?Not formally. FDA’s CSA guidance covers medical device production and quality system software. Its risk-based principles align with GAMP 5 Second Edition, which pharma and biotech organizations widely use. How often should a validated LIMS be reviewed?There is no universal interval. Set a risk-based periodic review frequency in your procedures (higher for systems with critical GMP data) and assess every change under change control in between. The bottom line LIMS validation is a risk-based discipline that proves your configured system works for its intended use and keeps proving it as the system changes. Put your effort where errors would matter, use your supplier’s evidence where you have assessed it, and treat change control, audit trail review and periodic review as part of running the system, rather than as paperwork after go-live. This article is independent editorial content and does not replace regulatory advice for your specific context. No vendor paid for inclusion. Read how we review lab software. Sources