Section 15 Security: The Digital Fortress that Pharmaceutical IT Never Knew It Needed

The draft Annex 11’s Section 15 Security represents nothing less than the regulatory codification of modern cybersecurity principles into pharmaceutical GMP. Where the 2011 version offered three brief security provisions totaling fewer than 100 words, the 2025 draft delivers 20 comprehensive subsections that read like a cybersecurity playbook designed by paranoid auditors who’ve spent too much time investigating ransomware attacks on manufacturing facilities. As someone with a bit of experience in that, I find the draft fascinating.

Section 15 transforms cybersecurity from a peripheral IT concern into a mandatory foundation of pharmaceutical operations, requiring organizations to implement enterprise-grade security controls. The European regulators have essentially declared that pharmaceutical cybersecurity can no longer be treated as someone else’s problem. Nor can it be treated as something outside of the GMPs.

The Philosophical Transformation: From Trust-Based to Threat-Driven Security

The current Annex 11’s security provisions reflect a fundamentally different era of threat landscape with an approach centering on access restriction and basic audit logging, assuming that physical controls and password authentication provide adequate protection. The language suggests that security controls should be “suitable” and scale with system “criticality,” offering organizations considerable discretion in determining what constitutes appropriate protection.

Section 15 obliterates this discretionary approach by mandating specific, measurable security controls that assume persistent, sophisticated threats as the baseline condition. Rather than suggesting organizations “should” implement firewalls and access controls, the draft requires organizations to deploy network segmentation, disaster recovery capabilities, penetration testing programs, and continuous security improvement processes.

The shift from “suitable methods of preventing unauthorised entry” to requiring “effective information security management systems” represents a fundamental change in regulatory philosophy. The 2011 version treats security breaches as unfortunate accidents to be prevented through reasonable precautions. The 2025 draft treats security breaches as inevitable events requiring comprehensive preparation, detection, response, and recovery capabilities.

Section 15.1 establishes this new paradigm by requiring regulated users to “ensure an effective information security management system is implemented and maintained, which safeguards authorised access to, and detects and prevents unauthorised access to GMP systems and data”. This language transforms cybersecurity from an operational consideration into a regulatory mandate with explicit requirements for ongoing management and continuous improvement.

Quite frankly, I worry that many Quality Units may not be ready for this new level of oversight.

Comparing Section 15 Against ISO 27001: Pharmaceutical-Specific Cybersecurity

The draft Section 15 creates striking alignments with ISO 27001’s Information Security Management System requirements while adding pharmaceutical-specific controls that reflect the unique risks of GMP environments. ISO 27001’s emphasis on risk-based security management, continuous improvement, and comprehensive control frameworks becomes regulatory mandate rather than voluntary best practice.

Physical Security Requirements in Section 15.4 exceed typical ISO 27001 implementations by mandating multi-factor authentication for physical access to server rooms and data centers. Where ISO 27001 Control A.11.1.1 requires “physical security perimeters” and “appropriate entry controls,” Section 15.4 specifically mandates protection against unauthorized access, damage, and loss while requiring secure locking mechanisms for data centers.

The pharmaceutical-specific risk profile drives requirements that extend beyond ISO 27001’s framework. Section 15.5’s disaster recovery provisions require data centers to be “constructed to minimise the risk and impact of natural and manmade disasters” including storms, flooding, earthquakes, fires, power outages, and network failures. This level of infrastructure resilience reflects the critical nature of pharmaceutical manufacturing where system failures can impact patient safety and drug supply chains.

Continuous Security Improvement mandated by Section 15.2 aligns closely with ISO 27001’s Plan-Do-Check-Act cycle while adding pharmaceutical-specific language about staying “updated about new security threats” and implementing measures to “counter this development”. The regulatory requirement transforms ISO 27001’s voluntary continuous improvement into a compliance obligation with potential inspection implications.

The Security Training and Testing requirements in Section 15.3 exceed typical ISO 27001 implementations by mandating “recurrent security awareness training” with effectiveness evaluation through “simulated tests”. This requirement acknowledges that pharmaceutical environments face sophisticated social engineering attacks targeting personnel with access to valuable research data and manufacturing systems.

NIST Cybersecurity Framework Convergence: Functions Become Requirements

Section 15’s structure and requirements create remarkable alignment with NIST Cybersecurity Framework 2.0’s core functions while transforming voluntary guidelines into mandatory pharmaceutical compliance requirements. The NIST CSF’s Identify, Protect, Detect, Respond, and Recover functions become implicit organizing principles for Section 15’s comprehensive security controls.

Asset Management and Risk Assessment requirements embedded throughout Section 15 align with NIST CSF’s Identify function. Section 15.8’s network segmentation requirements necessitate comprehensive asset inventories and network topology documentation, while Section 15.10’s platform management requirements demand systematic tracking of operating systems, applications, and support lifecycles.

The Protect function manifests through Section 15’s comprehensive defensive requirements including network segmentation, firewall management, access controls, and encryption. Section 15.8 mandates that “networks should be segmented, and effective firewalls implemented to provide barriers between networks, and control incoming and outgoing network traffic”. This requirement transforms NIST CSF’s voluntary protective measures into regulatory obligations with specific technical implementations.

Detection capabilities appear in Section 15.19’s penetration testing requirements, which mandate “regular intervals” of ethical hacking assessments for “critical systems facing the internet”. Section 15.18’s anti-virus requirements extend detection capabilities to endpoint protection with requirements for “continuously updated” virus definitions and “effectiveness monitoring”.

The Respond function emerges through Section 15.7’s disaster recovery planning requirements, which mandate tested disaster recovery plans ensuring “continuity of operation within a defined Recovery Time Objective (RTO)”. Section 15.13’s timely patching requirements create response obligations for addressing “critical vulnerabilities” that “might be immediately” requiring patches.

Recovery capabilities center on Section 15.6’s data replication requirements, which mandate automatic replication of “critical data” from primary to secondary data centers with “delay which is short enough to minimise the risk of loss of data”. The requirement for secondary data centers to be located at “safe distance from the primary site” ensures geographic separation supporting business continuity objectives.

Summary Across Key Guidance Documents

Security Requirement Area	Draft Annex 11 Section 15 (2025)	Current Annex 11 (2011)	ISO 27001:2022	NIST CSF 2.0 (2024)	Implementation Complexity
Information Security Management System	Mandatory – Effective ISMS implementation and maintenance required (15.1)	Basic – General security measures, no ISMS requirement	Core – ISMS is fundamental framework requirement (Clause 4-10)	Framework – Governance as foundational function across all activities	High – Requires comprehensive ISMS deployment
Continuous Security Improvement	Required – Continuous updates on threats and countermeasures (15.2)	Not specified – No continuous improvement mandate	Mandatory – Continual improvement through PDCA cycle (Clause 10.2)	Built-in – Continuous improvement through framework implementation	Medium – Ongoing process establishment needed
Security Training & Testing	Mandatory – Recurrent training with simulated testing effectiveness evaluation (15.3)	Not mentioned – No training or testing requirements	Required – Information security awareness and training (A.6.3)	Emphasized – Cybersecurity workforce development and training (GV.WF)	Medium – Training programs and testing infrastructure
Physical Security Controls	Explicit – Multi-factor authentication for server rooms, secure data centers (15.4)	Limited – “Suitable methods” for preventing unauthorized entry	Detailed – Physical and environmental security controls (A.11.1-11.2)	Addressed – Physical access controls within Protect function (PR.AC-2)	Medium – Physical infrastructure and access systems
Network Segmentation & Firewalls	Mandatory – Network segmentation with strict firewall rules, periodic reviews (15.8-15.9)	Basic – Firewalls mentioned without specific requirements	Specified – Network security management and segmentation (A.13.1)	Core – Network segmentation and boundary protection (PR.AC-5, PR.DS-5)	High – Network architecture redesign often required
Platform & Patch Management	Required – Timely OS updates, validation before vendor support expires (15.10-15.14)	Not specified – No explicit platform or patch management	Required – System security and vulnerability management (A.12.6, A.14.2)	Essential – Vulnerability management and patch deployment (ID.RA-1, RS.MI)	High – Complex validation and lifecycle management
Disaster Recovery & Business Continuity	Mandatory – Tested disaster recovery with defined RTO requirements (15.7)	Not mentioned – No disaster recovery requirements	Comprehensive – Information systems availability and business continuity (A.17)	Fundamental – Recovery planning and business continuity (RC.RP, RC.CO)	High – Business continuity infrastructure and testing
Data Replication & Backup	Required – Automatic critical data replication to geographically separated sites (15.6)	Limited – Basic backup provisions only	Required – Information backup and recovery procedures (A.12.3)	Critical – Data backup and recovery capabilities (PR.IP-4, RC.RP-1)	High – Geographic replication and automated systems
Endpoint Security & Device Control	Strict – USB port controls, bidirectional device scanning, default deactivation (15.15-15.17)1	Not specified – No device control requirements	Detailed – Equipment maintenance and secure disposal (A.11.2, A.11.2.7)	Important – Removable media and device controls (PR.PT-2)	Medium – Device management and scanning systems
Anti-virus & Malware Protection	Mandatory – Continuously updated anti-virus with effectiveness monitoring (15.18)	Not mentioned – No anti-virus requirements	Required – Protection against malware (A.12.2)	Standard – Malicious code protection (PR.PT-1)	Low – Standard anti-virus deployment
Penetration Testing	Required – Regular ethical hacking for internet-facing critical systems (15.19)	Not specified – No penetration testing requirements	Recommended – Technical vulnerability testing (A.14.2.8)	Recommended – Vulnerability assessments and penetration testing (DE.CM)	Medium – External testing services and internal capabilities
Risk-Based Security Assessment	Implicit – Risk-based approach integrated throughout all requirements	General – Risk assessment mentioned but not detailed	Fundamental – Risk management is core methodology (Clause 6.1.2)	Core – Risk assessment and management across all functions (GV.RM, ID.RA)	Medium – Risk assessment processes and documentation
Access Control & Authentication	Enhanced – Beyond basic access controls, integrated with physical security	Basic – Password protection and access restriction only	Comprehensive – Access control management framework (A.9)	Comprehensive – Identity management and access controls (PR.AC)	Medium – Enhanced access control systems
Incident Response & Management	Implied – Through disaster recovery and continuous improvement requirements	Not specified – No incident response requirements	Required – Information security incident management (A.16)	Detailed – Incident response and recovery processes (RS, RC functions)	Medium – Incident response processes and teams
Documentation & Audit Trail	Comprehensive – Detailed documentation for all security controls and testing	Limited – Basic audit trail and documentation	Mandatory – Documented information and records management (Clause 7.5)	Integral – Documentation and communication throughout framework	High – Comprehensive documentation and audit systems
Third-Party Risk Management	Implicit – Through platform management and network security requirements	Not mentioned – No third-party risk provisions	Required – Supplier relationships and information security (A.15)	Addressed – Supply chain risk management (ID.SC, GV.SC)	Medium – Supplier assessment and management processes
Encryption & Data Protection	Limited – Not explicitly detailed beyond data replication requirements	Not specified – No encryption requirements	Comprehensive – Cryptography and data protection controls (A.10)	Included – Data security and privacy protection (PR.DS)	Medium – Encryption deployment and key management
Change Management Integration	Integrated – Security updates must align with GMP validation processes	Basic – Change control mentioned generally	Integrated – Change management throughout ISMS (A.14.2.2)	Embedded – Change management within improvement processes	High – Integration with existing GMP change control
Compliance Monitoring	Built-in – Regular reviews, testing, and continuous improvement mandated	Limited – Periodic review mentioned without specifics	Required – Monitoring, measurement, and internal audits (Clause 9)	Systematic – Continuous monitoring and measurement (DE, GV functions)	Medium – Monitoring and measurement systems
Executive Oversight & Governance	Implied – Through ISMS requirements and continuous improvement mandates	Not specified – No governance requirements	Mandatory – Leadership commitment and management responsibility (Clause 5)	Essential – Governance and leadership accountability (GV function)4	Medium – Governance structure and accountability

The alignment with ISO 27001 and NIST CSF demonstrates that pharmaceutical organizations can no longer treat cybersecurity as a separate concern from GMP compliance—they become integrated regulatory requirements demanding enterprise-grade security capabilities that most pharmaceutical companies have historically considered optional.

Technical Requirements That Challenge Traditional Pharmaceutical IT Architecture

Section 15’s technical requirements will force fundamental changes in how pharmaceutical organizations architect, deploy, and manage their IT infrastructure. The regulatory prescriptions extend far beyond current industry practices and demand enterprise-grade security capabilities that many pharmaceutical companies currently lack.

Network Architecture Revolution begins with Section 15.8’s segmentation requirements, which mandate that “networks should be segmented, and effective firewalls implemented to provide barriers between networks”. This requirement eliminates the flat network architectures common in pharmaceutical manufacturing environments where laboratory instruments, manufacturing equipment, and enterprise systems often share network segments for operational convenience.

The firewall rule requirements demand “IP addresses, destinations, protocols, applications, or ports” to be “defined as strict as practically feasible, only allowing necessary and permissible traffic”. For pharmaceutical organizations accustomed to permissive network policies that allow broad connectivity for troubleshooting and maintenance, this represents a fundamental shift toward zero-trust architecture principles.

Section 15.9’s firewall review requirements acknowledge that “firewall rules tend to be changed or become insufficient over time” and mandate periodic reviews to ensure firewalls “continue to be set as tight as possible”. This requirement transforms firewall management from a deployment activity into an ongoing operational discipline requiring dedicated resources and systematic review processes.

Platform and Patch Management requirements in Sections 15.10 through 15.14 create comprehensive lifecycle management obligations that most pharmaceutical organizations currently handle inconsistently. Section 15.10 requires operating systems and platforms to be “updated in a timely manner according to vendor recommendations, to prevent their use in an unsupported state”.

The validation and migration requirements in Section 15.11 create tension between security imperatives and GMP validation requirements. Organizations must “plan and complete” validation of applications on updated platforms “in due time prior to the expiry of the vendor’s support”. This requirement demands coordination between IT security, quality assurance, and validation teams to ensure system updates don’t compromise GMP compliance.

Section 15.12’s isolation requirements for unsupported platforms acknowledge the reality that pharmaceutical organizations often operate legacy systems that cannot be easily updated. The requirement that such systems “should be isolated from computer networks and the internet” creates network architecture challenges where isolated systems must still support critical manufacturing processes.

Endpoint Security and Device Management requirements in Sections 15.15 through 15.18 address the proliferation of connected devices in pharmaceutical environments. Section 15.15’s “strict control” of bidirectional devices like USB drives acknowledges that pharmaceutical manufacturing environments often require portable storage for equipment maintenance and data collection.

The effective scanning requirements in Section 15.16 for devices that “may have been used outside the organisation” create operational challenges for service technicians and contractors who need to connect external devices to pharmaceutical systems. Organizations must implement scanning capabilities that can “effectively” detect malware without disrupting operational workflows.

Section 15.17’s requirements to deactivate USB ports “by default” unless needed for essential devices like keyboards and mice will require systematic review of all computer systems in pharmaceutical facilities. Manufacturing computers, laboratory instruments, and quality control systems that currently rely on USB connectivity for routine operations may require architectural changes or enhanced security controls.

Operational Impact: How Section 15 Changes Day-to-Day Operations

The implementation of Section 15’s security requirements will fundamentally change how pharmaceutical organizations conduct routine operations, from equipment maintenance to data management to personnel access. These changes extend far beyond IT departments to impact every function that interacts with computerized systems.

Manufacturing and Laboratory Operations will experience significant changes through network segmentation and access control requirements. Section 15.8’s segmentation requirements may isolate manufacturing systems from corporate networks, requiring new procedures for accessing data, transferring files, and conducting remote troubleshooting1. Equipment vendors who previously connected remotely to manufacturing systems for maintenance may need to adapt to more restrictive access controls and monitored connections.

The USB control requirements in Sections 15.15-15.17 will particularly impact operations where portable storage devices are routinely used for data collection, equipment calibration, and maintenance activities. Laboratory personnel accustomed to using USB drives for transferring analytical data may need to adopt network-based file transfer systems or enhanced scanning procedures.

Information Technology Operations must expand significantly to support Section 15’s comprehensive requirements. The continuous security improvement mandate in Section 15.2 requires dedicated resources for threat intelligence monitoring, security tool evaluation, and control implementation. Organizations that currently treat cybersecurity as a periodic concern will need to establish ongoing security operations capabilities.

Section 15.19’s penetration testing requirements for “critical systems facing the internet” will require organizations to either develop internal ethical hacking capabilities or establish relationships with external security testing providers. The requirement for “regular intervals” suggests ongoing testing programs rather than one-time assessments.

The firewall review requirements in Section 15.9 necessitate systematic processes for evaluating and updating network security rules. Organizations must establish procedures for documenting firewall changes, reviewing rule effectiveness, and ensuring rules remain “as tight as possible” while supporting legitimate business functions.

Quality Unit functions must expand to encompass cybersecurity validation and documentation requirements. Section 15.11’s requirements to validate applications on updated platforms before vendor support expires will require QA involvement in IT infrastructure changes. Quality systems must incorporate procedures for evaluating the GMP impact of security patches, platform updates, and network changes.

The business continuity requirements in Section 15.7 necessitate testing of disaster recovery plans and validation that systems can meet “defined Recovery Time Objectives”. Quality assurance must develop capabilities for validating disaster recovery processes and documenting that backup systems can support GMP operations during extended outages.

Strategic Implications: Organizational Structure and Budget Priorities

Section 15’s comprehensive security requirements will force pharmaceutical organizations to reconsider their IT governance structures, budget allocations, and strategic priorities. The regulatory mandate for enterprise-grade cybersecurity capabilities creates organizational challenges that extend beyond technical implementation.

IT-OT Convergence Acceleration becomes inevitable as Section 15’s requirements apply equally to traditional IT systems and operational technology supporting manufacturing processes. Organizations must develop unified security approaches spanning enterprise networks, manufacturing systems, and laboratory instruments. The traditional separation between corporate IT and manufacturing systems operations becomes unsustainable when both domains require coordinated security management.

The network segmentation requirements in Section 15.8 demand comprehensive understanding of all connected systems and their communication requirements. Organizations must develop capabilities for mapping and securing complex environments where ERP systems, manufacturing execution systems, laboratory instruments, and quality management applications share network infrastructure.

Cybersecurity Organizational Evolution will likely drive consolidation of security responsibilities under dedicated chief information security officer roles with expanded authority over both IT and operational technology domains. The continuous improvement mandates and comprehensive technical requirements demand specialized cybersecurity expertise that extends beyond traditional IT administration.

Section 15.3’s training and testing requirements necessitate systematic cybersecurity awareness programs with “effectiveness evaluation” through simulated attacks1. Organizations must develop internal capabilities for conducting phishing simulations, security training programs, and measuring personnel security behaviors.

Budget and Resource Reallocation becomes necessary to support Section 15’s comprehensive requirements. The penetration testing, platform management, network segmentation, and disaster recovery requirements represent significant ongoing operational expenses that many pharmaceutical organizations have not historically prioritized.

The validation requirements for security updates in Section 15.11 create ongoing costs for qualifying platform changes and validating application compatibility. Organizations must budget for accelerated validation cycles to ensure security updates don’t result in unsupported systems.

Inspection and Enforcement: The New Reality

Section 15’s detailed technical requirements create specific inspection targets that regulatory authorities can evaluate objectively during facility inspections. Unlike the current Annex 11’s general security provisions, Section 15’s prescriptive requirements enable inspectors to assess compliance through concrete evidence and documentation.

Technical Evidence Requirements emerge from Section 15’s specific mandates for firewalls, network segmentation, patch management, and penetration testing. Inspectors can evaluate firewall configurations, review network topology documentation, assess patch deployment records, and verify penetration testing reports. Organizations must maintain detailed documentation demonstrating compliance with each technical requirement.

The continuous improvement mandate in Section 15.2 creates expectations for ongoing security enhancement activities with documented evidence of threat monitoring and control implementation. Inspectors will expect to see systematic processes for identifying emerging threats and implementing appropriate countermeasures.

Operational Process Validation requirements extend to security operations including incident response, access control management, and backup testing. Section 15.7’s disaster recovery testing requirements create inspection opportunities for validating recovery procedures and verifying RTO achievement1. Organizations must demonstrate that their business continuity plans work effectively through documented testing activities.

The training and testing requirements in Section 15.3 create audit trails for security awareness programs and simulated attack exercises. Inspectors can evaluate training effectiveness through documentation of phishing simulation results, security incident responses, and personnel security behaviors.

Industry Transformation: From Compliance to Competitive Advantage

Organizations that excel at implementing Section 15’s requirements will gain significant competitive advantages through superior operational resilience, reduced cyber risk exposure, and enhanced regulatory relationships. The comprehensive security requirements create opportunities for differentiation through demonstrated cybersecurity maturity.

Supply Chain Security Leadership emerges as pharmaceutical companies with robust cybersecurity capabilities become preferred partners for collaborations, clinical trials, and manufacturing agreements. Section 15’s requirements create third-party evaluation criteria that customers and partners can use to assess supplier cybersecurity capabilities.

The disaster recovery and business continuity requirements in Sections 15.6 and 15.7 create operational resilience that supports supply chain reliability. Organizations that can demonstrate rapid recovery from cyber incidents maintain competitive advantages in markets where supply chain disruptions have significant patient impact.

Regulatory Efficiency Benefits accrue to organizations that proactively implement Section 15’s requirements before they become mandatory. Early implementation demonstrates regulatory leadership and may result in more efficient inspection processes and enhanced regulatory relationships.

The systematic approach to cybersecurity documentation and process validation creates operational efficiencies that extend beyond compliance. Organizations that implement comprehensive cybersecurity management systems often discover improvements in change control, incident response, and operational monitoring capabilities.

Section 15 Security ultimately represents the transformation of pharmaceutical cybersecurity from optional IT initiative to mandatory operational capability that is part of the pharmaceutical quality system. The pharmaceutical industry’s digital future depends on treating cybersecurity as seriously as traditional quality assurance—and Section 15 makes that treatment legally mandatory.

Draft Annex 11 Section 10: “Handling of Data” — Where Digital Reality Meets Data Integrity

Pharmaceutical compliance is experiencing a tectonic shift, and nowhere is that more clear than in the looming overhaul of EU GMP Annex 11. Most quality leaders have been laser-focused on the revised demands for electronic signatures, access management, or supplier oversight—as I’ve detailed in my previous deep analyses, but few realize that Section 10: Handling of Data is the sleeping volcano in the draft. It is here that the revised Annex 11 transforms data handling controls from “do your best and patch with SOPs” into an auditable, digital, risk-based discipline shaped by technological change.

This isn’t about stocking up your data archive or flipping the “audit trail” switch. This is about putting every point of data entry, transfer, migration, and security under the microscope—and making their control, verification, and risk mitigation the default, not the exception. If, until now, your team has managed GMP data with a cocktail of trust, periodic spot checks, and a healthy dose of hope, you are about to discover just how high the bar has been raised.

The Heart of Section 10: Every Data Touchpoint Is Critical

Section 10, as rewritten in the draft Annex 11, isn’t long, but it is dense. Its brevity belies the workload it creates: a mandate for systematizing, validating, and documenting every critical movement or entry of GMP-relevant data. The section is split into four thematic requirements, each of which deserves careful analysis:

Input verification—requiring plausibility checks for all manual entry of critical data,
Data transfer—enforcing validated electronic interfaces and exceptional controls for any manual transcription,
Data migration—demanding that every one-off or routine migration goes through a controlled, validated process,
Encryption—making secure storage and movement of critical data a risk-based expectation, not an afterthought.

Understanding these not as checkboxes but as an interconnected risk-control philosophy is the only way to achieve robust compliance—and to survive inspection without scrambling for a “procedural explanation” for each data error found.

Input Verification: Automating the Frontline Defense

The End of “Operator Skill” as a Compliance Pillar

Human error, for as long as there have been batch records and lab notebooks, has been a known compliance risk. Before electronic records, the answer was redundancy: a second set of eyes, a periodic QC review, or—let’s be realistic—a quick initial on a form the day before an audit. But in the age of digital systems, Section 10.1 recognizes the simple truth: where technology can prevent senseless or dangerous entries, it must.

Manual entry of critical data—think product counts, analytical results, process parameters—is now subject to real-time, system-enforced plausibility checks. Gone are the days when outlandish numbers in a yield calculation raises no flag, or when an analyst logs a temperature outside any physically possible range with little more than a raised eyebrow. Section 10 demands that every critical data field is bounded by logic—ranges, patterns, value consistency checks—and that nonsensical entries are not just flagged but, ideally, rejected automatically.

Any field that is critical to product quality or patient safety must be controlled at the entry point by automated means. If such logic is technically feasible but not deployed, expect intensive regulatory scrutiny—and be prepared to defend, in writing, why it isn’t in place.

Designing Plausibility Controls: Making Them Work

What does this mean on a practical level? It means scoping your process maps and digitized workflows to inventory every manual input touching GMP outcomes. For each, you need to:

Establish plausible ranges and patterns based on historical data, scientific rationale, and risk analysis.
Program system logic to enforce these boundaries, including mandatory explanatory overrides for any values outside “normal.”
Ensure every override is logged, investigated, and trended—because “frequent overrides” typically signal either badly set limits or a process slipping out of control.

But it’s not just numeric entries. Selectable options, free-text assessments, and uploads of evidence (e.g., images or files) must also be checked for logic and completeness, and mechanisms must exist to prevent accidental omissions or nonsensical entries (like uploading the wrong batch report for a product lot).

These expectations put pressure on system design teams and user interface developers, but they also fundamentally change the culture: from one where error detection is post hoc and personal, to one where error prevention is systemic and algorithmic.

Data Transfer: Validated Interfaces as the Foundation

Automated Data Flows, Not “Swivel Chair Integration”

The next Section 10 pillar wipes out the old “good enough” culture of manually keying critical data between systems—a common practice all the way up to the present day, despite decades of technical options to network devices, integrate systems, and use direct data feeds.

In this new paradigm, critical data must be transferred between systems electronically whenever possible. That means, for example, that:

Laboratory instruments should push their results to the LIMS automatically, not rely on an analyst to retype them.
The MES should transmit batch data to ERP systems for release decisions without recourse to copy-pasting or printout scanning.
Environmental monitoring systems should use validated data feeds into digital reports, not rely on handwritten transcriptions or spreadsheet imports.

Where technology blocks this approach—due to legacy equipment, bespoke protocols, or prohibitive costs—manual transfer is only justifiable as an explicitly assessed and mitigated risk. In those rare cases, organizations must implement secondary controls: independent verification by a second person, pre- and post-transfer checks, and logging of every step and confirmation.

What does a validated interface mean in this context? Not just that two systems can “talk,” but that the transfer is:

Complete (no dropped or duplicated records)
Accurate (no transformation errors or field misalignments)
Secure (with no risk of tampering or interception)

Every one of these must be tested at system qualification (OQ/PQ) and periodically revalidated if either end of the interface changes. Error conditions (such as data out of expected range, failed transfers, or discrepancies) must be logged, flagged to the user, and if possible, halt the associated GMP process until resolved.

Practical Hurdles—and Why They’re No Excuse

Organizations will protest: not every workflow can be harmonized, and some labyrinthine legacy systems lack the APIs or connectivity for automation. The response is clear: you can do manual transfer only when you’ve mapped, justified, and mitigated the added risk. This risk assessment and control strategy will be expected, and if auditors spot critical data being handed off by paper (including the batch record) or spreadsheet without robust double verification, you’ll have a finding that’s impossible to “train away.”

Remember, Annex 11’s philosophy flows from data integrity risk, not comfort or habit. In the new digital reality, technically possible is the compliance baseline.

Data Migration: Control, Validation, and Traceability

Migration Upgrades Are Compliance Projects, Not IT Favors

Section 10.3 brings overdue clarity to a part of compliance historically left to “IT shops” rather than Quality or data governance leads: migrations. In recent years, as cloud moves and system upgrades have exploded, so have the risks. Data gaps, incomplete mapping, field mismatches, and “it worked in test but not in prod” errors lurk in every migration, and their impact is enormous—lost batch records, orphaned critical information, and products released with documentation that simply vanished after a system reboot.

Annex 11 lays down a clear gauntlet: all data migrations must be planned, risk-assessed, and validated. Both the sending and receiving platforms must be evaluated for data constraints, and the migration process itself is subject to the same quality rigor as any new computerized system implementation.

This requires a full lifecycle approach:

Pre-migration planning to document field mapping, data types, format and allowable value reconciliations, and expected record counts.
Controlled execution with logs of each action, anomalies, and troubleshooting steps.
Post-migration verification—not just a “looks ok” sample, but a full reconciliation of batch counts, search for missing or duplicated records, and (where practical) data integrity spot checks.
Formal sign-off, with electronic evidence and supporting risk assessment, that the migration did not introduce errors, losses, or uncontrolled transformations.

Validating the Entire Chain, Not Just the Output

Annex 11’s approach is process-oriented. You can’t simply “prove a few outputs match”; you must show that the process as executed controlled, logged, and safeguarded every record. If source data was garbage, destination data will be worse—so validation includes both the “what” and the “how.” Don’t forget to document how you’ll highlight or remediate mismatched or orphaned records for future investigation or reprocessing; missing this step is a quality and regulatory land mine.

It’s no longer acceptable to treat migration as a purely technical exercise. Every migration is a compliance event. If you can’t show the system’s record—start-to-finish—of how, by whom, when, and under what procedural/corrective control migrations have been performed, you are vulnerable on every product released or batch referencing that data.

Encryption: Securing Data as a Business and Regulatory Mandate

Beyond “Defense in Depth” to a Compliance Expectation

Historically, data security and encryption were IT problems, and the GMP justification for employing them was often little stronger than “everyone else is doing it.” The revised Section 10 throws that era in the trash bin. Encryption is now a risk-based compliance requirement for storage and transfer of critical GMP data. If you don’t use strong encryption “where applicable,” you’d better have a risk assessment ready that shows why the threat is minimal or the technical/operational risk of encryption is greater than the gain.

This requirement is equally relevant whether you’re holding batch record files, digital signatures, process parameter archives, raw QC data, or product release records. Security compromises aren’t just a hacking story; they’re a data integrity, fraud prevention, and business continuity story. In the new regulatory mindset, unencrypted critical data is always suspicious. This is doubly so when the data moves through cloud services, outsourced IT, or is ever accessible outside the organization’s perimeter.

Implementing and Maintaining Encryption: Avoiding Hollow Controls

To comply, you need to specify and control:

Encryption standards (e.g., minimum AES-256 for rest and transit)
Robust key management (with access control, periodic audits, and revocation/logging routines)
Documentation for every location and method where data is or isn’t encrypted, with reference to risk assessments
Procedures for regularly verifying encryption status and responding to incidents or suspected compromises

Regulators will likely want to see not only system specifications but also periodic tests, audit trails of encryption/decryption, and readouts from recent patch cycles or vulnerability scans proving encryption hasn’t been silently “turned off” or configured improperly.

Section 10 Is the Hub of the Data Integrity Wheel

Section 10 cannot be treated in isolation. It underpins and is fed by virtually every other control in the GMP computerized system ecosystem.

Input controls support audit trails: If data can be entered erroneously or fraudulently, the best audit trail is just a record of error.
Validated transfers prevent downstream chaos: If system A and system B don’t transfer reliably, everything “downstream” is compromised.
Migrations touch batch continuity and product release: If you lose or misplace records, your recall and investigation responses are instantly impaired.
Encryption protects change control and deviation closure: If sensitive data is exposed, audit trails and signature controls can’t protect you from the consequences.

Risk-Based Implementation: From Doctrine to Daily Practice

The draft’s biggest strength is its honest embrace of risk-based thinking. Every expectation in Section 10 is to be scaled by impact to product quality and patient safety. You can—and must—document decisions for why a given control is (or is not) necessary for every data touchpoint in your process universe.

That means your risk assessment does more than check a box. For every GMP data field, every transfer, every planned or surprise migration, every storage endpoint, you need to:

Identify every way the data could be made inaccurate, incomplete, unavailable, or stolen.
Define controls appropriate both to the criticality of the data and the likelihood and detectability of error or compromise.
Test and document both normal and failure scenarios—because what matters in a recall, investigation, or regulatory challenge is what happens when things go wrong, not just when they go right.

ALCOA+ is codified by these risk processes: accuracy via plausibility checks, completeness via transfer validation, longevity via robust migration and storage; contemporaneity and endurability via encryption and audit linkage.

Handling of Data vs. Previous Guidance and Global Norms

While much of this seems “good practice,” make no mistake: the regulatory expectations have fundamentally changed. In 2011, Annex 11 was silent on specifics, and 21 CFR Part 11 relied on broad “input checks” and an expectation that organizations would design controls relative to what was reasonable at the time.

Now:

Electronic input plausibility is not just a “should” but a “must”—if your system can automate it, you must.
Manual transfer is justified, not assumed; all manual steps must have procedural/methodological reinforcement and evidence logs.
Migration is a qualification event. The entire lifecycle, not just the output, must be documented, trended, and reviewed.
Encryption is an expectation, not a best effort. The risk burden now falls on you to prove why it isn’t needed, not why it is.
Responsibility is on the MAH/manufacturer, not the vendor, IT, or “business owner.” You outsource activity, not liability.

This matches, in setting, recent FDA guidance via Computer Software Assurance (CSA), GAMP 5’s digital risk lifecycle, and every modern data privacy regulation. The difference is that, starting with the new Annex 11, these approaches are not “suggested”—they are codified.

Real-Life Scenarios: Application of Section 10

Imagine a high-speed packaging line. The operator enters the number of rejected vials per shift. In the old regime, the operator could mistype “80” as “800” or enter a negative number during a hasty correction. With section 10 in force, the system simply will not permit it—90% confidence that any such error will be caught before it mars the official record.

Now think about laboratory results—analysts transferring HPLC data into the LIMS manually. Every entry runs a risk of decimal misplacement or sample ID mismatch. Annex 11 now demands full instrument-to-LIMS interfacing (where feasible), and when not, a double verification protocol meticulously executed, logged, and reviewed.

On the migration front, consider upgrading your document management system. The stakes: decades of batch release records. In 2019, you might have planned a database export, a few spot checks, and post-migration validation of “high value” documents. Under the new Annex 11, you require a documented mapping of every critical field, technical and process reconciliation, error reporting, and lasting evidence for defensibility two or ten years from now.

Encryption is now expected as a default. Cloud-hosted data with no encryption? Prepare to be asked why, and to defend your choice with up-to-date, context-specific risk assessments—not hand-waving.

Bringing Section 10 to Life: Steps for Implementation

A successful strategy for aligning to Annex 11 Section 10 begins with an exhaustive mapping of all critical data touchpoints and their methods of entry, transfer, and storage. This is a multidisciplinary process, requiring cooperation among quality, IT, operations, and compliance teams.

For each critical data field or process, define:

The party responsible for its entry and management
The system’s capability for plausibility checking, range enforcement, and error prevention;
Mechanisms to block or correct entry outside expected norms
Methods of data handoff and transfer between systems, with documentation of integration or a procedural justification for unavoidable manual steps
Protocols and evidence logs for validation of both routine transfers and one-off (migration) events

For all manual data handling that remains, create detailed, risk-based procedures for independent verification and trending review. For data migration, walk through an end-to-end lifecycle—pre-migration risk mapping, execution protocols, post-migration review, discrepancy handling, and archiving of all planning/validation evidence.

For storage and transfer, produce a risk matrix for where and how critical data is held, updated, and moved, and deploy encryption accordingly. Document both technical standards and the process for periodic review and incident response.

Quality management is not the sole owner; business leads, system admins, and IT architects must be brought to the table. For every major change, tie change control procedures to a Section 10 review—any new process, upgrade, or integration comes back to data handling risk, with a closing check for automation and procedural compliance.

Regulatory Impact and Inspection Strategy

Regulatory expectations around data integrity are not only becoming more stringent—they are also far more precise and actionable than in the past. Inspectors now arrive prepared and trained to probe deeply into what’s called “data provenance”: that is, the complete, traceable life story of every critical data point. It’s no longer sufficient to show where a value appears in a final batch record or report; regulators want to see how that data originated, through which systems and interfaces it was transferred, how each entry or modification was verified, and exactly what controls were in place (or not in place) at each step.

Gone are the days when, if questioned about persistent risks like error-prone manual transcription, a company could deflect with, “that’s how we’ve always done it.” Now, inspectors expect detailed explanations and justifications for every manual, non-automated, or non-encrypted data entry or transfer. They will require you to produce not just policies but actual logs, complete audit trails, electronic signature evidence where required, and documented decision-making within your risk assessments for every process step that isn’t fully controlled by technology.

In practical terms, this means you must be able to reconstruct and defend the exact conditions and controls present at every point data is created, handled, moved, or modified. If a process relies on a workaround, a manual step, or an unvalidated migration, you will need transparent evidence that risks were understood, assessed, and mitigated—not simply asserted away.

The implications are profound: mastering Section 10 isn’t just about satisfying the regulator. Robust, risk-based data handling is fundamental to your operation’s resilience—improving traceability, minimizing costly errors or data loss, ensuring you can withstand disruption, and enabling true digital transformation across your business. Leaders who excel here will find that their compliance posture translates into real business value, competitive differentiation, and lasting operational stability.

The Bigger Picture: Section 10 as Industry Roadmap

What’s clear is this: Section 10 eliminates the excuses that have long made “data handling risk” a tolerated, if regrettable, feature of pharmaceutical compliance. It replaces them with a pathway for digital, risk-based, and auditable control culture. This is not just for global pharma behemoths—cloud-native startups, generics manufacturers, and even virtual companies reliant on CDMOs must take note. The same expectations now apply to every regulated data touchpoint, wherever in the supply chain or manufacturing lifecycle it lies.

Bringing your controls into compliance with Section 10 is a strategic imperative in 2025 and beyond. Those who move fastest will spend less time and money on post-inspection remediation, operate more efficiently, and have a defensible record for every outcome.

Requirement Area	Annex 11 (2011)	Draft Annex 11 Section 10 (2025)	21 CFR Part 11	GAMP 5 / Best Practice
Input verification	General expectation, not defined	Mandatory for critical manual entry; system logic and boundaries	“Input checks” required, methods not specified	Risk-based, ideally automated
Data transfer	Manual allowed, interface preferred	Validated interfaces wherever possible; strict controls for manual	Implicit through system interface requirements	Automated transfer is the baseline, double checked for manual
Manual transcription	Allowed, requires review	Only justified exceptions; robust secondary verification & documentation	Not directly mentioned	Two-person verification, periodic audit and trending
Data migration	Mentioned, not detailed	Must be planned, risk-assessed, validated, and be fully auditable	Implied via system lifecycle controls	Full protocol: mapping, logs, verification, and discrepancy handling
Encryption	Not referenced	Mandated for critical data; exceptions need documented, defensible risk	Recommended, not strictly required	Default for sensitive data; standard in cloud, backup, and distributed setups
Audit trail for handling	Implied via system change auditing	All data moves and handling steps linked/logged in audit trail	Required for modifications/rest/correction	Integrated with system actions, trended for error and compliance
Manual exceptions	Not formally addressed	Must be justified and mitigated; always subject to periodic review	Not directly stated	Exception management, always with trending, review, and CAPA

Handling of Data as Quality Culture, Not Just IT Control

Section 10 in the draft Annex 11 is nothing less than the codification of real data integrity for the digitalized era. It lays out a field guide for what true GMP data governance looks like—not in the clouds of intention, but in the minutiae of everyday operation. Whether you’re designing a new MES integration, cleaning up the residual technical debt of manual record transfer, or planning the next system migration, take heed: how you handle data when no one’s watching is the new standard of excellence in pharmaceutical quality.

As always, the organizations that embrace these requirements as opportunities—not just regulatory burdens—will build a culture, a system, and a supply chain that are robust, efficient, and genuinely defensible.

Why Using Dictionary Words in Passwords Is a Data Integrity Trap—And What Real Security Looks Like

Let’s not sugarcoat it: if you’re still allowing passwords like “Quality2025!” or “GMPpassword!” anywhere in your regulated workflow, you’re inviting trouble. The era of security theater is over. Modern cyberattacks and regulatory requirements—from NIST to EU GMP Annex 11—demand far more than adding an exclamation point to a dictionary word. It’s time to understand not just why dictionary words are dangerous, but how smart password strategy (including password managers) is now a fundamental part of data integrity and compliance.

In my last post “Draft Annex 11’s Identity & Access Management Changes: Why Your Current SOPs Won’t Cut It”, I discussed the EU’s latest overhaul of Annex 11 as more than incremental: it’s a foundational reset for access control in GxP environments, including password management. In this post I want to expand on those points.

Dictionary Words = Easy Prey

Let’s start with why dictionary words are pure liability. Attackers don’t waste resources guessing random character strings—they leverage enormous “dictionary lists” sourced from real-world breaches, wordlists, and common phrases. Tools like Hashcat or John the Ripper process billions of guesses—including every English word and thousands of easy permutations—faster than you can blink.

This means that passwords like “Laboratory2025” or “Pharma@123” fall within minutes (or seconds) of an attack. Even a special character or a capital letter doesn’t save you, because password-cracking tools automatically try those combinations.

The Verizon Data Breach Investigations Report has put it plainly: dictionary attacks and credential stuffing remain some of the top causes for data compromise. If a GxP system accepts any plain-language word, it’s a red flag for any inspection—and a massive technical vulnerability.

What the Latest NIST Guidance Says

The definitive voice for password policy, the National Institute of Standards and Technology (NIST), made a seismic shift with Special Publication 800-63B (“Digital Identity Guidelines: Authentication and Lifecycle Management”). The relevant part:

“Verifiers SHALL compare…”
NIST 800-63B Section 5.1.1.2 requires your system to check a new password against lists of known bad, common, or compromised passwords—including dictionary words. If it pops up anywhere, it’s out.

But NIST also dispelled the notion that pure complexity (“$” instead of “S”, “0” instead of “o”) provides security. Their new mantra is:

No dictionary words
No user IDs, product names, or predictable info
No passwords ever found in a breach
BUT: do make them long, unique, and easy to use with a password manager

Dictionary Words vs. Passphrases: Not All Words Are Bad—But Phrases Must Be Random

Many people hear “no dictionary words” and assume they must abandon human language. Not so! NIST recommend passphrases made of multiple, unrelated words. For example, random combos like “staple-moon-fence-candle” are immune to dictionary attacks if they’re unguessable and not popular memes or in well-known breach lists.

A password like “correcthorse” is (in 2025) as bad as “password123”—it’s too common. But “refinery-stream-drifter-nomad” is good, provided it’s randomly generated.

Password Managers Are Now an Organizational Baseline

The move away from memorizing or writing down complex passphrases means you need password managers in your toolkit. As I pointed out in my post on password managers and data integrity, modern password management tools:

Eliminate reuse by generating random, unique, breach-checked passwords for every system.
Increase the length and randomness of credentials far beyond what humans will remember.
Support compliance and auditing requirements—if you standardize (don’t let employees use their own random apps).
Can even integrate with MFA (multi-factor authentication) for defense in depth.

Critically, as I discuss in the blog post, password manager selection, configuration, and validation are now GxP and audit-relevant. You must document what solutions are allowed (no “bring your own app”), how you test them, and periodic vulnerability and update checks.

What Are the Best Practices for Passwords in 2025?

Let’s lay it out:

Block all dictionary words, product names, and user IDs.
Your system must reject any password containing recognizable words, no matter the embellishment.
Screen against breach data and block common patterns.
Before accepting a password, check it against up-to-date lists of compromised and weak passwords.
Prioritize password length (minimum 12–16 characters).
Random passphrases win. Four or more truly random words (not famous phrases) are vastly superior to gibberish or short “complex” passwords.
Push for password managers.
Make one or two IT-validated tools mandatory, make it simple, and do the qualification work. See my advice on password manager selection and qualification.
No forced periodic resets without cause.
NIST and ISO 27001 guidance agrees: only reset on suspicion or evidence of compromise, not on a schedule. Forced changes encourage bad habits.
Integrate MFA everywhere possible.
Passwords alone are never enough. Multi-factor authentication is the “fail-safe” for inevitable compromise.
Ongoing user education is vital.
Explain the risks of dictionary passwords and demonstrate how attack tools work. Show users—and your quality team—why policy isn’t just red tape.

Rewrite Your Password Policy—And Modernize Your Tools

Password security has never been just about meeting a checkbox. In regulated industries, your password policy is a direct reflection of your data integrity posture and audit readiness.
Embrace random, unique passphrases. Ban all dictionary words and known patterns. Screen every password against breach data—automatically. Standardize on organization-approved password managers and integrate with MFA whenever possible.

Regulatory expectations from NIST to new draft Annex 11 have joined cybersecurity experts in drawing a clear line: dictionary-word passwords are no longer just bad practice—they’re a compliance landmine.

Draft Annex 11’s Identity & Access Management Changes: Why Your Current SOPs Won’t Cut It

The draft EU Annex 11 Section 11 “Identity and Access Management” reads like a complete demolition of every lazy access-control practice organizations might have been coasting on for years. Gone are the vague handwaves about “appropriate controls.” The new IAM requirements are explicitly designed to eliminate the shared-account shortcuts and password recycling schemes that have made pharma IT security a running joke among auditors.

The regulatory bar for access management has been raised so high that most existing computerized systems will need major overhauls to comply. Organizations that think a username-password combo and quarterly access reviews will satisfy the new requirements are about to learn some expensive lessons about modern data integrity enforcement.

What Makes This Different from Every Other Access Control Update

The draft Annex 11’s Identity and Access Management section is a complete philosophical shift from “trust but verify” to “prove everything, always.” Where the 2011 version offered generic statements about restricting access to “authorised persons,” the 2025 draft delivers 11 detailed subsections that read like a cybersecurity playbook written by paranoid auditors who’ve spent too much time investigating data integrity failures.

This isn’t incremental improvement. Section 11 transforms IAM from a compliance checkbox into a fundamental pillar of data integrity that touches every aspect of how users interact with GMP systems. The draft makes it explicitly clear that poor access controls are considered violations of data integrity—not just security oversights.

European regulators have decided that the EU needs robust—and arguably more prescriptive—guidance for managing user access in an era where cloud services, remote work, and cyber threats have fundamentally changed the risk landscape. The result is regulatory text that assumes bad actors, compromised credentials, and insider threats as baseline conditions rather than edge cases.

The Eleven Subsections That Will Break Your Current Processes

11.1: Unique Accounts – The Death of Shared Logins

The draft opens with a declaration that will send shivers through organizations still using shared service accounts: “All users should have unique and personal accounts. The use of shared accounts except for those limited to read-only access (no data or settings can be changed), constitute a violation of data integrity”.

This isn’t a suggestion—it’s a flat prohibition with explicit regulatory consequences. Every shared “QC_User” account, every “Production_Shift” login, every “Maintenance_Team” credential becomes a data integrity violation the moment this guidance takes effect. The only exception is read-only accounts that cannot modify data or settings, which means most shared accounts used for batch record reviews, approval workflows, and system maintenance will need complete redesign.

The impact extends beyond just creating more user accounts. This sets out the need to address all the legacy systems that have coasted along for years. There are a lot of filter integrity testers, pH meters and balances, among other systems, that will require some deep views.

11.2: Continuous Management – Beyond Set-and-Forget

Where the 2011 Annex 11 simply required that access changes “should be recorded,” the draft demands “continuous management” with timely granting, modification, and revocation as users “join, change, and end their involvement in GMP activities”. The word “timely” appears to be doing significant regulatory work here—expect inspectors to scrutinize how quickly access is updated when employees change roles or leave the organization.

This requirement acknowledges the reality that modern pharmaceutical operations involve constant personnel changes, contractor rotations, and cross-functional project teams. Static annual access reviews become insufficient when users need different permissions for different projects, temporary elevated access for system maintenance, and immediate revocation when employment status changes. The continuous management standard implies real-time or near-real-time access administration that most organizations currently lack.

The operational implications are clear. It is no longer optional not to integrate HR systems with IT provisioning tools and tie it into your GxP systems. Contractor management processes will require pre-defined access templates and automatic expiration dates. Organizations that treat access management as a periodic administrative task rather than a dynamic business process will find themselves fundamentally out of compliance.

11.3: Certain Identification – The End of Token-Only Authentication

Perhaps the most technically disruptive requirement, Section 11.3 mandates authentication methods that “identify users with a high degree of certainty” while explicitly prohibiting “authentication only by means of a token or a smart card…if this could be used by another user”. This effectively eliminates proximity cards, USB tokens, and other “something you have” authentication methods as standalone solutions.

The regulation acknowledges biometric authentication as acceptable but requires username and password as the baseline, with other methods providing “at least the same level of security”. For organizations that have invested heavily in smart card infrastructure or hardware tokens, this represents a significant technology shift toward multi-factor authentication combining knowledge and possession factors.

The “high degree of certainty” language introduces a subjective standard that will likely be interpreted differently across regulatory jurisdictions. Organizations should expect inspectors to challenge any authentication method that could reasonably be shared, borrowed, or transferred between users. This standard effectively rules out any authentication approach that doesn’t require active user participation—no more swiping someone else’s badge to help them log in during busy periods.

Biometric systems become attractive under this standard, but the draft doesn’t provide guidance on acceptable biometric modalities, error rates, or privacy considerations. Organizations implementing fingerprint, facial recognition, or voice authentication systems will need to document the security characteristics that meet the “high degree of certainty” requirement while navigating European privacy regulations that may restrict biometric data collection.

11.4: Confidential Passwords – Personal Responsibility Meets System Enforcement

The draft’s password confidentiality requirements combine personal responsibility with system enforcement in ways that current pharmaceutical IT environments rarely support. Section 11.4 requires passwords to be “kept confidential and protected from all other users, both at system and at a personal level” while mandating that “passwords received from e.g. a manager, or a system administrator should be changed at the first login, preferably required by the system”1.

This requirement targets the common practice of IT administrators assigning temporary passwords that users may or may not change, creating audit trail ambiguity about who actually performed specific actions. The “preferably required by the system” language suggests that technical controls should enforce password changes rather than relying on user compliance with written procedures.

The personal responsibility aspect extends beyond individual users to organizational accountability. Companies must demonstrate that their password policies, training programs, and technical controls work together to prevent password sharing, writing passwords down, or other practices that compromise authentication integrity. This creates a documentation burden for organizations to prove that their password management practices support data integrity objectives.

11.5: Secure Passwords – Risk-Based Complexity That Actually Works

Rather than mandating specific password requirements, Section 11.5 takes a risk-based approach that requires password rules to be “commensurate with risks and consequences of unauthorised changes in systems and data”. For critical systems, the draft specifies passwords should be “of sufficient length to effectively prevent unauthorised access and contain a combination of uppercase, lowercase, numbers and symbols”.

The regulation prohibits common password anti-patterns: “A password should not contain e.g. words that can be found in a dictionary, the name of a person, a user id, product or organisation, and should be significantly different from a previous password”. This requirement goes beyond basic complexity rules to address predictable password patterns that reduce security effectiveness.

The risk-based approach means organizations must document their password requirements based on system criticality assessments. Manufacturing control systems, quality management databases, and regulatory submission platforms may require different password standards than training systems or general productivity applications. This creates a classification burden where organizations must justify their password requirements through formal risk assessments.

“Sufficient length” and “significantly different” introduce subjective standards that organizations must define and defend. Expect regulatory discussions about whether 8-character passwords meet the “sufficient length” requirement for critical systems, and whether changing a single character constitutes “significantly different” from previous passwords.

11.6: Strong Authentication – MFA for Remote Access

Section 11.6 represents the draft’s most explicit cybersecurity requirement: “Remote authentication on critical systems from outside controlled perimeters, should include multifactor authentication (MFA)”. This requirement acknowledges the reality of remote work, cloud services, and mobile access to pharmaceutical systems while establishing clear security expectations.

The “controlled perimeters” language requires organizations to define their network security boundaries and distinguish between internal and external access. Users connecting from corporate offices, manufacturing facilities, and other company-controlled locations may use different authentication methods than those connecting from home, hotels, or public networks.

“Critical systems” must be defined through risk assessment processes, creating another classification requirement. Organizations must identify which systems require MFA for remote access and document the criteria used for this determination. Laboratory instruments, manufacturing equipment, and quality management systems will likely qualify as critical, but organizations must make these determinations explicitly.

The MFA requirement doesn’t specify acceptable second factors, leaving organizations to choose between SMS codes, authenticator applications, hardware tokens, biometric verification, or other technologies. However, the emphasis on security effectiveness suggests that easily compromised methods like SMS may not satisfy regulatory expectations for critical system access.

Draft Annex 11, Section 13: What the Proposed Electronic Signature Rules Mean

11.7: Auto Locking – Administrative Controls for Security Failures

Account lockout requirements in Section 11.7 combine automated security controls with administrative oversight in ways that current pharmaceutical systems rarely implement effectively. The draft requires accounts to be “automatically locked after a pre-defined number of successive failed authentication attempts” with “accounts should only be unlocked by the system administrator after it has been confirmed that this was not part of an unauthorised login attempt or after the risk for such attempt has been removed”.

This requirement transforms routine password lockouts from simple user inconvenience into formal security incident investigations. System administrators cannot simply unlock accounts upon user request—they must investigate the failed login attempts and document their findings before restoring access. For organizations with hundreds or thousands of users, this represents a significant administrative burden that requires defined procedures and potentially additional staffing.

The “pre-defined number” must be established through risk assessment and documented in system configuration. Three failed attempts may be appropriate for highly sensitive systems, while five or more attempts might be acceptable for lower-risk applications. Organizations must justify their lockout thresholds based on balancing security protection with operational efficiency.

“Unauthorised login attempt” investigations require forensic capabilities that many pharmaceutical IT organizations currently lack. System administrators must be able to analyze login patterns, identify potential attack signatures, and distinguish between user errors and malicious activity. This capability implies enhanced logging, monitoring tools, and security expertise that extends beyond traditional IT support functions.

11.8: Inactivity Logout – Session Management That Users Cannot Override

Session management requirements in Section 11.8 establish mandatory timeout controls that users cannot circumvent: “Systems should include an automatic inactivity logout, which logs out a user after a defined period of inactivity. The user should not be able to change the inactivity logout time (outside defined and acceptable limits) or deactivate the functionality”.

The requirement for re-authentication after inactivity logout means users cannot simply resume their sessions—they must provide credentials again, creating multiple authentication points throughout extended work sessions. This approach prevents unauthorized access to unattended workstations while ensuring that long-running analytical procedures or batch processing operations don’t compromise security.

“Defined and acceptable limits” requires organizations to establish timeout parameters based on risk assessment while potentially allowing users some flexibility within security boundaries. A five-minute timeout might be appropriate for systems that directly impact product quality, while 30-minute timeouts could be acceptable for documentation or training applications.

The prohibition on user modification of timeout settings eliminates common workarounds where users extend session timeouts to avoid frequent re-authentication. System configurations must enforce these settings at a level that prevents user modification, requiring administrative control over session management parameters.

11.9: Access Log – Comprehensive Authentication Auditing

Section 11.9 establishes detailed logging requirements that extend far beyond basic audit trail functionality: “Systems should include an access log (separate, or as part of the audit trail) which, for each login, automatically logs the username, user role (if possible, to choose between several roles), the date and time for login, the date and time for logout (incl. inactivity logout)”.

The “separate, or as part of the audit trail” language recognizes that authentication events may need distinct handling from data modification events. Organizations must decide whether to integrate access logs with existing audit trail systems or maintain separate authentication logging capabilities. This decision affects log analysis, retention policies, and regulatory presentation during inspections.

Role logging requirements are particularly significant for organizations using role-based access control systems. Users who can assume different roles during a session (QC analyst, batch reviewer, system administrator) must have their role selections logged with each login event. This requirement supports accountability by ensuring auditors can determine which permissions were active during specific time periods.

The requirement for logs to be “sortable and searchable, or alternatively…exported to a tool which provides this functionality” establishes performance standards for authentication logging systems. Organizations cannot simply capture access events—they must provide analytical capabilities that support investigation, trend analysis, and regulatory review.

11.10: Guiding Principles – Segregation of Duties and Least Privilege

Section 11.10 codifies two fundamental security principles that transform access management from user convenience to risk mitigation: “Segregation of duties, i.e. that users who are involved in GMP activities do not have administrative privileges” and “Least privilege principle, i.e. that users do not have higher access privileges than what is necessary for their job function”.

Segregation of duties eliminates the common practice of granting administrative rights to power users, subject matter experts, or senior personnel who also perform GMP activities. Quality managers cannot also serve as system administrators. Production supervisors cannot have database administrative privileges. Laboratory directors cannot configure their own LIMS access permissions. This separation requires organizations to maintain distinct IT support functions independent from GMP operations.

The least privilege principle requires ongoing access optimization rather than one-time role assignments. Users should receive minimum necessary permissions for their specific job functions, with temporary elevation only when required for specific tasks. This approach conflicts with traditional pharmaceutical access management where users often accumulate permissions over time or receive broad access to minimize support requests.

Implementation of these principles requires formal role definition, access classification, and privilege escalation procedures. Organizations must document job functions, identify minimum necessary permissions, and establish processes for temporary access elevation when users need additional capabilities for specific projects or maintenance activities.

11.11: Recurrent Reviews – Documented Access Verification

The final requirement establishes ongoing access governance through “recurrent reviews where managers confirm the continued access of their employees in order to detect accesses which should have been changed or revoked during daily operation, but were accidentally forgotten”. This requirement goes beyond periodic access reviews to establish manager accountability for their team’s system permissions.

Manager confirmation creates personal responsibility for access accuracy rather than delegating reviews to IT or security teams. Functional managers must understand what systems their employees access, why those permissions are necessary, and whether access levels remain appropriate for current job responsibilities. This approach requires manager training on system capabilities and access implications.

Role-based access reviews extend the requirement to organizational roles rather than just individual users: “If user accounts are managed by means of roles, these should be subject to the same kind of reviews, where the accesses of roles are confirmed”. Organizations using role-based access control must review role definitions, permission assignments, and user-to-role mappings with the same rigor applied to individual account reviews.

Documentation and action requirements ensure that reviews produce evidence and corrections: “The reviews should be documented, and appropriate action taken”. Organizations cannot simply perform reviews—they must record findings, document decisions, and implement access modifications identified during the review process.

Risk-based frequency allows organizations to adjust review cycles based on system criticality: “The frequency of these reviews should be commensurate with the risks and consequences of changes in systems and data made by unauthorised individuals”. Critical manufacturing systems may require monthly reviews, while training systems might be reviewed annually.

How This Compares to 21 CFR Part 11 and Current Best Practices

The draft Annex 11’s Identity and Access Management requirements represent a significant advancement over 21 CFR Part 11, which addressed access control through basic authority checks and user authentication rather than comprehensive identity management. Part 11’s requirement for “at least two distinct identification components” becomes the foundation for much more sophisticated authentication and access control frameworks.

Multi-factor authentication requirements in the draft Annex 11 exceed Part 11 expectations by mandating MFA for remote access to critical systems, while Part 11 remains silent on multi-factor approaches. This difference reflects 25 years of cybersecurity evolution and acknowledges that username-password combinations provide insufficient protection for modern threat environments.

Current data integrity best practices have evolved toward comprehensive access management, risk-based authentication, and continuous monitoring—approaches that the draft Annex 11 now mandates rather than recommends. Organizations following ALCOA+ principles and implementing robust access controls will find the new requirements align with existing practices, while those relying on minimal compliance approaches will face significant gaps.

The Operational Reality of Implementation

Three major implementation areas of AIM represented graphically

System Architecture Changes

Most pharmaceutical computerized systems were designed assuming manual access management and periodic reviews would satisfy regulatory requirements. The draft Annex 11 requirements will force fundamental architecture changes including:

Identity Management Integration: Manufacturing execution systems, laboratory information management systems, and quality management platforms must integrate with centralized identity management systems to support continuous access management and role-based controls.

Authentication Infrastructure: Organizations must deploy multi-factor authentication systems capable of supporting diverse user populations, remote access scenarios, and integration with existing applications.

Logging and Monitoring: Enhanced access logging requirements demand centralized log management, analytical capabilities, and integration between authentication systems and audit trail infrastructure.

Session Management: Applications must implement configurable session timeout controls, prevent user modification of security settings, and support re-authentication without disrupting long-running processes.

Process Reengineering Requirements

The regulatory requirements will force organizations to redesign fundamental access management processes:

Continuous Provisioning: HR onboarding, role changes, and termination processes must trigger immediate access modifications rather than waiting for periodic reviews.

Manager Accountability: Access review processes must shift from IT-driven activities to manager-driven confirmations with documented decision-making and corrective actions.

Risk-Based Classification: Organizations must classify systems based on criticality, define access requirements accordingly, and maintain documentation supporting these determinations.

Incident Response: Account lockout events must trigger formal security investigations rather than simple password resets, requiring enhanced forensic capabilities and documented procedures.

Training and Cultural Changes

Implementation success requires significant organizational change management:

Manager Training: Functional managers must understand system capabilities, access implications, and review responsibilities rather than delegating access decisions to IT teams.

User Education: Password security, MFA usage, and session management practices require user training programs that emphasize data integrity implications rather than just security compliance.

IT Skill Development: System administrators must develop security investigation capabilities, risk assessment skills, and regulatory compliance expertise beyond traditional technical support functions.

Audit Readiness: Organizations must prepare to demonstrate access control effectiveness through documentation, metrics, and investigative capabilities during regulatory inspections.

Strategic Implementation Approach

The Annex 11 Draft is just taking good cybersecurity and enshrining it more firmly in the GMPs. Organizations should not wait for the effective version to implement. Get that budget prioritized and start now.

Phase 1: Assessment and Classification

Organizations should begin with comprehensive assessment of current access control practices against the new requirements:

System Inventory: Catalog all computerized systems used in GMP activities, identifying shared accounts, authentication methods, and access control capabilities.
Risk Classification: Determine which systems qualify as “critical” requiring enhanced authentication and access controls.
Gap Analysis: Compare current practices against each subsection requirement, identifying technical, procedural, and training gaps.
Compliance Timeline: Develop implementation roadmap aligned with expected regulatory effective dates and system upgrade cycles.

Phase 2: Infrastructure Development

Focus on foundational technology changes required to support the new requirements:

Identity Management Platform: Deploy or enhance centralized identity management systems capable of supporting continuous provisioning and role-based access control.
Multi-Factor Authentication: Implement MFA systems supporting diverse authentication methods and integration with existing applications.
Enhanced Logging: Deploy log management platforms capable of aggregating, analyzing, and presenting access events from distributed systems.
Session Management: Upgrade applications to support configurable timeout controls and prevent user modification of security settings.

Phase 3: Process Implementation

Redesign access management processes to support continuous management and enhanced accountability:

Provisioning Automation: Integrate HR systems with IT provisioning tools to support automatic access changes based on employment events.
Manager Accountability: Train functional managers on access review responsibilities and implement documented review processes.
Security Incident Response: Develop procedures for investigating account lockouts and documenting security findings.
Audit Trail Integration: Ensure access events are properly integrated with existing audit trail review and batch release processes.

Phase 4: Validation and Documentation

When the Draft becomes effective you’ll be ready to complete validation activities demonstrating compliance with the new requirements:

Access Control Testing: Validate that technical controls prevent unauthorized access, enforce authentication requirements, and log security events appropriately.
Process Verification: Demonstrate that access management processes support continuous management, manager accountability, and risk-based reviews.
Training Verification: Document that personnel understand their responsibilities for password security, session management, and access control compliance.
Audit Readiness: Prepare documentation, metrics, and investigative capabilities required to demonstrate compliance during regulatory inspections.

The Competitive Advantage of Early Implementation

Organizations that proactively implement the draft Annex 11 IAM requirements will gain significant advantages beyond regulatory compliance:

Enhanced Security Posture: The access control improvements provide protection against cyber threats, insider risks, and accidental data compromise that extend beyond GMP applications to general IT security.
Operational Efficiency: Automated provisioning, role-based access, and centralized identity management reduce administrative overhead while improving access accuracy.
Audit Confidence: Comprehensive access logging, manager accountability, and continuous management provide evidence of control effectiveness that regulators and auditors will recognize.
Digital Transformation Enablement: Modern identity and access management infrastructure supports cloud adoption, mobile access, and advanced analytics initiatives that drive business value.
Risk Mitigation: Enhanced access controls reduce the likelihood of data integrity violations, security incidents, and regulatory findings that can disrupt operations and damage reputation.

Looking Forward: The End of Security Theater

The draft Annex 11’s Identity and Access Management requirements represent the end of security theater in pharmaceutical access control. Organizations can no longer satisfy regulatory expectations through generic policies and a reliance on periodic reviews to provide the appearance of control without actual security effectiveness.

The new requirements assume that user access is a continuous risk requiring active management, real-time monitoring, and ongoing verification. This approach aligns with modern cybersecurity practices while establishing regulatory expectations that reflect the actual threat environment facing pharmaceutical operations.

Implementation success will require significant investment in technology infrastructure, process reengineering, and organizational change management. However, organizations that embrace these requirements as opportunities for security improvement rather than compliance burdens will build competitive advantages that extend far beyond regulatory satisfaction.

The transition period between now and the expected 2026 effective date provides a ideal window for organizations to assess their current practices, develop implementation strategies, and begin the technical and procedural changes required for compliance. Organizations that delay implementation risk finding themselves scrambling to achieve compliance while their competitors demonstrate regulatory leadership through proactive adoption.

For pharmaceutical organizations serious about data integrity, operational security, and regulatory compliance, the draft Annex 11 IAM requirements aren’t obstacles to overcome—they’re the roadmap to building access control practices worthy of the products and patients we serve. The only question is whether your organization will lead this transformation or follow in the wake of those who do.

Requirement	Current Annex 11 (2011)	Draft Annex 11 Section 11 (2025)	21 CFR Part 11
User Account Management	Basic – creation, change, cancellation should be recorded	Continuous management – grant, modify, revoke as users join/change/leave	Basic user management, creation/change/cancellation recorded
Authentication Methods	Physical/logical controls, pass cards, personal codes with passwords, biometrics	Username + password or equivalent (biometrics); tokens/smart cards alone insufficient	At least two distinct identification components (ID code + password)
Password Requirements	Not specified in detail	Secure passwords enforced by systems, length/complexity based on risk, dictionary words prohibited	Unique ID/password combinations, periodic checking/revision required
Multi-factor Authentication	Not mentioned	Required for remote access to critical systems from outside controlled perimeters	Not explicitly required
Access Control Principles	Restrict access to authorized persons	Segregation of duties + least privilege principle explicitly mandated	Authority checks to ensure only authorized individuals access system
Account Lockout	Not specified	Auto-lock after failed attempts, admin unlock only after investigation	Not specified
Session Management	Not specified	Auto inactivity logout with re-authentication required	Not specified
Access Logging	Record identity of operators with date/time	Access log with username, role, login/logout times, searchable/exportable	Audit trails record operator entries and actions
Role-based Access	Not explicitly mentioned	Role-based access controls explicitly required	Authority checks for different functions
Access Reviews	Not specified	Recurrent reviews of user accounts and roles, documented with action taken	Periodic checking of ID codes and passwords
Segregation of Duties	Not mentioned	Users cannot have administrative privileges for GMP activities	Not explicitly stated
Unique User Accounts	Not explicitly required	All users must have unique personal accounts, shared accounts violate data integrity	Each electronic signature unique to one individual
Remote Access Control	Not specified	MFA required for remote access to critical systems	Additional controls for open systems
Password Confidentiality	Not specified	Passwords confidential at system and personal level, change at first login	Password security and integrity controls required
Account Administration	Not detailed	System administrators control unlock, access privilege assignment	Administrative controls over password issuance

NIST SP 800-171

One of the reasons I joined my organization is that I wanted to experience being a Department of Defense contractor. The work Evotec is doing is just super fascinating, so it was hard to resist.

This means I am taking a NIST SP 800-171 crash course as I figure out what it means to comply with Compliance with the Defense Federal Acquisition Regulation Supplement (DFARS) cybersecurity clause 252.204-7012. I swear this makes Part 11 look like the kindergarten it is.

NIST SP 800-17 has 110 security requirements across 14 control families, including:

Access Control
Awareness and Training
Audit and Accountability
Configuration Management
Identification and Authentication
Incident Response
Maintenance
Media Protection
Personnel Security
Physical Protection
Risk Assessment
Security Assessment
System and Communications Protection
System and Information Integrity

It spells out self-assessment and implementation of the security requirements. Organizations must:

Form an assessment team
Create an assessment plan
Collect relevant documents and evidence
Assess individual requirements
Create a plan of action for unmet requirements
Develop a System Security Plan (SSP)

Here’s a comparison of NIST SP 800-171 and ISO 27001 presented in a table format:

Aspect	NIST SP 800-171	ISO 27001
Purpose	Protect Controlled Unclassified Information (CUI) in non-federal systems	Provide framework for Information Security Management System (ISMS)
Scope	Focused on data security for CUI	Broader approach to overall information security management
Origin	U.S. National Institute of Standards and Technology	International Organization for Standardization
Primary Users	U.S. Department of Defense contractors and subcontractors	Organizations worldwide seeking robust information security
Certification	No formal certification process	Offers formal certification through third-party audits
Structure	110 security requirements across 14 families	114 controls across 14 domains (Annex A)
Flexibility	Prescriptive requirements	More flexible, risk-based approach
Mandatory Controls	All requirements are mandatory	No mandatory controls; risk-based selection
International Recognition	Primarily recognized in the U.S.	Globally recognized standard
Cost	Generally less expensive to implement	Can be more costly due to certification process
Maturity Model	Does not include a maturity model	Does not include a maturity model (but compatible with other maturity models)
Documentation	Less extensive documentation requirements	Extensive documentation requirements
Regulatory Compliance	Specific to U.S. DoD contracts	Can be adapted to various regulatory requirements

comparison of NIST SP 800-171 and ISO 27001