If an owner specification says “alarm system shall comply with EEMUA 191” and another says “per ANSI/ISA-18.2”, you are being asked for two different kinds of thing. One is guidance you follow; the other is a standard you can be audited against. This article sets out what each document actually requires, where they differ, and what a compliance audit asks you to produce.
What Each Document Is
| EEMUA 191 | ANSI/ISA-18.2 (IEC 62682) | |
|---|---|---|
| Publisher | Engineering Equipment and Materials Users Association (UK) | ISA / ANSI, adopted as IEC 62682 |
| Nature | Guidance — a design, management and procurement guide | Standard — normative requirements with “shall” clauses |
| Origin | UK process industry, first published 1999 | US process industry, first published 2009 |
| Strongest contribution | The performance benchmarks — the numbers everyone quotes | The lifecycle model and management-of-change discipline |
| How it is cited | “in line with EEMUA 191” | “compliant with ISA-18.2” |
| Auditable | Benchmarks yes; process partly | Yes, clause by clause |
The practical consequence: EEMUA 191 tells you what good performance looks like. ISA-18.2 tells you what process you must run and document to get there and stay there. They are complementary, and most mature specifications reference both.
The Benchmarks — Where the Famous Numbers Come From
The alarm rate figures quoted across the industry originate in EEMUA 191 and were subsequently reflected in ISA-18.2. They are stated per operator console.
| Metric | Benchmark | Source |
|---|---|---|
| Average alarms per 10 minutes | ≤ 2 (1–2 target) | EEMUA 191 / ISA-18.2 |
| Maximum manageable per 10 minutes | 10 | EEMUA 191 |
| Alarms per hour, steady state | ≤ 6–12 | EEMUA 191 |
| Peak alarms in 10 min after major upset | ≤ 10 (flood threshold) | ISA-18.2 |
| Percentage of time in flood | < 1% | ISA-18.2 |
| Standing alarms | < 10, reviewed daily | EEMUA 191 |
| Priority distribution | ~80% low / 15% medium / 5% high | EEMUA 191 |
| Alarms requiring no operator action | 0% | Both |
The ISA-18.2 Lifecycle — The Part That Gets Audited
ISA-18.2 defines alarm management as a closed lifecycle rather than a project. An audit follows these stages and asks for the artefact each one produces.
| Stage | What it requires | Evidence an auditor asks for |
|---|---|---|
| Philosophy | A written alarm philosophy document defining priorities, classes, performance targets and roles | The signed philosophy document |
| Identification | A defined method for proposing alarms (HAZOP, LOPA, P&ID review, incident actions) | Traceability from hazard study to alarm |
| Rationalisation | Every alarm justified, prioritised, classified and documented | The master alarm database |
| Detailed design | Setpoints, deadbands, delays, HMI presentation | Design records and configuration exports |
| Implementation | Controlled deployment and commissioning testing | Test records, as-built configuration |
| Operation | Alarm response procedures available to operators | Response procedures per alarm class |
| Maintenance | Testing, repair and out-of-service handling | Maintenance and bypass records |
| Monitoring & assessment | Continuous KPI measurement against targets | Periodic KPI reports |
| Management of change | Controlled process for any alarm change | MOC records with approvals |
| Audit | Periodic review of the whole system | Audit reports and closure of findings |
Notice how much of this is documentation rather than configuration. Most plants that fail an alarm audit do not fail on alarm rates — they fail because they cannot produce a master alarm database, or because alarms were changed without an MOC record.
The Master Alarm Database Is the Central Artefact
If you take one thing from ISA-18.2, take this: the master alarm database is the system of record. It is not an export of the DCS configuration. It is the authoritative list of every alarm with its justification, and the DCS is supposed to match it — not the other way round.
A conforming record carries, per alarm, at minimum:
- Tag, description and alarm type
- Setpoint, deadband, on/off delay
- Priority and the consequence-plus-response-time reasoning that set it
- Alarm class (e.g. safety, environmental, quality, regulatory)
- Cause, consequence of inaction, and the corrective action expected
- Allowable response time
- Rationalisation date, participants and approval
- Change history with MOC reference
When an owner audit asks “show me why this alarm is High priority”, this record is the answer. If the answer is “because it always has been”, that is a finding.
Where the Two Documents Genuinely Differ
Alarm classes
ISA-18.2 requires alarms to be assigned to classes with class-specific requirements for testing, training and documentation — a safety-related alarm carries obligations a quality alarm does not. EEMUA 191 discusses categorisation but does not impose the same formal class machinery.
Management of change
ISA-18.2 makes MOC a normative requirement. This is the clause that most often catches plants: adding an alarm during a night shift without a record is a non-conformance even if the alarm is a good idea.
Highly managed alarms
ISA-18.2 treats certain categories — safety alarms, alarms credited in LOPA as independent protection layers — with additional rigour including periodic proof testing. If an alarm is credited in a LOPA, it inherits testing obligations similar to an instrumented function.
Suppression and shelving
Both permit designed suppression. ISA-18.2 is stricter about the record: who shelved it, why, for how long, and what brings it back. Indefinite shelving with no expiry is treated as a defect.
What This Means for a Vendor Package
If you supply a subsystem — an analyser package, a compressor skid, a CEMS or DAS — into a plant with an ISA-18.2 programme, your package is expected to arrive with alarms already rationalised, priorities consistent with the site philosophy, and a master alarm database entry per alarm. Delivering a package with 400 alarms all set to High is the fastest way to fail acceptance and be sent back to do the work at your own cost.
This is worth pricing into the bid rather than discovering at FAT.
A Realistic Compliance Path
- Write the philosophy first. Without it, rationalisation has no rules to apply and every decision is re-argued.
- Baseline the KPIs. Thirty days of history against the EEMUA benchmarks tells you the size of the problem.
- Clear bad actors. Fastest measurable improvement, no philosophy debate needed.
- Rationalise by unit, not by plant — a unit at a time keeps the workshops finite and the momentum visible.
- Stand up the master alarm database as the record, with MOC wired into it.
- Report KPIs monthly to a named owner. This is what makes it survive.
Getting a Baseline Against These Benchmarks
Send us 30 days of alarm history and the applicable owner specification, and we will return your position against each benchmark in this article, plus the gap list an ISA-18.2 audit would raise. NEO AEGIS is the platform we use to hold the master alarm database and report the KPIs continuously.
Related reading: What is an alarm flood · Chattering alarms and bad actors · How alarm rationalisation is actually done