PE-13(2): Suppression Systems — Automatic Activation and Notification

To meet the pe-13(2): suppression systems — automatic activation and notification requirement, you must have fire suppression in applicable spaces that triggers automatically (without human action) and sends timely notifications to the defined recipients (your facility/security operations points of contact). Operationalize it by documenting scope, configuring automatic activation and alert routing, and keeping test/inspection evidence that proves both activation and notification work.

Key takeaways:

• Define exactly which rooms/areas require automatic suppression, then tie them to system boundaries and asset criticality.
• Configure automatic activation plus notification paths (primary and backup) to named roles, not just generic inboxes.
• Retain recurring evidence: inspection/test reports, alarm panel logs, notification test results, and corrective action records.

PE-13(2) is a facilities-to-security control that fails most often for one reason: teams treat suppression hardware as “building stuff” and never collect security-grade evidence that it activates automatically and notifies the right people. Assessors do not accept “the landlord handles it” without artifacts that show what is installed, where it is installed, how it behaves on activation, and how you verify it keeps working.

The control text is short, but the operational work spans multiple owners: Facilities, Data Center Operations (or workplace/real estate), Security Operations, and your third parties (landlord, colocation provider, or managed data center). Your job as CCO/CCO delegate or GRC lead is to (1) translate the notification placeholders into named recipients and escalation rules, (2) make sure the suppression and alarm/monitoring stack is actually configured to notify them automatically, and (3) build a clean evidence package that can be reused every assessment cycle.

This page gives requirement-level implementation guidance you can execute quickly: scoping, ownership, configuration, testing, and what to retain for audit readiness, mapped directly to PE-13(2) in NIST SP 800-53 Rev. 5. ¹

Regulatory text

NIST SP 800-53 Rev. 5 control enhancement PE-13(2) excerpt: “Employ fire suppression systems that activate automatically and notify {{ insert: param, pe-13.02_odp.01 }} and {{ insert: param, pe-13.02_odp.02 }}; and” ²

What the operator must do

You must:

1. Use fire suppression systems with automatic activation in the in-scope areas (no human intervention required to discharge/engage).
2. Send notifications automatically when the system activates (or when the suppression/alarm panel detects the triggering condition), to two defined notification targets (the placeholders are organization-defined parameters you must fill in with your roles/teams). ²

The control text does not prescribe the technology (sprinkler vs. clean agent), the transmission method (panel dialer, IP, monitoring service), or the recipient type. You define those in your system-specific implementation, then prove it works.

Plain-English interpretation

If a fire starts in an area that matters to your system, the suppression must kick in automatically, and your organization must get notified without relying on someone noticing smoke and calling you. “Notify” means actionable alerting that reaches responsible personnel (or a monitoring service that dispatches responsible personnel) fast enough to drive response actions.

For audit purposes, “we have sprinklers” is incomplete. You need evidence that:

• the system is present in the right places,
• it is configured for automatic activation, and
• activation generates notifications to the named recipients you defined for this control.

Who it applies to (entity and operational context)

Applies to:

• Federal information systems and contractor systems handling federal data where NIST SP 800-53 Rev. 5 is in scope (for example, via agency requirements or contract clauses). ¹

Operational contexts where it shows up:

• On-prem data centers and server rooms.
• Corporate facilities hosting regulated system components (network closets, MDF/IDF rooms, secure storage rooms).
• Colocation cages and suites.
• Third-party managed data centers (you still need evidence and notification routing, even if the third party operates the equipment).

Practical scoping rule: if loss of that space could materially impact confidentiality/integrity/availability of the system (or safety of personnel supporting it), treat it as in-scope for PE-13(2) and document your rationale.

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

Step 1: Assign an owner and define the two notification targets

• Control owner (single throat to choke): usually Facilities/Physical Security with GRC oversight.
• Define ODP 1 and ODP 2 as named roles and escalation paths, for example:
  • Primary: Security Operations or on-call facilities engineer group.
  • Secondary: Building monitoring center / third-party monitoring service / duty manager.
• Document substitutions for off-hours (on-call rotation) and how recipients are maintained.

Deliverable: “PE-13(2) Notification Matrix” (roles, contact methods, hours, escalation).

Step 2: Identify in-scope spaces and suppression coverage

Create a simple inventory table:

Space / location	System assets present	Suppression type	Auto-activation?	Alarm/Panel ID	Notification path

Include third-party sites (colocation, managed hosting) with a pointer to the contract/SLA section or MSA exhibit that covers fire suppression and monitoring responsibilities.

Step 3: Validate automatic activation (design + configuration)

You are proving the suppression “activates automatically.” Do this in two layers:

• Design evidence: system specification, commissioning documents, or as-built diagrams stating automatic activation via detectors/panel logic.
• Operational evidence: periodic inspection/testing reports that indicate automatic functions are in service.

If you rely on a third party (landlord/colo), require written confirmation plus their inspection/testing artifacts, not a verbal assurance.

Step 4: Implement automatic notification routing (primary + secondary)

This is where assessments often fail.

You need to show:

• What event triggers notification (alarm condition, water flow, agent discharge, panel alarm).
• Where the notification goes (roles/teams defined in Step 1).
• How it gets there (monitoring service, building management system integration, alarm dialer, or IP-based alerting).

Operational checks:

• Ensure notifications do not terminate only at a front desk or a single person.
• Ensure after-hours routing is explicit (on-call, answering service, monitoring center).
• Ensure notification paths are tested, and failures create tickets/work orders.

Step 5: Test, document results, and track corrective actions

Run a coordinated test with Facilities and Security:

• Confirm the test type is safe (often this is an alarm/monitoring test rather than an actual discharge).
• Record: date/time, participants, test method, expected recipients, actual recipients, and timestamps.
• If notifications fail or are delayed, open a corrective action and retest after changes.

Step 6: Build an assessor-ready evidence package (repeatable)

Create a single folder (or GRC control record) with:

• Scope table (spaces + coverage).
• Notification matrix (ODP 1/ODP 2).
• Most recent inspection/testing artifacts.
• Most recent notification test results.
• Open/closed corrective actions and retest proof.

Daydream fit (earned, not forced): if you struggle to keep facilities artifacts, third-party reports, and recurring tests tied to one control, Daydream can act as the system of record for mapping PE-13(2) to an owner, a procedure, and recurring evidence requests from third parties, so the evidence package exists before the assessor asks.

Required evidence and artifacts to retain

Minimum evidence set (keep versioned copies):

• Control implementation statement for PE-13(2): what systems are used, where, and how notifications work. ³
• Inventory/scope list of covered spaces and suppression systems.
• Inspection, testing, and maintenance reports for suppression and associated alarm panels (internal or third party-provided).
• Notification test records: screenshots/emails, monitoring center test confirmations, alarm panel logs, ticketing records created from alerts.
• Contact roster/on-call procedure showing who receives alerts and how changes are managed.
• Corrective action records (work orders, incident/problem tickets) plus retest evidence.

Evidence quality tip: assessors prefer artifacts that show dates, system identifiers, locations, and pass/fail outcomes, not just a generic “all systems inspected” letter.

Common exam/audit questions and hangups

Expect these:

• “Show me which rooms are in scope and what suppression is installed in each.”
• “Prove the system activates automatically, not manually.”
• “Who are the two notification recipients in your environment (ODP 1 and ODP 2), and how do you keep contact details current?”
• “Show a test where an alarm event generated notifications to both recipients.”
• “If this is a colocation or landlord-managed site, show the contract language and the latest inspection/test report you received.”

Hangups that drive findings:

• Notification is configured, but only to one recipient or one channel.
• Tests exist for suppression hardware, but no proof notifications were sent/received.
• Third party performs tests, but you do not collect the reports.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating PE-13(2) as “sprinklers exist.”
   Fix: pair suppression evidence with notification evidence in the same control record.

2. Mistake: ODP placeholders never get defined.
   Fix: define ODP 1/2 as roles with escalation and backups; don’t leave it as “Facilities.”

3. Mistake: Relying on a third party without artifacts.
   Fix: add recurring evidence requests to the third-party governance cadence (contract exhibit, QBR checklist, or annual compliance pack).

4. Mistake: Notification goes to a shared mailbox nobody monitors after hours.
   Fix: require an on-call or monitoring service path, and test it.

5. Mistake: No linkage to incident response.
   Fix: ensure fire/suppression alerts create a ticket or incident record, even if it’s later closed as a test.

Risk implications (why operators care)

PE-13(2) is about time-to-detect and time-to-respond for facility fire events that can cause system outages, equipment destruction, and safety risk. The compliance failure mode is predictable: you cannot prove automatic activation and notification, so assessors treat it as an unimplemented enhancement, or they scope it as a systemic facilities governance gap. That can cascade into broader findings about third-party oversight, monitoring, and contingency planning.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Assign control owner and backup owner.
• Define ODP 1/ODP 2 notification targets (roles, channels, escalation).
• Build the in-scope space inventory and identify all third-party managed locations.
• Collect whatever inspection/test artifacts already exist; log gaps.

Day 31–60 (configure, validate, and close obvious gaps)

• Validate automatic activation design for each in-scope space (as-builts, commissioning docs, or third-party confirmations).
• Confirm notification routing for each panel/system to both recipients.
• Add third-party evidence requests to contract management (recurring request template).
• Draft the PE-13(2) implementation statement and store it with evidence.

Day 61–90 (prove operation with tests and make it repeatable)

• Run a notification test (or coordinate a permitted alarm/monitoring test) and capture results.
• Open corrective actions for failures; retest and document closure.
• Establish a recurring calendar: inspection/test intake, notification roster review, and evidence refresh.
• In Daydream (or your GRC), map PE-13(2) to the owner, procedure, and recurring evidence tasks so the control stays “alive” between audits.

Frequently Asked Questions

Do I need a clean-agent system to meet PE-13(2)?

PE-13(2) does not specify a suppression agent type; it requires automatic activation and automatic notification. Your evidence should focus on “auto-activates” and “notifies the defined recipients,” regardless of the suppression technology. ²

What should I put for the two notification placeholders (ODP 1 and ODP 2)?

Define role-based recipients with an escalation path, such as “Security Operations on-call” and “Facilities on-call” or a monitoring center plus an internal responder. Document how coverage works after hours and how contact details are maintained.

Our building/colocation provider manages suppression. Can we inherit this control?

You can rely on a third party operationally, but you still need artifacts: scope of coverage, proof of automatic activation, and proof of notification routing and tests. Put evidence collection into your third-party oversight process and keep it with the control record.

What counts as proof of notification?

Logs from the alarm panel/monitoring platform, monitoring center test confirmations, emails/SMS records, and tickets created from alert events are common forms of proof. The artifact should show the recipient targets you defined and the event timestamp.

How often do we have to test automatic activation and notification?

PE-13(2) does not set a specific interval in the excerpt provided. Set a risk-based cadence that matches your facilities program and contract terms, then document it and follow it consistently. ³

What’s the fastest path to audit readiness if evidence is scattered across teams?

Start by building a single PE-13(2) evidence package with a scope list, notification matrix, and the latest inspection and notification-test artifacts. Then operationalize recurring evidence collection in your GRC workflow so you do not rebuild the package for every assessment.

Footnotes

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

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

3. NIST SP 800-53 Rev. 5