Cybersecurity Controls for GMP Computerized Systems

Cybersecurity is part of maintaining data integrity, system availability, and the validated state. A cyber incident can alter regulated records, disable critical controls, interrupt manufacturing or laboratory operations, expose privileged credentials, or prevent retrieval of information required for product-quality decisions.

Cybersecurity controls should therefore be integrated into computerized-system governance, validation planning, infrastructure qualification, supplier management, change control, incident response, periodic review, and retirement. They should not be treated as a separate Information Technology activity with no connection to GMP risk.

The objective is not to prove that a system is immune from attack. It is to establish proportionate controls that prevent, detect, contain, investigate, and recover from cybersecurity events while protecting product quality, patient safety, trustworthy records, and continued operation.

Regulatory and Quality-System Context

GMP regulations do not prescribe a single cybersecurity framework, firewall design, patch schedule, or malware-protection product. They do require computerized systems and records to remain controlled, reliable, protected, and available for their intended use.

Under 21 CFR 211.68, appropriate controls must be exercised over computer systems, authorized changes must be controlled, and backup data must be exact, complete, and protected from alteration, erasure, or loss.

For applicable electronic records, 21 CFR 11.10 addresses validation, record protection, system access, operational checks, authority checks, device checks, audit trails, and documentation controls.

A compromised account, malicious configuration change, disabled audit trail, ransomware event, or unavailable database can therefore become a GMP compliance issue when it affects a regulated process or record.

Cybersecurity and the Validated State

The validated state means that the computerized system remains suitable for its approved intended use under controlled conditions.

Cybersecurity can affect the validated state by changing or disabling:

• application software;
• operating systems;
• database software;
• infrastructure;
• configuration;
• user access;
• audit trails;
• interfaces;
• calculations;
• reports;
• time synchronization;
• security controls;
• backup functions;
• and system availability.

A security patch can protect the system but also introduce functional or compatibility risk. Conversely, postponing a patch can leave the system exposed to exploitation. Both decisions require documented assessment.

Cybersecurity risk management should therefore balance:

• threat and vulnerability exposure;
• product and patient impact;
• data-integrity impact;
• availability requirements;
• system support status;
• patch urgency;
• technical dependencies;
• verification needs;
• and operational constraints.

Integrating Cybersecurity with Computerized System Validation

Cybersecurity requirements should be incorporated into the computerized-system validation lifecycle when security controls protect regulated records, critical functions, system availability, or recovery capability. They should not be maintained only in separate Information Technology or security documentation.

The validation strategy should identify which cybersecurity controls are:

• part of the application’s intended use;
• necessary to protect data integrity;
• necessary to restrict regulated functions and records;
• required for system availability or recovery;
• implemented through application configuration;
• implemented through qualified infrastructure;
• provided by a supplier or cloud service;
• or maintained through procedural controls.

Not every enterprise cybersecurity control requires separate application-level validation. The required assurance should reflect the control’s relationship to the system’s intended GxP use and the consequence of its failure. Shared infrastructure controls may be qualified or assessed centrally, while application-specific configuration and functionality should be verified within the application-validation scope.

Cybersecurity should be reflected in applicable validation deliverables:

Cybersecurity verification should use objective evidence appropriate to the control. Evidence may include approved configuration records, access tests, firewall-rule verification, security-log review, vulnerability reports, supplier documentation, alert challenges, backup-restoration results, and incident-response exercises.

A cybersecurity weakness does not automatically invalidate the entire computerized system. Its effect on the validated state should be determined through documented impact assessment considering the affected function, records, exposure, exploitability, existing controls, detectability, and actual or potential GMP consequences.

Cybersecurity Lifecycle

A useful cybersecurity lifecycle follows six coordinated functions:

1. Govern;
2. Identify;
3. Protect;
4. Detect;
5. Respond;
6. Recover.

These functions align with the NIST Cybersecurity Framework 2.0. For GMP use, their outputs should connect to system ownership, risk assessment, validation evidence, change control, deviations, incident investigation, recovery, and periodic review.

These cybersecurity functions support but do not replace the computerized-system validation lifecycle. Cybersecurity requirements and controls should be incorporated into validation planning, specifications, risk assessment, verification, release, change control, and periodic review when they protect intended GxP functions, regulated records, data integrity, or system availability.

Governance and Responsibilities

Cybersecurity governance should establish:

• accountable management;
• system ownership;
• process ownership;
• infrastructure ownership;
• Quality oversight;
• security responsibilities;
• supplier responsibilities;
• escalation pathways;
• risk-acceptance authority;
• and incident decision authority.

Responsibilities should be coordinated rather than divided into isolated technical and quality functions.

Information Technology or security personnel may identify a vulnerability and recommend technical controls. The system owner and process owner should evaluate operational and data impact. Validation personnel should determine required verification. The Quality unit should provide oversight when the issue can affect GMP processes, records, release decisions, or the validated state.

Governance documents should define when cybersecurity events require:

• technical incident records;
• GMP deviations;
• data-integrity assessment;
• change control;
• investigation;
• revalidation;
• regulatory evaluation;
• supplier escalation;
• and management notification.

System Inventory

Effective cybersecurity control begins with an accurate system inventory. The inventory should identify, as applicable:

• system name and owner;
• business process;
• intended use;
• GxP classification;
• criticality;
• application version;
• operating system;
• database;
• server or cloud service;
• network location;
• interfaces;
• endpoints;
• supplier;
• support status;
• remote-access method;
• privileged accounts;
• backup arrangement;
• and security-monitoring coverage.

Infrastructure components and supporting services should not be omitted. An application can remain vulnerable through an unsupported operating system, database, network appliance, remote-access service, identity provider, or backup agent.

The inventory should include inactive or legacy systems that retain regulated records. A system does not cease to require protection merely because it no longer processes new transactions.

System Criticality

Cybersecurity criticality should reflect how system compromise or unavailability could affect:

• product quality;
• patient safety;
• regulated decisions;
• critical process controls;
• material or product status;
• laboratory results;
• batch release;
• data integrity;
• electronic records;
• business continuity;
• and recovery capability.

Criticality should not be based only on system size, technology, or department.

A small standalone application performing a critical calculation may require stronger protection than a large administrative platform. An infrastructure component may become critical because several validated applications depend on it.

Criticality should influence control strength, monitoring, response priority, restoration priority, vulnerability-remediation urgency, and periodic-review scope.

Supported Versions and Obsolescence

Systems should use supported software and firmware versions whenever reasonably achievable. The organization should monitor support status for:

• application software;
• operating systems;
• databases;
• middleware;
• browsers;
• virtual platforms;
• network devices;
• security appliances;
• backup software;
• instrument firmware;
• and cloud-service components.

Unsupported technology may no longer receive:

• security patches;
• vulnerability corrections;
• compatibility updates;
• malware signatures;
• technical support;
• or reliable recovery assistance.

Continued use of unsupported technology should be justified through documented risk assessment and compensating controls.

Possible controls include:

• network isolation;
• removal of internet access;
• restricted user access;
• blocked removable media;
• enhanced monitoring;
• application allowlisting;
• protected backups;
• reduced functionality;
• virtualized preservation;
• and accelerated replacement planning.

Obsolescence should be included in periodic review and retirement planning.

Secure Configuration

Secure configuration establishes an approved technical baseline that reduces unnecessary exposure. The baseline may address:

• enabled services;
• open ports;
• local accounts;
• default credentials;
• authentication;
• password settings;
• multifactor authentication;
• firewall rules;
• remote access;
• logging;
• audit policies;
• encryption;
• removable media;
• malware protection;
• time synchronization;
• database settings;
• browser settings;
• and automatic-update behavior.

Unused services, software, accounts, and communication paths should be disabled or removed when practical.

Security-hardening recommendations should be assessed against the system’s intended use, supplier support, validated configuration, performance, and recovery requirements. Generic hardening should not be applied blindly when it could disable required GMP functions or invalidate supplier support.

The approved configuration should be documented as part of the controlled baseline and verified during installation, qualification, release, and relevant changes. Security requirements should be traceable to the applicable design or configuration specification, implemented setting, verification evidence, deviation, and release decision. Evidence may include approved configuration records, system-generated exports, screenshots, firewall-rule records, account settings, security-agent status, and executed test results. The as-built security configuration should be included in or referenced by the controlled system baseline.

Defense in Depth

No single control should be relied upon to protect a critical GMP system. Defense in depth uses multiple coordinated controls, including:

• network segmentation;
• firewalls;
• secure configuration;
• identity and access control;
• privileged-access restrictions;
• malware protection;
• vulnerability management;
• security monitoring;
• backup protection;
• and incident response.

If one control fails, another should reduce the likelihood or consequence of compromise.

The design should recognize the difference between enterprise Information Technology and operational technology. Manufacturing-control systems, instruments, laboratory equipment, building systems, and environmental-monitoring platforms may have unique availability, performance, safety, supplier-support, and patching constraints.

NIST SP 800-82 Rev. 3, Guide to Operational Technology Security, provides guidance for securing operational technology while considering its reliability, safety, and performance requirements.

Network Segmentation

Network segmentation separates systems into controlled zones based on risk, function, trust, and required communication. Segmentation can reduce:

• unauthorized access;
• lateral movement;
• malware propagation;
• accidental communication;
• exposure of legacy systems;
• and the effect of a compromised enterprise endpoint.

A segmented architecture may distinguish:

• enterprise networks;
• user networks;
• server networks;
• manufacturing networks;
• laboratory networks;
• operational-technology zones;
• controlled interface zones;
• backup networks;
• supplier-access zones;
• and critical-system enclaves.

Segmentation should be supported by documented network diagrams, data flows, firewall rules, required protocols, approved source and destination addresses, and responsible owners.

The presence of separate subnets does not establish effective segmentation unless communication between them is restricted and monitored.

Firewalls and Communication Rules

Firewalls should permit only necessary communication between approved sources and destinations. Rules should define:

• source;
• destination;
• port;
• protocol;
• direction;
• purpose;
• owner;
• approval;
• and review frequency.

Broad rules such as “allow any” should be avoided unless technically necessary, documented, and supported by compensating controls.

Firewall changes should be assessed for their effect on:

• application communication;
• interfaces;
• remote access;
• backup;
• monitoring;
• time synchronization;
• identity services;
• and recovery.

Periodic rule review should remove obsolete, duplicate, temporary, or unjustified access.

Remote Access

Remote access introduces a controlled pathway into the regulated environment and should be enabled only when justified. Controls should include:

• approved users;
• unique accounts;
• multifactor authentication;
• managed endpoints;
• encrypted connections;
• time-limited authorization;
• restricted destinations;
• least privilege;
• session monitoring;
• activity logging;
• supplier supervision where appropriate;
• and prompt access removal.

Standing supplier access should be avoided when temporary, approved access can meet the support need.

Remote sessions should not bypass application access controls, change control, or data-integrity requirements. Actions taken remotely should remain attributable.

Emergency remote access should be documented and retrospectively reviewed.

Privileged Access

Privileged accounts can modify software, configuration, security controls, databases, logs, backups, and user access. Their compromise can directly affect the validated state. Privileged-access controls should address:

• named administrator accounts;
• least privilege;
• segregation of duties;
• independent authorization;
• multifactor authentication;
• credential vaulting;
• password or secret rotation;
• emergency accounts;
• service accounts;
• session logging;
• and periodic access review.

Administrators should not routinely perform regulated business activities using privileged accounts.

Where supplier administrators or cloud-provider personnel can access customer environments or data, responsibilities, monitoring, notification, and audit rights should be defined contractually.

See User Access, Privileged Accounts, and Electronic Signatures for the complete access-control framework.

Malware Protection

Malware controls may include:

• endpoint protection;
• antivirus software;
• application allowlisting;
• behavioral detection;
• email filtering;
• web filtering;
• removable-media control;
• file scanning;
• and network-based detection.

The selected control should be compatible with the application, operating system, performance requirements, and supplier recommendations.

For systems that cannot support conventional endpoint protection, alternatives may include:

• network isolation;
• application allowlisting;
• controlled file-transfer stations;
• removable-media scanning;
• restricted administration;
• enhanced monitoring;
• and tightly controlled supplier access.

Malware-signature or detection-engine updates should be managed so that protection remains current without causing uncontrolled system changes or performance problems.

Vulnerability Monitoring

The organization should monitor vulnerabilities affecting its inventory. Sources may include:

• supplier notifications;
• security advisories;
• vulnerability-scanning tools;
• government alerts;
• cloud-provider notices;
• threat intelligence;
• penetration-test findings;
• and incident investigations.

The assessment should determine:

• whether the affected product and version are present;
• whether the vulnerable function is enabled;
• whether the system is exposed;
• whether exploitation is known;
• whether a patch is available;
• whether supplier support exists;
• and what GMP consequences could result.

The CISA Known Exploited Vulnerabilities Catalog can help identify vulnerabilities with evidence of active exploitation. It should supplement, not replace, system-specific assessment.

A vulnerability should not be closed merely because its numerical severity score is below a procedural threshold. Exposure, exploitability, system criticality, data impact, existing controls, and business consequences should also be considered.

Patch Assessment

Patches, hotfixes, firmware updates, security-agent updates, and configuration changes should be evaluated through a documented process. The assessment should consider:

• vulnerability severity;
• active exploitation;
• affected version;
• system exposure;
• system criticality;
• product and patient impact;
• data-integrity impact;
• availability risk;
• supplier recommendation;
• compatibility;
• required downtime;
• test requirements;
• rollback;
• and compensating controls.

The validation impact assessment should identify the affected requirements, configured functions, interfaces, calculations, reports, records, infrastructure components, and security controls. Test scope should be based on the patch’s technical effect and regression risk rather than assigned automatically from the supplier’s patch classification. The rationale for functions excluded from regression testing should be documented.

Patch decisions may include:

• expedited implementation;
• normal controlled implementation;
• deferred implementation with interim controls;
• nonimplementation because the vulnerable component is absent or disabled;
• or replacement of the unsupported system.

The decision and rationale should remain traceable to the applicable vulnerability, system, change record, testing, release, and residual-risk acceptance.

Compensating Controls

A compensating control reduces risk when the preferred control cannot be implemented immediately or completely. Examples include:

• network isolation;
• firewall restriction;
• removal of internet access;
• disabled vulnerable service;
• restricted remote access;
• enhanced logging;
• increased monitoring;
• application allowlisting;
• blocked removable media;
• manual review;
• protected backups;
• or temporary process restrictions.

Compensating controls should be specific, verifiable, assigned to an owner, and maintained for a defined period.

A statement that a system is “behind a firewall” is not adequate by itself. The assessment should identify the actual rule, traffic path, exposure reduction, monitoring, and residual risk.

Temporary controls should have an expiration or reassessment date. They should not become permanent through inattention.

Vulnerability and Patch Decision

Vulnerability management should connect identification, impact assessment, remediation, testing, validated release, and continuing monitoring. The selected path may be to patch, apply compensating controls, or accept defined residual risk. Every path should lead to documented validated-state closure.

Security Logging

Security logs should support detection, investigation, and reconstruction of security events. Relevant logs may include:

• successful and failed authentication;
• privileged activity;
• account creation and removal;
• role changes;
• remote sessions;
• firewall events;
• malware detections;
• vulnerability-scan results;
• configuration changes;
• service-account activity;
• backup administration;
• security-control disablement;
• and unusual data access.

Logging requirements should define:

• events captured;
• timestamp source;
• retention;
• protection;
• access;
• monitoring;
• review responsibility;
• and escalation.

Security logs should be protected against unauthorized alteration and deletion.

Security logs do not replace application audit trails. Audit trails document regulated record and configuration changes, while security logs provide broader evidence about access, technical events, and possible compromise. The two may need to be correlated during investigation.

See Audit Trails, Data Changes, and Review Controls.

Detection and Alerting

Detection controls should identify unusual or unauthorized activity before it causes prolonged or widespread harm. Detection may include:

• abnormal login patterns;
• repeated failed authentication;
• unexpected privileged activity;
• malware alerts;
• unusual network traffic;
• unauthorized connections;
• configuration drift;
• disabled security controls;
• unexpected data export;
• backup deletion;
• rapid file encryption;
• and changes outside approved windows.

Alerts should be meaningful, assigned, prioritized, investigated, and retained.

A large number of unreviewed alerts does not establish effective monitoring. Alert thresholds, response procedures, staffing, and escalation should reflect system criticality and credible threats.

Cybersecurity Incident Response

The incident-response process should address both technical containment and GMP impact. The response should include:

1. detection and initial triage;
2. containment;
3. preservation of evidence;
4. identification of affected systems and records;
5. assessment of product, patient, data, and availability impact;
6. eradication or remediation;
7. recovery;
8. verification;
9. authorization to return to service;
10. and post-incident review.

The investigation should determine whether the event affected:

• regulated records;
• metadata;
• audit trails;
• electronic signatures;
• configuration;
• calculations;
• reports;
• interfaces;
• material or product status;
• batch release;
• backup integrity;
• or system availability.

A technical conclusion that malware was removed is insufficient when the organization has not determined whether GMP records or decisions were affected.

The incident assessment should also determine whether the system remains in a validated state. Revalidation or targeted verification should be considered when the incident may have altered software, configuration, access controls, records, metadata, audit trails, interfaces, calculations, reports, backup integrity, or recovery capability. The decision and supporting rationale should be documented before unrestricted return to GMP operation.

Quality, process owners, system owners, Information Technology, security, legal, privacy, regulatory, and suppliers should be involved according to the nature of the event.

Ransomware Resilience

Ransomware can encrypt or destroy application data, shared files, databases, virtual machines, configuration, and accessible backups. Resilience controls should include:

• network segmentation;
• multifactor authentication;
• restricted privileged access;
• vulnerability remediation;
• malware protection;
• security monitoring;
• protected backups;
• tested restoration;
• incident-response procedures;
• and business-continuity arrangements.

CISA’s StopRansomware Guide recommends protected backups, restoration testing, network segmentation, access control, and other measures intended to reduce ransomware risk.

A recovery strategy should assume that production credentials, connected storage, replication targets, and online backups may also be compromised.

Protected Backups

Recovery copies should be protected from the same event that can compromise production. Controls may include:

• offline copies;
• immutable storage;
• separate administrative credentials;
• separate identity domains;
• network isolation;
• geographic separation;
• restricted deletion;
• encryption;
• integrity checking;
• and independent monitoring.

Backup scope should include regulated data, metadata, audit trails, configuration, attachments, interfaces, and technical dependencies needed for recovery.

Backup completion should be monitored. Restoration testing should demonstrate that the protected copies are usable.

See Backup, Restoration, Disaster Recovery, and Business Continuity.

Restoration and Trusted Recovery

Recovery after a cybersecurity incident differs from routine restoration because the original environment may remain compromised.

The organization should determine:

• when the compromise began;
• which recovery point is trustworthy;
• whether credentials must be reset;
• whether systems should be rebuilt rather than restored;
• whether malware persists;
• whether configuration was altered;
• whether backups were affected;
• and whether restored data remain complete and accurate.

Recovery verification should confirm:

• expected records;
• metadata;
• audit trails;
• configuration;
• access controls;
• security controls;
• interfaces;
• calculations;
• reports;
• and critical business functions.

Delayed or manually recorded transactions should be reconciled before normal operation resumes.

Return to service should require defined technical, business, and Quality approval appropriate to the event’s impact.

Supplier Notification and Support

Suppliers should notify customers of security issues that can affect the product or service. Contracts or quality agreements should address:

• vulnerability notification;
• incident notification;
• affected versions;
• severity and exploitability;
• remediation;
• patches;
• workarounds;
• release timing;
• subcontractors;
• remote access;
• investigation support;
• recovery support;
• and end-of-support notification.

The regulated organization should define how supplier notices are received, assigned, evaluated, documented, and closed.

Supplier testing and security evidence may be leveraged after assessment, but they do not replace evaluation of the site-specific configuration, exposure, interfaces, data, users, and process impact.

See Computerized System Supplier Assessment and Evidence Leverage.

Cloud Responsibilities

Cloud cybersecurity is based on shared responsibilities.

The provider may control portions of:

• physical facilities;
• hardware;
• virtualization;
• networking;
• managed databases;
• platform services;
• application software;
• monitoring;
• backup;
• and incident response.

The customer may remain responsible for:

• intended use;
• configuration;
• user access;
• privileged roles;
• data classification;
• interface security;
• retention;
• monitoring;
• supplier oversight;
• incident escalation;
• and validation.

The responsibility boundary depends on whether the service is infrastructure as a service, platform as a service, or software as a service.

Contracts should define security responsibilities, access, notification, subcontractors, data location, logging, recovery, audit rights, and termination support.

See Cloud and SaaS Systems in GMP Environments.

Cybersecurity Change Control

Security changes should be controlled according to their possible effect on intended use and the validated state. Changes may include:

• patches;
• hotfixes;
• firmware;
• firewall rules;
• network segmentation;
• endpoint protection;
• security agents;
• authentication;
• multifactor authentication;
• certificates;
• encryption;
• remote access;
• logging;
• monitoring;
• backup protection;
• and cloud-security configuration.

The change record should address:

• reason;
• affected systems;
• risk;
• data and record impact;
• configuration impact;
• test scope;
• regression scope;
• rollback;
• procedures;
• training;
• release;
• and post-implementation monitoring.

Emergency security changes may require accelerated implementation. They should still be documented, verified to the extent practical, and retrospectively reviewed.

See Computerized System Change Control, Patching, and Revalidation.

Security Testing

Security testing should be scaled to intended use, criticality, architecture, exposure, supplier capability, and risk.

The validation plan should distinguish controls verified through shared infrastructure qualification or enterprise security assurance from controls requiring application-specific verification. Application validation should confirm security functions that affect the system’s intended GxP use, including configured access restrictions, privileged functions, auditability, approved communication paths, backup and recovery, and protection of regulated records. Central security evidence may be leveraged when its scope, applicability, execution, and results are assessed and documented.

Testing may include:

• secure-configuration verification;
• port and service review;
• firewall-rule verification;
• access testing;
• privileged-role testing;
• remote-access testing;
• multifactor-authentication testing;
• vulnerability scanning;
• malware-control verification;
• logging and alert testing;
• backup-protection testing;
• restoration testing;
• failover testing;
• and incident-response exercises.

Penetration testing may be appropriate for exposed, complex, or high-risk systems. It should be planned carefully for operational technology and production environments to avoid unsafe interruption or uncontrolled change.

Testing should confirm both the security control and the continued operation of critical GMP functions.

Failed or partially effective controls should be documented, investigated, corrected, and retested.

Periodic Review

Periodic review should evaluate whether cybersecurity controls remain suitable and effective. Inputs should include:

• inventory accuracy;
• system criticality;
• supported-version status;
• vulnerabilities;
• patches;
• compensating controls;
• firewall rules;
• remote access;
• privileged accounts;
• malware status;
• security logs;
• alerts;
• incidents;
• backup protection;
• restoration results;
• supplier notifications;
• cloud changes;
• unresolved risks;
• and security-related deviations.

The review should identify cumulative changes, control degradation, unsupported components, recurring incidents, and risks that are no longer acceptable.

Review frequency should reflect system criticality, exposure, rate of change, supplier activity, prior findings, and the threat environment.

Documented Risk Acceptance

Residual cybersecurity risk may remain after reasonable controls are implemented. Risk acceptance should document:

• affected system;
• vulnerability or threat;
• affected version or component;
• exposure;
• credible consequences;
• existing controls;
• compensating controls;
• residual risk;
• rationale;
• owner;
• approval;
• expiration or reassessment date;
• and remediation plan where applicable.

The accepted risk should be traceable to the affected system and the applicable vulnerability record, supplier notice, risk assessment, deviation, change record, incident, or periodic-review action. Any compensating controls should be included in the controlled configuration or operating procedures and verified before approval. Risk acceptance should not be used to bypass required remediation, testing, or change control.

Risk acceptance should not be open-ended. The decision should be reassessed when:

• threat information changes;
• exploitation becomes known;
• system exposure changes;
• a patch becomes available;
• supplier support changes;
• an incident occurs;
• compensating controls fail;
• or the system’s intended use changes.

Acceptance authority should be proportionate to potential GMP and business consequences and should include Quality involvement where the risk can affect regulated processes or records.

Maintaining Cybersecurity and the Validated State

Cybersecurity controls for GMP computerized systems should establish:

• an accurate system inventory;
• risk-based criticality;
• supported technology;
• secure configuration;
• network segmentation;
• controlled remote and privileged access;
• malware protection;
• vulnerability monitoring;
• documented patch decisions;
• effective compensating controls;
• security logging and detection;
• coordinated incident response;
• ransomware resilience;
• protected and tested backups;
• supplier and cloud accountability;
• controlled security changes;
• periodic testing;
• periodic review;
• and documented residual-risk acceptance.

Cybersecurity documentation becomes part of the computerized system’s lifecycle validation evidence when it supports assurance of intended GxP use. Applicable evidence may include requirements, risk assessments, architecture and data-flow diagrams, approved configurations, supplier assessments, vulnerability evaluations, patch decisions, access tests, firewall verification, security logs, restoration results, incident assessments, deviations, change records, and periodic-review conclusions.

Cybersecurity does not replace validation, and validation does not establish cybersecurity by itself. The two should operate together so that intended GMP functions, trustworthy electronic records, and recovery capabilities remain controlled throughout the computerized-system lifecycle.