HIPAA Security Rule & HITRUST

## Scope of the Security Rule The **HIPAA Security Rule** is 45 CFR part 164, **subpart C** (sections 164.302 to 164.318). Under `164.302` it binds **covered entities** (health plans, health care clearinghouses and health care providers that transmit health information electronically in covered transactions) and **business associates**. It protects **electronic protected health information (ePHI)** only; PHI on paper or spoken aloud is the Privacy Rule's concern, not this subpart's. `164.306(a)` sets the general duties: ensure the **confidentiality, integrity and availability** of all ePHI the entity creates, receives, maintains or transmits; protect against reasonably anticipated threats and against impermissible uses or disclosures; and ensure workforce compliance. ## The three safeguard families Each section contains **standards**, and most standards carry **implementation specifications** marked *Required* or *Addressable*. | Family | Section | Standards (abridged) | |---|---|---| | Administrative | `164.308` | Security management process; assigned security responsibility; workforce security; information access management; security awareness and training; security incident procedures; contingency plan; evaluation; business associate contracts | | Physical | `164.310` | Facility access controls; workstation use; workstation security; device and media controls | | Technical | `164.312` | Access control; audit controls; integrity; person or entity authentication; transmission security | Two further sections complete the subpart: `164.314` (organizational requirements, including business associate contracts) and `164.316` (policies, procedures and documentation, retained for **6 years** from creation or last effective date, whichever is later). Examples a candidate should be able to place: - **Unique user identification** and **emergency access procedure** are required specifications under access control in `164.312(a)`. - **Disposal** and **media re-use** are required specifications under device and media controls in `164.310(d)`. - **Data backup plan**, **disaster recovery plan** and **emergency mode operation plan** are required under the contingency plan standard in `164.308(a)(7)`. - **Audit controls** (`164.312(b)`) is a standard with no separate implementation specifications. ## The security management process and risk analysis The first administrative standard, `164.308(a)(1)`, is the **security management process**: policies and procedures to prevent, detect, contain and correct security violations. Its four implementation specifications are all **required**: 1. **Risk analysis** - conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of ePHI held by the entity. 2. **Risk management** - implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. 3. **Sanction policy** - apply appropriate sanctions to workforce members who fail to comply. 4. **Information system activity review** - regularly review records such as audit logs, access reports and security incident tracking reports. ## Why the risk analysis comes first The Rule is deliberately **technology-neutral and scalable**. `164.306(b)` lets an entity use any security measures that reasonably and appropriately implement the standards, and requires it to weigh: - its size, complexity and capabilities; - its technical infrastructure, hardware and software security capabilities; - the costs of security measures; - the probability and criticality of potential risks to ePHI. The last factor is exactly what the risk analysis produces. Without it, the entity cannot show why its access controls, logging depth or encryption decisions are reasonable, and it cannot perform the assessment that every addressable specification demands. That is why interviewers treat a missing or stale risk analysis as the root failure behind most other gaps. ## Keeping it current The analysis is not a one-off document: - `164.306(e)` requires reviewing and modifying security measures as needed and updating their documentation. - `164.308(a)(8)` requires a periodic technical and nontechnical **evaluation**, and a new one in response to environmental or operational changes affecting ePHI security. - `164.316(b)(2)(iii)` requires documentation to be reviewed periodically and updated after such changes. ## A worked example A small clinic finds in its risk analysis that shared front-desk workstations stay logged in all day. That single finding touches all three families: an administrative fix (workforce access procedures and training), a physical fix (workstation placement under workstation use and security) and a technical fix (automatic logoff, an addressable specification under `164.312(a)(2)(iii)`). The risk analysis is what links the three and explains why each measure was chosen. A strong answer names the three sections, gives one example standard from each, states that the risk analysis is required rather than addressable, and ties it to the flexibility factors in `164.306(b)`. The method used to run the assessment itself is a risk-management topic of its own.