Alarm & Interlock
Verification Record FAQ

An alarm is a notification that alerts an operator when a parameter moves outside its defined limits, while an interlock is an automated action that actually changes equipment behaviour — such as stopping a process or preventing equipment from operating — when a defined condition is met; both need to be verified, but the approach differs because an interlock's actual physical or logical action has to be confirmed, not just the notification.

Some conditions have both an alarm and an interlock associated with them — for example, a high-temperature alarm that warns an operator, followed by an interlock that shuts down heating if the temperature keeps rising — and each layer should be independently verified rather than assuming a passing interlock test also confirms the alarm functioned correctly.

Verification effort should be risk-based and prioritised toward alarms tied to GxP-critical parameters — those affecting product quality, patient safety, or data integrity — while lower-risk, purely operational or informational alarms may receive a lighter level of verification or none at all, provided that prioritisation is documented and justified rather than assumed.

Alarm and interlock verification is most commonly executed as part of Operational Qualification, since OQ is where the system is tested across its full operating range including at and beyond normal limits — but for complex automation, some organisations run a dedicated alarm and interlock verification protocol either within or immediately alongside OQ, rather than folding it loosely into general functional testing.

The risk assessment should identify which parameters are critical to product quality, patient safety, or data integrity, and the alarms and interlocks protecting those parameters inherit that criticality — the risk assessment is what justifies why certain alarms receive rigorous verification and periodic re-verification while others don't.

Yes — any bypass or override capability for a GxP-critical interlock needs to be verified in its own right, confirming that the override requires appropriate authorisation, is logged with who performed it and why, and that the interlock automatically re-arms once the override condition ends, since an unverified or unrestricted override effectively defeats the safety or quality protection the interlock was designed to provide.

Interlocks are typically tested by simulating or forcing the triggering input at the sensor or controller level — rather than physically driving the process to a genuinely hazardous condition — while confirming the interlock's actual downstream action, such as a valve closing or a motor stopping, is independently observed and verified, not just inferred from a software status flag.

A forced or simulated input value at the sensor or transmitter is generally an acceptable and often necessary way to test an alarm setpoint, particularly where physically driving the process parameter to its actual limit would be unsafe, costly, or impractical — but the test should confirm the alarm logic itself responds correctly to that input, not merely that the input was successfully forced.

Verification should confirm the complete notification chain — that the alarm generates the correct audible or visual indication at the point of use, and where remote notification is configured, that it actually reaches the designated recipient through that channel, such as a text message or paging system — rather than stopping at confirming the alarm condition was correctly detected in software.

A software-simulated test of the interlock logic is a valid and often necessary part of verification, but it should be complemented by confirming the interlock's actual physical action occurs — the software correctly deciding to close a valve is not the same as verifying the valve physically closes when commanded, and both should be demonstrated somewhere in the verification evidence.

Where an interlock genuinely cannot be safely tested under live production conditions, verification should rely on simulated or forced inputs combined with independent confirmation of the physical action, supplemented by design review, FAT-stage testing, or manufacturer verification evidence, with the rationale for not testing under live conditions explicitly documented and risk-assessed rather than the interlock simply being left unverified.

A failed alarm or interlock test should be documented as a deviation, investigated to determine root cause, and the alarm or interlock corrected and successfully retested before it can be considered verified — a GxP-critical alarm or interlock that fails testing should not be accepted with a workaround or informal fix that bypasses formal retesting.

A failed test of a GxP-critical alarm or interlock should block qualification until it's resolved and successfully retested, rather than being carried forward as a punch list item — punch list treatment is appropriate for minor, non-critical issues, and a failed safety or quality-critical alarm or interlock does not fit that category.

A change to a GxP-critical alarm setpoint should go through change control and requires re-verification of the alarm at its new setpoint, not just a documentation update — the original verification evidence was specific to the previous setpoint value and doesn't demonstrate the alarm functions correctly at the new one.

Ongoing accuracy is typically maintained through periodic calibration of the sensors and transmitters feeding the alarm, combined with a periodic review or requalification activity that re-confirms critical alarms still function and trigger at the correct setpoint — relying solely on the original qualification evidence years later doesn't account for instrument drift or configuration changes made since.

Alarm rationalization, the process of reviewing and reducing unnecessary or poorly configured alarms, should happen before or alongside verification planning, since verifying every nuisance alarm as though it were GxP-critical wastes effort and can also mask genuinely critical alarms within excessive noise — a rationalized alarm list is what verification should actually be scoped against.

An inspection-ready record should let a reviewer confirm exactly which alarm or interlock was tested, at what setpoint, how the test was performed, what the expected and actual response was, and who verified the result — a summary statement that alarms were tested without this supporting detail doesn't demonstrate the testing actually occurred as described.

• Alarm or interlock identifier and the parameter it protects.
• Setpoint or triggering condition tested.
• Test method: forced input, simulated condition, or physical condition induced.
• Expected response and actual observed response.
• Pass/fail result and any deviation raised.
• Tester name, reviewer name, and date.

The engineer who executed the testing typically signs as the executor, with a technical reviewer confirming the test method and results, and QA providing final approval — the specific signatory requirements should follow the same protocol approval hierarchy used for the broader OQ or qualification package the verification is part of.

Alarm and interlock verification records should be retained for at least as long as the qualification records for the system they support, since they're foundational evidence that safety and quality-critical protections were confirmed functional — commonly the system's operational lifetime plus the site's standard retention period after decommissioning.

Inspectors typically pick a GxP-critical alarm or interlock, confirm it was actually tested rather than just documented as functional, check that the tested setpoint matches the currently configured setpoint, and verify that any setpoint changes since initial qualification were accompanied by re-verification evidence.

A frequent finding is a mismatch between the setpoint documented in the original verification record and the setpoint currently configured in the system — this suggests the setpoint was changed at some point without triggering the expected re-verification and change control process.

The most common mistake is verifying alarms and interlocks thoroughly at initial qualification and then never revisiting that verification as setpoints change, instruments drift, or automation logic is updated — treating alarm and interlock verification as a one-time qualification milestone rather than a control that needs periodic reconfirmation is how a genuinely critical protection quietly stops working without anyone noticing until it's needed.