PE-23: Facility Location

PE-23: Facility Location requires you to make deliberate, documented decisions about where facilities housing your systems are placed, based on physical and environmental hazards (flood, fire, seismic, severe weather, industrial accidents), and to keep evidence that those decisions are made and maintained. Your fastest path is a repeatable site-risk assessment tied to each hosting location, with clear ownership and review triggers. ¹

Key takeaways:

• PE-23 is a planning-and-evidence control: you must show how location risks were assessed and addressed for each facility that hosts the system. ¹
• Scope includes owned sites, colocation, and other third-party facilities if your system resides there; “we don’t control the building” is not a pass. ¹
• Operationalize PE-23 with a site hazard register, a standardized assessment, and lifecycle triggers tied to moves, expansions, and material environmental changes. ²

The pe-23: facility location requirement is easy to under-implement because teams treat it as a one-time real estate decision. Auditors tend to treat it differently: if your system runs in a data center, office, warehouse, plant, lab, or colocation cage, you should be able to explain why that location is acceptable given local hazards, what mitigations exist, and when you will reassess.

PE-23 sits in the Physical and Environmental Protection (PE) control family. Even if most of your stack is “in the cloud,” your system still resides somewhere physically. Your job is to ensure facility placement decisions consider realistic threats like flooding, earthquakes, wildfires, extreme heat, nearby chemical facilities, civil disruption, and critical infrastructure dependencies. Then you must retain evidence that those considerations happened, were approved, and remain current. ¹

This page gives you requirement-level implementation guidance: scope, control intent in plain English, a step-by-step procedure you can adopt immediately, evidence to retain, and the audit questions that typically stall teams.

Regulatory text

NIST excerpt (PE-23): “Plan the location or site of the facility where the system resides considering physical and environmental hazards; and” ¹

What the operator must do:

1. Identify the facility or facilities where the system resides (including third-party sites).
2. Evaluate location-specific physical and environmental hazards that could impact confidentiality, integrity, availability, or safety.
3. Make and document a placement decision (or continued-operations decision) that accounts for those hazards, including required mitigations and acceptance of residual risk.
4. Maintain the decision over time through reassessment triggers and evidence retention. ¹

NIST’s intent here is straightforward: facility placement is part of your risk management. You do not need to predict every disaster; you must show that hazards were considered and handled through design choices, compensating controls, and governance. ²

Plain-English interpretation

PE-23 means: you can’t host important systems “wherever is convenient” without checking whether the location is exposed to foreseeable hazards. If the facility is in a flood plain, near a wildfire interface, in a high-crime industrial corridor, adjacent to hazardous material transport, or on an unstable power grid, your program needs to show either (a) you chose a different location, or (b) you implemented mitigations and formally accepted residual risk.

Think of PE-23 as the site-selection and site-continuance control:

• Selection: new office, new data center, new colocation cage, new on-prem server room, new manufacturing site.
• Continuance: existing sites as hazards, building use, or dependencies change.

Who it applies to

Entities: Federal information systems and contractor systems handling federal data ¹

Operational context (what to include in scope):

• Owned/leased facilities housing production systems (server rooms, network closets, on-prem data centers).
• Colocation and managed hosting where your racks/cages sit in a third party’s building.
• Critical support facilities if loss would take down the system (primary NOC/SOC, network aggregation sites, backup media storage).
• Hybrid environments: even if compute is “cloud,” include facilities that host identity, network edge, backups, or operational tooling that would impair the system if disrupted.

Practical scoping rule: if the system’s authorization boundary includes equipment in a facility, or the facility’s loss would cause a material outage, treat it as a PE-23 location.

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

1) Assign ownership and define the system-to-facility map

• Control owner: usually Physical Security, Facilities, or Corporate Security; co-owned with IT/Infrastructure for system boundary accuracy.
• Build a System Facility Register: system name, facility name/address, facility type (owned/leased/colo/third party), function (primary/DR/support), and dependency notes (power, telecom, water).
  Evidence outcome: a single list you can hand to an assessor.

2) Define a standard hazard assessment template

Create a one-page Facility Location Hazard Assessment template with:

• Hazard categories: flood, seismic, wildfire, wind, extreme temperatures, industrial accidents, hazardous materials, civil unrest, crime trends, transportation corridors, aviation risk, nearby construction, and single points of failure in utilities.
• Impact statement: how the hazard affects the system (availability first, but also confidentiality/integrity via physical intrusion during emergencies).
• Inherent risk rating and residual risk rating (use your enterprise risk method).
• Mitigations already in place and required gaps.
• Decision and sign-off (approve, approve with conditions, reject/relocate, or accept risk with remediation plan).

Keep the template consistent across sites; consistency is what makes this control assessable.

3) Collect hazard inputs you can defend

Auditors rarely require a specific data source, but they do require that your sources are reasonable and repeatable. Use:

• Internal incident history (flooded basements, HVAC failures, repeated brownouts).
• Building/property reports (where available).
• Third-party site packages for colocation (SOC reports, facility resilience documentation, local hazard disclosures).

If a third party refuses to share, document the request, the response, and your compensating approach (for example, contractual commitments, alternative site, stronger DR).

4) Decide: avoid, mitigate, transfer, or accept

For each facility:

• Avoid: choose a different site for primary hosting if hazards are high and mitigations are not realistic.
• Mitigate: flood barriers, raised floor, water detection, fire suppression, enhanced physical access controls, redundant HVAC, generator capacity, diverse telecom paths.
• Transfer: insurance and contractual SLAs help, but do not replace engineering controls.
• Accept: only with explicit risk acceptance tied to the system risk owner.

Document the rationale. PE-23 is satisfied by a defensible decision, not by perfection. ¹

5) Tie PE-23 to lifecycle triggers

Define reassessment triggers so PE-23 stays alive:

• Facility move, expansion, or major renovation.
• Hosting model change (on-prem to colo; colo to cloud interconnect site).
• Major local hazard changes (new nearby industrial plant; repeated regional wildfire smoke events affecting HVAC; changes in flood mapping).
• After a significant incident or near miss.

6) Make the evidence recurring and audit-ready

Operationalize evidence production:

• Quarterly or semiannual check that the System Facility Register is current (pick a cadence you can sustain).
• Annual refresh of hazard assessments for primary sites, or aligned to your enterprise risk cycle.
• Central repository (GRC tool or controlled document library) with versioning.

If you use Daydream to map PE-23 to an owner, procedure, and recurring artifacts, you reduce the most common failure mode: having “good intent” but no consistent evidence trail across systems and sites. ¹

Required evidence and artifacts to retain

Minimum set that usually satisfies assessors:

• System Facility Register (system-to-site mapping, current).
• Facility Location Hazard Assessment per in-scope facility, with dates, sources used, and risk ratings.
• Mitigation plan(s) and completion evidence (work orders, project tickets, commissioning reports).
• Risk acceptance memos (if residual risk remains).
• Third-party documentation for colocation/managed facilities (resilience statements, audit reports, contractual clauses).
• Change management records showing reassessment on move/expansion.
• Policy/procedure describing how facility location planning is performed and reviewed. ²

Common exam/audit questions and hangups

Assessors commonly ask:

• “List every facility where this system resides. How do you know you didn’t miss any?”
• “Show me the hazard analysis for this site. Who approved it?”
• “Why is your primary site in a high-risk area, and what compensating controls exist?”
• “How do you reassess when conditions change?”
• “For colocation: what evidence do you have that the provider manages environmental risks appropriately?”

Hangups that slow audits:

• No single authoritative system-to-facility list.
• Hazard assessment exists only for “the data center,” not for support sites (network hubs, backup media storage).
• Risk acceptance is informal (“we talked about it”) rather than documented.

Frequent implementation mistakes (and how to avoid them)

1. Treating PE-23 as a one-time checklist.
   Fix: add lifecycle triggers and require reassessment on moves and major changes.

2. Relying on cloud provider statements while ignoring your own physical dependencies.
   Fix: include offices, network egress sites, identity infrastructure, and backup storage locations in the facility register.

3. Conflating “we have DR” with “site placement risk is addressed.”
   Fix: DR supports availability; PE-23 asks whether the chosen location is appropriate given hazards.

4. No written rationale for “why here.”
   Fix: require a short decision paragraph in every hazard assessment.

5. Third-party blind spot (colo/managed hosting).
   Fix: bake facility resilience evidence into procurement and contracting, and document exceptions.

Risk implications (why operators care)

Facility location decisions drive:

• Availability risk: regional disasters can take out power, staff access, and telecom at once.
• Security risk: emergencies create opportunities for tailgating, forced entry, and degraded monitoring.
• Safety and compliance risk: certain facilities introduce physical safety hazards that become operational outages and incident-reporting events.

PE-23 gives you a governance hook to prevent “silent” concentration risk, especially where multiple systems end up in the same hazard zone due to convenience or legacy real estate.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Name the PE-23 control owner and backup.
• Build the System Facility Register for your highest-impact systems and primary sites.
• Draft the Facility Location Hazard Assessment template and approval workflow.
• Choose a repository and evidence naming convention.

Days 31–60 (assess and close obvious gaps)

• Complete hazard assessments for primary facilities and any site with known historical issues.
• Identify mitigation gaps that are procedural (signage, access, monitoring) versus capital work (HVAC redundancy, flood protection).
• Put remediation work into tracked tickets with owners and target dates.
• Add PE-23 requirements to third-party intake for colocation/managed hosting.

Days 61–90 (make it repeatable)

• Expand assessments to remaining in-scope facilities (support sites, storage, network hubs).
• Add reassessment triggers to change management and facilities project intake.
• Run a tabletop review: “What happens if this facility is inaccessible for an extended period?” Capture actions and owners.
• In Daydream, map PE-23 to the owner, implementation procedure, and recurring evidence artifacts so audits pull from a single control record. ¹

Output you want by the end of the third phase: every system has an attributable hosting location list, every location has a documented hazard assessment and decision, and reassessment is triggered by real operational events.

Frequently Asked Questions

Does PE-23 apply if everything is in a public cloud?

It can. Your system may still “reside” in facilities you control, like network edge locations, offices with critical admin workstations, backup storage, or identity infrastructure. Document your system boundary and include any physical locations inside it. ¹

We use colocation. How can we meet PE-23 if we don’t control the building location?

You still need a location decision record: what hazards exist, what the provider does to mitigate them, and what you do to compensate (DR design, diverse connectivity, contractual requirements). Keep evidence of due diligence and risk acceptance where needed. ²

What’s the minimum evidence an assessor will accept for the pe-23: facility location requirement?

A facility register, a hazard assessment per in-scope site, and an approval/decision trail are the core. Add mitigation work evidence and reassessment triggers if you want the control to pass consistently across audits. ¹

Is “we have insurance” a sufficient mitigation for facility location hazards?

Insurance can transfer financial loss, but it does not keep systems available or prevent data loss during a physical disruption. Treat insurance as a supplement, and document engineering and operational mitigations for material hazards. ²

How detailed does the hazard analysis need to be?

Detailed enough that a reviewer can see your inputs, reasoning, and decision without guessing. One strong page per facility beats a vague paragraph in a policy. Tie each hazard to a system impact and a mitigation or acceptance decision. ²

How do we keep PE-23 current without creating busywork?

Connect reassessments to events you already track: facilities projects, data center moves, major incidents, and sourcing changes. Keep the template short, require approvals, and store artifacts in one place so the evidence stays easy to retrieve. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5