This is a ready-to-use master alarm database and rationalization record. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control. A worked filled specimen follows the blank grid. Verify each cited reference against the current source before you rely on it.
Alarm rationalization is the documented review that decides, for each alarm, whether it is needed, what its limit should be, how urgent it is, and what the operator is supposed to do about it. The output is a controlled master alarm database. Alarm setpoints are configured values that protect product and patient, so an inspector expects each one to trace to a reason, not to a vendor default, and the alarm and event log to be complete and attributable. The alarm management standard this aligns to is ANSI/ISA-18.2 (mirrored internationally as IEC 62682); the requirement is described here in general terms, not reproduced.
Document control header
| Field | Entry |
|---|---|
| Document title | Alarm Rationalization and Master Alarm Database Record |
| Document number | <<FILL: DOC-ID, e.g. QP-AUT-021-F02>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: effective date>> |
| System / area | <<FILL: SYSTEM NAME / PROCESS AREA>> |
| Document owner | <<FILL: role, e.g. Automation / Process SME>> |
1. Purpose
This record documents the rationalization of every alarm configured on <<FILL: SYSTEM NAME>> and maintains the master alarm database, so that each alarm is justified, correctly prioritized, and under change control, and so that the alarm and event log remains a trustworthy GMP record.
2. Scope
This record covers all process, equipment, and safety-related alarms presented to operators on <<FILL: SYSTEM NAME>>. Each alarm entry records its limit, priority, cause, consequence, and required operator response, plus the risk basis and the change history. It does not replace the alarm and event log itself, which is generated automatically by the system.
3. Definitions
- Alarm: a configured condition that requires a timely operator response, distinct from an event or a status indication that requires none.
- Rationalization: the documented decision that an alarm is necessary, and the assignment of its limit, priority, and response.
- Priority: the relative urgency assigned to an alarm so an operator facing several at once knows what to act on first.
- Master alarm database: the controlled list of every configured alarm and its rationalized attributes, and the authority against which the live configuration is verified.
- Alarm flood: a burst of more alarms than an operator can process, a known failure mode that rationalization is meant to prevent.
4. Instructions
- List every configured alarm on the system. For each, record the tag, description, and alarm type (for example high, high-high, low, deviation, rate-of-change, discrete fault).
- For each alarm, rationalize and record: the setpoint (limit), the engineering units, the cause (what makes it activate), the consequence if no action is taken, the required operator response, the time available to respond, and the assigned priority.
- State the risk basis: why this alarm exists and why the limit is where it is, tracing to the process requirement, the safe operating range, or the risk assessment, not to a vendor default.
- Confirm the priority distribution is workable (most alarms should not be top priority) and that no critical condition is left un-alarmed.
- Record the change control reference for any alarm that is added, removed, or has its limit or priority changed, and confirm the change was authorized and captured in the audit trail.
- Verify periodically that the live system configuration matches this master database and record the verification.
- The author signs and dates; a second qualified reviewer and QA review and approve.
5. Acceptance criteria
The alarm rationalization is acceptable when all of the following are true:
- Every configured alarm appears in the master database with a limit, priority, cause, consequence, and required response.
- Each limit and priority traces to a documented risk basis, not a default.
- No credible critical condition is left without an alarm, and no unnecessary alarm remains that would contribute to a flood.
- Every change to an alarm limit or priority carries a change control reference and appears in the system audit trail with who, when, and old-to-new.
- The live configuration has been verified against the master database, and the record is complete, signed, and approved.
6. Master alarm database (blank)
| Tag | Description | Alarm type | Setpoint / EU | Priority | Cause | Consequence if no action | Required operator response | Time to respond | Risk basis | Change ref |
|---|---|---|---|---|---|---|---|---|---|---|
<<FILL: TT-201>> | <<FILL: Reactor jacket temp high>> | <<FILL: High>> | <<FILL: 140 degC>> | <<FILL: High>> | <<FILL: cooling loss / exotherm>> | <<FILL: batch quality excursion>> | <<FILL: verify cooling, hold step>> | <<FILL: e.g. 5 min>> | <<FILL: upper edge of validated range + margin>> | <<FILL: CC-#>> |
<<FILL: TT-201>> | <<FILL: Reactor jacket temp high-high>> | <<FILL: High-high>> | <<FILL: 148 degC>> | <<FILL: Critical>> | <<FILL: control failure>> | <<FILL: product loss / safety>> | <<FILL: initiate defined shutdown>> | <<FILL: e.g. 2 min>> | <<FILL: below hazard limit, above High>> | <<FILL: CC-#>> |
Author: <<FILL: name, signature, date>> Reviewer: <<FILL>> QA: <<FILL>>
7. References
21 CFR Part 11 (electronic records) and 21 CFR 211.68; alarm and event records are GMP records. EU GMP Annex 11 (computerised systems), including audit trail and event expectations. ANSI/ISA-18.2 and IEC 62682, Management of Alarm Systems for the Process Industries (referenced by number and title; described, not reproduced). The system risk assessment and the validated operating ranges that justify each limit.
Confirm the current version and clause numbers of each reference before issue.
8. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
9. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (Process / Automation SME) | <<FILL>> | ||
| Reviewer | <<FILL>> | ||
| Approver (QA) | <<FILL>> |
Filled specimen
The following shows two rationalized alarms on an example bioreactor, so you can see the level of detail expected. The system, tags, and numbers are illustrative; replace them with your own.
| Tag | Description | Alarm type | Setpoint / EU | Priority | Cause | Consequence if no action | Required operator response | Time to respond | Risk basis | Change ref |
|---|---|---|---|---|---|---|---|---|---|---|
| TIC-101 | Culture temp high | High | 37.8 degC | High | Jacket control loss or exotherm | Cell viability and product quality drift outside the validated range | Confirm loop in auto, verify cooling, notify supervisor, assess hold | 10 min | Upper edge of the validated 36.5 to 37.5 range plus a 0.3 degC margin | CC-2026-0088 |
| TIC-101 | Culture temp high-high | High-high | 39.0 degC | Critical | Failure of primary temperature control | Batch loss and possible safety impact | Initiate the defined controlled shutdown of the affected step | 3 min | Set below the point where the culture is unrecoverable, above the High alarm | CC-2026-0088 |
In this example, both alarms trace to the validated temperature range and the point of no return for the culture rather than to the DCS default, the two levels give the operator a graded response, and the setpoints were set through change control CC-2026-0088 with the change captured in the audit trail. If an inspector asks why the high alarm is at 37.8, the record answers with the risk basis, not a shrug.
Common inspection findings this record prevents
- Alarm setpoints are vendor defaults with no documented risk rationale.
- A critical alarm limit was changed on the floor with no change control and no audit trail entry.
- Everything is set to high priority, so an operator in an alarm flood cannot tell what matters.
- A credible critical condition has no alarm at all, discovered only after a deviation.
- The live alarm configuration no longer matches any controlled master list, so no one can say what the alarms are supposed to be.
How to adapt this record
- Set your document number, system, and owner in the header.
- Populate the database from your actual configured alarm list, one row per alarm, including high-high and low-low levels.
- Tie the priority scheme to your own operator response model and confirm the distribution is not top-heavy.
- Point the change reference column at your real change control procedure.
- Add a periodic reconciliation step that compares the live configuration to this master database and records the result, and reference it from your automation periodic review.