164.310(a)(2)(ii) Facility security plan requirements

What a HIPAA facility security plan must cover and why it is often weak

When an assessor asks for the facility security plan under 45 CFR 164.310(a)(2)(ii), the honest answer is often that the organization has practices but no written plan. The standard asks for policies and procedures that safeguard the facility and the equipment in it from unauthorized physical access, tampering and theft. It is an addressable specification, so it is not optional in the sense that you may skip it. Under 45 CFR 164.306(d)(3), you must first assess whether the measure is reasonable and appropriate for your environment. If it is, you implement it and document how. If it is not, you document why and implement an equivalent alternative measure if one is reasonable and appropriate. Either way, the assessment itself is a record an auditor will expect to see. Confirm with your security official whether that assessment exists for this specification and when it was last reviewed.

The plan also anchors the other facility access specifications under 164.310(a)(1). Contingency operations, access control and validation, and maintenance records all depend on knowing which doors, rooms, server closets and equipment the plan protects and who is responsible for each. A plan that lists the building but not the server room, the network closet or the imaging modality in a shared corridor leaves the sibling procedures without a defined scope. Write the plan so each protected area, its controls and its owner are named, and cross-reference the access validation and maintenance procedures from it.

The usual weakness is that the plan is written once, usually for an earlier move or audit, and never tied to a current vulnerability analysis. NIST SP 800-66 Rev. 2 describes developing a facility security plan after analyzing existing physical security vulnerabilities and identifying corrective measures (section 5.2.1), and the NIST SP 800-66 Rev. 2 resource guide is the place to check that sequence. A useful test is whether each control in the plan traces to a vulnerability found in a walkthrough, a recent risk analysis or an incident. If a control cannot be traced, either the plan is out of date or the walkthrough was never done. Schedule a review after facility changes, and keep dated revisions so the plan's history can be shown.

Which facilities, equipment and third-party sites fall under the plan

A facility security plan under 45 CFR 164.310(a)(2)(ii) has to cover every location and piece of equipment where ePHI is created, stored, processed or transmitted. The scope decision is the first step, and the cards below separate owned sites from sites run by landlords and hosting providers, where the plan still needs to show what is inherited and what is assessed.

Data centers and server rooms

Any room that houses servers, storage arrays, backup appliances or network core equipment holding ePHI belongs in scope, including small rooms inside offices that people often forget. The plan should list each room, who holds keys or badges, and how access is logged. Walk each room and compare the physical reality against the list, because undocumented closets and cabinets are a common gap.

Clinics and offices with workstations

Clinical areas, reception desks, billing offices and staff workspaces are in scope wherever workstations or mobile devices can open ePHI. Scope the plan by function as well as by address, so that a shared exam room with a shared terminal is not treated as a non-issue. Confirm which areas have screens facing the public and which doors stay unlocked during opening hours.

Network closets and wiring rooms

Wiring closets, patch panels and small cabinets often hold switches, firewalls and cabling that carry ePHI traffic, and they are easy to leave out of a plan written around the main data room. Include each closet in the facility inventory and record the lock type and key holders. Tampering with a switch can expose traffic without touching a server, so these rooms need the same protections as the core.

Off-site storage and colocation space

Backup tapes, archive boxes and racks in a colocation facility are owned by you but sit in someone else's building. Your plan must cover the equipment you control there, and the contract should state how the provider handles physical access, visitor logs and incident notice. Ask the colocation provider for its own physical security documentation and confirm which parts of your plan depend on it.

Landlord and hosting provider controls

When a landlord, building manager or hosting provider controls access to a site, you may inherit some safeguards but you still need evidence that they work. Request the provider's written physical control descriptions and any independent attestation it holds, and map each claim to a specific part of your plan. Note that a provider's attestation does not replace your own access validation for rooms you control.

Cloud-hosted systems and shared responsibility

For cloud-hosted ePHI, the provider runs the physical data centers, so part of the facility work moves to its documented controls. Your plan should name the provider, identify which facility safeguards it covers under its contract and documentation, and record the parts that stay with you, such as endpoints and local offices. Confirm that the provider will sign a business associate agreement before any ePHI is placed in its environment.

How an assessor tests the facility security plan

This table walks through how an assessor typically tests a facility security plan under 164.310(a)(2)(ii), from the written plan to the physical walkthrough. Read each row as a test step, the evidence it calls for, and the gap that most often shows up. The main takeaway is that a plan on paper is only half the test, since the assessor will check that it matches the building and that someone reviews it.

Test step	What the assessor checks	Common finding
Review the written plan	Whether a current, written facility security plan exists and covers the buildings, rooms and equipment that hold ePHI	Plan describes an earlier floor layout or a site that has since moved or expanded
Review the vulnerability analysis	Evidence that physical vulnerabilities were identified first, and that the plan's measures respond to them	Plan lists locks and cameras but no analysis showing why those measures were chosen
Check the addressable decision	For any measure not implemented, a documented reason it is not reasonable and appropriate and an equivalent alternative	Measure skipped with no written rationale, or alternative measure never described
Review approval and revision history	Named approver, dated versions and a record of changes after facility, staffing or equipment changes	Plan carries no date or owner, or changes are not logged
Confirm periodic review	Records showing the plan is reviewed on a set schedule and after incidents or moves	No review record since the plan was first written
Walk through the facility	Whether locks, doors, server rooms, monitoring and visitor controls match what the plan says	Plan says server room is locked, but the door is propped open or the key holders are unknown
Interview staff	Whether the people who work in the building know the plan and their part in it	Staff describe practices that differ from the written procedures
Check incident and tampering records	Logs of break-ins, lost keys, tampering or theft, and how the plan was updated afterward	Incidents recorded elsewhere but not linked to any plan change

How to build the facility security plan step by step

This sequence takes an organization from an unknown set of physical locations to an approved, dated facility security plan that documents how it protects ePHI systems, and the reasoning behind every addressable decision.

Inventory physical locations and equipment holding ePHI
Start by listing every facility that houses systems, workstations, servers, network closets, backup media or paper-to-digital equipment that touches ePHI, including offices, data centers, branch sites, clinics and any space a vendor or home workstation uses. For each location, record the address, the owner or landlord, the people with access, and the equipment inside. The output is a location register that the privacy and security teams both sign off on. You know this step is done when a walkthrough or a facilities record confirms that no ePHI-bearing location is missing from the list.
Analyze existing physical security vulnerabilities
For each location in the register, assess how unauthorized people could enter, tamper with equipment or steal it. Look at perimeter doors, locks, alarms, cameras, lighting, visitor routes, server room construction, equipment placement near windows or public areas, and how lost or stolen devices are reported. NIST SP 800-66 Rev. 2 treats this analysis as the step that comes before choosing controls. The output is a vulnerability list tied to each location, and you know it is done when each vulnerability has a short description, a likelihood note and the name of the person who verified it on site.
Decide corrective measures for each vulnerability
For each vulnerability, decide the corrective measure, such as rekeying a door, adding badge logging to a server room, relocating a monitor, or adding a cable lock policy for laptops. Record the measure, the reason it addresses the gap, and any measure you consider but reject. Where a measure is not reasonable and appropriate, note that now so the addressable analysis in a later step has its input. The output is a measures table linked to the vulnerability list, and you know it is done when every vulnerability has either a measure or a documented reason for accepting the risk.
Assign owners and dependencies
Name one accountable owner for each measure, usually a facilities lead, IT lead or the security official, and record who must approve budget, landlord consent or vendor work. Identify dependencies, such as a lock change that depends on a building management contract or a camera project that depends on network capacity. The output is an owner matrix, and you know it is done when each measure has exactly one accountable name and every external dependency has a named contact.
Write the facility security plan
Draft the plan as a controlled document that describes the facilities in scope, the safeguards in place, the corrective measures and their owners, the rules for visitors and maintenance staff, and how the plan connects to access validation, maintenance records and device and media controls. Keep the language specific to your locations so an auditor can trace a sentence to a real door or room. The output is a draft plan, and you know it is done when a person outside the drafting team can follow it to find each safeguard at each location.
Document the addressable decision and any equivalent alternative
Because this specification is addressable, record whether implementing it as written is reasonable and appropriate for each location. If it is, cite the measure that implements it. If it is not, write down why, then document the equivalent alternative measure and why it is reasonable and appropriate. The record should follow the assessment-and-documentation logic in 45 CFR 164.306(d). The output is a signed decision record, and you know it is done when no location has an unexplained gap between the requirement and the chosen measure.
Approve the plan and schedule its review
Route the plan to the official who owns security risk, and to the business leader who accepts residual risk. Record the approver, the approval date and the version number in the document control record, and store the approved version where the workforce can find it. Set a review schedule and name the trigger events that force an earlier review, such as a lease change, a breach or a new data center. The output is an approved, versioned plan with a review date, and you know it is done when the approval record and the review schedule both exist and the prior version is archived.

Documenting why an addressable safeguard is reasonable or not

The facility security plan is addressable, so the first question is not whether to build one but whether it is reasonable and appropriate for your organization. Under 45 CFR 164.306(d)(3), you decide in three steps: assess whether the measure is reasonable and appropriate, implement it if it is, and if it is not, document why and implement an equivalent alternative measure that is reasonable and appropriate. The decision is yours to make and to defend, so the record matters as much as the choice. For a facility security plan, the assessment should start from the physical vulnerabilities you have identified for each location, including where ePHI systems sit, who can reach them after hours, and which doors, windows and equipment rooms are weak points. NIST SP 800-66 Rev. 2 describes the same sequence in its guidance on developing a facility security plan, which you can use as a working checklist when you record your reasoning.

A documented rationale must name the factors you weighed: the size of the facility, the number of people with access, the volume and sensitivity of ePHI on site, the cost and disruption of the proposed control, and the risk that remains if you do not adopt it. Record who made the decision, the date, and the evidence reviewed, such as a walkthrough note or a risk analysis entry. Then record the alternative you chose and how it addresses the same risk. Store these records under your documentation policy so they are retrievable and kept in version control, since an assessor will ask for the decision and the version in force when an incident occurred. Confirm with your counsel or compliance lead how long your organization must keep these records, because the documentation standard in 164.316 sets its own retention period.

*Illustrative example:* a three-clinician practice in a leased suite considers a badge reader on its records room. The owner assesses the cost, the landlord's approval requirement, and the small number of staff who need access, and concludes the reader is not proportionate. The owner documents that reasoning, adopts a sign-out key log for the single key, and keeps the server and paper charts in a locked cabinet bolted to the wall with access limited to two named staff. The owner reviews the log monthly and revisits the decision if the practice grows or moves. An assessor would look for the same elements in a real record: the factors, the decision, the alternative, and evidence the alternative is operating.

Evidence that shows the facility security plan works

An assessor testing 164.310(a)(2)(ii) looks for a plan that matches the building, the equipment and the decisions behind them. The cards below cover the artifacts that prove the plan exists, reflects reality and is kept current, along with the triggers that force an update between reviews.

Signed plan with version history

The facility security plan itself should carry a version number, the date it was approved and the name of the official who approved it. Keep every superseded version so an assessor can see what protections were in force on a given date. Check that the plan names the physical areas it covers, such as server rooms, records storage and network closets, and that the document is stored in a controlled location with access logged.

Physical vulnerability analysis

NIST SP 800-66 Rev. 2 describes the plan as following an analysis of existing physical security vulnerabilities. Record each identified weakness, such as an unmonitored loading dock, a shared badge for a restricted room or a door propped open during deliveries, with the date it was found and the method used to find it. Each finding should point to the corrective measure or to a documented decision to accept the risk.

Addressable decision record

Because 164.310(a)(2)(ii) is addressable, the file should show how the organization assessed each safeguard in the plan. For every measure it chose not to adopt, record why it was not reasonable and appropriate and which equivalent alternative was put in place. Without this record, an assessor cannot tell a deliberate decision from an omission, and the plan reads as incomplete.

Floor plans and asset location register

Current floor plans should mark entry points, restricted zones, camera coverage and the location of every system holding ePHI. Pair them with an asset register that lists which rack, room or cabinet houses each server, workstation and storage device. Reconcile both against a physical walk-through at each review. A plan that describes a room the organization no longer occupies is one of the first gaps an assessor finds.

Change requests tied to plan updates

Each change to access controls, equipment or layout should produce a change request that references the plan section it affects. Keep the request, its approval and the date the plan was revised as a set. This creates a traceable link between what changed in the building and what the written plan says. Confirm that changes made by facilities contractors, not only the IT team, enter the same process.

Review sign-off and update triggers

Record each periodic review with the reviewer's name, the date and the outcome, even when no change is needed. Define triggers that force an out-of-cycle review, including office moves, new data centers or closets, changes in tenants or building management, new physical access systems and equipment refreshes. Each trigger should have an owner who confirms the plan was checked within a defined window after the change.

What meeting 164.310(a)(2)(ii) costs in money and effort

This table lists each cost component of a facility security plan, who usually pays for it, whether it is one-time or recurring, and what pushes it up or down. No fees or durations are given because none are supplied for this topic, so use the drivers column to scope a quote. The main takeaway is that site count and the number of facilities holding ePHI drive most of the effort, while the plan itself is mostly staff time.

Cost component	One-time or recurring	Who is paid or who spends effort	What drives it up or down
Site inventory and physical risk analysis	One-time, then refreshed	Internal security or facilities staff, possibly an outside consultant	Number of sites, data centers and server rooms, and whether ePHI sits on-premises or with a hosting provider
Physical security hardware and locks	One-time purchase, recurring maintenance	Facilities vendor or building owner, sometimes the covered entity directly	Only where the plan calls for it; existing building controls, lease terms and the gap found in the inventory
Writing, review and approval of the plan	One-time, then updated	Security official, facilities leads, legal or compliance reviewers, executive sign-off	Number of facilities covered by one plan, how many procedures are already written, and how many approvers are needed
Periodic review and updates	Recurring	Security official and facilities staff	Frequency of site changes, moves, remodels and turnover, and how the review is scheduled and recorded
Evidence collection and version control	Recurring	Compliance or security staff	Whether plan revisions and approvals are tracked in a documented system or scattered across files
Documentation tooling licenses	Recurring	Software vendor or self-hosted platform operator	Commercial licenses per seat or per instance versus self-hosted open-source wiki tools, plus hosting and admin time
External review or third-party assessment	Recurring or per engagement	Independent assessor or consultant chosen by the entity	Scope of sites reviewed, whether the review is a readiness check or a formal assessment, and the quoted scope in writing
Auditor or OCR sampling and document requests	Recurring, when an assessment occurs	Covered entity staff who produce evidence; assessor or OCR examines it	Number of facilities sampled, quality of records, and how quickly evidence can be retrieved

Who owns the plan, who can prepare it and who must independently test it

The covered entity or business associate owns the facility security plan under 45 CFR 164.310(a)(2)(ii). The Security Rule places the duty on the regulated organization, so leadership, the security official and facilities management must decide what the plan protects, which risks it accepts, and which alternative measures are reasonable and appropriate where a specification is addressable. Those decisions are recorded in the plan and approved by people with authority to accept risk.

Plan ownership: A named owner, usually the security official with facilities input, is accountable for the plan and its review cycle.
Risk decisions: Leadership decides whether each physical measure is reasonable and appropriate, and documents why any measure is not implemented.
Approvals: Sign-off by an authorized executive is recorded for each version of the plan.
Operational execution: Facilities, security guards and building managers carry out locks, badge rules, camera coverage and visitor escort.
Retained responsibility: Outsourcing preparation does not transfer ownership of the controls or the outcome.

Confirm internally who holds the authority to approve the plan and who will answer an auditor's questions about it.

Where facility security plans usually fall short

Most facility security plans fail in predictable ways: they are generic, disconnected from the physical risk analysis, and never updated. The cards below pair each common gap with a practical fix, so the plan can show what the facility actually does under 164.310(a)(2)(ii).

Template text with no site detail

A plan copied from a generic template names no buildings, floors, doors, server rooms or vendors that are specific to the organization. An assessor reading it cannot tell whether anyone has looked at the actual premises. Fix: write the plan around the real layout, listing each entry point, the room housing ePHI systems and who holds keys or badges to it.

No link to vulnerability analysis

NIST SP 800-66 Rev. 2 places the facility security plan after an analysis of existing physical security vulnerabilities and the corrective measures that follow from it. A plan that does not cite that analysis cannot show why its measures were chosen. Fix: map each measure in the plan to a finding in the physical vulnerability review, and record the findings still open.

Undocumented addressable decisions

This specification is addressable, so the organization must decide whether it is reasonable and appropriate and document the result. Plans often implement some measures silently and skip others without recording why. Fix: keep a short decision log stating each measure adopted, each measure declined, the reason, and any equivalent alternative chosen under 45 CFR 164.306(d).

Unversioned files with no approval

A plan saved as a loose document on a shared drive has no visible owner, approval date or change history. Staff may work from different copies, and no one can prove which version was in force on a given date. Fix: store the plan in a version-controlled wiki or document system with a named approver, approval date and a retained history of changes.

Off-site storage and contractors ignored

Many plans cover the main office only. Records storage vendors, cleaning crews, colocation providers, shredding services and field technicians also reach equipment or media that holds ePHI. Fix: list every third party with physical access, state the controls each must follow, and confirm those duties in the contract or vendor agreement.

No review after changes

A plan written for one office rarely fits after a move, a new server room, a hardware refresh or a change in staffing. Without a trigger for review, the plan describes a facility that no longer exists. Fix: set a scheduled review, and require a documented update whenever the premises, equipment or access arrangements change, with the reviewer recorded on each revision.

Keeping the plan under version control with self-hosted wiki tools

A facility security plan is only useful as evidence if you can show what it said on any given date, who changed it and who approved those changes. A self-hosted wiki such as XWiki addresses this directly. XWiki keeps every change to a page under version control, recording what changed, when and by whom. Reviewers can compare any two versions side by side and roll the page back to an earlier revision. For a plan that covers the facility's perimeter, access points, visitor handling and equipment protection, that history lets you show an assessor the state of the plan at the time of a past incident or audit, not just the current text. Confirm in your own deployment that the version history is retained for the period your retention policy requires, that it cannot be silently purged by page editors, and that the license of the edition you run (XWiki is LGPL-2.1-or-later) fits your internal use and any extensions you add.

Version history records changes but does not stop unauthorized edits, so access design matters as much. BookStack, an MIT-licensed wiki, assigns each user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. A practical pattern for the facility security plan is to place it in its own book, give a small named group of security and facilities staff edit rights there, and give the broader workforce view-only access to the sections they need to follow. Physical security details such as camera placement or lock schedules may need narrower read access than general policy text, which page-level overrides can handle. Decide who may approve edits before you configure anything, then test the roles with a non-administrator account. Confirm the permission model of the version you deploy, since roles and override behavior can differ between releases.

Questions about the facility security plan and outside help

Can we skip the facility security plan because it is addressable?

No, not without a documented decision. Under 45 CFR 164.306(d)(3), an addressable specification is not optional in the sense of being ignored. You must assess whether the plan is reasonable and appropriate for your facilities. If it is, you implement it. If it is not, you document why, then implement an equivalent alternative measure if one is reasonable and appropriate. Most organizations with any on-premises ePHI systems find a written plan easy to justify, because the facility and its equipment are the subject of the safeguard. Keep the assessment itself in your records, since an assessor will ask to see the reasoning as well as the outcome.

How long does it take to write a facility security plan?

The duration depends on how many sites, how many rooms and systems that hold ePHI, and how much physical security analysis already exists. NIST SP 800-66 Rev. 2 describes the plan as following an analysis of existing physical security vulnerabilities and the identification of corrective measures, so the analysis is the longest part. Drivers include the number of locations, whether data centers or server closets are leased or shared, how many third-party tenants share a building, and whether access logs and camera coverage already exist. Ask any provider to break the work into site survey, vulnerability analysis, plan drafting, review and sign-off, and to state which of those steps depend on your staff's availability.

Can our own team write the facility security plan without outside help?

Yes, a covered entity or business associate can write the plan internally, and the Security Rule does not require outside help. The work needs someone who can walk every site, identify physical weaknesses such as unmanaged doors, shared loading docks, unlocked comms rooms or unescorted visitors, and connect each finding to a corrective measure. Teams that lack facilities or physical security experience often find the walkthrough and written justification the hardest part. Before deciding, confirm that someone accountable for the plan has time to maintain it after the first version, because an outdated plan is weaker evidence than no plan at all.

What can an outside implementation partner do for the facility security plan, and what can it not do?

An implementation partner can help prepare the systems and evidence the plan depends on: site analysis, the written plan, supporting procedures, access logs, configuration records and staff documentation. DeployOpen, for example, prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. It cannot accept the risk on your behalf, decide what is reasonable for your facilities, or make your staff follow the procedures. Your organization owns its controls and the decisions in them. Ask any partner for a written scope listing the sites, deliverables and the evidence handed over at closure.

Does a facility security plan written by a consultant satisfy OCR?

A consultant's plan can be part of your evidence, but it does not replace your own compliance obligation. HHS states that no Security Rule standard requires certification, and that HHS does not endorse or recognize private certifications, which also do not prevent HHS from later finding a violation. OCR enforces the Security Rule through complaint investigations, compliance reviews and audits, and in those reviews it looks at whether your organization implemented the safeguard and can show it. Treat the plan as yours once adopted. Staff should know it, sites should follow it, and you should be able to show how it was reviewed and updated.

How will the proposed Security Rule changes affect the facility security plan?

The current addressable status of the facility security plan remains in force until a final rule changes it. HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898), with comments due March 7, 2025. As of October 2026, no final rule has been published, and the latest Unified Agenda lists the rulemaking under Long-Term Actions with final action projected for July 2027. Confirm the proposal's text and any final action on the Federal Register and reginfo.gov before changing your plan. Build the plan so it can be updated on a set cycle, since the content of any final requirements is not yet known.

What evidence shows OCR that the facility security plan works?

Evidence should show the plan exists, was approved, and is followed at each site. Useful items include the dated written plan, the vulnerability analysis behind it, the corrective measures and their owners, access validation records, visitor logs, and maintenance records for locks and doors. Keep the decision record for the addressable assessment too. Store documents under version control with a clear review history, so you can show who changed what and when. Confirm with your assessor which records they expect to see for your site types.

How DeployOpen prepares facility security evidence for HIPAA assessments

DeployOpen works on the facility security plan as an implementation partner. We help the organization scope the plan, document its physical safeguards around the systems that hold ePHI, and organize the evidence an assessor will ask for. The organization owns the plan and its decisions, and only an independent assessor can test and report on it.

How we scope

Written scope names the facilities, server rooms and workstation areas that hold or access ePHI systems.
We confirm which self-hosted platforms and their hardware sit inside each facility boundary.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We help draft the facility security plan from a documented analysis of physical vulnerabilities and corrective measures.
We document how the plan's measures are applied to self-hosted infrastructure in your own data center or cloud facilities.
We record the equivalent alternative measure and the reason for it wherever an addressable measure is not adopted as written.

How we hand over

You receive the plan, procedure documents and a map linking each measure to the physical protections it covers.
Evidence is organized in a version-controlled knowledge base so changes and their authors remain traceable.
We walk your security and compliance staff through the evidence so they can answer assessor questions without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
A retainer can keep the facility security plan current as rooms, tenants, hardware and staff change.
Ask any prospective assessor which evidence formats they accept before we finalize the document set.