Why IEC 62443 Matters Now for Pharma
For most of the history of pharma automation, cybersecurity was an IT department concern. The control system was air-gapped or effectively isolated, and the regulatory frameworks — Annex 11, 21 CFR Part 11 — addressed access control and audit trails but said relatively little about the network layer. That has changed. GAMP 5 2nd Edition (2022) explicitly references IEC 62443 as the recommended cybersecurity standard for computerised systems in GMP environments, and Annex 11 inspection findings increasingly include cybersecurity observations — particularly around network segregation, patch management, and remote access.
The reason IEC 62443 is a good fit for pharma is that it is fundamentally risk-based. It does not mandate specific technologies or configurations — it requires that you identify your assets, assess the threats and vulnerabilities, determine the security level required, and implement controls proportionate to the risk. That is exactly the same logic as GAMP 5 risk-based validation. The standards are not competing; they address the same system from different angles, and integrating them produces a coherent compliance argument rather than two parallel stacks of documentation.
GAMP 5 2nd Edition Chapter 5 (Risk Management) and Appendix M (Cybersecurity) explicitly acknowledge IEC 62443 as the applicable standard for OT cybersecurity. The GAMP 5 position is that cybersecurity risk assessment should be integrated with the GxP risk management process — not treated as a separate workstream. Your RMP-SYS-001 should include cybersecurity threat scenarios alongside functional failure scenarios. Your URS should include cybersecurity requirements derived from the risk assessment. The HDS should document the controls that address those requirements. This is the same V-model logic applied to a different risk domain.
IEC 62443 Structure — What the Standard Actually Says
IEC 62443 is a family of standards, not a single document. The parts most relevant to a pharma automation project are 62443-2-1 (security management for asset owners), 62443-3-2 (security risk assessment for system design), and 62443-3-3 (system security requirements and security levels). You do not need to implement every part — you need to understand which elements apply to a typical pharma SI project and how they map to deliverables you are already producing.
Security Levels — What SL-1, SL-2, SL-3 Mean in Practice
IEC 62443 defines four security levels (SL-1 through SL-4) that describe the capability of an attacker the system is designed to resist. SL-1 protects against casual or unintentional violations — someone accidentally accessing the wrong system. SL-2 protects against intentional violation using simple means — a disgruntled employee or script kiddie with basic tools. SL-3 protects against intentional violation using sophisticated means — a motivated attacker with specialist knowledge. SL-4 is nation-state level threat, rarely relevant to commercial pharma.
Most pharma OT systems are designed to SL-2 for the OT supervision zone and SL-1 for pure field instrumentation. The OT control zone (PLC, safety systems) may warrant SL-2 or SL-3 depending on the consequence of compromise — a PLC managing a sterile filling line has higher consequences than one managing a warehouse conveyor. The target security level (SL-T) is determined during the risk assessment and drives the control requirements. A zone with SL-T 2 must implement all SL-1 controls plus the additional SL-2 controls defined in IEC 62443-3-3.
The Seven Foundational Requirements
IEC 62443-3-3 organises security controls into seven Foundational Requirements (FRs). These are the categories that every security control on a pharma OT system should map to. Understanding them helps you structure both the cybersecurity risk assessment and the HDS security section.
| FR | Foundational Requirement | Pharma OT Examples | Document Ref |
|---|---|---|---|
| FR-1 | Identification and Authentication Control | Unique user IDs, password policy, account lockout, MFA for remote access | HDS §7, SDS §5 (security model), URS-SEC-001 |
| FR-2 | Use Control | Role-based access control, least-privilege, session timeout, operator vs administrator roles | SDS §5, SCADA user management config, OQ Section 7 |
| FR-3 | System Integrity | Software hash verification, integrity checking of validated configuration, write-once audit trail | RBP-SYS-001 (hash log), OQ-021 (SQL adversarial test), IQ hash chain |
| FR-4 | Data Confidentiality | Encrypted communications between SCADA and historian, VPN for remote sessions, SQL Server encryption at rest | HDS §7.2, SOP-ADMIN-SYS-001 |
| FR-5 | Restricted Data Flow | Firewall rule set, VLAN segmentation, DMZ architecture, default-deny policy | HDS §7.3 (firewall rules), IQ network verification |
| FR-6 | Timely Response to Events | Security event logging, audit trail of access denials, NTP synchronisation for forensic timestamps | Audit trail config, NTP SOP, SOP-ADMIN-SYS-001 |
| FR-7 | Resource Availability | Redundant network paths, UPS protection, backup and restore procedure, RTO definition | HDS §1.2 (redundancy), RBP-SYS-001 |
The value of mapping your existing validation deliverables to the seven FRs is that you can demonstrate IEC 62443 alignment without producing separate cybersecurity documents. The HDS already covers FR-5. The SDS security model already covers FR-1 and FR-2. The OQ audit trail tests already cover FR-3 and FR-6. The RBP covers FR-7. A one-page mapping table in the Risk Management Plan is often sufficient to show the cybersecurity controls are addressed.
Integrating Cybersecurity into the GAMP 5 Risk Assessment
The most practical approach on a pharma project is to add a cybersecurity threat section to your existing GAMP 5 risk assessment rather than running a separate cybersecurity risk assessment process. The same risk scoring approach — severity, probability, detectability — applies. The difference is the threat scenarios: instead of "sensor fails high," you are assessing "attacker modifies historian database" or "unauthorised user gains Supervisor role access."
The risk assessment for cybersecurity follows the same logic: identify the asset (historian database), identify the threat (unauthorised modification), assess severity (data integrity compromise — high), assess probability given existing controls (low if write-once SQL enforced and network segmented), assess detectability (medium — audit trail would show the attempt but detection depends on review frequency). The resulting risk level drives whether additional controls are needed.
The cybersecurity scenario that Annex 11 inspectors focus on most is unauthorised modification of GMP records. Not ransomware, not data theft — record falsification. A system where a determined insider could modify a batch record, a historian data point, or an audit trail entry without detection is a data integrity risk, not just a cybersecurity risk. The write-once audit trail, the SQL adversarial test, and the network segmentation that prevents direct database access from the corporate network are all cybersecurity controls serving a data integrity objective. Frame your cybersecurity risk assessment with this priority in mind.
How IEC 62443 Maps to Annex 11
Annex 11 does not reference IEC 62443 by name, but its requirements in §12 (Security) and §11 (Audit Trails) map directly to the IEC 62443 framework. Understanding the mapping lets you satisfy both requirements with the same controls rather than treating them as parallel obligations.
| Annex 11 Requirement | IEC 62443 FR | Control Implementation |
|---|---|---|
| §12.1 — Physical and logical access controls | FR-1, FR-2 | Role-based access, unique IDs, password policy, physical server room access |
| §12.3 — Network security, segregation | FR-5 | VLAN segmentation, DMZ, firewall rule set, default-deny |
| §11 — Audit trails, tamper-evident records | FR-3, FR-6 | Write-once SQL, audit trail integrity verification, NTP-synchronised timestamps |
| §7.1 — Data storage, backup | FR-7 | Daily backup, off-site copy, RTO ≤4h, hash verification on restore |
| §12.4 — Security incident management | FR-6 | Security event logging, access denial alerts, incident response procedure |
What the System Integrator Delivers
On a pharma project where the SI is responsible for system design and delivery, the cybersecurity deliverables are typically: a cybersecurity section in the URS (requirements), a network security architecture in the HDS (design), a security controls verification in the IQ (implementation check), and cybersecurity test cases in the OQ (functional verification). These are not additional documents — they are sections within the existing GAMP validation package.
The most common mistake SIs make is treating cybersecurity as an afterthought addressed in a single paragraph in the HDS. By the time you are in IQ, there is no mechanism to verify a paragraph. A structured firewall rule set, a documented VLAN assignment table, and specific IQ test steps for each security control are what allows the IQ team to actually verify the cybersecurity architecture. The OT network architecture documentation and the network segmentation and firewall rule set are the engineering deliverables that make IEC 62443 compliance verifiable rather than asserted.
The QLean Framework integrates cybersecurity throughout the validation package rather than treating it as a separate workstream. HDS-SYS-001 Section 7 covers the network security architecture with zone definitions and firewall rules structured for IQ verification. The RMP-SYS-001 risk management plan includes cybersecurity threat scenarios alongside functional failure scenarios, with the same scoring methodology. URS-SYS-001 Section 8 contains cybersecurity requirements (URS-CYB-001 series) that drive the HDS network design. IQ-SYS-001 includes cybersecurity verification steps that map directly to the HDS firewall rules and VLAN assignments. This traceability — from URS requirement through HDS design to IQ verification — is what satisfies both GAMP 5 and IEC 62443 without doubling the documentation effort.
Supplier Cybersecurity Requirements
IEC 62443-2-1 places obligations on asset owners to manage the cybersecurity of their supply chain. In practice this means the pharma client's supplier assessment process — which you are going through as the SI — should include cybersecurity questions. The GAMP 5 supplier assessment process covers cybersecurity competence in the SAQ: whether you follow IEC 62443, how you manage default credentials, what your remote access controls are, and whether you include a cybersecurity risk assessment as a standard project deliverable. If your answer to those questions is no, the risk assessment in the SAR will flag it as a gap, which becomes a contractual condition before the project starts.
As an SI entering pharma for the first time, being able to describe your cybersecurity approach in IEC 62443 terms — zones and conduits, security levels, foundational requirements — is increasingly a differentiator. Pharma clients and their QA teams are becoming more sophisticated about OT cybersecurity. An SI who can speak the language and deliver the documentation has a meaningful advantage over one who delivers a system that works but cannot be audited.