Maintenance Records

The HIPAA Security Rule’s maintenance records requirement means you must have written policies and procedures to document security-related repairs and modifications to your facility’s physical components, and you must keep those records as evidence. Build a repeatable log process that captures what changed, when, where, who approved it, who performed it, and how you validated security afterward. ¹

Key takeaways:

• Document repairs/modifications to security-relevant facility components, not just “IT changes.” ¹
• Treat maintenance records as audit evidence: approvals, work orders, vendor tickets, and post-change validation matter.
• Define scope clearly (doors, locks, cameras, badge readers, server room controls) and make one system the source of truth.

“Maintenance Records” under HIPAA is a physical safeguards requirement that gets missed because teams assume it lives with Facilities, not Security or Compliance. The rule is narrow but operationally demanding: you need policies and procedures that ensure repairs and modifications to security-related physical components are documented consistently, retained, and reviewable. ¹

This requirement shows up during audits because it’s easy to claim you control physical access, but harder to prove you controlled changes over time. Examiners will look for discipline: a defined scope of what counts as “security-related physical components,” a standard record format, clear ownership across Facilities/Security/IT, and evidence that third parties (locksmiths, alarm installers, data center providers) follow your rules.

The fastest path to operationalization is to treat this like change management for the facility perimeter: a ticket or work order for every security-relevant physical change, linked artifacts (quotes, invoices, technician notes), and a short post-maintenance verification step that confirms the control still works and access remains appropriate.

Regulatory text

Requirement (quoted): “Implement policies and procedures to document repairs and modifications to the physical components of a facility which are related to security.” ¹

Operator interpretation: You must (1) write down how your organization documents security-related physical maintenance, and (2) actually create and retain those records when repairs or modifications occur. The focus is on physical facility components that have a security purpose (access control, surveillance, barriers, and related infrastructure), not general building maintenance with no security impact. ¹

Plain-English interpretation (what the requirement really means)

You need an auditable trail of “what changed” for physical security controls at your sites and rooms where ePHI could be accessed. If a lock is re-keyed, a badge reader is replaced, a camera is moved, or a server room door is repaired, you should be able to show:

• the request and reason,
• the approval,
• the work performed (internal or third party),
• the date/time and location,
• and that security was checked afterward.

If your records are scattered across emails, invoices, and informal notes, you are relying on luck during an audit. This control is about repeatability and proof.

Who it applies to (entity and operational context)

Applies to:

• Covered Entities and Business Associates subject to the HIPAA Security Rule. ¹

Operational contexts where it matters most:

• Clinics, hospitals, and administrative offices where ePHI is accessible
• Data centers, server rooms, network closets, and records rooms that support ePHI systems
• Remote or branch sites with shared facilities management
• Co-located spaces (shared buildings, suites) where you control only certain doors/areas
• Environments with frequent third-party physical service calls (alarm vendors, access control installers, electricians, landlords)

Third parties in scope: locksmiths, alarm/security installers, building management, managed data center providers, and any contractor who can affect a security-relevant physical component. Your process should require them to provide documentation that feeds your maintenance record.

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

1) Define “security-related physical components” for your environment

Create a scoped list. Keep it practical and tied to security function. Typical categories:

• Perimeter and entry controls: doors, locks, keys, cores, hinges, strike plates, gates
• Electronic access control: badge readers, keypads, panels/controllers, door contacts, request-to-exit devices
• Surveillance: cameras, NVR/DVR equipment, camera placement/fields of view
• Intrusion and monitoring: alarms, motion sensors, glass break sensors
• Sensitive-area protections: server room cages, racks with locks, cabinets containing network gear that supports ePHI access

Write this list into your policy appendix so teams do not debate scope each time.

2) Assign ownership and handoffs

Set explicit roles:

• Process owner: Physical Security, Facilities, or IT Security (pick one).
• Record custodian: whoever maintains the system of record (ticketing system, CMMS, or GRC tool).
• Approvers: site lead + security (and IT for server room changes).
• Implementers: internal maintenance staff and approved third parties.

Document who must open the ticket and who must attach artifacts.

3) Standardize the “maintenance record” fields

Use a form, ticket template, or work order schema. Minimum fields that stand up in audits:

• Site/location (building, floor, room)
• Asset/control identifier (door ID, camera ID, panel ID)
• Change type (repair vs modification; like-for-like replacement vs upgrade)
• Reason (break/failure, security finding, remodel, risk remediation)
• Requestor and approver(s)
• Service provider (internal team or third party; tech name if available)
• Date/time work started and completed
• What was done (plain language, parts replaced, configuration changes)
• Key material handling (if keys/cores involved): issued/returned, re-key outcome
• Post-work verification (what you checked and who checked it)
• Related incidents (if work was incident-driven)

4) Route all work through a controlled intake

Require that no security-related physical work begins without a record being opened, except emergencies. For emergencies, require a retroactive record with the same fields and a reason code (“emergency repair”).

Practical intake options:

• Facilities CMMS as system of record, with a “Security-Related” flag and required attachments
• ITSM ticketing (common for access control systems that integrate with IT)
• A GRC workflow that links to the work order as evidence

If you use Daydream for third-party risk and due diligence, treat physical security vendors as third parties and map their work orders and service reports into the same evidence stream, so you can answer “who changed the physical control” without chasing email threads.

5) Control third-party access and documentation

Add contract or work order terms that require:

• named technicians (or company roster) and arrival/departure confirmation
• service report describing work performed
• parts/serial numbers where relevant
• confirmation of testing and any “left in bypass” states (alarms, sensors)

Make the internal sponsor responsible for attaching the third-party service report to the maintenance record.

6) Perform post-maintenance security validation

Define lightweight checks by category:

• Door/lock: verify latch, self-close, lock engages, key control updated
• Badge reader/panel: verify authorized badge works, terminated badge fails, door forced/held alarms function (if applicable)
• Camera: verify correct view, recording active, retention as configured
• Alarm sensor: verify test event received by monitoring console (if applicable)

Record the validation result in the ticket and capture supporting screenshots or test logs where feasible.

7) Retain records and make them searchable

HIPAA requires you to implement documentation processes; auditors will expect you to retain them long enough to demonstrate continuity. Keep records centralized, with:

• consistent naming (site + asset + date)
• immutable attachments (PDF service reports, photos)
• access controls (limit editing; maintain history)
• export capability for audits

Required evidence and artifacts to retain

Keep a “maintenance evidence packet” per event:

• Policy and procedure for maintenance records (the written requirement) ¹
• Ticket/work order with required fields completed
• Approval evidence (workflow approval, email, or signed work order)
• Third-party service report or internal technician notes
• Invoice/quote (optional but often useful corroboration)
• Photos (before/after) for cameras, doors, and sensitive areas
• Post-maintenance test/verification notes (and screenshots/logs where relevant)
• Updated physical asset inventory entry (if you maintain one)

Common exam/audit questions and hangups

Expect questions like:

• “Show me maintenance records for your server room access controls for a recent period.” ¹
• “How do you determine what ‘security-related physical components’ are?” ¹
• “How do you ensure contractors document work and you retain it?”
• “What happens in emergencies?”
• “How do you verify controls worked after repairs?”
• “Where are records stored, and who can change them?”

Hangups auditors commonly press:

• Records exist but are not complete (missing approvals, missing verification).
• Records exist but are not centralized (scattered across Facilities email and vendor portals).
• Scope is unclear (teams document badge readers but not door hardware or camera repositioning).

Frequent implementation mistakes (and how to avoid them)

1. Treating this as “Facilities only.”
   Fix: make Security/Compliance co-owners and require a security flag in the work order for scoped assets.

2. Logging only “break/fix” but not modifications.
   Fix: include remodels, camera moves, re-key projects, panel upgrades, and access control configuration changes tied to physical components. ¹

3. No post-work verification.
   Fix: add a mandatory checklist item and an accountable verifier.

4. Third parties do the work; you keep no evidence.
   Fix: require service reports as a condition of payment/closure.

5. Over-scoping everything in the building.
   Fix: keep scope tied to security function; document the rationale so the boundary is defensible.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement, so don’t build your program around assumptions about case outcomes. Treat the risk as practical: poor maintenance documentation makes it difficult to prove physical access controls remained effective over time, especially after incidents, remodels, or vendor service calls. ¹

Operationally, weak maintenance records increase the chance of “unknown exposure,” such as keys that were copied without tracking, cameras that stopped recording after a repair, or doors left misaligned and not latching.

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Name the process owner and agree on the system of record (CMMS/ITSM/GRC).
• Publish the scoped list of security-related physical components.
• Create the ticket/work order template with required fields and attachments.
• Start capturing records for all new security-related work, including third-party calls.

By 60 days (Control maturity)

• Update third-party SOW/PO language to require service documentation and technician identification.
• Train Facilities, Security, and site managers on intake and closure requirements.
• Implement post-maintenance verification checklists by asset category.
• Perform a spot-check review of recent tickets to confirm completeness and fix gaps.

By 90 days (Audit-ready operations)

• Run an internal audit: pick a site and trace several maintenance events end-to-end (request → approval → work → verification → retention).
• Tune the scope list and templates based on what caused confusion.
• Build an evidence export package (policy + sample records) for audit readiness.
• If you use Daydream, map physical security third parties to your third-party inventory and attach maintenance artifacts to the third-party record for faster audits and cleaner oversight.

Frequently Asked Questions

What counts as a “security-related physical component” under this requirement?

Components whose purpose is to control, monitor, or restrict physical access, such as locks, doors protecting sensitive areas, badge readers, cameras, and alarm sensors. Document your scope in writing and keep it tied to security function. ¹

Do we need maintenance records for general building repairs like HVAC or plumbing?

Not unless the work affects security-related physical components or sensitive areas (for example, opening secure ceilings above a server room). Keep the program scoped so records stay meaningful and reviewable.

Our landlord manages building access controls. Are we still responsible?

If you rely on building-managed controls to protect areas where ePHI could be accessed, you still need a way to obtain and retain documentation of relevant repairs/modifications. Put documentation requirements into your lease addendum, building rules, or a written operating agreement.

Can an email thread or invoice count as a maintenance record?

It can be supporting evidence, but auditors will look for a consistent record with required fields, approvals, and verification. Use a ticket/work order as the spine, then attach emails and invoices.

What’s the minimum we should capture after a lock re-key or badge reader replacement?

Record the location and asset ID, who approved it, who performed the work, when it happened, what changed, how keys/badges were handled, and how you verified correct access afterward. ¹

How should we handle emergencies where work starts immediately?

Allow emergency work, then require a retroactive maintenance record with the same fields plus an “emergency” justification and a post-work security validation. Close the loop quickly so you can still prove control. ¹

Footnotes

1. 45 CFR Parts 160, 162, 164