May 16, 2026 · Guide

SCADA Alarm Management: Best Practices for ISA-18.2 Compliance

The average SCADA operator in a poorly managed plant sees over 1,000 alarms per day. During an upset condition, that number can spike to 10,000 or more. No human being can process that volume of information and make correct decisions under pressure. The result is predictable: operators ignore alarms, miss the critical ones, and incidents escalate. For a broader understanding of how SCADA systems are structured to support effective alarm management, see our guide to SCADA system architecture.

This is not a hypothetical problem. Every major industrial accident in the last two decades, from Texas City to Deepwater Horizon, had alarm management failures as a contributing factor. The good news is that the solution is well-understood, standardized, and achievable. ISA-18.2 (the American standard) and its international equivalent IEC 62682 provide a clear framework for designing and maintaining an effective alarm system.

This guide covers what you need to know to implement SCADA alarm management that actually works: reducing alarm floods, building a rationalization process, configuring deadbands and delays, tracking KPIs, and avoiding the anti-patterns that make most alarm systems useless.

The Alarm Management Problem

Industrial alarm systems suffer from three chronic failures that compound each other:

Alarm Floods

An alarm flood occurs when more alarms activate in a short period than an operator can physically read, evaluate, and respond to. EEMUA 191 defines a flood as more than 10 alarms in any 10-minute window. In most plants, floods happen during startup, shutdown, and upsets, exactly when operators need the clearest information. During a flood, critical alarms are buried in noise.

Stale and Standing Alarms

Stale alarms are alarms that have been active for so long that operators stop noticing them. A typical example: a tank level high-high alarm that has been active for three weeks because the setpoint was never adjusted after a process change. Standing alarms degrade operator trust in the entire system. If the alarm is always on, it is not an alarm. It is wallpaper.

Operator Fatigue

When an operator sees hundreds of meaningless alarms per shift, they develop alarm fatigue. They stop reading alarm text. They stop investigating. They develop a habit of acknowledging and dismissing without analysis. Then, when a genuine emergency occurs, their response is delayed because they have been conditioned to treat every alarm as noise.

ISA-18.2 / IEC 62682: The Standard Framework

ISA-18.2, published by the International Society of Automation, and its international counterpart IEC 62682 define the lifecycle for designing, implementing, and maintaining industrial alarm systems. The standard applies to every industry: oil and gas, power generation, water treatment, pharmaceuticals, manufacturing, and more. For context on where alarm management fits within the broader HMI design, see our comparison of SCADA vs HMI.

The alarm management lifecycle defined by ISA-18.2 has seven stages:

1. Alarm philosophy. Define what qualifies as an alarm, how priorities are assigned, and the governance structure.
2. Identification. Determine which process conditions require alarms based on hazard analysis and operability studies.
3. Rationalization. Review each proposed alarm for justification, priority, setpoint, and operator response.
4. Detailed design. Configure deadbands, delays, suppression logic, and HMI presentation.
5. Implementation. Deploy alarms to the SCADA system, train operators, and verify configuration.
6. Operation. Monitor alarm performance, maintain the system, and handle shelving.
7. Audit and review. Measure KPIs, identify problems, and continuously improve.

You do not need to implement all seven stages at once. Most plants start with rationalization and a basic alarm philosophy document, then build out the lifecycle over successive quarters.

The Alarm Philosophy Document

The alarm philosophy document is the foundation of your entire alarm management program. Without it, every alarm decision is ad-hoc and inconsistent. The document should be a living artifact that is reviewed and updated at least annually. At minimum, it must contain:

• Definition of an alarm. A clear statement that an alarm is a signal that requires an operator action. If no action is required, it is not an alarm. It is informational and should not appear in the alarm summary.
• Priority classification scheme. How many priority levels you use (typically 3 or 4), what each level means in terms of consequence severity and response time, and the color coding for each level on the HMI.
• Rationalization criteria. The questions every alarm must answer: what consequence does this alarm prevent? What action should the operator take? How much time does the operator have?
• Roles and responsibilities. Who approves new alarms, who performs rationalization reviews, who has authority to shelve or suppress alarms, and who conducts audits.
• Performance targets. The specific KPIs you are tracking and the acceptable thresholds (aligned with EEMUA 191 benchmarks).
• Change management process. How new alarms are requested, evaluated, approved, configured, and tested before going live.

Alarm Rationalization

Rationalization is the single most impactful activity in alarm management. It is a structured review of every configured alarm in your SCADA system to determine whether it is justified, properly prioritized, and correctly configured. The process involves a cross-functional team: process engineers, operators, maintenance staff, and automation engineers.

The Rationalization Workflow

1. Inventory. Export every configured alarm from your SCADA system. Most sites discover they have 2x to 5x more alarms than anyone realized.
2. Review each alarm. For every alarm, the team answers four questions: What is the consequence if the operator misses this alarm? What specific action should the operator take? How much time does the operator have before the consequence occurs? Is this the best way to detect this condition?
3. Assign priority. Based on consequence severity and response time, assign a priority level (critical, warning, advisory, or informational). Most alarms will end up at low priority. That is correct.
4. Document the response. Record the required operator action, the expected response time, and any supporting information (reference documents, related equipment, escalation contacts).
5. Decide the outcome. Each alarm is either justified (keep with documented priority), removed (delete from system), changed to an alert or event (no operator action required), or reconfigured (adjust setpoint, deadband, or delay).

A typical rationalization session eliminates 30% to 60% of configured alarms. This is not negligence. Most of those alarms were added during commissioning by engineers who "wanted to know" about conditions that do not require operator intervention.

Alarm Classification: Priority Levels

ISA-18.2 recommends using no more than four priority levels. More levels dilute operator understanding and create ambiguity. A practical classification scheme:

• Critical (Priority 1). Immediate danger to personnel, environment, or major equipment. Requires action within minutes. Example: reactor pressure exceeding safety limits. Target: fewer than 5% of all configured alarms.
• Warning (Priority 2). Significant process deviation that will lead to production loss, quality issues, or equipment damage if not addressed. Action within 10 to 30 minutes. Example: column temperature deviating beyond acceptable range. Target: 15% of configured alarms.
• Advisory (Priority 3). Process condition that needs operator awareness but allows a longer response time. Action within hours. Example: spare pump auto-start on main pump trip. Target: 30% of configured alarms.
• Informational (not a true alarm). Status notifications like pump running/stopped, valve open/closed. These should be displayed on the HMI graphic, not in the alarm summary. If an operator does not need to take action, it should not generate an alarm event.

The distribution matters. If 80% of your alarms are Critical, operators will treat none of them as critical. Priority differentiation only works when it reflects genuine differences in consequence and urgency.

Reducing Alarm Chatter: Deadbands and Delays

Alarm chatter is one of the most common and most damaging problems in industrial alarm systems. It occurs when an analog value oscillates around an alarm setpoint, causing the same alarm to activate, clear, and reactivate repeatedly. A single noisy transmitter can generate thousands of annunciations per day.

Deadband Configuration

A deadband is a range above (for high alarms) or below (for low alarms) the setpoint that the process value must cross before the alarm can clear. For example, if a high temperature alarm is set at 100 degrees with a 2-degree deadband, the alarm activates at 100 degrees but does not clear until the temperature drops below 98 degrees. This prevents the alarm from chattering when the temperature oscillates between 99 and 101.

Recommended deadband settings:

• Flow measurements: 2% to 5% of span (flow is inherently noisy).
• Level measurements: 1% to 3% of span.
• Temperature measurements: 0.5% to 2% of span (temperature is relatively stable).
• Pressure measurements: 1% to 3% of span.

On-Delay and Off-Delay

Delays add a time qualification to alarm activation and clearing. An on-delay requires the condition to persist for a specified duration before the alarm annunciates. An off-delay requires the condition to clear for a specified duration before the alarm returns to normal.

• On-delay filters out transient spikes. A 5-second on-delay on a pressure alarm means a momentary pressure spike from a valve operation does not trigger the alarm.
• Off-delay prevents rapid clearing and re-annunciation. Combined with deadband, it eliminates the vast majority of chattering alarms.

Use both deadband and delay together for noisy signals. Deadband handles the magnitude component of noise. Delay handles the time component. Together they are extremely effective at eliminating chatter without masking real events.

Shelving and Suppression

Not every alarm is relevant at all times. ISA-18.2 defines two legitimate mechanisms for temporarily removing alarms from the operator's view:

Alarm Shelving

Shelving is an operator-initiated, time-limited action that temporarily silences a specific alarm. The operator shelves an alarm when they are aware of the condition, it is being managed, and continued annunciation would be distracting. Key requirements:

• Shelving has a maximum duration (typically 8 or 12 hours), after which the alarm automatically reactivates.
• Every shelving action is logged with operator ID, timestamp, reason, and duration.
• Shelved alarms are visible on a dedicated display so they are not forgotten.
• The supervisor should review shelving activity during shift handover.

Alarm Suppression

Suppression is automatic, logic-driven deactivation based on plant state. It is configured by engineers, not initiated by operators. Examples:

• Suppress pump discharge pressure low alarm when the pump is confirmed off.
• Suppress tank level alarms when the tank is in maintenance mode.
• Suppress instrument readings when the instrument is flagged as out-of-service or under calibration.

Suppression is the correct solution for alarms that are inherently invalid under certain operating states. It is not a workaround for poorly configured alarms.

Alarm Performance Metrics (KPIs)

You cannot improve what you do not measure. These are the key performance indicators that ISA-18.2 and EEMUA 191 recommend tracking continuously:

Track these metrics in a dashboard that is reviewed weekly by the operations team and monthly by management. Alarm performance should be a standing agenda item in operations meetings, not a report that sits in a drawer.

Common Anti-Patterns

After auditing dozens of industrial alarm systems, the same problems appear repeatedly:

• Alarming everything. Configuring an alarm on every measured variable "just in case." If the operator does not need to take action, it is not an alarm. Informational states belong on the HMI graphic, not in the alarm list.
• No priority differentiation. All alarms configured at the same priority (usually high). When everything is critical, nothing is critical. Operators cannot triage effectively.
• No alarm documentation. Alarms configured with default descriptions and no operator response instructions. When an operator sees "Temp_HH," they have no context for what to do.
• Zero deadband. Analog alarms with zero deadband are guaranteed to chatter on noisy signals. This is the number one cause of alarm floods in most systems.
• Duplicate alarms. The same condition alarmed in multiple places: the transmitter, the controller, and the SCADA point. One event generates three alarm annunciations, tripling the flood.
• Using alarms for status information. "Pump stopped" is a status change, not an alarm, unless the pump was not supposed to stop. Alarm on abnormal conditions, not on state changes.
• Never auditing. Alarm systems degrade over time as engineers add alarms without going through the rationalization process. Without periodic audits, the system returns to chaos within 12 to 18 months.

Good vs Bad Alarm Management Practices

Implementing with Modern SCADA Tools

Modern SCADA platforms provide the building blocks for effective alarm management. What matters is whether those building blocks are actually used. For guidance on selecting a system that supports these capabilities, see our analysis of SCADA architecture patterns. For high-availability deployments where alarm reliability is critical, see our guide to SCADA redundancy and high availability.

What Your SCADA Platform Should Support

• Configurable deadband and delay per alarm point. If your platform does not allow per-point deadband configuration, you will not be able to eliminate chatter without custom programming.
• Priority-based filtering and sorting. Operators should be able to filter the alarm summary by priority, area, and time. During an upset, filtering to Critical-only should be one click.
• Shelving with automatic reactivation and audit logging. This is a safety-critical feature. Shelving without audit logging is not compliant with ISA-18.2.
• State-based suppression logic. The ability to configure suppression rules based on equipment state without writing custom scripts.
• Built-in alarm analytics. Automatic calculation of alarms-per-hour, flood detection, stale alarm identification, and chattering alarm detection. If you have to export data to a spreadsheet to calculate these, the analytics are not usable.
• Alarm response documentation. The ability to attach cause, consequence, and response instructions to each alarm that operators can view inline.

Implementation Sequence

If you are starting from a poorly managed alarm system, follow this sequence:

1. Week 1-2: Write the alarm philosophy document. Get operations and engineering sign-off.
2. Week 3-4: Export the alarm inventory and identify the top 20 worst offenders (highest frequency, most chattering, longest standing). Fix those immediately with deadband, delay, or removal.
3. Month 2-4: Conduct rationalization workshops covering the highest-impact areas first (safety-critical, high-frequency, upset-prone).
4. Month 5-6: Implement state-based suppression for equipment that runs in multiple modes.
5. Ongoing: Weekly KPI review, quarterly rationalization of new and modified alarms, annual full-system audit.

The first pass of rationalization typically achieves a 50% to 80% reduction in alarm volume. Subsequent passes and ongoing maintenance keep the system performing within EEMUA targets.

Frequently Asked Questions

What is SCADA alarm management?

SCADA alarm management is the systematic process of designing, implementing, and maintaining alarms in a SCADA system so that operators receive meaningful, actionable alerts. It follows standards like ISA-18.2 and IEC 62682 to reduce alarm floods, eliminate stale alarms, and ensure every alarm has a clear operator response. The goal is to keep alarm rates below industry benchmarks, typically fewer than 6 alarms per hour per operator.

What is alarm rationalization in ISA-18.2?

Alarm rationalization is the structured review process defined by ISA-18.2 where each alarm is evaluated against criteria including consequence of missing the alarm, response time available, and operator action required. The review team assigns priority levels, documents the required operator response, and decides whether the alarm is justified. Alarms that fail rationalization are removed, downgraded to alerts, or reconfigured with appropriate deadbands and delays.

How many alarms per hour is acceptable in a SCADA system?

The EEMUA 191 benchmark defines three performance levels: a target of fewer than 6 alarms per hour per operator (manageable), 6 to 12 alarms per hour (high and likely to cause operator overload), and over 12 alarms per hour (very high, where operators cannot effectively respond). ISA-18.2 and IEC 62682 recommend keeping systems below the 6 alarms per hour target. Most poorly managed systems generate 50 to 150 alarms per hour during normal operations.

What is the difference between alarm shelving and alarm suppression?

Alarm shelving is a temporary operator-initiated action that silences a specific alarm for a defined period, after which it automatically reactivates. It is tracked, logged, and auditable. Alarm suppression is a system-level configuration where an alarm is disabled based on plant state logic, such as suppressing a pump discharge pressure low alarm when the pump is confirmed off. Both are legitimate ISA-18.2 techniques, but shelving requires operator accountability while suppression is automatic based on process conditions.

Further Reading

• SCADA System Architecture: Design Patterns for Industrial Monitoring
• SCADA vs HMI: What System Integrators Need to Know
• SCADA Redundancy and High Availability: Architecture Guide
• OT Security Checklist for SCADA Systems
• SCADA OEE and Downtime Tracking for Manufacturing