How to Conduct an Alarm System Audit

Back to Blog

Reconcile Live Configuration Against the Database

The core of the audit is comparing what the plant is actually running against what the master alarm database says it should be. Export the live setpoints, priorities, deadbands, delays, and enabled states, and diff them against the database. Every difference is either an undocumented change to the plant or a database that fell behind, and both are findings.

Undocumented changes are the audit's most important catch, because they mean an alarm was altered outside the process and no one recorded why. A setpoint quietly moved or an alarm quietly disabled is exactly the drift the audit exists to surface.

Verify the KPIs Against Targets

Pull the alarm KPIs over the audit period and check them against the philosophy's targets: average and peak alarm rate, percent of time in flood, standing alarm count, and priority distribution. This is a benchmark against design intent, so a system that has drifted above target on any KPI is a finding even if each individual alarm looks fine.

Use the same metric definitions as the monthly KPI review so the audit and the ongoing reviews agree. A trend of a KPI drifting toward its limit over the period is itself a finding, because it predicts a future breach the audit can pre-empt.

Confirm Change Control Was Followed

Check that every alarm change during the period went through management of change with a reason, an approval, and a record. Cross-reference the change log against the undocumented changes you found in the reconciliation; any plant change with no matching change record is a governance failure, not just a data error.

Confirm rationalization and the philosophy are actually being applied, not just documented. An audit that finds the paperwork exists but the practice lapsed has still found a real problem, because the system is only as good as the discipline maintaining it.

Record Findings and Corrective Actions

Turn every discrepancy into a finding with a severity and a corrective action owner. An undocumented setpoint change, a KPI over target, and a missing change record are all findings, and each needs an action to correct the immediate issue and, where relevant, the process gap that allowed it.

Route the corrective actions the same way as any change, through management of change, so fixing an audit finding does not itself become an undocumented change. Track the actions to closure and carry open ones to the next audit.

Verifying the Audit

Confirm the reconciliation covered the whole alarm population, not a sample, because an undocumented change hides wherever you did not look. If time forces a sample, weight it toward the highest-priority alarms and the alarms most recently changed, since those carry the most risk.

Check that the audit's findings connect to actions and the actions to closure. An audit that produces a list of discrepancies but no owned corrective actions has documented the drift without correcting it, which is the same failure the audit was meant to prevent.

Common Mistakes to Avoid

The central mistake is auditing the database against itself instead of against the live plant, which cannot catch the undocumented changes that are the whole reason to audit. The second is checking KPIs but never reconciling configuration, so drift in individual alarms goes unseen.

Auditors also produce findings with no owned corrective actions, so the report is filed and the drift persists. And they fix findings directly on the console outside change control, which corrects one discrepancy while creating another and undermines the master database the audit is protecting.

Frequently Asked Questions