Key takeaways

  • The Security Rule applies to covered entities and to business associates. It requires an accurate and thorough risk analysis, which is a required specification, not an option.
  • Safeguards fall into three groups: administrative, physical and technical. "Addressable" does not mean optional: you must implement the control or document why an equivalent measure is reasonable.
  • After a breach of unsecured PHI, individual notice is due without unreasonable delay and no later than 60 calendar days after discovery. A business associate has the same outer limit to notify the covered entity, and your contract may set a shorter one.
  • HHS proposed a major Security Rule update in January 2025. As of this review, the federal agenda lists final action for July 2027, so the current rule remains the law.

Who the Security Rule covers

The HIPAA Security Rule is the part of the HIPAA regulations (45 CFR Part 164, Subpart C) that protects electronic protected health information, or ePHI. It applies to two groups. Covered entities are health plans, health care clearinghouses and health care providers that transmit health information electronically. That includes most medical, dental, behavioral health and specialty practices. Business associates are the vendors and contractors that create, receive, maintain or transmit ePHI on a covered entity's behalf. Billing companies, IT providers, cloud hosts, e-prescribing platforms and shredding or backup services all commonly fall into this group.

The rule's general requirement is short. A covered entity or business associate must ensure the confidentiality, integrity and availability of all ePHI it creates, receives, maintains or transmits, protect against reasonably anticipated threats, and ensure that its workforce complies. Everything else in the rule serves that sentence. The rule is flexible about how: each organization may choose controls that fit its size, complexity and risk.

Step 1: The risk analysis comes first

Under the administrative safeguards, the security management process is the first standard, and it has four required parts: a risk analysis, risk management, a sanction policy, and a regular review of information system activity. The risk analysis is defined as an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of the ePHI the organization holds. Risk management then requires security measures sufficient to reduce those risks to a reasonable and appropriate level.

A usable risk analysis has a few parts. List every place ePHI lives, including the electronic health record, email, scanners and copiers, laptops, phones, backups, cloud storage and vendor systems. Identify the threats and vulnerabilities for each one, such as ransomware, a lost device, a misdirected email or an unpatched server. Rate the likelihood and impact, record the controls already in place, and decide what to fix first. Then write it down and date it. A checklist from a vendor is not a risk analysis unless it reflects your actual systems. Redo the analysis when you adopt new technology, move offices, change vendors or suffer an incident.

Keep the documentation. Section 164.316 requires you to retain the policies, procedures and records the Security Rule calls for for 6 years from the date they were created or last in effect, whichever is later.

Step 2: Administrative safeguards

The Security Rule's administrative standards are about people and process. Use this list to check your practice.

  • Assigned security responsibility: name one person who is accountable for the security program. This is a required standard.
  • Workforce security and information access management: give each employee only the access their job requires, and remove access promptly when someone leaves or changes roles. Authorization, clearance and termination procedures are addressable specifications.
  • Security awareness and training: train all workforce members, with reminders, protection from malicious software, log-in monitoring and password management as addressable specifications.
  • Security incident procedures: have a written process to identify, respond to and report security incidents. Response and reporting is a required specification.
  • Contingency plan: maintain a data backup plan, a disaster recovery plan and an emergency mode operation plan, all required. Testing and revision procedures and an applications and data criticality analysis are addressable.
  • Evaluation: perform periodic technical and non-technical evaluations of your safeguards, especially after environmental or operational changes. This is a required standard.
  • Business associate contracts: obtain written satisfactory assurances from every business associate. More on this below.

Step 3: Physical safeguards

Physical safeguards protect the buildings, rooms and devices where ePHI is stored or used. The standards cover facility access controls (contingency operations, a facility security plan, access control and validation procedures, and maintenance records, all addressable), workstation use and workstation security (both required), and device and media controls.

In a practice this means locked server closets, screens that cannot be read from the waiting room, and a clear rule about where workstations may be used. It also means controlling what happens to hardware. Disposal and media re-use are required specifications: before a hard drive, copier or phone leaves your control, ePHI must be destroyed or removed. Accountability for hardware movement and data backup and storage before moving equipment are addressable.

Step 4: Technical safeguards

Technical safeguards are the controls built into your systems. The required specifications are unique user identification and an emergency access procedure under access control, audit controls, and person or entity authentication. Addressable specifications include automatic logoff and encryption and decryption, a mechanism to authenticate ePHI as part of integrity, and integrity controls and encryption under transmission security.

Several of the most important controls in practice are labeled addressable, which causes confusion. The rule explains what the label means. For each addressable specification you must assess whether it is reasonable and appropriate in your environment. If it is, you implement it. If it is not, you document why and implement an equivalent alternative measure if one is reasonable. You cannot simply skip it. In today's threat environment, encryption of laptops and backups, encrypted transmission of ePHI, automatic logoff on shared workstations and multi-factor authentication for remote and administrative access are difficult to justify omitting, and a regulator reviewing a breach will ask about each of them.

Audit controls deserve special attention because they are required. You must record and examine activity in systems that contain or use ePHI. In practice, turn on logging in your EHR, your email platform and your file servers, make sure someone reviews the logs, and keep them long enough to investigate an incident.

Step 5: Business associates and BAAs

A covered entity may let a business associate handle ePHI only if it obtains satisfactory assurances, in a written contract or other arrangement, that the associate will appropriately safeguard the information. That contract is the business associate agreement, or BAA. The rule requires the agreement to make the business associate comply with the Security Rule's applicable requirements, to ensure that its subcontractors agree to the same restrictions, and to report security incidents, including breaches of unsecured PHI, to the covered entity.

A practical BAA checklist follows.

  • Keep a current inventory of every vendor that touches ePHI, including IT support, cloud and email hosts, billing, transcription, e-fax, backup and answering services.
  • Sign a BAA before the vendor receives any ePHI. Do not rely on a sales contract that is silent on HIPAA.
  • Set a faster internal reporting deadline than the legal outer limit. The regulation lets a business associate take up to 60 calendar days to notify you, but you will want days, not weeks.
  • Ask how the vendor secures ePHI: encryption, access control, logging, subcontractors and where data is stored.
  • Review BAAs when services change, and end them with a clear return-or-destroy process for data.

Business associates are directly subject to the Security Rule. If your company is a business associate, you need your own risk analysis, policies and safeguards, and you need BAAs with your own subcontractors. A signed agreement with a client does not replace your own compliance program.

Breach notification: the timelines

The Breach Notification Rule is in Subpart D of the same Part 164. It applies when there is a breach of unsecured PHI, which generally means PHI that is not encrypted or destroyed in a way that makes it unusable, unreadable or indecipherable to unauthorized people. The deadlines are the following.

  • Individuals: a covered entity must notify each affected individual without unreasonable delay and in no case later than 60 calendar days after discovery of the breach. Notice must describe what happened, the types of information involved, steps individuals should take, what you are doing in response, and how to reach you.
  • Media: for a breach involving more than 500 residents of a state or jurisdiction, the covered entity must also notify prominent media outlets serving that area, within the same 60-day outer limit.
  • HHS, 500 or more individuals: notice to the Secretary of HHS must be provided at the same time as the individual notice, in the manner HHS specifies on its website.
  • HHS, fewer than 500 individuals: keep a log of these breaches and report them to HHS no later than 60 days after the end of the calendar year in which they were discovered.
  • Business associate to covered entity: a business associate must notify the covered entity without unreasonable delay and no later than 60 calendar days after discovery.

A breach is treated as discovered on the first day it is known, or would have been known by exercising reasonable diligence, to any workforce member or agent other than the person who committed it. The clock does not wait for your investigation to finish. The 60‑day figure is an outer limit, and the regulation requires notice without unreasonable delay. State law may add shorter deadlines or additional recipients. For example, Florida's breach statute sets its own notice period, which we cover in a separate article.

Where the proposed Security Rule update stands

On January 6, 2025, HHS published a notice of proposed rulemaking in the Federal Register to modify the Security Rule. The comment period closed on March 7, 2025. The proposal cites rising breaches and cyberattacks and the deficiencies the Office for Civil Rights has seen in its investigations.

The proposal would, among other things, remove the distinction between required and addressable implementation specifications so that all specifications are mandatory. It would require a written technology asset inventory and network map, reviewed at least every 12 months, and a risk analysis that is updated at least every 12 months. It would require written procedures to restore critical systems and data within 72 hours of a loss, an annual compliance audit, notice to other regulated entities within 24 hours when a workforce member's access is changed or terminated, and multi-factor authentication, network segmentation and penetration testing of relevant systems. Business associates would have to notify covered entities when they activate their contingency plan, and BAAs would be revised to match.

These are proposals, not law. The federal Unified Agenda entry for the rulemaking (RIN 0945‑AA22) shows the notice of proposed rulemaking dated January 6, 2025, the stage as Long-Term Actions, and final action as July 2027. That is a delay from earlier targets, and agency timetables are estimates rather than commitments. We found no final rule published as of this review on November 8, 2026. The current Security Rule, as amended in 2013, remains in force and enforceable.

The smart way to treat the proposal is as a preview of what regulators already consider good practice. Practices that already inventory their assets, test restoration, require multi-factor authentication and conduct annual reviews will find a final rule easy to meet. Practices that wait for the final text may have little time to catch up, so building these controls now costs little extra.

A one-page checklist to start with

  • A current, written risk analysis and a risk management plan with owners and dates
  • A named security official and a documented workforce training record
  • Written policies and procedures, retained for 6 years
  • An inventory of systems and vendors that touch ePHI, with a signed BAA for each vendor
  • Role-based access, prompt termination of access, unique user IDs and multi-factor authentication for remote access
  • Encryption for laptops, phones, backups and data in transit
  • Audit logging turned on and reviewed
  • Tested backups and a documented disaster recovery and emergency mode plan
  • A written incident response plan that includes the breach notification deadlines above
  • A periodic evaluation, repeated after any significant change

Clayton Cybernetics designs and operates security programs for regulated organizations, including risk analyses, access controls, logging, backup and recovery testing, and incident response planning. If you would like a second set of eyes on your safeguards, our assessment is a good place to start.

Sources

This article is general information, not legal advice. HIPAA obligations depend on your facts, and state laws may add requirements. Confirm your obligations with your compliance counsel, and check the Unified Agenda for the current status of the proposed rule. Last reviewed .

Keep reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity