The HIPAA Security Rule is short enough to read in an afternoon, and most teams still misread its structure. They treat it as a checklist of technologies. It is closer to a management framework, with a list of topics that framework must cover.
The rule sorts its requirements into three groups: administrative, physical, and technical safeguards. Knowing what belongs in each group, and how the groups depend on each other, tells you where the work sits. Most of it is not in the technical section. This article covers how the rule is built, what each safeguard type contains, and the mistakes that come from reading the categories too literally.
Where the Security Rule sits
HIPAA's administrative simplification rules are in 45 CFR Parts 160 and 164. The Security Rule is Part 164, Subpart C. It applies to covered entities (health plans, health care clearinghouses, and health care providers that conduct standard transactions electronically) and to their business associates.
Its scope is narrower than people assume. The Security Rule protects electronic protected health information (ePHI) only. Paper records and spoken conversations fall under the Privacy Rule, in Subpart E, which covers PHI in any form.
Section 164.306 sets the goal. You must ensure the confidentiality, integrity, and availability of all ePHI you create, receive, maintain, or transmit. You must protect against reasonably anticipated threats to it, and against reasonably anticipated uses or disclosures the Privacy Rule does not permit. You must also ensure your workforce complies.
The safeguards are the means to that goal, in three sections: 164.308 (administrative), 164.310 (physical), and 164.312 (technical). Two more sections complete the picture: 164.314 for business associate contracts and other organizational requirements, and 164.316 for policies, procedures, and documentation.
Standards, implementation specifications, and flexibility
Each safeguard section is a list of standards. Many standards have implementation specifications beneath them, which describe in more detail how the standard is met. Each specification is labeled required or addressable.
Required means what it says. Addressable does not mean optional. For an addressable specification, you 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 and appropriate. The documentation is the part teams skip, and it is the part an investigator asks for.
The rule also builds in flexibility. Section 164.306(b) lets you choose measures based on your size, complexity, and capabilities; your technical infrastructure; the cost of the measures; and the probability and criticality of potential risks to ePHI. That clause is why the rule names almost no products. It is also why your risk analysis carries so much weight: it is the record of how you applied those factors.
Administrative safeguards: the management system
Section 164.304 defines administrative safeguards as the actions, policies, and procedures that manage the selection, development, implementation, and maintenance of security measures, and manage your workforce's conduct. They are the longest section and the foundation for the other two. There are nine standards:
Security management process. Risk analysis, risk management, a sanction policy, and information system activity review, all required.
Assigned security responsibility. A named security official.
Workforce security. Authorization or supervision, clearance, and termination procedures.
Information access management. How access to ePHI is authorized, granted, and changed.
Security awareness and training. For the whole workforce, management included.
Security incident procedures. Identifying, responding to, mitigating, and documenting incidents.
Contingency plan. Data backup, disaster recovery, and emergency mode operation, with testing and a criticality analysis as addressable specifications.
Evaluation. Periodic technical and nontechnical evaluation of how well your safeguards meet the rule.
Business associate contracts and other arrangements.
The risk analysis sits at the top for a reason. Almost every other decision in the rule, including how you handle each addressable specification, should trace back to it.
Physical safeguards: buildings, workstations, and media
Physical safeguards protect your electronic information systems, and the buildings and equipment that house them, from natural and environmental hazards and from unauthorized intrusion. There are four standards:
Facility access controls. Addressable specifications for contingency operations, a facility security plan, access control and validation procedures, and maintenance records.
Workstation use. Policies on the functions a workstation may perform and the way it is used.
Workstation security. Physical safeguards for every workstation that can access ePHI.
Device and media controls. Disposal and media re-use are required. Accountability for moving hardware and media, and a backup before moving equipment, are addressable.
For a company with no office and no data center, this section looks almost empty. It is not. Your cloud provider covers its facilities, which you show through its attestations and your agreement with it. Laptops, phones, and anything else that reaches ePHI remain yours, wherever your staff work.
Technical safeguards: controls inside the systems
Technical safeguards are the technology, and the policies and procedures for its use, that protect ePHI and control access to it. There are five standards:
| Standard | Implementation specifications |
|---|---|
| Access control | Unique user identification (required), emergency access procedure (required), automatic logoff (addressable), encryption and decryption (addressable) |
| Audit controls | None listed; the standard itself is required |
| Integrity | Mechanism to authenticate ePHI (addressable) |
| Person or entity authentication | None listed; the standard itself is required |
| Transmission security | Integrity controls (addressable), encryption (addressable) |
Two things in that table surprise people. Encryption, at rest and in transit, is addressable rather than required. And the current rule does not name multi-factor authentication; person or entity authentication requires procedures to verify that whoever seeks access is who they claim to be.
Neither point is permission to skip the control. If you decide encryption is not reasonable and appropriate for a system holding ePHI, you need a documented reason that survives scrutiny, and few do. Encryption also changes your position under the Breach Notification Rule: PHI encrypted in line with HHS guidance is not "unsecured," so its loss may not trigger notification.
The two sections people forget
Section 164.314 sets out what your business associate agreements must say about security, with parallel requirements for group health plans. Section 164.316 requires reasonable and appropriate policies and procedures, and written documentation of them and of any action, activity, or assessment the rule requires you to document.
The retention period is six years from the date a document was created or was last in effect, whichever is later. That covers policies, superseded versions, and records such as each risk analysis and evaluation report. The documentation must be available to the people who implement it, and you must review and update it periodically.
In practice, 164.316 is where the three safeguard types become demonstrable. A control with no written procedure and no dated record of operation is hard to prove to anyone, including the HHS Office for Civil Rights (OCR) during an investigation.
Where the categories blur
The three-way split is an organizing device, not a strict boundary. Several controls span more than one type:
Encryption is a technical safeguard. Deciding where to use it, and managing the keys, is administrative work.
Offboarding sits in workforce security, which is administrative. Disabling the account is access control, which is technical. Recovering the laptop is device and media control, which is physical.
Backups are a contingency plan requirement, but the physical standard has its own backup specification for moving equipment.
Audit controls generate the logs. Information system activity review is the requirement that someone reads them.
This matters because ownership often follows the category. If engineering owns "technical" and the compliance lead owns "administrative," the seams are where things fall through. Assign each control an owner by what it does, and use the safeguard types only to check that nothing is missing.
A sensible order of work
If you are starting from nothing, the rule's own structure suggests an order:
Inventory where ePHI is created, received, maintained, and transmitted. Everything else depends on this scope.
Run the risk analysis against that inventory.
Name a security official and write the policies the administrative safeguards require.
Close the technical gaps your risk analysis ranked highest.
Cover the physical safeguards for devices and for any facility you operate.
Set up the documentation, retention, and review cycle that 164.316 requires.
The HIPAA framework page summarizes each requirement, and the glossary defines the terms used here. If your team also works toward SOC 2, the trust services criteria cover much of the same ground under different names.
How TrustLynce helps
TrustLynce maps HIPAA's standards and implementation specifications to the controls you run for other frameworks, so one piece of evidence can support several requirements (compliance automation). The readiness dashboard shows which safeguards have an owner, a policy, and current evidence, and which do not.