HIPAA Security Rule

The HIPAA Security Rule establishes national standards for protecting electronic protected health information (ePHI). It requires covered entities and business associates to implement safeguards ensuring the confidentiality, integrity, and availability of ePHI. The Security Rule is organized into three categories of safeguards — administrative, physical, and technical — plus organizational and documentation requirements that hold the program together.

Two design principles shape everything in the rule. First, it is technology neutral: written in 2003, it never names specific products or protocols, which is why it still functions in a cloud era it never anticipated. Second, it is flexible and scalable: regulators expect a four-person startup and a 40-hospital system to implement the same standards differently, based on size, complexity, capabilities, cost, and risk. Flexibility is not a loophole — it shifts the burden onto you to make reasonable decisions and document why they are reasonable.

Note that HHS has proposed significant Security Rule updates that would make many currently flexible specifications mandatory (including encryption and multi-factor authentication). Building to strong modern practice now is the safe bet regardless of when final rules land.

How the Rule Is Structured

The Security Rule contains standards, each of which may include implementation specifications. Specifications come in two flavors:

Required (R) — you must implement them, full stop.
Addressable (A) — you must assess whether the specification is reasonable and appropriate for your environment. If yes, implement it. If not, document why and implement an equivalent alternative measure. Addressable never means optional. OCR treats an undocumented decision to skip an addressable specification as a violation.

This distinction matters most for encryption, which is technically addressable — and the source of the most expensive documentation failures in HIPAA history. In practice, no modern organization can credibly document that encryption is unreasonable, so treat it as required.

Administrative Safeguards

Administrative safeguards are the policies, procedures, and management processes governing your security program. They account for more than half of the rule's requirements, and they are where OCR investigations focus first.

Risk analysis (required) is the foundation of the entire rule. You must conduct an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI you hold — everywhere it lives, including production databases, backups, logs, analytics pipelines, laptops, and SaaS tools. This is not optional and not a one-time event: it is the single most cited deficiency in HIPAA enforcement actions, and OCR has run a dedicated Risk Analysis Initiative because so many investigated entities cannot produce one. A defensible risk analysis includes an ePHI inventory and data flow map, identified threats and vulnerabilities, current controls, likelihood and impact ratings, and a resulting risk register. NIST SP 800-30 is the commonly used methodology.

Risk management (required) means actually reducing the risks you identified to a reasonable and appropriate level, on a documented plan with owners and dates. A risk analysis with no follow-through is nearly as damaging in an investigation as no analysis at all.

Sanction policy and information system activity review (required) — you need documented consequences for workforce violations and a routine process for reviewing logs, access reports, and incident records. "We collect logs" is not the same as "we review them"; assessors and investigators ask for evidence of review.

Assigned security responsibility (required) — one identified security official. In a startup, this is usually a founder or engineering lead; the point is unambiguous accountability.

Workforce security and information access management cover authorization, supervision, and termination procedures. The termination procedure is a classic failure point: departing employees whose credentials survive them are a recurring breach cause. Tie offboarding to a checklist that revokes every system, ideally same-day via SSO deprovisioning.

Security awareness and training requires ongoing education — including security reminders, malware protection awareness, login monitoring, and password management (all addressable specifications, all cheap to implement). Train at hire and periodically after, and keep completion records.

Security incident procedures (required) — identify, respond to, mitigate, and document security incidents. This connects directly to the Breach Notification Rule: your incident process must include the breach risk assessment.

Contingency planning requires a data backup plan, disaster recovery plan, and emergency mode operation plan (all required), plus testing and criticality analysis (addressable). Ransomware has made this family existential for healthcare: tested, isolated backups are the difference between an outage and a catastrophe.

Evaluation (required) — periodic technical and non-technical evaluation of how well your safeguards work, especially after environmental or operational changes. Annual internal assessments or third-party assessments satisfy this.

Physical Safeguards

Physical safeguards protect physical access to systems and facilities housing ePHI. The standards cover:

Facility access controls — limiting physical access while ensuring authorized access is allowed, with contingency operations, a facility security plan, access control and validation, and maintenance records.
Workstation use and workstation security — policies for how and where workstations that access ePHI may be used, plus physical protections (screen privacy in clinical settings, locked offices, cable locks).
Device and media controls — disposal and media re-use are required: ePHI must be rendered unrecoverable before hardware is discarded or reused. Accountability (media movement logs) and data backup before equipment moves are addressable.

For cloud-first companies, most facility obligations are inherited from your cloud provider — AWS, Azure, and GCP address data center physical security, and their compliance reports are your evidence. What remains yours: laptops, phones, any office hardware, and disposal procedures. Full-disk encryption on every endpoint plus MDM enforcement covers the majority of realistic physical risk for a distributed team, because a stolen encrypted laptop is generally not a reportable breach.

Technical Safeguards

Technical safeguards are the technology controls protecting ePHI. There are five standards:

Access control (required standard) — unique user identification and emergency access procedures are required; automatic logoff and encryption/decryption at rest are addressable. Practically: no shared accounts ever, role-based access, and session timeouts.
Audit controls (required) — mechanisms that record and allow examination of activity in systems containing ePHI. In modern stacks this means application audit logs, cloud provider logs (CloudTrail and equivalents), and centralized retention. Note the rule requires the capability and use of audit mechanisms; the administrative safeguards require you to actually review them.
Integrity (addressable specification) — mechanisms to corroborate that ePHI has not been improperly altered or destroyed: checksums, versioning, immutable backups, database integrity controls.
Person or entity authentication (required) — verify that the person seeking access is who they claim to be. The rule does not mandate multi-factor authentication by name, but MFA is the contemporary standard of care, and proposed rule updates would make it explicit. Enforce it everywhere.
Transmission security — integrity controls and encryption in transit are addressable, but TLS everywhere is table stakes. Watch for the forgotten channels: SFTP integrations with health systems, email (use secure messaging or enforced TLS with DLP), and internal service-to-service traffic.

Required vs Addressable: Quick Reference

Specification	Category	Status	Practical 2026 Answer
Risk analysis	Administrative	Required	Annual, documented, all ePHI in scope
Risk management plan	Administrative	Required	Risk register with owners and dates
Termination procedures	Administrative	Addressable	Same-day SSO deprovisioning checklist
Data backup plan	Administrative	Required	Automated, tested, isolated from production credentials
Disposal / media re-use	Physical	Required	Crypto-erase or destruction, with records
Unique user identification	Technical	Required	No shared accounts, SSO
Automatic logoff	Technical	Addressable	Session timeouts — implement it
Encryption at rest	Technical	Addressable	Implement it; treat as effectively required
Encryption in transit	Technical	Addressable	TLS 1.2+ everywhere; treat as effectively required
Audit controls	Technical	Required	Centralized logging with retention and review
Authentication	Technical	Required	MFA on all workforce and admin access

Why encryption deserves special emphasis: under the Breach Notification Rule, properly encrypted ePHI (per NIST guidance) is "secured," and its loss is generally not a reportable breach. Encryption is the closest thing HIPAA has to a safe harbor. A stolen unencrypted laptop is a reportable breach and a likely settlement; a stolen encrypted laptop is an inventory note.

Organizational Requirements and Documentation

Beyond the three safeguard families, the rule requires business associate agreements with vendors handling ePHI (covered fully in the business associates lesson) and imposes documentation rules: policies and procedures must be written, retained for six years from creation or last effective date, made available to the workforce, and updated as your environment changes. In an OCR investigation, if it is not documented, it did not happen.

Security Rule Implementation Checklist

Frequently Asked Questions

Is encryption actually required under HIPAA?

Formally, encryption is an addressable specification, so the letter of the rule permits a documented alternative. In reality, OCR has repeatedly penalized organizations that lost unencrypted devices, encryption is the de facto safe harbor against breach notification, and proposed Security Rule updates would make it mandatory. Treat it as required.

How often do I need to do a risk analysis?

The rule says the analysis must be accurate and thorough and that your program must be maintained — it does not name a frequency. The enforceable expectation is at least annually and after any significant change: new product, new cloud environment, acquisition, major incident. An outdated risk analysis that omits systems you actually run is treated like a missing one.

Does the Security Rule apply to paper records?

No — the Security Rule covers only electronic PHI. Paper and oral PHI are protected by the Privacy Rule's safeguards requirement instead. Almost every modern organization's PHI is predominantly electronic, so the Security Rule carries most of the operational weight.

Can a small startup satisfy the Security Rule without a security team?

Yes. The rule explicitly scales with organization size and resources. A small company with SSO, MFA, encrypted managed laptops, a hardened cloud environment, written policies, training, and an honest annual risk analysis can be fully compliant. What does not scale down is documentation — small companies must still write things down.

Does a SOC 2 report or HITRUST certification mean we comply with the Security Rule?

Not automatically, but there is heavy overlap. SOC 2 with the security criteria plus HIPAA-mapped controls, or HITRUST certification, covers most technical and administrative territory. Gaps typically remain around HIPAA-specific items: breach risk assessment procedures, BAA management, six-year documentation retention, and the sanction policy. Map explicitly rather than assuming.

Who enforces the Security Rule against business associates?

OCR, directly. Since the HITECH Act, business associates carry independent liability for Security Rule failures — OCR has settled with cloud hosts, IT vendors, and records companies without any action against their covered entity customers.

In the next lesson, we will cover the HIPAA Privacy Rule.

Most teams implement the Security Rule with the help of a compliance automation platform that maps controls, collects evidence, and monitors drift. AuditXYZ helps you compare compliance automation platforms and auditors so you can choose tooling that fits your stack and your ePHI footprint.

HIPAA Security Rule: Safeguards for Electronic PHI