GLP Audit Trails: A Guide to Compliant File Systems

Good Laboratory Practice (GLP) represents a foundational quality framework in the life sciences, ensuring that non-clinical laboratory studies generate reliable, reproducible data for health and environmental safety decisions (^[14]) (^[12]). Unlike manufacturing-focused regulations (GMP) where multiple data points support a final product, in GLP the data itself are the product. In GLP-regulated studies, every procedure, observation, and measurement must be thoroughly documented. As a 2024 GLP overview notes, GLP is “less about what you found and more about proving how you found it — cleanly, consistently, and under independent QA oversight” (^[15]). This emphasis on transparency places strict requirements on laboratory data systems: they must capture all raw data contemporaneously, and preserve them “complete, attributable, and enduring” for years (^[16]) (^[11]).

Modern GLP data management may use digital systems alongside, or instead of, paper records. Historically, GLP compliance relied on bound notebooks, paper forms, and manual archiving. Today, electronic lab notebooks (ELNs), laboratory information management systems (LIMS), analytical instruments, and general-purpose servers capture volumes of digital data. While digital records can improve accessibility and efficiency, they also create data-integrity risks from accidental or unauthorized alteration. Applicable predicate rules require records to be maintained reliably; controls, including audit trails where appropriate, should be selected through a justified and documented risk assessment rather than on the assumption that every electronic-record change requires the same trail (^[17], OECD GLP Data Integrity Advisory Document No. 22).

This report focuses on the intersection of GLP requirements and IT architecture, specifically file systems and network shares designed to support compliant audit trails. It explores how file storage can support GLP through risk-appropriate controls for record integrity and retention, strong access controls, and audit trails for the documented set of relevant records and actions. We examine regulatory guidance like FDA 21 CFR Part 58 (US GLP) and OECD GLP Principles (^[18]) (^[3]), identify technical features for auditable storage (WORM, encryption, versioning) (^[19]) (^[20]), and survey available technologies (NAS appliances, object stores, clustering) that laboratories can use. We include detailed analysis, data, and case examples to illustrate best practices. By the end of this report, readers will understand both why GLP mandates stringent audit trail capabilities and how to implement them in practice across a range of storage platforms and networked environments.

GLP compliance is codified differently across regions but shares common principles. In the United States, 21 CFR Part 58 defines GLP for nonclinical laboratory studies supporting FDA submissions (^[21]). In Europe and other OECD member countries, the OECD Principles of Good Laboratory Practice (first issued 1998) serve as the harmonized standard. Both regulations require that CPUs (computerized systems) used in GLP studies maintain “a record of all original observations, instrument readings, or activities that are relevant to the study” (^[3]). Key elements include a responsible Study Director, an independent Quality Assurance Unit (QAU), controlled SOPs and protocols, and controls that preserve raw data and enable reconstruction of relevant activities. For electronic records subject to applicable requirements, audit trails and other controls should prevent or make changes and deletions detectable, based on documented risk assessment (^[2]). In practice, this means every piece of raw data must be attributable to a source, recorded contemporaneously, and preserved in its original form (^[5]) (^[12]).

International guidance has increasingly emphasized data integrity under GLP. The OECD’s 2021 GLP Data Integrity guidance (No. 22) promotes a risk-based approach to data lifecycle management (^[22]). It urges test facilities to map data flows and apply stronger security controls where data are “critical”. Building on this, the OECD published Position Paper No. 25 on Good Laboratory Practice and IT Security in December 2024, addressing evolving cyber threats to GLP data and stressing that test facilities bear ultimate responsibility for IT security even when outsourcing to service providers (^[4]). Similarly, the UK MHRA’s GxP Data Integrity guidance (2018, updated 2021) outlines “core elements of a compliant data governance system” across GxP systems (^[23]). These include preventing unauthorized data modification, ensuring GED (good documentation practice) and ALCOA+ (Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete/Consistent/Enduring/Available) data (^[16]) (^[12]). In fact, one industry glossarist observes: “ALCOA+ [in GLP] is evidenced by immutable audit trails and durable archives” (^[12]).

In parallel, FDA guidance (21 CFR Part 11) and EU GMP Annex 11 impose computerized system requirements that overlap with GLP. 21 CFR Part 11 applies to electronic records required by applicable FDA predicate rules when they are maintained electronically in place of paper, to certain electronic records relied on for regulated activities, and to electronic records submitted to FDA. Test facilities should identify the applicable predicate rules and document the system's intended use and Part 11 applicability rather than assume that Part 11 automatically governs every computerized GLP record (^[17]). Section 11.10, for example, mandates that software used in regulated environments include audit trails that “independently record the date and time of operator entries and actions that create, modify, or delete electronic records” (^[16]). FDA’s current Computer Software Assurance (CSA) guidance was issued in February 2026 and supersedes the September 24, 2025 final guidance. Its stated scope is computer software assurance for production and quality-management-system software used in medical-device manufacturing; it should not be presented as GLP guidance without a study- and system-specific basis (^[24]). Additionally, in July 2025, the European Commission released a major draft revision of EU GMP Annex 11 (alongside updates to Chapter 4 and a new Annex 22), more than tripling the document's size from 5 to 19 pages. The 2025 draft mandates ALCOA++ principles, explicitly addresses cloud infrastructure, artificial intelligence, and digital service providers, and strengthens requirements for data integrity and lifecycle management of computerized systems (^[25]). The final version is expected by mid-2026 and will significantly impact GLP-adjacent compliance strategies. Organizations thus aim to adopt one coherent approach to data integrity across GLP and GxP more broadly, reinforcing that no record “can change without trace” or its reliability is lost (^[16]).

In summary, GLP regulations and related guidance consistently demand:

• Comprehensive audit trails: Automated, secure logs that record user identity, timestamp, and action for every data event (^[5]) (^[26]).
• Data retention and archiving: Preservation of raw data and archives for the retention period required by the applicable jurisdiction and study. In U.S. FDA GLP, 21 CFR 58.195 ties retention to the relevant research or marketing-permit timeline, or to study completion where no marketing permit is filed; it does not set a universal 10–15-year period (^[27]).
• Controlled access: Strict user authentication, authorization, and change control (e.g. SOP approvals) to prevent unauthorized alterations (^[9]) (^[12]).
• Integrity and traceability: Data must remain intact (unaltered) and readily reconstructable from the audit trail if needed (^[16]) (^[3]).

Meeting these requirements in an electronic computing environment is non-trivial, particularly as data volumes grow and systems become distributed. The next sections delve into how technology—specifically, storage file systems and network shares—can be architected to satisfy these GLP mandates.

An audit trail is a secure record of specified actions affecting electronic records or system configuration. The actions and detail it must capture—including identity, date and time, action, and any required reason for change—depend on the applicable predicate rules, the record’s intended use, and a justified, documented risk assessment. FDA states that audit trails or other appropriate measures may be needed to ensure trustworthy, reliable records, particularly where users create, modify, or delete regulated records during normal operation (^[17]). For electronic records subject to applicable predicate rules, a validated system and its procedures should provide audit trails or other appropriate controls, based on documented risk assessment, to maintain reliable records:

• Automated Capture: For electronic records subject to applicable predicate rules, the validated system should automatically capture the documented, risk-based set of actions needed to maintain reliable records. The required scope depends on the record, intended use, and applicable requirements; manual logs alone should not substitute for controls needed to preserve record reliability.
• Secure and Tamper-Evident: Audit trails should be protected by validated controls so that changes or deletions are prevented or detectable. Depending on the documented risk assessment and system design, these controls can include restricted administrative access, append-only logging, integrity monitoring, and retention locking; WORM is one possible control, not a universal GLP requirement (^[2]).
• Timestamped (Contemporaneous): Each audit entry includes an accurate date/time stamp from a controlled clock. The clock itself must be locked down (e.g. synced to a secure time server) to prevent retrospective changes (^[5]).
• Attributable: The entry must record who (user ID or instrument) performed the action (^[26]) (^[5]). This links each change to a responsible individual.
• Action and Data Details: The entry logs what was done to which record. Typically this includes the record’s identifier, the previous and new values, and any reason or comment for the change (^[26]) (^[28]).
• Integrity: Audit logs must be protected by validated controls that prevent or make unauthorized modification or deletion detectable and support reconstruction of the record history. Append-only logging or retention-locked storage may be appropriate risk-based controls, but the necessary safeguards depend on the intended use and system design (^[2]).
• Retention and Availability: Audit trails must be retained as long as the corresponding records (often matching multi-year GLP retention) and must be readily available for regulatory review (^[5]) (^[26]).

In essence, audit trails should be complete and reviewable for the defined records and actions within their documented scope. The applicable predicate rules and risk assessment determine what data an audit trail must contain and how it is reviewed. FDA notes that, even where a predicate rule does not require a particular date, time, or event sequence, audit trails or other physical, logical, or procedural measures may still be appropriate to ensure record trustworthiness and reliability (^[17]).

Audit-trail scope and review should be documented and risk-based, taking account of applicable predicate rules, intended use, and the criticality of the data. FDA’s Part 11 scope guidance focuses enforcement discretion on records needed to meet predicate rules or submitted to FDA, while OECD GLP data-integrity guidance calls for risk-based controls throughout the data life cycle. A test facility should therefore define which GLP records and events require audit trails, what those trails must capture, and how they will be reviewed. The ISPE GAMP® 5 Guide (Second Edition) and the ISPE GAMP® RDI Good Practice Guide: Data Integrity by Design further clarify that meaningful audit trail review must be integrated into the data lifecycle and routine operations—not treated as an isolated compliance exercise. GAMP 5 makes a critical distinction between data audit trails (linked to GxP-relevant records) and system technical logs, recommending that only audit trails associated with GxP-relevant records require routine review (^[29]).

The table below summarizes the essential features of GLP audit trails and their purpose:

Audit Trail Feature	Purpose/Example
Defined scope	The organization documents the records and actions requiring audit trails or other controls based on applicable predicate rules, intended use, and risk assessment ([17])
Secure and protected	Validated controls prevent or make unauthorized modification or deletion detectable and support record reliability; append-only or retention-locked storage may be appropriate ([2])
Attribution and timing, where required	The trail captures the information needed to meet applicable requirements and support the reliability of the record, such as identity, date, time, sequence, and change information ([17])
Retention	Preserved for the required retention period of the corresponding record; the applicable jurisdiction and study determine the period ([27])
Reviewable	Available in a form that supports inspection, review, and copying as required by applicable rules ([17])

For records and actions within the documented audit-trail scope, the implemented controls should prevent or make unauthorized manipulation detectable. The organization should validate the controls and define how it will detect, investigate, and manage attempts to disable, alter, or truncate audit logging.

In practice, many regulated systems integrate audit trails at multiple levels: the application (ELN/LIMS logs user activities), the database (DB triggers log any SQL changes), and sometimes the OS (file-access logs). A robust GLP IT strategy often centralizes logs into an immutable ledger or database where they are periodically reviewed (e.g. by QA). The concept of a single source of truth emerges: if the system’s data are questioned, the audit trail is the ultimate evidence of authenticity. As one authority succinctly puts it: “The audit trail turns data into defendable evidence” (^[30]).

Closely aligned with audit trails is the concept of data integrity, often encapsulated by the ALCOA+ acronym (^[16]) (^[12]). ALCOA stands for Attributable, Legible, Contemporaneous, Original, Accurate, and the “+” adds elements like Complete, Consistent, Enduring, and Available. ALCOA+ is commonly used to describe data-integrity attributes. OECD guidance states that data should remain complete, consistent, accurate, trustworthy, and maintained throughout the data life cycle:

• Attributable: Each data point and record must clearly show who created it and when. This is achieved by unique logins, electronic signatures, and audit trails (^[12]) (^[5]).
• Legible: Records must be human-readable throughout their retention period. In digital form, this means file formats and displays that can be rendered or printed in an understandable way. (Part of this is ensuring file formats remain standardizable over decades (^[10]).)
• Contemporaneous: Data entries must be made as the observation occurs, with minimal delay, supported by secure system clocks (^[5]).
• Original: The first capture of the data (e.g. raw instrument output) is preserved. If copies are used, they must be certified as true copies. Digital systems accomplish this by directly storing original electronic outputs or by generating checksums.
• Accurate: Data must correctly reflect the observation, and any corrections must be documented in the audit trail with reasoning.

The “+” additions are particularly relevant to archiving:

• Complete: All data (including metadata, calibration records, QA reviews) are captured, none deleted.
• Consistent: Data and audit records use a coherent format/linkage (e.g. every log entry can be cross-checked with source data).
• Enduring: Data retention over the full period required by the applicable jurisdiction and study; this is not a universal 10–15-year GLP rule (^[27]).
• Available: Stored so that it can be efficiently retrieved throughout and after the retention period (^[31]).

To illustrate compliance with these principles, GLP archives must be carefully managed. The OECD guidance emphasizes a risk-based, life cycle approach to data management (^[22]), meaning labs must identify their critical data and apply appropriate controls. For example, a stability study’s raw measurements would be considered critical and must be locked down with full traceability, whereas incidental metadata might have lighter control.

The archive itself is a key component of integrity. Under FDA GLP, archives must provide secure storage and retrieval, with records retained for the periods specified in 21 CFR 58.195. Those periods depend on the relevant research or marketing-permit timeline, or on study completion where no marketing permit is filed; they are not a universal 10–15-year requirement. Archive design should therefore include media and format-management strategies appropriate to the applicable retention period (^[32], 21 CFR 58.195). Long-term archives often adopt WORM storage, tape libraries, or cloud object storage with strict retention policies, to ensure “data can’t be modified or deleted” accidentally or maliciously (^[33]) (^[34]).

In practical terms, GLP requires data to remain complete and retrievable for the applicable retention period; the duration is determined by the governing jurisdiction and study, rather than by a universal requirement to retain data for decades (^[27]). This means, for example, that a CSV file stored today must be readable (or convertible) in the future, and its audit trail entries (possibly in a log file or database) must still correspond correctly. Failing to preserve the “original context” of data is considered a breach of GLP.

In summary, GLP ALCOA+ requirements translate directly into storage and logging practices:

• Store data in non-erasable (WORM) media or highly controlled file systems (^[19]).
• Use secure time synchronization (e.g. NTP to dedicated servers) to enforce accurate timestamps.
• Implement role-based access control (RBAC) and multi-factor auth so that symbols in the audit trail reliably map to real individuals (^[9]) (^[35]).
• Establish quality assurance reviews of audit trails to verify data plausibility (e.g. QAU inspections of log reports).
• Plan for long retention: many organizations use tiered storage (active short-term on fast disk, archived long-term on tape or cold cloud) with policies to prevent premature deletion (^[31]) (^[10]).

The forthcoming sections examine the technology options to achieve these controls in detail.

File systems—whether local volumes, NAS shares, or cloud object stores—form the foundation of any data infrastructure. By default, general-purpose file systems (ext4, NTFS, XFS, etc.) focus on performance and flexibility, not on regulatory compliance. However, GLP institutions can leverage certain file system features and adjunct technologies to meet audit trail needs. Key concepts include journaling vs. auditing, snapshotting, immutability, and secure logging.

Journaling and Basic Filesystems

Most modern file systems (Linux ext4/XFS, Windows NTFS) are journaling file systems. Journaling ensures file system metadata integrity after crashes by recording changes before they are committed. While journaling helps prevent corruption, it is not a substitute for GLP audit trails, because it does not record who changed a file or its content. Journaling is internal to the OS and invisible to end-users, and journals are typically cyclic (older journal entries overwritten as segments fill). Thus, journaling file systems do NOT inherently provide the write-once, append-only logging GLP requires.

Nevertheless, standard file systems can be part of a compliant solution if augmented:

• Write Permissions: GLP solutions often configure file or directory permissions carefully (e.g. removing write permission after file creation except via controlled processes).
• Append-Only Flags: On Unix-like systems, files can sometimes be marked append-only, preventing modifications except appending. (Linux’s chattr +a allows this on ext4, but it requires privileged control and may not survive all operations.)
• Mount Options: File systems can be mounted read-only or with certain modes disabled to prevent unauthorized changes.
• Filesystem ACLs: Beyond basic permissions, Access Control Lists can restrict which users can create/modify files. Combined with authentication, ACLs help ensure Attributable data.

But crucially, audit logging is not automatic. To capture who did what, one often relies on OS-level audit frameworks. For example:

• Linux Audit Daemon (auditd): A common approach on Linux servers is to run auditd, which can be configured to watch specific files or directories. If a GLP data directory is audit-monitored, any read or write event gets logged in /var/log/audit/audit.log with user and timestamp (^[36]). This log can serve as an audit trail (though it must also be protected and managed under GLP controls).
• Windows File Auditing: On Windows, enabling file share auditing (SACLs on NTFS) can record access events in the Security Event Log (^[36]). For example, one can audit “Audit File Share” to track file creations, deletions, and modifications on any share. The Windows event log will record which user accessed which file (including source IP if accessed over SMB) (^[36]). Again, these logs must themselves be secured and included in the audit trail.

While these OS-level logs can capture detailed events, they have caveats: they can generate enormous volumes of data, and they rely on the underlying OS being trusted. A malicious admin or clever hacker might tamper with auditd or Windows event logs if not properly safeguarded. GLP compliance thus often discourages relying solely on traditional OS logs without additional controls. For instance, regulators might require that logs be regularly exported to an immutable repository.

Encrypted and Authenticated Shares

Network file shares add dimensions of security and auditing:

• SMB/CIFS Shares: Common in Windows environments. Windows Server can host SMB file shares with granular permission sets. SMBv3 can even encrypt traffic in transit. Windows Active Directory provides centralized user authentication, strengthening the “Attributable” aspect. With audit policies enabled (via Group Policy) for “object access”, each file operation on a share can be logged (^[36]). Natively, SMB does not provide WORM, but share folders can be mapped to underlying WORM volumes.
• NFS (Network File System): Widely used in Linux/Unix labs. NFSv4 supports Kerberos authentication and ACLs. However, NFS has historically offered weaker security; additional configuration (e.g. Kerberos with strong keys, or NFSv4.2 with encryption) is needed to ensure secure attribution. NFS servers can also be mounted in ro (read-only) for archival directories, preventing changes after data is written.

Regardless of SMB vs NFS, many Network Attached Storage (NAS) appliances provide advanced compliance features. For example, appliances from major vendors (NetApp, Dell, IBM) allow entire directories to be set to immutability (WORM mode) or snapshots to be locked. Such NAS can also run audit logging services or integrate with SIEM. In a GLP lab, a typical design might be: each instrument writes data to a NAS share; a service daemon or user interface then triggers an “archive” process that moves files into a WORM-protected folder on the NAS (e.g. by copying and then marking immutable) and logs an audit entry. The original live share might be write-protected after confirmation.

Object Storage (Cloud File Systems)

Cloud storage systems represent a special category. Services like Amazon S3, Azure Blob Storage, and Google Cloud Storage enable “object” storage accessible via APIs or SMB/NFS gateways. These are inherently network-shares in principle. Crucially, they offer built-in immutability options:

• Amazon S3 Object Lock: Already in widespread use, S3 Object Lock can place a retention mode on individual objects, making them WORM (^[34]). AWS has certified Object Lock for various compliance needs (e.g. SEC 17a-4, FINRA) and customers (e.g. broker-dealers) use it to satisfy record-keeping regs (^[34]) (^[37]). S3 also offers Glacier Vault Lock for WORM storage on tape-backed vaults. CloudTrail object-level data events are not logged by default; they must be explicitly configured, and the chosen log destination, retention, access restrictions, and any immutability protection for the logs must be configured and validated.
• Azure Blob Immutable Storage: Azure provides time-based retention and legal holds on Blob Storage containers (^[33]). Once a blob is under a retention policy, it cannot be modified or deleted until the retention expires. Microsoft explicitly cites usage by healthcare and financial institutions to store immutable data properly (^[38]). Azure resource logs must be explicitly routed through diagnostic settings to a selected destination; retention, access restrictions, and any immutability policy for that destination must be configured and validated.
• Hybrid/Enterprise NAS with Cloud: Some on-prem appliances integrate with cloud tiers. For example, Dell EMC PowerScale (Isilon) SmartLock offers on-prem WORM, and can tier old data to cloud using WORM policies (^[39]). IBM Spectrum Protect offers content addressable storage (CAS) with WORM. These enterprise solutions often form the back-end of a GLP archive.

One caveat of object storage is that it is “flat” (no directories) and accessed over HTTP APIs or SMB-like gateways. Traditional file sharing (directory trees) may need an NFS gateway or SMB share front-end. From a compliance view, though, object storage’s native immutability and versioning make it attractive for GLP archives.

Snapshot and Versioning Mechanisms

Another approach is versioning: storing each change as a new version. Many file systems and databases allow version history (e.g. Git-like systems, ZFS snapshots, SharePoint versioning). In GLP, versioning can help track changes, but it must be coupled with audit info (who changed, etc.). Standalone versioning without an audit log still can’t prove who made the alteration, so it is usually used alongside or within a broader system. For example, a ZFS file system can keep snapshots of a volume over time. If logs are lost or suspect, one could compare snapshots to see if data changed unexpectedly, but snapshots alone don't replace audit trails for regulatory compliance.

It is more common in GLP labs to rely on snapshots for recovery (e.g. recover a previous version if a file was damaged) and on dedicated audit trails for traceability. However, snapshots do enforce enduring storage: even if someone deletes a file, an admin can revert to a snapshot. This is a useful safety net against data loss, although regulators would treat snapshot restoration as a form of data recovery that itself should be documented in the audit trail.

Secure Logging Services

Given that neither raw filesystems nor network shares inherently log everything, many organizations use secure logging services. All audit logs generated by applications, OS, and network equipment are forwarded to a protected logging server or Security Information and Event Management (SIEM) system. These platforms are configured as write-once storage (often with WORM disks) so that once an audit log event is written, it cannot be physically altered. Examples include:

• Syslog/Tacacs: Many instruments and network devices can send syslog events to a central collector. If syslog is secured (e.g. via TLS and with logs written to WORM storage), it could provide part of the audit trail for devices.
• Database Audit Vaults: Some databases (Oracle, SQL Server) have audit vaults or journaling features that publish logs to secure stores.
• Blockchain/Immutable Ledger: Emerging research suggests using blockchain-like ledgers to record audit entries (^[40]). While not mainstream in GLP, prototypes like “BlockAudit” aim to distribute log integrity. No regulatory guidance yet endorses blockchain, but it represents a future-proof idea for tamper-proof logging.

In practice, the chosen logging framework must align with GLP’s immutable and traceable requirements. For example, if using a SIEM, one would ensure it cryptographically signs audit entries. Similarly, any archival of logs must respect retention requirements; old logs themselves become regulatory records.

File Share Configuration for GLP

For laboratories deploying network file shares, best practices include:

• Logical Segmentation: Separate shares or volumes by data criticality. For instance, instrument raw data, QA documents, and general reports each have their own shares with tailored retention and access controls.
• Permission Harden: Grant “create” and “modify” rights only to process/service accounts or to specific validated users. Remove write access from generic admin accounts. Often the GLP approach is “write once” even on network shares: users copy data into the share under an accountable regime and then the share is effectively read-only afterwards (^[10]).
• SOPs for Data Handling: Document procedures for moving data between shares and archives, including how to handle audit trails. For example, the procedure might require an operator to upload raw data, press an “archive” button that signs and copies it to a WORM subfolder, and log the event in a system log.
• Audit Log Monitoring: Enable and regularly review file access logs (using tools like Windows Audit/File Share or Linux auditd). Automated alerts (e.g. via SIEM) can catch unusual events like deletion attempts.
• Encryption: Wherever feasible, enforce encryption both in transit (SMB3 encryption, NFS Kerberos, etc.) and at rest (Bitlocker, Linux LUKS, or cloud provider encryption). This protects data and audit logs from unauthorized reading or tampering by physical attackers (^[9]) (^[41]).

By combining all these controls, a network file share can act as a secure, GLP-compliant data repository.

Summary: Designing a GLP-Compliant File System

To ensure compliance, the entire storage solution must be treated as a validated system:

• Protection of final archival data: Implement validated, risk-based controls that prevent or make unauthorized modification and deletion detectable for the applicable retention period. WORM volumes or object locks can be appropriate technical controls, but should be selected and validated for the intended use rather than treated as a universal GLP mandate (^[2]).
• Immutable Flags and Snapshots: Leverage file system or NAS features to “lock” folders/files and use snapshots for fallback.
• Hardware Separation: As Oracle notes, compliance appliances often isolate RAID controllers and require physical security to prevent circumvention (^[42]) (e.g., no other external access to the disk array).
• Audit Logging: As described, capture file events at multiple layers and secure the logs.
• Procedural Controls: Document how systems are configured, who can change compliance settings, and ensure QAU audit checks.

The figure below (Table 1) compares representative storage platforms and their GLP-relevant features.

Storage Platform / Share	Description	WORM/Immutability	Audit Log Support	Encryption	Comments (Compliance)
On-Prem NAS Appliance*	Enterprise NAS (e.g. NetApp or Dell EMC PowerScale)	SmartLock (WORM)	Hardware logs; integrate with SIEM	Yes	Designed for compliance archiving; file shares with snapshots & ACLs; validated per config.
ON-Prem File Server	Standard server with NTFS (Windows) or ext4/XFS (Linux)	No (unless custom)	OS auditd/Event Log	Yes (disk)	Base system; use ACLs, OS logging; needs additional controls (see text).
Amazon S3 Object Store	Cloud object storage with APIs	Yes (Object Lock)	CloudTrail data events when explicitly configured; protect the selected log destination separately	Yes	Object Lock provides WORM; configure and validate object-level logging, log retention, access restrictions, and any immutability control for the logs.
Azure Blob Storage	Cloud object storage with immutable policies	Yes (immutable policies)	Resource logs when explicitly routed through diagnostic settings; protect the selected destination separately	Yes	Time-based retention & legal holds can enforce WORM state; configure and validate log routing, retention, access restrictions, and any immutability control for the logs.
Tape Library (LTO)	Offline/archival storage with WORM tape option	Yes (physical WORM)	Logs of writes to tape	N/A	Traditional long-term archive; susceptible to physical damage; low-cost.
Linux File System share	NFS share on Linux (ext4/XFS, Samba)	No	Linux auditd; Samba logs	Depends	Widely used; needs auditd, secure configs; not inherently WORM.
Windows Share (SMB)	CIFS/SMB network share on Windows Server	No (unless Clustering)	Windows Security Audit	Depends	Supports ACL and share auditing ([36]); use EFS if needed.

*NAS Appliances: Specialized NAS often include built-in compliance features (dir locking, secure snapshots) that simplify GLP archiving. Vendor documentation (e.g. Dell, HPE, NetApp) provide specific guidance on setting up compliance modes.

Table 1: Comparison of storage solutions and GLP-relevant features.

In practice, GLP labs often use a hybrid architecture: high-speed file shares for in-process work, backed by immutable archives for long-term storage. Data may first reside on a normal server or NAS during study execution, with routine snapshots for recovery. After study conclusion or at fixed intervals, data are archived (copied) into a secure, WORM-protected volume or cloud bucket. All along, audit logs capture these transfers and any file access.

Many GLP laboratories operate in distributed settings: multiple instruments, sites, or collaborators. Network shares (NAS, SAN, unified file systems) play a central role. The critical point is that the network reveals multiple attack vectors: not only must the local file system be secure, but the network protocols and access controls must also meet GLP standards.

Network Protocols: SMB vs. NFS

SMB (Server Message Block) is ubiquitous in Windows environments. When properly configured, SMB can be quite secure:

• Authentication: SMB integrates with Windows Active Directory. Users log in with domain credentials, so each action is linked to an identity. This meets the “attributable” requirement from audit trails (^[26]).
• Access Control: NTFS ACLs apply over SMB shares. Permissions can be set finely (e.g. only certain users can write). After an approved data-write, an admin can flip a share/volume to read-only.
• Encryption: SMB3 introduced per-share encryption. A GLP lab may enforce that all traffic between instruments/clients and the SMB server is encrypted (protecting data in transit).
• Audit Policies: Windows offers SACLs (System Access Control Lists) to audit object access. When enabled on a share or folder, every create, delete, or modify event generates a Windows Security log entry (^[36]). These can be forwarded to a log server or SIEM for retention. Importantly, file share auditing (set via Group Policy “Audit Object Access” or the “Audit File Share” setting shown in Microsoft docs (^[36])) can record the user, timestamp, and even the client IP for each file event. Thus, a Windows share can fulfill the requirement “track what content was accessed, the source (IP address and port), and the user account” (^[36]).
• Example: A biochemist saving a chromatogram to \\LabServer\GLPData. Windows would log: “User Alice created file test1.csv at 10:23:45 on \LabServer\GLPData (source IP 10.1.2.3)”. Combined with later entries (file closed, etc.), this becomes part of the audit trail.

NFS (Network File System) is common in Unix/Linux labs. NFSv4 supports Kerberos (krb5p) which can authenticate users. However, typical NFS deployments in labs may still rely on host-based IP restrictions or simple root access maps. To make NFS GLP-compliant:

• Use Kerberos-secured NFSv4 so that user identities are carried through, not just client IP.
• Restrict exports so only authorized IPs or VLANs can mount the share.
• Treat data directories as read-only once data is finalized.
• Use Linux auditd on the NFS server to monitor the exported directories. The server logs file operations by user (as mapped by Kerberos).
• (Alternatively) Many labs avoid scanning NFS logs by instead having all instruments upload to a local data directory, which a backend application then deposits into the NFS share.

In either case, baseline network security (firewalls, VLAN segmentation) is assumed. For GLP, one ensures that only the instrument PCs or approved computers are in the same secure DMZ/VLAN, limiting exposure.

Centralized vs. Distributed Archives

Centralization refers to having a single archive (or a cluster) holding all GLP data. This aids consistency and audit: as Arkivum notes, scattered lab data “hinders revisiting past data and complicates inspections” (^[43]). In contrast, a single validated archive (even if it has redundant sites) ensures one point of control. For example:

• A laboratory network might have multiple acquisition PCs in various labs, but each directs its data to the same central NAS cluster over NFS/SMB.
• The central NAS then runs global compliance policies (e.g. one retention rule for all data, a unified user directory for permissions, etc.).
• Auditors need only inspect one system instead of many.

Fault tolerance and replication become important: if you have a single archive but it fails, all data are at risk. Many compliance-minded designs use RAID redundancy plus replication or snapshots synced to an offsite clone. For instance, one stand-by cluster might mirror the primary (possibly in another building) to protect against fire or theft. All such data transfers must also be logged and controlled.

Case study (Arkivum): The Arkivum solution advocates a centralized lab archive with GLP validation built-in (^[44]). They emphasize that a central archive minimizes “time spent locating data from multiple sources” during inspections (^[44]). In practice, large pharmaceutical companies often operate global lab data repositories for this reason.

Audit Trails Across the Network

Audit trails in a networked environment include both application-level logs and network logs. Besides file share audits, one must consider:

• Instrument and Application Logs: Many modern lab instruments generate digital output logs. These may need to be included in the audit trail. For example, an HPLC system might log each calibration or run, which is as important as the raw data it produces. Interfacing with instrument logs is a topic unto itself (sometimes addressed via LIMS integration), but for completeness, a GLP-compliant network must capture these logs too.
• User Activity Logs: If scientists interact with an ELN or LIMS through the network, those systems’ audit trails (usually in a database) must align with the file-level logs. For instance, if a user downloads a spectrum from the server, the ELN should log the download and the file server should log the file access event.
• Backup and Restore Logs: Taking backups is mandatory for data safety, but restoring data on a backup must also be audit-traced. A robust GLP policy often treats backups as a separate record: even if a restore is needed, the original data’s audit trail must remain intact and the restore event itself logged as an audit event.

In summary, use defense-in-depth: secure the data at the instrument, database, OS, and network levels; record events at all layers; centralize logging in a tamper-proof way.

We now survey specific technologies and practices for GLP file storage and network shares. The goal is to map GLP requirements to concrete features. This section covers:

• Write-Once (WORM) Storage: Enforcing immutability at the storage layer.
• Data Encryption and Security: Protecting data privacy and integrity.
• Physical and Logical Access Control: Ensuring only authorized modifications.
• System Validation Considerations: Validating the storage solution per GLP.

WORM (Write-Once Read-Many) Technologies

GLP archives should use validated, risk-based controls that preserve records and their associated metadata for the applicable retention period. WORM storage can be one appropriate technical control for final records, but GLP does not universally prescribe it (^[2]). WORM storage means that once a file is written, it cannot be altered or deleted until a predetermined retention period expires (^[19]). In the context of file systems and network shares:

• Hardware/Media WORM: For example, Write-Once optical disks or WORM tape libraries. These media physically prevent rewriting and are inherently non-erasable until the media is replaced.
• File System WORM: Some specialized file systems embed WORM semantics. The Oracle StorageTek Compliance Archiving (example) converts normal files into WORM files by setting special bits on Unix/Windows files (^[45]). NetApp’s “SnapLock Compliance” in ONTAP and Dell PowerScale’s “SmartLock” allow files in a directory to become immutable after creation.
• Object Storage WORM: S3 Object Lock applies retention settings to individual object versions. In governance mode, users granted s3:BypassGovernanceRetention can delete protected versions or shorten retention; in compliance mode, protected object versions cannot be overwritten or deleted by any user, including the AWS account root user, until retention expires. A delete marker or a new version may still be created, so applications must account for versioning behavior when retrieving protected records (^[46], Amazon S3 Object Lock considerations).
• Filesystem Mount Options: Some filesystems (like Linux’s UDF or ISO-9660 on CD-ROM) are inherently WORM. Network files systems typically not, but as mentioned, you can emulate by marking directories read-only after data load.

Key points from the Oracle document on Solarist Compliance Arch Paging system (^[19]):

“WORM means ‘write-once, read-many’ and indicates that the file is archived in non-rewritable, non-erasable storage. A more accurate description is that after a data management application designates a file as WORM, the file becomes permanently immutable… WORM files cannot be modified, extended, or renamed. A WORM file can be deleted only when its retention time has been met and in accordance with file retention rules (^[47]).”

In practice, implementing WORM typically involves a trigger: an event or command that locks a file or volume, such as copying data into a special directory or setting a file flag. Once locked, even root cannot revert it (^[47]). Permitted operations might include viewing or copying out (read operations) but not writes.

WORM advantages for GLP:

• 100% assurance that archived records are preserved exactly as written.
• Provides compelling evidence to auditors; files physically cannot change undetectably.
• Often comes with enforcement of retention policies (e.g. preventing deletion until expiry) (^[48]).

WORM limitations to consider:

• You must plan deletion carefully: usually only after approval. Operations to remove a WORM file before retention end are explicitly prevented by systems (^[48]), unless using advisory mode which GLP rarely would.
• Metadata changes (e.g. renaming, moving files between folders) may be restricted. Some WORM volumes disallow renaming of non-empty directories to preserve path integrity (^[49]).
• Compressing or encrypting a WORM file after creation typically is not allowed, so plan format and encryption at creation time.
• Legacy data migrations need handling: existing files may need to be re-written to new WORM media.

Given these, many GLP archives dedicate specific volumes or buckets as compliance volumes. For example:

• Dell EMC PowerScale (Isilon) SmartLock: Assumes a compliance mode on a directory or project. Files put there become WORM. SmartLock supports both retention locks and "Compliance Lock" per directory (^[39]).
• NetApp SnapLock: Available in two flavors: “Enterprise” (for time-based retention) and “Compliance” (where retention cannot be shortened). These allow administrators to create WORM directories that appear as normal CIFS/NFS to users (^[50]). SnapLock is certified to meet stringent industry compliance requirements including SEC 17a-4(f), FINRA, and CFTC. Notably, as of March 2025, Amazon FSx for NetApp ONTAP eliminated SnapLock licensing fees, making it significantly more cost-effective for organizations to deploy cloud-based WORM storage for compliance use cases (^[51]).
• AWS S3 Object Lock and archival storage: One can use S3 Object Lock on object versions requiring regulatory retention and transition eligible objects to lower-cost S3 Glacier storage classes while the applicable Object Lock retention remains in effect. Amazon S3 Glacier Vault Lock is a separate feature for Amazon S3 Glacier vaults, not for objects transitioned into S3 Glacier storage classes.
• Google Cloud Storage: Google now offers both Bucket Lock (bucket-level retention policies) and Object Retention Lock (per-object retention with granular “retain until time” controls). As of 2025–2026, Object Retention Lock can be enabled on existing buckets, and buckets can now support both Bucket Lock and Object Versioning simultaneously—providing more flexibility for GLP archive configurations (^[52]).
• Software WORM: Solutions like OpenText LiveVault, Actiance Archive, or Emc Centera are older archiving appliances implementing WORM semantics.

Case Example: Financial WORM vs GLP WORM

It is instructive to note that WORM compliance is common in other regulated industries. For instance, FINRA and SEC require broker-dealers to keep communications in WORM form, and thousands of firms have been fined for WORM non-compliance (^[13]). Financial archivists have developed robust WORM technologies which the life sciences world can leverage. Pagefreezer’s whitepaper notes that “organizations in regulated industries need to ensure their data is unalterable and secure in WORM compliant storage” (^[53]). Though GLP itself is laboratory-focused, the same principle holds: once experimental data is written, it must be preservation-ready.

Laboratories considering WORM should thus look at enterprise offerings used by banks. It is equally important to validate (per GLP) that the chosen storage truly prevents changes. For instance, the Oracle Compliance Archiving software requires the RAID not connect to any network other than the NAS itself (^[42]), emphasizing that physical security complements software controls.

Encryption and Security Controls

GLP does not typically prescribe encryption, but it aligns with the broader data integrity mandate to protect data confidentiality and prevent unauthorized tampering (^[9]) (^[41]). Encryption is particularly relevant for network shares and offsite archives:

• Encryption at Rest: Encrypting disks or volumes (using LUKS, BitLocker, or hardware encryption) ensures that if backup media or disks are stolen, the data remain unreadable. Cloud services typically encrypt data at rest by default (AWS S3 SSE, Azure Storage encryption). From a compliance viewpoint, encryption is part of maintaining integrity, especially for sensitive data (^[9]).
• Encryption in Transit: For example, use SMB3 encryption for Windows shares and Kerberos with RPCSEC_GSS for NFS, or a VPN/TLS tunnel. This prevents network sniffing or man-in-the-middle attacks from injecting false audit log entries.
• Key Management: If encryption is used, keys must also be GLP-controlled. For instance, an encryption key that could unlock many files should itself be under strict access control (perhaps stored in a Hardware Security Module or cloud KMS under MFA).
• Multi-factor Authentication: For administrative access to file servers or storage consoles, MFA strongly binds individuals to actions (^[35]). While not a stored “file system” feature per se, it ensures the attribution is strong.
• Physical Security: Vault the physical servers and storage. Even if software is perfect, someone could theoretically swap disks. Regulations assume the site is secure, but strict labs often keep WORM appliances in locked rooms with limited entry (^[42]).

AWS and Azure guidelines stress encryption: AWS whitepapers advise “encrypt sensitive data in transit and at-rest to meet highest info security standards” (^[41]). For GLP, this often coincides with compliance standards like ISO 27001 which labs may pursue alongside GLP (^[54]).

Access Control and Authentication

Complementing encryption, robust access control is mandatory. GLP file systems should implement:

• Unique User IDs: Each person (or even instrument/device) with access gets a distinct login. Generic accounts (e.g. “labtech1”) defeat attribution. With network shares, this usually means tying to directory services (e.g. Active Directory, LDAP).
• Role-Based Permissions: Align share and folder ACLs with job roles. For instance, analysts might have write rights to certain lab shares, supervisors have read/metadata rights, and admins have no direct rights to change archived data.
• Separation of Duties: If possible, the labs employ one user to write data and a different QA user to approve/flag it in the system. While not enforced by the file system, it is an associated control.
• Time-lock Change Windows: Some systems support scheduling changes only in maintenance windows (though rarely used in GLP).
• Logging of Login Sessions: Using SIEM or session logs can show that logins and file accesses part of normal patterns; if an unusual login occurs at 2 AM, QA could investigate.

Strong authentication can involve:

• Two-Factor or MFA: Requiring tokens or biometrics prevents stolen credentials from being misused. This is now a recommended best practice for any regulated data (^[35]).
• Service Accounts: For automated data transfers (e.g. instrument PC uploading to NAS), use locked-down service accounts (with their use logged in audit trails).
• Privileged Access Management: For administrators, use a PAM system where admin creds are vaulted and access is session-logged.

System Validation and Audit

Under GLP, any computerized system must be validated (Computerized System Validation, CSV). This includes the storage system. For a file server or NAS, validation means documented testing that confirms the implemented controls. For example:

• Configuration Review: Document and test that WORM volumes cannot be disabled without authorized procedure. Verify default ACLs are as intended.
• Access Tests: Attempt forbidden actions under test (e.g. normal user trying to delete a WORM file) to ensure the system blocks them.
• Audit Trail Integrity Checks: Check that the audit log cannot be turned off by normal users and that log entries can only be appended.
• Retire/Replacement Plan: Because hardware and software age, the validation plan should include periodic revalidation (e.g. after upgrades) and data migration procedures that preserve audit trail continuity.

Quality Assurance (QA) units should routinely review storage logs (e.g. file access summaries) and confirm no abnormal events. Periodic audits might involve retrieving a file and verifying its checksum matches the original, and comparing log entries to ensure they align.

Data Retention and Archival Cycles

Finally, GLP requires defined data-retention schedules. The required period is set by the applicable jurisdiction and study; for U.S. FDA GLP, 21 CFR 58.195 specifies retention based on the relevant research or marketing-permit timeline or, where no marketing permit is filed, on study completion (^[27]). The storage system must support:

• Policy Enforcement: Files older than X can be flagged for archival or deletion only under controlled procedures. Some systems allow auto-enforcement (e.g. after N years, lock file or migrate to cold storage).
• Version Migration: If a file format becomes obsolete (e.g. proprietary binary), the GLP archive may need a plan to export to a new format without losing audit trail metadata.
• Network Share of Archive: Some labs use WORM objects as final archives, while still keeping them “accessible” through an indexed network share or web portal that reads from the immutable store.
• Disaster Recovery: Backup procedures (ideally also GLP-compliant backup solutions) ensure even in event of hardware failure, data can be recovered while maintaining audit history.

Summary of Technical Controls

Putting it together, a GLP-compliant storage architecture might be depicted as follows:

• Active Zone: High-speed file shares (NAS or SAN) for day-to-day data capture (with snapshots, encryption, auditd).
• Archive Zone: Immutable storage (WORM) for data at study completion, possibly using cloud or tape for longevity.
• Access Layer: Directory services, RBAC, MFA protecting who can even see the files.
• Logging Infrastructure: Centralized and tamper-proof logging of all storage events.
• Administrative Procedures: SOPs for data retention, system changes, and QAU audits verifying controls.

The goal is to define and implement controls that make the relevant records and critical actions traceable from capture through archive, based on applicable requirements, intended use, and documented risk assessment.

Real-world experiences illustrate these principles:

• Pharmaceutical Company Compliance: A 2024 case study recounts a large pharma firm achieving full GLP compliance through process optimization and technology integration (^[55]). The firm streamlined documentation, instituted strong QA oversight, and “introduced cutting-edge software solutions to facilitate data management” including audit trail readiness (^[56]). The result was greater efficiency and compliance (full GLP attainment) with fewer regulatory risks (^[7]). Although the study does not detail specific file systems, it underscores that GLP consulting often recommends automated digital archive solutions.

• LIMS/ELN Systems: Many labs deploy dedicated ELNs or LIMS with built-in audit trails rather than rely on raw file shares. For instance, an Electronic Document Management System (EDMS) can enforce version control and logging. As noted by GLP experts, “EDMS ensures version control, document access control, and audit trails … while maintaining compliance with GLP regulations” (^[8]). Such systems integrate with file storage: raw data may be stored as attachments or in a governed repository under the EDMS. When certified for Part 11, these systems provide a turnkey audit trail.

• AWS Cloud Migration: Large companies like Merck, Moderna, and Veeva have migrated portions of their GxP workflows to AWS (^[57]). AWS provides reference architectures for GxP workflows: e.g. using AWS Service Catalog and Landing Zone to standardize deployments (^[58]). They recommend “centralized logging” (such as aggregating all audit logs in an immutable repository) and “automated change management” for compliance (^[59]). For example, an instrument output could be uploaded to an EC2 file server or directly to S3; if the relevant S3 object-level data events are explicitly configured, CloudTrail can log the S3 PUT. While these references are GxP-wide, the GLP case is analogous: use cloud regions and accounts to isolate GLP data, configure S3 Object Lock on buckets, and record all actions with CloudTrail for audit (^[34]) (^[59]).

• Academic Labs Implementation: A 2021 scoping review of academic health science labs found that digital management systems (LIMS, ELN, etc.) are “evolving tools in compliance with GLP principles” (^[60]). While many academic labs struggle with personnel turnover and funding (^[61]), reported implementations show real benefits: improvements in workflow, error reduction, and audit-readiness when using systems with traceability features. For instance, several studies cited in that review discussed building custom lab software where every experimental step was recorded electronically, effectively serving as an audit trail (^[62]). This reinforces that digital archiving is not just a theoretical construct but a practical necessity, even in resource-challenged settings.

• Archive Services: Specialized vendors have emerged to serve GLP archiving. For example, Arkivum provides a “GLP-compliant laboratory data archive” solution (^[63]). They emphasize risk-based archiving: labs must centralize data and choose validated archiving tools to ensure integrity and longevity (^[63]) (^[10]). In their view, using ad hoc methods (e.g. “storing long-term GLP data in LIMS or even a cloud file share” (^[64])) is classic but problematic, as it makes long-term control and retrieval unreliable. An Arkivum deployment typically ingests data from various sources into a unified, indexed archive, enforcing WORM and checksums under the hood (though their marketing doesn’t detail the tech). The case of Arkivum exemplifies an industry recognizing that GLP data is too valuable to leave on generic storage indefinitely. Their arguments echo the technical points made earlier: centralization, WORM storage, and easy search while preserving immutability are critical.

• Audit Trail Review Example: Though not a full case study, industry training sessions reveal typical audit trail findings. One GMP-oriented review in Contract Pharma described discovering that an analyst had deleted injection data, a fact only uncovered by diligent audit trail review. While not specifically GLP, it illustrates that audit trails must be monitored systematically and staff should have only as much access as needed. This underscores an operational lesson: technical compliance alone isn’t enough; regular review of audit logs (perhaps via automated software) is vital to catch anomalies.

• Government Guidance: Regulator-led initiatives highlight these challenges. The OECD’s GLP Data Integrity Advisory (No. 22, 2021), the MHRA’s GxP Data Integrity guide (2021), and most recently the OECD Position Paper No. 25 on GLP and IT Security (December 2024) focus heavily on computerized data risks. The IT Security paper stresses that data must be ”secure from the specific hazards encountered in the computerised environment” and that while IT security may be outsourced, responsibility remains with the test facility (^[4]). This means any network share or file system must be hardened against cyber threats (e.g. ransomware, unauthorized access). This guidance shows that IT security and data-integrity controls are relevant considerations for GLP test facilities. The article does not provide a direct primary source for a worldwide numerical count of facilities found non-compliant or withdrawn from GLP status, so that claim is omitted.

Together, these examples reveal key patterns: organizations that succeed in GLP archiving automate controls and archive centrally, use modern validated systems, and integrate audit logging at all levels. They also show the flip side: using generic, ungoverned file shares or neglecting digital logs tends to create regulatory and operational headaches.

While there is no central database of GLP data breaches (as there is in, say, finance), indirect evidence underscores the importance of compliant storage:

• Regulatory penalties: In financial markets, firms have been fined millions for not using WORM storage for client records (^[13]). In life sciences, regulators may not publicize GLP violations as widely, but warning letters often cite “missing records” or “failure to maintain audit trails” similar to this focus. The exercise of simulating audits has shown that even good labs sometimes have gaps if their archives were not planful. For example, FDA warning letters (publicly available on FDA website) occasionally mention that raw data could not be retrieved or date stamps were inconsistent – issues exactly prevented by robust systems.
• Adoption metrics: According to the MDPI scoping review, of 32 digital management projects in academic labs, about nine studies specifically evaluated their compliance impacts (^[62]). All reported improvements in traceability. While not a large sample, it suggests a trend: labs adopting digital systems see measurable gains in “workflow and quality”. This qualitative data reinforces that structured data systems (including file systems with audit trails) yield GLP benefits.
• Retention planning: Retention periods must be established from the applicable jurisdictional and study-specific requirements. For U.S. FDA GLP, 21 CFR 58.195 does not establish a universal 10–15-year period. Storage capacity, media choice, and retrieval arrangements should be justified through the organization’s documented risk assessment and retention schedule rather than through unsupported generic volume or cost assumptions (^[27]).
• Security incidents: Although rare, GLP labs are not immune to cyber threats. Ransomware attacks on research institutions have been publicized; if a lab’s network share is encrypted by malware, not only is data lost, but the chain of custody is broken. This gives added impetus to immutable, offline backups as part of the system analysis.

Overall, quantitative data is scarce, but qualitative research and industry reports consistently show that better digital data management correlates with better GLP compliance outcomes (^[60]) (^[7]). Combining this with what we know of other industries, the evidence supports investing in engineered storage solutions with audit controls.

The trajectory of technology and regulation suggests that GLP-compliant storage will remain a critical area:

• Increasing Digitalization: GLP regulations themselves are being updated to explicitly address electronic methods. The OECD’s GLP Data Integrity guidance (No. 22, 2021) reflects “risk-based controls” for GLP data, acknowledging that computerized systems are ubiquitous (^[22]), while the more recent OECD Position Paper No. 25 on GLP and IT Security (December 2024) explicitly addresses emerging cyber threats and the responsibilities of test facilities when using cloud and outsourced IT services. Labs should interpret these as encouragement to implement and govern digital archives where electronic systems are used. GLP data-integrity guidance applies to paper, electronic, and hybrid records; electronic audit trails are relevant to electronic data, not a universal replacement for paper records.
• Remote Auditing: COVID-19 spurred an interest in remote inspections. The Knowledge Ridge analysis points out that digital archives and tools enabling “real-time remote auditing and inspection” can be valuable, especially when travel is restricted (^[65]). In the near future, a GLP inspector could log into a secure portal to view data and audit trails from anywhere. This raises the bar for LIS systems to have web interfaces and granular audit review functions.
• Cloud Adoption: As AWS, Azure, and others highlight, cloud can automate many controls (immutable buckets, centralized logging) (^[34]) (^[59]). We expect more GLP data to reside in certified cloud services; regulators have shown openness (FDA has allowed submissions from cloud-hosted systems on a case-by-case basis). The challenge will be validating dynamic cloud resources (e.g. ephemeral containers running lab apps) and controlling global data flows (GLP data often has country-of-origin restrictions).
• Integration with Data Analytics: As big data and AI enter lab sciences, the audit trail must adapt. For example, if data are analyzed by machine learning, audit logs should capture the model version and code used. Future systems may need to not only store raw data immutably but also record complete analysis pipelines as part of the audit trail.
• Blockchain and Immutable Ledgers: Research (e.g. “BlockAudit” (^[40])) investigates using distributed ledger tech to enhance audit trails. One could imagine a GLP system where each data write also posts a hash to a blockchain, creating an incontrovertible timestamp. While not mainstream, this could address auditor demands for independently verifiable logs. Start-ups in “immutable audit log” may emerge in biotech.
• Regulatory Evolution: Watch for harmonization. OECD now “takes precedence” on data integrity respectively (^[66]), so national authorities may soon expect GLP data to meet OECD advisory doc specifications (including data governance frameworks). A major development is the July 2025 draft revision of EU GMP Annex 11, which more than triples the document's size and introduces prescriptive requirements for cloud computing, AI systems, and digital service providers. The draft mandates ALCOA++ principles and is expected to finalize by mid-2026 (^[25]). Meanwhile, the FDA's QMSR (which replaced legacy QSR 21 CFR Part 820 effective February 2, 2026) aligns U.S. medical device regulations with ISO 13485—though 21 CFR Part 11 remains the governing regulation for electronic records and signatures. FDA publishes warning letters, but this article does not provide a reproducible FDA methodology supporting a specific second-half 2025 total, year-over-year percentage change, or ranking of cited deficiencies. Also, as data privacy (GDPR) and GLP overlap (if patient data are involved), labs may need to navigate dual compliance.
• AI and Algorithmic Audit Trails: As AI and machine learning tools enter laboratory data analysis, organizations should determine controls from the tool's intended use, the applicable predicate rules, and a documented risk assessment. FDA's AI guidance for drug and biological products is draft, nonbinding guidance that proposes a risk-based credibility-assessment framework; it does not establish a universal Part 11 requirement that every AI processing GxP data capture algorithmic decisions, model versions, and training-data provenance in an audit trail (^[67], FDA Guiding Principles of Good AI Practice in Drug Development).
• Hardware Developments: Federated file systems (Ceph, Gluster, Spectrum Scale) may gain popularity, especially for large consortia. These can span data centers, replicating data across nodes. If GLP archives use such systems, the consistency model (e.g. eventual consistency) must be carefully managed to avoid losing critical updates.
• Vendor Solutions: Expect more out-of-the-box GLP offerings. Already, lab management platforms promise GLP/21CFRPart11 support. AWS's elimination of SnapLock licensing fees on FSx for NetApp ONTAP (March 2025) signals a trend toward more accessible compliance-grade cloud storage. We may see NAS vendors offer “GLP compliance bundles” (prevalidated configs, QMS integrations, etc.).

For laboratory management and IT teams, the implications are clear: GLP data storage is not low-tech. Cutting corners (like simply sharing folders on a generic server without audit) risks non-compliance. Conversely, a well-architected, documented system can reduce QA burden by automating many existence checks. Organizations achieving true GLP compliance can demonstrate trustworthiness of data and likely gain a competitive edge in regulatory submissions.

Governments and regulators will continue refining guidance. For GLP computerized systems, test facilities should use the applicable GLP requirements and official guidance to determine the required controls, validate the implemented system, and conduct documented, risk-based review of relevant audit trails. The 2025 EU GMP consultation should not be treated as a final rule or as GLP guidance unless and until an official, applicable publication is issued (^[2], European Commission consultation).

Good Laboratory Practice imposes a rigorous framework to ensure that scientific data are reliable and defendable. In the digital age, GLP compliance hinges on having GLP-compliant storage: files and shares that guarantee data integrity, security, and traceability over years. As this report has detailed, achieving this requires a multi-faceted approach:

• Record protection: Applying validated, risk-based controls that preserve records and make unauthorized changes or deletions preventable or detectable. WORM technologies can be suitable controls for particular archival use cases, but are not a universal GLP requirement (^[2]).
• Comprehensive Audit Trails: Defining, implementing, and reviewing the documented, risk-based audit trails and related controls needed for applicable GLP records and system functions.
• Strict Access and Security: Enforcing RBAC, strong authentication, encryption, and network protections so that only authorized, authenticated operations occur (^[9]) (^[36]).
• Validated Systems and Processes: Documenting and testing every part of the storage architecture to show regulators that controls work as intended.
• Organizational Controls: Complementing technology with SOPs for data retention, change management, and QA oversight of the logs and archives (^[3]) (^[12]).

The end result is not merely technical compliance. A well-designed GLP storage system also enhances scientific quality by preventing data loss, making audits smoother, and enabling analytics on reliable data.

Key recommendations: Laboratories should assess their current file storage and network share setup against GLP requirements. Where gaps exist (e.g. no audit logging, no immutability, insecure access), they should plan upgrades. Vendors or IT departments can provide technical implementations, but organizational commitment is essential. Regular audits (internal or external) of the IT system should include these aspects.

GLP compliance is an ongoing process. New studies, personnel changes, or technological updates mean storage systems must be continuously managed. Future innovations (like blockchain logs or automated data integrity scanning) may further strengthen the archive.

In closing, the relevant GLP records must remain reliable, secure, and available for the applicable retention period. The strategies outlined here help laboratories define, validate, and maintain risk-appropriate controls so the records and actions within scope can be reviewed when needed (^[1], FDA Part 11 Scope and Application Guidance, OECD GLP Data Integrity Advisory Document No. 22).

Key sources: The cited materials include regulatory guidance, technical documentation, academic literature, and commentary. Readers should consult the applicable primary sources and requirements when evaluating a specific system.