PE-14(2): Monitoring with Alarms and Notifications

PE-14(2) is a requirement many security teams think they “inherit” from building management, until an assessor asks for proof that alarms are configured, routed to the right people, and tested. This control enhancement is specific: environmental control monitoring must produce an alarm or notification when conditions change in ways that could harm personnel or equipment. In practice, that means you need (1) defined environmental parameters and thresholds, (2) a monitoring system that can detect and log changes, (3) alerting that reliably notifies on-call staff, and (4) an operational response process with tickets, escalations, and post-incident review when needed.

This page is written for Compliance Officers, CCOs, and GRC leads who need to operationalize the requirement quickly across facilities, data centers, network closets, labs, and other controlled spaces supporting federal information systems or contractor systems handling federal data. Your goal is to make the control assessable: clear ownership, clear scope, and repeatable evidence that alarms and notifications actually fire and drive action.

Regulatory text

Requirement (verbatim excerpt): “Employ environmental control monitoring that provides an alarm or notification of changes potentially harmful to personnel or equipment to {{ insert: param, pe-14.02_odp }}.” ¹

What the operator must do:

• “Employ environmental control monitoring” means you have sensors/monitoring for environmental conditions in spaces where system components operate (or where their failure could harm people).
• “Provides an alarm or notification” means the monitoring must actively alert; a passive log or a dashboard alone is not enough for this enhancement.
• “Changes potentially harmful to personnel or equipment” means you must define the harmful conditions for your environment (examples below) and set thresholds or triggers that generate alerts.
• The “{{ insert: param, pe-14.02_odp }}” parameter is an organization-defined parameter. You must define it in your control implementation (what locations/conditions are covered, who is notified, what timeframes/escalations apply, and any tailoring).

Control family context: PE controls sit in Physical and Environmental Protection and typically require coordination among Facilities, Security Operations, IT Operations, and sometimes a colocation provider. ²

Plain-English interpretation of the requirement

You need continuous or scheduled monitoring of environmental conditions that matter for safety and equipment reliability, plus alerting that reaches accountable humans (or an automated paging system) when conditions drift into dangerous ranges or when environmental systems fail. Then you must be able to show an assessor the configuration and proof of operation: alert rules, recipients, test results, and response records.

Common environmental conditions in scope (choose based on your risk and environment; document your choices):

• Temperature and humidity out of safe range for installed equipment
• Water leaks in/near equipment areas
• Smoke/fire detection interface events (as applicable to your facility design)
• Power anomalies affecting environmental systems (HVAC failure, loss of cooling)
• Airflow/pressure anomalies in controlled rooms (where relevant)
• Refrigerant or other hazardous conditions if present in your environment

Who it applies to (entity and operational context)

Entity types:

• Federal information systems
• Contractor systems handling federal data ¹

Operational contexts where assessors expect PE-14(2) to be implemented:

• On-prem data centers and server rooms
• Network closets/IDFs/MDFs with critical equipment
• Labs and test environments with specialized equipment
• Storage areas for backup media or sensitive hardware
• Colocation cages/suites (shared responsibility with the colo provider)
• Third-party managed facilities where you still have accountability for controls, even if implementation is shared

Boundary rule (practical): If a facility condition can take systems down, destroy equipment, or create a safety incident, you need monitoring and alerts within your system boundary or as a formally inherited/common control with evidence.

What you actually need to do (step-by-step)

Step 1: Assign ownership and define the control boundary

1. Name a control owner (often Facilities, with Security/GRC as co-owners).
2. List in-scope spaces (rooms, cages, closets) and map each to an environmental monitoring method (BMS, dedicated sensors, managed service).
3. Document shared responsibility for any third party facility (colocation, landlord building systems) in a short RACI or responsibility matrix.

Deliverable: Control implementation statement and boundary list for PE-14(2). ²

Step 2: Define “potentially harmful” changes and your organization-defined parameters

1. Identify environmental conditions to monitor (temperature, humidity, water, HVAC status, etc.).
2. Define alert triggers: thresholds, rate-of-change, device offline, or subsystem failure.
3. Set severity tiers (warning vs critical) and the expected response handling (who responds, escalation path).

Tip: Auditors look for specificity. “We monitor temperature” is weaker than “Temperature sensors in each server room generate a critical alert when readings exceed our defined threshold; alerts page on-call facilities and create an incident ticket.”

Deliverable: PE-14(2) parameter definitions and alert matrix.

Step 3: Implement monitoring with alarms/notifications (not just monitoring)

1. Confirm sensors exist and are positioned sensibly (e.g., where heat/water accumulates, near CRAC units, under raised floors if applicable).
2. Confirm the monitoring platform logs readings and device health (battery, connectivity).
3. Configure alerting paths:
   • Primary: paging/notification tool, on-call phone/SMS, or staffed SOC queue
   • Secondary: email distribution list for redundancy
   • Tertiary: escalation to management for unacknowledged critical alerts
4. Ensure alerts are actionable: include location, sensor ID, last reading, and runbook link.

Deliverable: Screenshots/exports of alert rules and notification routing.

Step 4: Write response procedures that match how your teams work

1. Create a short runbook per alert type: triage steps, safety checks, shutdown steps (if needed), and who to contact.
2. Integrate with incident management: create tickets/incidents for critical alerts; track time to acknowledge and resolution notes.
3. Define after-hours coverage and escalation expectations.

Deliverable: Environmental alert runbooks + incident/ticket workflow mapping.

Step 5: Test and prove alarms/notifications work end-to-end

1. Perform initial commissioning tests: trigger representative alerts (or simulated events) and confirm receipt by the right responders.
2. Validate acknowledgements and escalation behavior.
3. Record evidence of the test, including timestamps, recipients, and remediation if something failed.

Deliverable: Alarm/notification test records and corrective actions.

Step 6: Operationalize recurring review and maintenance

1. Review alert configurations after facility changes (moves/adds/changes, HVAC upgrades, cage changes).
2. Maintain sensor health: batteries, calibration (if applicable), connectivity checks.
3. Periodically sample alert/ticket records to confirm responders follow the runbooks.

Deliverable: Change records, maintenance logs, periodic control self-assessment notes.

Required evidence and artifacts to retain

Keep evidence that shows design, implementation, and ongoing operation:

Design / governance

• PE-14(2) control statement with organization-defined parameters ¹
• Control ownership (RACI) and scoped location inventory
• Alert severity matrix and routing rules (who gets what, when)

Technical configuration

• Sensor inventory (type, location, unique ID, connectivity method)
• Monitoring system configuration exports/screenshots
• Alarm/notification rule definitions (thresholds, device offline alerts, escalation)

Operational proof

• Alarm/notification test plans and completed test results
• Incident/ticket records tied to environmental alerts (triage notes, resolution, closures)
• Maintenance logs (battery replacement, calibration where relevant)
• Evidence of periodic review (meeting notes, attestation, or GRC control check)

If you use Daydream to manage control execution, map PE-14(2) to a named owner, a written procedure, and a recurring evidence checklist so you can produce consistent artifacts on demand.

Common exam/audit questions and hangups

Auditors and assessors typically press on these points:

1. “Show me the alarms.” They want to see configured rules and notification recipients, not a narrative.
2. “How do you know the alert reaches a human?” A dashboard in a facilities office is weak if nobody watches it after hours.
3. “What’s your threshold and why?” You do not need to cite an external standard, but you must show you defined “potentially harmful” in your environment and made it operational.
4. “What happens if the sensor goes offline?” Device-health alerting is part of making monitoring reliable.
5. “Is this inherited from the colocation provider?” If yes, show the inheritance agreement and evidence (reports, SOC documentation, or provider portal exports) that alarms/notifications exist and are acted on.

Frequent implementation mistakes and how to avoid them

Mistake: Monitoring without notification.
Fix: Demonstrate alert routing to on-call responders and test it.

Mistake: Undefined “harmful” conditions.
Fix: Write the organization-defined parameters and thresholds; tie them to equipment/safety considerations in your environment.

Mistake: Alert fatigue from noisy sensors.
Fix: Use severity tiers and tune thresholds; create separate rules for “warning” vs “critical,” and suppress duplicate alerts during an active incident.

Mistake: Assuming a third party handles it without evidence.
Fix: Treat colocation/BMS as a shared control. Collect recurring evidence and document responsibilities.

Mistake: No proof of ongoing operation.
Fix: Retain alert test results, incident tickets, and periodic reviews. Missing implementation evidence is a known risk factor for this requirement. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for PE-14(2), so this page does not cite enforcement actions.

Operationally, failure of environmental monitoring and alerting increases the likelihood of:

• Equipment damage and unplanned downtime
• Loss of evidence if monitoring systems fail silently
• Safety incidents if hazardous conditions go undetected

From a compliance standpoint, this control is easy to “say” and harder to “prove.” The usual failure mode is not the absence of sensors; it’s lack of tested notifications, unclear ownership, and missing artifacts during assessment.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Assign a primary owner and confirm Facilities/SecOps/IT Ops roles for alert handling.
• Inventory in-scope locations and identify where monitoring exists vs gaps.
• Define organization parameters: monitored conditions, triggers, recipients, escalation.
• Collect baseline evidence: current configurations, sensor list, and any existing runbooks.

Days 31–60 (make alarms real and assessable)

• Configure/clean up alert rules so every critical condition generates a notification to accountable responders.
• Implement sensor-health alerts (offline/battery) and verify routing.
• Write short runbooks aligned to real response behavior and staffing.
• Run an end-to-end alert test and document outcomes and fixes.

Days 61–90 (operationalize and make it repeatable)

• Integrate environmental alerts into incident/ticketing consistently.
• Add a recurring control check: review alert rules after changes, sample incidents, confirm on-call rosters.
• Build an evidence package template (screenshots/exports, test records, sample tickets) and store it in your GRC system.
• If you rely on a third party facility, formalize inheritance and set a cadence for evidence collection.

Frequently Asked Questions

Do I need a dedicated environmental monitoring system, or can I rely on the building management system (BMS)?

Either can work if it provides alarms/notifications for harmful changes and you can produce configuration and operational evidence. If BMS is managed by a third party, document shared responsibility and retain proof the notifications are configured and tested.

What counts as an “alarm or notification” for PE-14(2)?

An alarm/notification is a signal that reaches responders without someone continuously watching a screen, such as paging, SMS, phone call, or a monitored SOC queue. A dashboard alone is usually insufficient because it does not show active notification.

How do we define “potentially harmful” without citing external thresholds?

Define it as organization parameters based on your equipment and safety needs, then document the triggers and response actions. Assessors mainly want to see that you made an explicit, controlled decision and implemented it consistently. ¹

We are fully in the cloud. Does PE-14(2) still apply?

It can, depending on your system boundary and whether you operate any physical spaces (offices with network gear, labs, backup media storage). For cloud-only workloads, you may inherit physical/environmental controls from the cloud provider, but you still need documented inheritance and evidence appropriate to your authorization approach. ²

What evidence is most persuasive in an assessment?

A tight evidence set includes alert rule exports, notification routing lists, a completed end-to-end test record, and a small sample of tickets showing response and resolution. Pair that with a clear scope list of monitored locations.

Who should receive the alerts: Facilities, Security Operations, or IT?

Route alerts to whoever can act fastest and safest, usually Facilities for HVAC/water issues and Security/IT for access-controlled rooms or equipment protection actions. Make routing explicit by alert type and severity so ownership is unambiguous during after-hours events.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5