PE-13(1): Detection Systems — Automatic Activation and Notification

PE-13(1) requires you to have fire detection systems that automatically activate and automatically notify the right internal and external parties when a fire event occurs. To operationalize it fast, define “who gets notified,” confirm your detection-to-notification signaling path works end-to-end, and retain test/inspection evidence that proves the system activates and notifications fire without manual intervention. ¹

Key takeaways:

• Automatic activation is mandatory; manual-only detection or manual call trees do not satisfy PE-13(1). ¹
• The “notification list” is an organization-defined parameter; you must explicitly name roles/teams and document them. ¹
• Audit success hinges on recurring evidence: inspection/testing logs, alarm routing diagrams, and notification test results. ¹

The pe-13(1): detection systems — automatic activation and notification requirement sits in the Physical and Environmental Protection (PE) family and is assessed like an operations control, not a paper control. Assessors will look for two things: (1) fire detection that triggers automatically, and (2) automatic notification to the parties you designated, without relying on a person to notice, decide, and call someone. ¹

This enhancement is easy to “say yes” to and surprisingly easy to fail in practice. Common failure modes include: unclear notification ownership (no one can name who receives alarms), alarm paths that stop at a building panel with no remote monitoring, and missing evidence because facilities testing happens outside the GRC program. Your job as a CCO/GRC lead is to translate this into a small, testable set of operational requirements, assign accountable owners across Facilities and Security, and collect evidence on a cadence that stands up in an assessment.

This page gives you requirement-level implementation guidance: how to define the notification parties, how to validate the alarm routing, what artifacts to retain, and how to handle edge cases like colocation data centers and leased offices.

Regulatory text

Requirement (verbatim): “Employ fire detection systems that activate automatically and notify {{ insert: param, pe-13.01_odp.01 }} and {{ insert: param, pe-13.01_odp.02 }} in the event of a fire.” ¹

Operator interpretation of the placeholders: Those two “insert: param” fields are organization-defined parameters. You must decide and document exactly who gets notified (by role and/or organization), then implement detection and alarm routing so notifications happen automatically. ¹

What an assessor expects you to demonstrate:

• Fire detection exists in the relevant facilities/areas.
• Detection triggers automatically (not only via human reporting).
• Notification to defined recipients happens automatically (not only “security will call”). ¹

Plain-English requirement interpretation

You need a fire detection capability (commonly smoke/heat detection connected to a fire alarm control panel and/or monitoring service) that:

1. Automatically activates when fire conditions occur, and
2. Automatically notifies the parties you pre-identified (for example, building security, facilities on-call, a monitoring station, and/or emergency responders), according to your environment and risk model.

PE-13(1) is about speed and reliability under stress. People miss alarms. Shifts change. Phones die. Automatic activation and notification reduce dependence on human judgment during an incident.

Who it applies to

Entity types

• Federal information systems and contractor systems handling federal data that implement NIST SP 800-53 controls (common in FedRAMP, agency ATOs, and many contractual security requirements). ¹

Operational contexts

• Owned offices, data centers, labs, and warehouses where your system components reside.
• Leased space where you control portions of physical security and safety operations.
• Colocation or hosted data centers where a third party operates building systems; you still need contractually-backed assurance and evidence.

Scope tip for GRC: Treat “system” scope as “where the information system is processed, stored, or administered,” then map each location to how detection and notifications work there.

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

1) Name the notification recipients (the “ODPs”)

Define the two organization-specific notification parameters as explicit recipients. Use roles and escalation coverage, not personal names.

A practical pattern:

• Recipient group A (internal): Facilities on-call / Corporate Security / SOC (if they handle facilities alarms)
• Recipient group B (external): Central monitoring station and/or local emergency services (as appropriate to your environment and contracts)

Document for each site:

• Primary and secondary recipients
• Method (panel dialer, IP communicator, monitoring portal, email/SMS, building management system integration)
• Hours of coverage and escalation

Record this in a control narrative and in a facilities runbook so it survives org changes.

2) Inventory detection and alarm routing per location

Build a simple matrix (one row per site/area) that answers:

• What detection exists (smoke, heat, aspirating detection in high-value rooms, etc.)?
• What triggers the alarm (automatic sensor activation)?
• Where does the alarm go (local panel, guard desk, monitoring service, SOC tool)?
• Who receives the notification automatically?

If you are in a colocation, your matrix should include the third party’s monitoring/dispatch responsibilities and your own internal notification path.

3) Validate “automatic” end-to-end (activation + notification)

Run an end-to-end test that demonstrates:

• A detector activation produces an alarm condition without a person initiating it.
• The alarm condition produces notifications to the defined recipients without manual forwarding.

Testing may be performed by Facilities, the landlord, or the colocation operator. Your job is to ensure:

• You get evidence of the test.
• The evidence ties to your defined recipients (not just “alarm sounded”).

4) Define an incident handling handoff

PE-13(1) stops at activation and notification, but audits often probe what happens next. Create a short handoff procedure:

• Who acknowledges the alarm?
• Who contacts emergency responders if the monitoring station does not?
• Who triggers IT actions (safe shutdown, DR invocation, building access restrictions)?

Keep it short and operational. Point to your incident response process for the broader lifecycle.

5) Formalize ownership and recurring evidence collection

Assign:

• Control owner: often Facilities/Security Operations (with GRC oversight)
• Evidence owner: someone who can reliably pull inspection/testing logs and monitoring notifications
• Reviewer: GRC to confirm completeness and retain artifacts

Daydream (or any GRC workflow) becomes useful here because PE controls often fail due to missing recurring evidence. Map PE-13(1) to a control owner, implementation procedure, and recurring evidence artifacts so collection is consistent across sites. ¹

Required evidence and artifacts to retain

Keep evidence that proves design (how it is supposed to work) and operation (it works repeatedly).

Design artifacts

• Fire detection and alarm routing diagram(s) showing detectors → panel → monitoring/notification targets
• List of defined notification recipients (your filled-in “ODPs”) and escalation coverage
• Contracts/SOWs for colocation or monitoring services that describe alarm monitoring and dispatch/notification responsibilities

Operational artifacts

• Inspection and testing logs for fire detection/alarm systems (from Facilities/landlord/colo)
• Monitoring station reports or alarm history exports showing test signals and notifications delivered
• Work orders or corrective action tickets for deficiencies found during testing
• Change records when notification targets change (phone numbers, receiver accounts, routing rules)

Retention approach

• Store site-specific evidence alongside your system authorization package or compliance repository.
• Index by location and test date so an auditor can trace “site X” without searching email.

Common exam/audit questions and hangups

Use these as a pre-audit checklist:

1. “Who exactly gets notified?”
   Auditors dislike “security is notified.” Provide roles/groups and evidence of routing. ¹

2. “Is notification automatic or dependent on a person?”
   If a guard hears an alarm and then calls Facilities, that is not automatic notification. Show the automatic path.

3. “Does this cover all in-scope locations?”
   Hybrid footprints fail here. Auditors will sample a smaller site.

4. “Where is the evidence?”
   Facilities may test regularly but not retain reports in a way GRC can produce quickly.

5. “What about third-party sites?”
   For colocation, show contractual assurance plus artifacts from the operator (test reports, SOC2-type reports if available, and incident/test logs specific to alarm monitoring).

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Avoid it by
Notification recipients are undefined or stale	The requirement explicitly depends on organization-defined recipients. 1	Put recipients in a controlled document and review on a set cadence tied to on-call rotations.
Local-only alarms	A siren in a room does not notify responders if no one is present	Confirm remote monitoring or automatic messaging to staffed roles.
Evidence lives with the landlord/colo and isn’t retrievable	You cannot demonstrate operation during an assessment	Add evidence delivery requirements to contracts and collect after each test.
Testing proves “alarm sounded” but not “notifications sent”	PE-13(1) requires notification, not just activation. 1	Require end-to-end notification test artifacts (monitoring report, call/SMS log, alarm history).
GRC owns the control with no Facilities owner	Control becomes theoretical	Make Facilities/Security Ops accountable; GRC validates and retains evidence.

Risk implications (why operators care)

If detection activates but notifications fail, you increase:

• Safety risk to personnel
• Downtime risk (small incidents become major outages)
• Data security risk (loss of physical controls, forced evacuation, emergency access)

From an assessment standpoint, PE control failures frequently expand sample sizes and trigger broader facilities scrutiny, especially where your system supports mission-critical services.

Practical execution plan (30/60/90)

You asked for fast operationalization; this plan is staged by phases without making claims about exact elapsed time.

First 30 days (stabilize scope and ownership)

• Identify all in-scope facilities/colo sites for the system.
• Fill in the two notification parameters: name recipient groups and escalation coverage. ¹
• Assign control/evidence owners (Facilities/Security Ops + GRC reviewer).
• Create the site matrix (detection type, routing path, recipients, evidence source).

Days 31–60 (prove the control works end-to-end)

• Collect existing inspection/testing reports for each site.
• Perform or schedule an end-to-end alarm-to-notification test where evidence is weak.
• For third-party sites, request alarm monitoring/test artifacts and confirm contractual obligations for notification.

Days 61–90 (make it repeatable and audit-ready)

• Implement recurring evidence collection tasks (after each inspection/test, after any routing change).
• Add change triggers: any on-call rotation change updates notification targets.
• Store artifacts in a single compliance repository with clear naming by site/date.
• In Daydream, map PE-13(1) to the owner, procedure, and recurring evidence checklist so you can produce an auditor-ready packet without chasing Facilities. ¹

Frequently Asked Questions

Does a manual pull station satisfy PE-13(1)?

A pull station can be part of your fire safety system, but PE-13(1) specifically requires detection systems that activate automatically and notify designated recipients. Treat manual stations as additive, not sufficient by themselves. ¹

Can the notification go only to a third-party monitoring company?

It can, as long as your defined notification recipients include that monitoring function and you can show notifications occur automatically. Most teams also define an internal recipient so your organization is informed even if responders are dispatched. ¹

We’re in a leased office where the landlord runs the fire system. How do we comply?

Document the landlord-operated detection/notification approach, obtain inspection/testing evidence, and ensure your organization’s defined recipients are notified (directly or via a contracted monitoring workflow). If you cannot get evidence, treat it as a risk and close the gap contractually. ¹

What evidence is strongest for auditors?

End-to-end testing artifacts that show a detector event produced a logged notification to your defined recipients, plus routine inspection/testing reports from the responsible party. Pair that with a routing diagram and a current recipient list. ¹

Does PE-13(1) apply to cloud-only systems with no facilities?

If your authorization boundary includes only cloud services and no organization-controlled facilities, the control may be inherited or not applicable, but that decision must be documented in your system’s control implementation. If you have offices where administrators work or where supporting systems exist, those locations can still bring PE controls into scope.

How do we keep notifications current when on-call rotations change?

Use role-based distribution lists or an on-call system integration, then tie changes to your access/change management process so updates produce a tracked record and a quick notification test.

Footnotes

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