Change Control and Periodic Review of Facility Automation

Purpose and Scope

Change control and periodic review maintain facility automation systems in a qualified and controlled state after initial release.

The scope may include:

• Building Management Systems
• Environmental Monitoring Systems
• HVAC and utility controllers
• Programmable logic controllers
• Supervisory applications
• Data historians and databases
• Alarm and notification platforms
• Sensors and transmitters
• Operator and engineering workstations
• Interfaces
• Networks and servers
• User and role configurations
• Backup and recovery components
• Cybersecurity controls
• Supporting procedures and records

The lifecycle process should address changes to hardware, software, firmware, configuration, records, infrastructure, security, operating procedures, and external dependencies.

A change should not be classified as non-GMP merely because it is:

• Routine
• Like-for-like
• Vendor-recommended
• Performed by information technology
• Intended to improve cybersecurity
• Implemented during maintenance
• Made outside the primary application

The determining question is whether the change can affect an intended GMP function, required record, alarm, interface, security control, qualified configuration, or system availability.

Maintaining the Qualified State

The qualified state depends on more than the installed software version.

It includes the approved combination of:

• Intended use
• System boundary
• Hardware
• Software and firmware
• Controller logic
• Point configuration
• Alarm configuration
• Historian settings
• Interfaces
• User roles
• Cybersecurity controls
• Network and server dependencies
• Backup and recovery arrangements
• Procedures
• Training
• Qualification evidence
• Open risks and compensating controls

Change control evaluates proposed modifications before implementation. Periodic review evaluates accumulated evidence after the system has operated over time.

These controls are related but serve different purposes:

An equipment failure or security incident is not automatically a change. It may initiate deviation or incident management first and generate a change when a corrective modification is proposed.

Configuration Baseline

Effective change assessment requires a known current baseline.

The baseline should identify, as applicable:

• Hardware inventory
• Controller and panel identification
• Software and firmware versions
• Server and virtual-machine configuration
• Operating-system version
• Installed services
• Network addresses and communication paths
• Controller programs
• Point and input/output assignments
• Sensor ranges and scaling
• Engineering units
• Control sequences
• Setpoints
• Alarm thresholds, delays, deadbands, and priorities
• Operating modes
• Interlocks and permissives
• Graphics
• Reports
• Historian and data-compression settings
• Interface mappings
• Notification routes
• User roles and privileged accounts
• Audit-trail configuration
• Backup scope and schedule
• Time-synchronization settings
• Firewall rules and remote-access controls
• Approved specifications and drawings

The baseline may be maintained through controlled configuration exports, version repositories, checksums, database extracts, point lists, alarm matrices, drawings, inventories, and approved specifications.

Screenshots alone are generally insufficient where machine-readable configuration evidence is available.

The change record should identify the affected baseline item and the approved pre-change and post-change states.

Change Categories

Change categories support consistent routing and approval. They should not predetermine impact or testing without assessment.

Administrative labels such as minor, major, standard, or emergency should be defined in procedure. They should not replace the technical and GMP impact assessment.

Change-Initiation Requirements

A change request should define:

• Reason for the change
• Current condition
• Proposed condition
• Affected system and boundary components
• Affected facilities, rooms, utilities, or equipment
• Associated incident, deviation, CAPA, maintenance, or security record
• Expected benefit
• Known risks
• Proposed implementation method
• Proposed verification
• Rollback or contingency plan
• Required outage
• Manufacturing restrictions
• Responsible owners
• Required approvals
• Target implementation date

The description should be detailed enough for an independent reviewer to understand what will change.

Statements such as “upgrade software,” “replace sensor,” or “update alarms” are not adequate without identifying the affected version, device, point, parameter, function, or configuration.

Facility-automation change control should begin with the approved baseline and evaluate the complete effect on GMP functions, records, security, availability, interfaces, and procedures. The resulting verification scope should reflect change depth, failure consequence, uncertainty, and the ability to detect unintended effects.

Change-Impact Assessment

The assessment should evaluate both the intended modification and credible unintended effects.

Relevant considerations include:

Intended Use and Requirements

• Does the change modify intended use?
• Are existing requirements affected?
• Are new requirements necessary?
• Does the change remove or weaken a previously qualified function?
• Does the operating procedure change?

Control and Monitoring

• Are control sequences, modes, setpoints, or interlocks affected?
• Can the change influence product protection or containment?
• Are monitoring accuracy, frequency, or availability affected?
• Can unchanged points be affected through shared logic or infrastructure?

Alarms and Notification

• Are thresholds, delays, deadbands, priorities, suppression, or escalation affected?
• Does the change affect alarm generation, display, recording, or notification?
• Can communication or notification failures become less visible?

Data and Records

• Is the official GMP record affected?
• Are data format, calculation, timestamp, metadata, retention, or retrieval affected?
• Can records be lost, duplicated, overwritten, delayed, or rendered inaccessible?
• Is audit-trail coverage affected?
• Does Part 11 applicability change?

Interfaces and Dependencies

• Are source or destination mappings affected?
• Are protocol, scaling, units, precision, timestamps, or data-quality flags affected?
• Are network, directory, time, certificate, database, or virtualization dependencies affected?
• Can another qualified system be affected?

Security and Access

• Are user roles, privileged access, authentication, remote access, or segregation of duties affected?
• Does the change introduce or correct a vulnerability?
• Can a security control interrupt operation, data transfer, alarm notification, or recovery?

Availability and Recovery

• Is an outage required?
• Can local control continue?
• Are backup, rollback, restoration, or disaster-recovery arrangements affected?
• Can the previous configuration be reliably restored?
• Is temporary monitoring required?

Qualification and Documentation

• Which requirements, specifications, risks, tests, drawings, inventories, procedures, and training records are affected?
• What regression testing is required?
• Which unchanged functions can remain covered by prior evidence?
• Is targeted or broader requalification necessary?

Uncertainty should increase review or verification depth. It should not be recorded as evidence of no impact.

Change Classification and Verification Depth

The organization may classify changes by complexity or impact, but the final scope should be justified from the actual assessment.

Limited-Impact Change

A limited-impact change may require:

• Documented technical review
• Confirmation of compatibility
• Baseline update
• Targeted inspection
• Targeted functional verification
• Approval before closure

Examples may include a documentation correction or replacement of a noncritical component with an identical approved item when configuration and function remain demonstrably unchanged.

Moderate-Impact Change

A moderate change may require:

• Updated risk assessment
• Configuration verification
• Functional testing
• Alarm testing
• Interface testing
• Security verification
• Targeted regression testing
• Procedure or training updates
• Formal release approval

Major Change

A major change may require:

• Revised requirements and specifications
• Supplier assessment
• Updated Part 11 or data-integrity assessment
• Protocol-based installation or operational testing
• End-to-end interface verification
• Backup and restoration testing
• Performance confirmation
• Broader regression testing
• Validation summary and formal release

Full repetition of the original qualification is not automatically required. Unchanged functions may remain covered when nonimpact is technically justified and documented.

Emergency Changes

Emergency changes may be necessary to:

• Protect personnel
• Prevent product or environmental impact
• Restore a failed critical function
• Contain a cybersecurity threat
• Recover required records
• Restore monitoring or alarming
• Prevent equipment damage
• Maintain facility containment

Emergency status permits an expedited process, not uncontrolled implementation.

The emergency-change process should define:

• Conditions permitting emergency use
• Authorized initiators and approvers
• Minimum preimplementation assessment
• Current configuration capture
• Backup or rollback arrangements
• Temporary operational restrictions
• Immediate verification
• Required documentation
• Quality notification
• Retrospective assessment
• Permanent-change determination
• Due date for formal closure

Where prior approval is not practicable, the responsible authority should be notified as soon as defined by procedure. The change should then receive retrospective technical, validation, data-integrity, cybersecurity, and quality assessment.

Temporary logic, forced values, disabled alarms, local overrides, firewall exceptions, shared accounts, or manual workarounds should be:

• Specifically authorized
• Time-limited
• Visible to affected personnel
• Documented
• Periodically reviewed while active
• Removed or formalized through permanent change control
• Verified after removal

“Emergency” should not become a recurring route for poor planning or delayed maintenance.

Software Patches and Updates

Patches should be assessed before deployment to GMP-relevant automation systems.

The assessment should consider:

• Vulnerability or defect addressed
• Severity and exploitability
• Current exposure
• Vendor recommendation
• Affected software and components
• Prerequisites
• Compatibility
• Known issues
• Required restart
• Database or configuration changes
• Interface impact
• Effect on drivers, services, and communication
• Effect on audit trails and records
• Effect on alarm and notification services
• Backup and rollback capability
• Supplier test evidence
• Site testing
• Deployment sequence
• Consequence of delaying the patch

The outcome may be:

• Install on an expedited basis
• Test before controlled deployment
• Defer with documented justification
• Apply a compensating control
• Isolate an affected component
• Replace or upgrade the platform

A patch should not be installed automatically solely because it is vendor-issued. It should not be deferred indefinitely solely because the system is qualified.

Patch testing should focus on the functions that the patch can credibly affect, including critical control, monitoring, records, security, interfaces, alarms, startup, shutdown, and recovery.

Cybersecurity Changes

Cybersecurity changes may include:

• Firewall-rule changes
• Network segmentation
• Antivirus or endpoint-protection updates
• Application allowlisting
• Certificate replacement
• Password-policy changes
• Multifactor authentication
• Directory-service changes
• Remote-access controls
• Vulnerability remediation
• Security monitoring
• Port or protocol restrictions
• System isolation
• Vendor-access changes

Cybersecurity improvements can introduce operational risk. Examples include:

• Blocking a required interface
• Delaying data transfer
• Preventing user authentication
• Interrupting remote alarms
• Forcing an unexpected restart
• Quarantining an application file
• Causing certificate-based communication failure
• Preventing backup or time synchronization

Assessment should involve automation engineering, information technology, cybersecurity, operations, validation, and quality according to the change’s significance.

Verification should demonstrate both:

• The security control operates as intended.
• GMP control, monitoring, alarm, record, interface, and recovery functions remain acceptable.

Alarm-Configuration Changes

Alarm changes may involve:

• Thresholds
• Delays
• Deadbands
• Priorities
• Enabling or disabling
• Suppression
• Operating-mode logic
• Notification recipients
• Escalation paths
• Acknowledgment requirements
• Return-to-normal behavior
• Alarm-report configuration

The assessment should identify:

• Scientific or operational justification
• Relationship to approved limits
• Effect on detection time
• Effect on nuisance or recurring alarms
• Product, environmental, or containment consequences
• Effect on response procedures
• Required quality oversight
• Affected reports and historical trending
• Required regression testing

Changing a notification recipient does not necessarily change the original alarm logic, but it can change whether personnel receive timely notice. The alarm-generation and notification paths should therefore be assessed separately.

Repeated adjustment of alarm limits or delays may indicate a design, sensor, operating-range, maintenance, or process-control problem. Change control should not be used to normalize adverse performance.

Sensor Replacement and Modification

Sensor work may affect measurement, control, alarming, data history, and qualified room performance.

Assessment should consider:

• Like-for-like status
• Manufacturer and model
• Measurement principle
• Range
• Accuracy
• Resolution
• Response time
• Output signal
• Scaling
• Engineering unit
• Installation location
• Orientation
• Pressure reference
• Calibration requirement
• Controller mapping
• Alarm and control use
• Data continuity
• Effect on independent monitoring

Verification may include:

• Installation inspection
• Identification
• Calibration
• Loop check
• Scaling verification
• Point mapping
• Display and historian verification
• Alarm challenge
• Control-loop response
• Comparison with an independent reference
• Environmental-performance confirmation

A nominally identical replacement may still require configuration restoration, calibration, loop verification, and confirmation that historical and current records remain correctly associated with the point.

User and Access Changes

Routine creation or removal of individual accounts may be managed through an approved user-administration procedure rather than a separate change record for every account.

Changes to the access-control model require broader assessment. These may include:

• New roles
• Modified permissions
• Privileged-access changes
• Shared or service accounts
• Authentication changes
• Password-policy changes
• Remote access
• Vendor access
• Directory integration
• Electronic-approval authority
• Ability to modify data or configuration

The assessment should determine whether the change affects:

• Segregation of duties
• Least-privilege principles
• Approval authority
• Audit-trail generation
• Record modification or deletion
• Configuration authority
• Account attribution
• Emergency access
• Account recovery
• Periodic access review

Temporary or vendor access should be authorized, restricted, time-limited, monitored where appropriate, and disabled when no longer required.

Implementation Planning

The approved implementation plan should identify:

• Pre-change backup
• Baseline capture
• Required approvals
• Responsible personnel
• Implementation sequence
• System outage
• Manufacturing restrictions
• Temporary monitoring or manual operation
• Communication to affected users
• Verification activities
• Acceptance criteria
• Deviation handling
• Rollback criteria
• Restoration method
• Post-change observation
• Release authority

The plan should account for connected systems. A change implemented successfully in one application may still create mapping, timestamp, authentication, alarm, reporting, or data-transfer problems elsewhere.

Post-Change Verification and Regression Testing

Verification should demonstrate that:

• The intended change was correctly implemented.
• Affected functions continue to meet requirements.
• Credibly affected unchanged functions remain acceptable.
• No unacceptable unintended effect was introduced.

Testing may include:

• Configuration comparison
• Point and scaling verification
• Control-sequence testing
• Mode and interlock testing
• Alarm generation
• Notification and escalation
• Data recording
• Audit trails
• User restrictions
• Interface transfer
• Time synchronization
• Communication-loss behavior
• Backup and restoration
• Startup and restart
• Failover
• Manual operation
• Report generation
• Record retrieval

Regression scope should be based on technical dependency and risk. It should not be limited to the visible feature that initiated the change.

Unexpected results should be documented and assessed before release. Repeated testing should not conceal the original failure.

Release and Closure

Return to routine GMP operation should require documented confirmation that:

• Implementation was completed as approved
• Verification met acceptance criteria
• Deviations were resolved or acceptably controlled
• Required regression testing was completed
• Configuration records were updated
• Backup of the released configuration exists
• Requirements and traceability were updated
• Drawings and specifications were updated
• Procedures were approved
• Training was completed
• Temporary controls were removed or formally retained
• Cybersecurity and access controls are active
• Operations and quality were notified
• Release was approved

Change closure should not occur merely because installation work is complete.

Post-implementation review may be appropriate when performance can only be confirmed through operation over time.

Periodic Review Objectives

Periodic review should determine whether the automation system remains:

• Suitable for intended use
• Consistent with the approved baseline
• Qualified
• Secure
• Reliable
• Supportable
• Capable of producing complete and trustworthy records
• Adequately maintained
• Recoverable
• Properly governed

Periodic review is not automatic repetition of qualification testing. It is an evidence-based evaluation of continued control.

Periodic-Review Inputs

Review inputs should be selected according to system functions and risks.

They may include:

System and Configuration

• Current intended use
• Current system boundary
• Hardware and software inventory
• Software and firmware versions
• Configuration baseline
• Point inventory
• Alarm matrix
• Interface inventory
• Current specifications and drawings
• Configuration discrepancies

Change and Performance History

• Change controls
• Emergency changes
• Temporary changes
• Deviations and investigations
• CAPA
• Maintenance history
• Recurring failures
• System downtime
• Manual-operation periods
• Open discrepancies
• Previous review actions

Alarms and Monitoring

• Alarm frequency
• Recurring or standing alarms
• Disabled or suppressed alarms
• Alarm floods
• Notification failures
• Delayed responses
• Data gaps
• Stale or invalid values
• Environmental trends
• Sensor failures
• Calibration and out-of-tolerance history

Data Integrity

• Audit-trail events
• Audit-trail review records
• Unexplained configuration changes
• Record deletions or modifications
• Shared or inactive accounts
• Privileged-user activity
• Missing metadata
• Timestamp discrepancies
• Data-transfer failures
• Record-retention status
• Retrieval capability
• Accurate-copy capability

Security and Infrastructure

• User-access review
• Privileged and service accounts
• Remote-access history
• Cybersecurity incidents
• Vulnerability status
• Deferred patches
• Firewall and network changes
• Antivirus or allowlisting status
• Certificate expiration
• Operating-system support
• Directory and time-service dependencies

Backup and Recovery

• Backup success and failure
• Backup scope
• Retention
• Restoration testing
• Recovery exercises
• Recovery-time performance
• Record reconciliation
• Configuration-recovery capability

Supplier and Lifecycle

• Vendor support status
• Release notes
• Known defects
• Product roadmap
• License status
• Spare-part availability
• Platform compatibility
• Obsolescence notices
• End-of-support dates
• Replacement or migration planning

The review should evaluate relationships among these inputs. A series of individually acceptable changes may produce an unacceptable cumulative effect.

Data-Integrity Review

The data-integrity portion of periodic review should evaluate whether records remain complete, consistent, accurate, attributable, contemporaneous, original or true copies, and available through the required retention period.

The review should determine:

• Whether the official record remains clearly defined
• Whether required metadata remain linked to the data
• Whether audit trails are enabled and retained
• Whether required audit-trail reviews occur
• Whether users can modify or delete records outside approved processes
• Whether privileged activities are attributable
• Whether shared accounts exist
• Whether timestamps remain synchronized
• Whether interfaces preserve identity and chronology
• Whether missing or buffered data are reconciled
• Whether backup copies remain exact and complete
• Whether records remain retrievable after software or infrastructure changes

FDA describes data integrity as applying throughout the data lifecycle, including creation, modification, maintenance, archival, retrieval, transmission, and disposition. It also expects validation depth to be commensurate with the risk posed by the automated workflow. FDA Data Integrity and Compliance With Drug CGMP

Vendor Support and Obsolescence

Continued qualification does not establish continued technical supportability.

Periodic review should evaluate:

• Current vendor support
• Software and firmware lifecycle
• Operating-system support
• Database compatibility
• Hardware availability
• Spare controllers and input/output modules
• Licensing
• Security-update availability
• Proprietary programming tools
• Availability of qualified service personnel
• Ability to restore the system
• Ability to migrate records
• Availability of configuration exports
• Availability of replacement sensors and components

Obsolescence risk increases when:

• Security patches are no longer available
• Replacement hardware is unavailable
• Backup restoration depends on unsupported components
• Only one individual understands the configuration
• Vendor remote access is required for routine recovery
• Records cannot be migrated or retrieved independently
• Interfaces depend on obsolete protocols
• Qualification evidence no longer represents the installed system

Possible actions include:

• Enhanced monitoring
• Acquisition of critical spares
• Controlled platform upgrade
• Network isolation
• Compensating cybersecurity controls
• Configuration migration
• Data archival
• System replacement
• Retirement planning

A system does not become unqualified automatically on its end-of-support date. Continued use requires documented assessment of risk, controls, supportability, and replacement strategy.

Periodic-Review Frequency

Review frequency should consider:

• GMP criticality
• Data significance
• System complexity
• Rate of change
• Configuration accessibility
• Failure history
• Alarm performance
• Cybersecurity exposure
• Vendor support
• Obsolescence
• Previous review findings
• Regulatory and procedural requirements

Periodic review may also be initiated by:

• Significant change
• Repeated emergency changes
• Adverse performance trend
• Data-integrity concern
• Major cybersecurity event
• Extended outage
• Failed restoration
• Vendor end-of-support notification
• Cumulative minor changes
• Significant change in intended use

The frequency and event-driven triggers should be defined and justified.

Periodic-Review Outcomes

The review should reach a documented conclusion rather than merely list collected records.

Possible outcomes include:

• Continue operation without additional action
• Correct documentation or inventory
• Update configuration baselines
• Remove obsolete accounts
• Resolve recurring alarms
• Strengthen backup or recovery controls
• Perform targeted verification
• Increase monitoring
• Revise procedures or training
• Initiate deviation or CAPA
• Perform data-integrity assessment
• Implement cybersecurity remediation
• Complete supplier or obsolescence assessment
• Initiate targeted requalification
• Initiate broader requalification
• Plan upgrade, migration, replacement, or retirement

Each action should identify:

• Rationale
• Responsible owner
• Priority
• Due date
• Interim control
• Closure evidence
• Approval authority

Continued use with unresolved significant findings should be explicitly assessed and approved.

Revalidation and Requalification Decisions

Change control and periodic review should determine the verification necessary to retain confidence in intended use.

Targeted requalification may be appropriate when:

• Critical logic changes
• Alarm strategy changes
• Sensors are relocated or their measurement principle changes
• Interfaces or data transformations change
• The historian or official record changes
• Controllers are replaced
• Software or firmware is upgraded
• Servers or virtual environments are migrated
• Cybersecurity changes affect application behavior
• Backup or recovery architecture changes
• Significant failures expose uncertainty
• Accumulated changes weaken the original qualification basis

Broader requalification may be appropriate when:

• Intended use changes substantially
• The architecture or qualified boundary changes
• Extensive configuration is replaced
• Original traceability is inadequate
• Data integrity cannot be established
• Multiple interacting systems are migrated
• The cumulative effect of changes is uncertain
• Prior evidence no longer represents the installed system

Calendar-based review does not automatically require retesting. Conversely, the absence of a major change does not justify continued use when failures, data-integrity concerns, obsolescence, or adverse trends create uncertainty.

Roles and Responsibilities

Responsibilities should be assigned according to the system and change.

System Owner

• Maintains intended-use and operational ownership
• Initiates or supports change assessment
• Confirms operational readiness
• Ensures procedures and training remain current

Automation Engineering

• Defines technical impact
• Maintains configuration
• Develops implementation and rollback plans
• Performs or supports technical verification

Information Technology and Cybersecurity

• Assesses infrastructure and security impact
• Controls servers, networks, authentication, and backup services
• Coordinates patching and recovery
• Provides supporting evidence

Validation

• Evaluates qualification impact
• Defines verification and regression scope
• Maintains traceability
• Reviews validation evidence

Quality Unit

• Provides oversight according to GMP significance
• Reviews deviations and residual risk
• Approves release where required
• Ensures significant findings enter the quality system

Operations and Facilities

• Provide operational-impact assessment
• Coordinate outage and manual controls
• Confirm routine-use readiness
• Report performance issues

Vendor activity should remain subject to site authorization, supervision, access control, documentation, and acceptance.

Common Lifecycle-Control Weaknesses

Common weaknesses include:

• No reliable configuration baseline
• Treating every vendor update as automatically acceptable
• Deferring security patches without documented assessment
• Allowing IT changes outside automation change control
• Classifying sensor replacement as automatically like-for-like
• Changing alarms without evaluating response time or product impact
• Updating notification recipients without testing escalation
• Failing to assess connected systems
• Testing only the modified screen
• Ignoring controller, historian, and interface effects
• Missing pre-change backup
• Undefined rollback criteria
• Uncontrolled temporary overrides
• Emergency changes remaining permanently open
• Closing changes before documentation and training are complete
• Repeated alarm adjustments used to conceal poor performance
• Shared or obsolete user accounts
• Incomplete audit-trail review
• Assuming successful backup demonstrates successful recovery
• Failing to assess cumulative changes
• Periodic reviews that only compile documents
• Unsupported software retained without an obsolescence strategy
• Automatically requiring full requalification for every change
• Avoiding necessary requalification by labeling changes minor

Maintaining Defensible Lifecycle Control

A defensible facility-automation lifecycle program should establish:

• The current approved configuration
• Which changes require formal assessment
• How emergency changes are controlled
• How patches and cybersecurity changes are evaluated
• How alarms, sensors, access, interfaces, and records are protected
• How verification depth is selected
• How regression scope is justified
• How the system is released after change
• How documentation and traceability are updated
• Which evidence is periodically reviewed
• How data integrity and access are evaluated
• How vendor support and obsolescence are managed
• When targeted or broader requalification is required
• How actions are assigned and closed

The objective is not to prevent change. It is to ensure that each change is understood, controlled, verified, documented, and incorporated into the approved baseline while accumulated lifecycle evidence continues to support reliable GMP operation.