Jump to a page

32 pages.

All servicesAssessments, testing, and advisory work for security and compliance programs.
PCI DSS readinessScoping, readiness, and remediation for card-payment environments
Penetration testingAuthorized testing of apps, APIs, and networks
Compliance readinessSOC 2, ISO/IEC 27001, HIPAA, and CMMC readiness
Cloud & application securityArchitecture, configuration, and identity reviews
vCISO advisorySecurity leadership without a full-time hire
Incident readinessResponse plans and tabletop exercises
Risk assessmentsWhere you stand against NIST CSF 2.0 and CIS Controls
Policies, controls & evidenceA security program you can repeat and prove
Vendor riskThird-party reviews with clear priorities
Find the right service
SOC 2 readiness
ISO/IEC 27001 readiness
HIPAA Security Rule readiness
CMMC readiness
Assurance and trust centerHow to check credentials, how engagements run, how we stay independent, and how this website handles your data.
Credentials & authorizationsHow credentials and authorizations work, and how to check them
MethodologyHow engagements are scoped, run, and reported
IndependenceHow advisory work stays separate from formal assessment
Responsible disclosureHow to report a security issue in our website or systems
About
Team
Industries
Pricing
Contact
InsightsPlain-language articles on security and compliance topics
GlossarySecurity and compliance terms, defined in plain language
Search the siteServices, readiness guides, glossary terms, and articles
Privacy notice
Terms of use
Accessibility
Privacy choices

Guide

HIPAA Security Rule checklist: every standard, explained

A HIPAA Security Rule checklist is only as good as its source. This one follows the regulation itself, 45 CFR 164.308 to 164.316: every standard and implementation specification, which ones are required and which are addressable, and the records that show each one is in place. It reflects the rule in force, not HHS's 2025 proposal.

Compliance10 min read

By Security Inspect · Sources checked

Key takeaways

  • The Security Rule's checklist is in the regulation: standards and implementation specifications in 45 CFR 164.308, 164.310, 164.312, 164.314 and 164.316, summarized in the rule's Appendix A matrix.
  • Required specifications must be implemented. Addressable ones must be assessed, implemented if reasonable and appropriate, and otherwise documented with an equivalent alternative where that is reasonable and appropriate (45 CFR 164.306(d)).
  • Encryption of ePHI is addressable under the rule in force, which means it needs an assessment and a documented decision, not that it is optional.
  • Security Rule documentation must be kept for 6 years from its creation or the date it was last in effect, whichever is later (45 CFR 164.316(b)(2)(i)).
  • A checklist records what exists. The required risk analysis decides what is reasonable and appropriate for your organization.

How to use this checklist

The HIPAA Security Rule is organized as standards, most of which carry implementation specifications. Each specification is marked either Required or Addressable in the regulation itself (45 CFR 164.306(d)(1)), and the rule's Appendix A, the Security Standards Matrix, lists them in one table. The tables below follow that structure, section by section.

Required means required: when a standard includes required implementation specifications, a covered entity or business associate must implement them (164.306(d)(2)). Addressable means a documented decision, in the order the rule sets out:

  1. Assess whether the specification is a reasonable and appropriate safeguard in your environment, considering how much it would contribute to protecting ePHI.
  2. Implement it if it is reasonable and appropriate.
  3. If it isn't, document why it would not be reasonable and appropriate.
  4. Implement an equivalent alternative measure if that is reasonable and appropriate.

What “reasonable and appropriate” takes into account

The rule lets each organization choose security measures that fit it. Under 164.306(b)(2), you weigh your size, complexity and capabilities; your technical infrastructure, hardware and software security capabilities; the costs of security measures; and the probability and criticality of potential risks to ePHI. Your risk analysis is where those factors are weighed and recorded, so keep the checklist and the risk analysis side by side.

Administrative safeguards checklist (45 CFR 164.308)

Administrative safeguards are the largest group: nine standards covering how security is managed, staffed, trained, tested and contracted. Two of them, assigned security responsibility and evaluation, have no separate implementation specifications; the Appendix A matrix marks each of those standards itself as required.

Administrative safeguards: standards and implementation specifications, 45 CFR 164.308 (R = Required, A = Addressable)
StandardCitationImplementation specifications
Security management process164.308(a)(1)Risk analysis (R); risk management (R); sanction policy (R); information system activity review (R)
Assigned security responsibility164.308(a)(2)None separate: identify the security official (R)
Workforce security164.308(a)(3)Authorization and/or supervision (A); workforce clearance procedure (A); termination procedures (A)
Information access management164.308(a)(4)Isolating health care clearinghouse functions (R); access authorization (A); access establishment and modification (A)
Security awareness and training164.308(a)(5)Security reminders (A); protection from malicious software (A); log-in monitoring (A); password management (A)
Security incident procedures164.308(a)(6)Response and reporting (R)
Contingency plan164.308(a)(7)Data backup plan (R); disaster recovery plan (R); emergency mode operation plan (R); testing and revision procedures (A); applications and data criticality analysis (A)
Evaluation164.308(a)(8)None separate: periodic technical and nontechnical evaluation (R)
Business associate contracts and other arrangements164.308(b)(1)Written contract or other arrangement (R)

Records that show the administrative safeguards are in place

Advice, not a list from the rule: these are the records an evaluation or an outside review usually asks to see first.

  • The current risk analysis and the risk management plan that follows from it
  • The name of the security official, and the policies that person is responsible for
  • Access requests, approvals, periodic access reviews and termination records
  • Training content, attendance records and the security reminders you send
  • The incident log, with how each incident was handled and documented
  • Backup and restore test results, and the date the contingency plan was last tested and revised

Physical safeguards checklist (45 CFR 164.310)

Physical safeguards cover the facilities, workstations, and hardware and media that hold ePHI. They apply wherever ePHI lives, so include remote workspaces and any hosting or colocation arrangements in scope, not only the main office.

Physical safeguards: standards and implementation specifications, 45 CFR 164.310 (R = Required, A = Addressable)
StandardCitationImplementation specifications
Facility access controls164.310(a)(1)Contingency operations (A); facility security plan (A); access control and validation procedures (A); maintenance records (A)
Workstation use164.310(b)None separate: policies on how workstations that access ePHI are used (R)
Workstation security164.310(c)None separate: physical safeguards that restrict workstations to authorized users (R)
Device and media controls164.310(d)(1)Disposal (R); media re-use (R); accountability (A); data backup and storage (A)

Device and media controls in practice

Disposal and media re-use are both required: you need policies for the final disposition of ePHI and the media that hold it, and procedures to remove ePHI before media are re-used. Keep records of wiped and destroyed devices, and include laptops, phones, copiers and removable drives that may hold ePHI.

Technical safeguards checklist (45 CFR 164.312)

Technical safeguards are the controls inside your systems: who can get in, what is recorded, how data is protected from alteration, and how it is protected in transit. Audit controls and person or entity authentication have no separate implementation specifications; the matrix marks both standards as required.

Technical safeguards: standards and implementation specifications, 45 CFR 164.312 (R = Required, A = Addressable)
StandardCitationImplementation specifications
Access control164.312(a)(1)Unique user identification (R); emergency access procedure (R); automatic logoff (A); encryption and decryption (A)
Audit controls164.312(b)None separate: mechanisms that record and examine activity in systems containing ePHI (R)
Integrity164.312(c)(1)Mechanism to authenticate ePHI (A)
Person or entity authentication164.312(d)None separate: verify that a person or entity seeking access is the one claimed (R)
Transmission security164.312(e)(1)Integrity controls (A); encryption (A)

Encryption: addressable, not optional

Encryption appears twice, both times as addressable: a mechanism to encrypt and decrypt ePHI (164.312(a)(2)(iv)) and encryption of ePHI in transmission whenever deemed appropriate (164.312(e)(2)(ii)). For each, record your assessment and decision. If you decide encryption isn't reasonable and appropriate somewhere, write down why, and what equivalent alternative protects that data instead.

Organizational, policy and documentation requirements (45 CFR 164.314 and 164.316)

The last two sections aren't safeguards in the technical sense, but they are part of the checklist. Section 164.314 sets what business associate contracts and group health plan documents must say, and 164.316 requires written policies and procedures and sets how long documentation is kept. Appendix A doesn't list these two sections, so the markers below come from the section text.

Organizational requirements and documentation, 45 CFR 164.314 and 164.316 (R = Required)
StandardCitationImplementation specifications
Business associate contracts or other arrangements164.314(a)(1)Business associate contracts, other arrangements, and contracts with subcontractors (R)
Requirements for group health plans164.314(b)(1)Plan documents that require the plan sponsor to safeguard ePHI (R)
Policies and procedures164.316(a)None separate: reasonable and appropriate policies and procedures to comply with the subpart
Documentation164.316(b)(1)Time limit (R); availability (R); updates (R)

What a business associate contract must require

Under 164.314(a)(2)(i), the contract must provide that the business associate will comply with the applicable requirements of the Security Rule; ensure that its subcontractors that handle ePHI agree to comply, through their own contracts; and report to the covered entity any security incident it becomes aware of, including breaches of unsecured protected health information as required by 164.410.

How long to keep the documentation

Keep policies, procedures, and records of required actions, activities and assessments in written form, which may be electronic. Retain them for 6 years from the date of creation or the date they were last in effect, whichever is later; make them available to the people responsible for the procedures; and review them periodically, updating them as needed after environmental or operational changes that affect the security of ePHI.

Gaps worth checking first

Advice rather than rule text: a checklist review tends to find the same kinds of gaps, and each is easier to fix before an evaluation than during one.

  • A risk analysis that covers only the main clinical or product system instead of all ePHI the organization creates, receives, maintains or transmits
  • Addressable specifications, such as encryption or automatic logoff, with no documented assessment or decision
  • Cloud, software and support vendors that handle ePHI without a business associate contract
  • A contingency plan that has never been tested, or backups that have never been restored
  • Audit logs that are collected but never reviewed, although information system activity review is required
  • Policies that were written once and haven't been reviewed since the systems or the organization changed

What HHS's 2025 proposal would change

On January 6, 2025, HHS published a proposed rule to update the Security Rule (90 FR 898, RIN 0945-AA22). As of September 27, 2026, the Federal Register lists only that proposed rule for the RIN; it hasn't been finalized or withdrawn, so the checklist above is still the rule in force.

Among other changes, HHS proposed ending the distinction between required and addressable specifications, with limited exceptions, and requiring encryption, multi-factor authentication, vulnerability scanning at least every six months and penetration testing at least once every 12 months. Treat these as possible future requirements, and keep your decisions tied to your own risk analysis so they hold whatever the final rule says.

Where our work fits

  • HIPAA Security Rule readiness — risk analysis support, safeguards review, and remediation planning.
  • Security Inspect is not a law firm, a CPA firm, or an ISO/IEC 27001 certification body. We don't give legal opinions, issue SOC 2 reports or ISO/IEC 27001 certificates, or guarantee that a client will pass an assessment.
  • When a program requires a formal assessment, audit, or certification, it's performed by an independent, authorized assessor. We keep advisory work and formal assessment apart: a practitioner never assesses controls they designed, developed, or implemented.

Questions

Is encryption required under the HIPAA Security Rule?

Under the rule in force, both encryption specifications are addressable: encryption and decryption of ePHI (164.312(a)(2)(iv)) and encryption in transmission (164.312(e)(2)(ii)). You must assess whether encryption is reasonable and appropriate, implement it if so, and if not, document why and implement an equivalent alternative measure if that is reasonable and appropriate. HHS's 2025 proposal would require encryption with limited exceptions, but as of September 27, 2026 it hasn't been finalized.

Which Security Rule standards have no separate implementation specifications?

Six safeguard standards: assigned security responsibility (164.308(a)(2)), evaluation (164.308(a)(8)), workstation use (164.310(b)), workstation security (164.310(c)), audit controls (164.312(b)) and person or entity authentication (164.312(d)). The Appendix A matrix marks each of these standards as required. The policies and procedures standard at 164.316(a) also has no separate implementation specifications.

Can we skip an addressable implementation specification?

Not without an assessment. Under 164.306(d)(3), you assess whether each addressable specification is reasonable and appropriate in your environment. If it isn't, you document why and implement an equivalent alternative measure if that is reasonable and appropriate. Leaving it out without that documented analysis doesn't meet the rule.

How long do we keep HIPAA security documentation?

Six years from the date it was created or the date it was last in effect, whichever is later (164.316(b)(2)(i)). The rule also requires making the documentation available to the people responsible for the procedures it covers, and reviewing it periodically, with updates as needed after environmental or operational changes that affect the security of ePHI.

Primary sources

Related guides

Terms in this guide

More on this site

Information on this website is general and educational. It isn't legal advice, and it doesn't create a client relationship.

Talk through your situation with a practitioner

Every engagement begins with a written scope and proposal.

Security Inspect is not a law firm or a CPA firm and does not provide legal opinions or issue SOC 2 reports. ISO/IEC 27001 certification is performed independently by an accredited certification body. CMMC organization-level assessment authority depends on an active C3PAO listing. Specific PCI services depend on the company’s active PCI SSC program listing and scope.