For anyone responsible for systems holding patient data: practice managers, IT and security staff, compliance officers and administrators. This is the HIPAA SECURITY course, covering 45 CFR Part 164 Subpart C - electronic PHI only. Required versus addressable specifications, the mandatory security risk analysis, administrative, physical and technical safeguards, encryption and its breach safe harbour, business associate agreements and the Breach Notification Rule. If you need to know who may see patient information rather than how systems protect it, take HIPAA Patient Confidentiality.
Health care remains among the most targeted sectors for cyberattack, and the reason is economic: a medical record contains a name, date of birth, address, insurance details and clinical history, and unlike a payment card it cannot be cancelled and reissued. Breaches affecting hundreds of thousands of individuals are now routine, and the Office for Civil Rights publishes every breach affecting 500 or more people on a public portal.
Most people who have completed HIPAA training have covered the Privacy Rule - who may see protected health information, for what purposes, and what a patient may authorise. That is a different body of law from the one this course addresses.
The Security Rule, at 45 CFR Part 164 Subpart C, governs electronic protected health information specifically. It does not tell you who may look at a record. It tells you what technical, physical and administrative controls must exist so that only the right people can.
Enforcement has shifted noticeably. A large share of OCR settlements now turn on a single failure: the covered entity never performed an accurate and thorough risk analysis, which the Security Rule makes a required implementation specification. Organisations are penalised not for being breached but for never having assessed where they were exposed.
This course covers what the Security Rule actually requires, where the Privacy and Security Rules divide, and what your obligations are as someone who handles electronic PHI.
The two rules are frequently conflated, including inside compliance programs. Understanding the division tells you which one governs a given question.
The Privacy Rule (45 CFR Part 164 Subpart E) applies to protected health information in any form - spoken, written on paper, faxed, or electronic. It governs permitted uses and disclosures: treatment, payment and health care operations; what requires patient authorisation; the minimum necessary standard; and patients' rights of access, amendment and accounting.
The Security Rule (Subpart C) applies only to electronic PHI, usually written ePHI. It governs the safeguards that protect the confidentiality, integrity and availability of that information.
Those three words are the Security Rule's stated objective, and each is distinct:
A conversation overheard in a corridor is a Privacy Rule matter. An unencrypted laptop stolen from a car is a Security Rule matter. Both may trigger the Breach Notification Rule.
Protected health information is individually identifiable health information held or transmitted by a covered entity or business associate. When it is created, received, maintained or transmitted in electronic form, it is ePHI and the Security Rule applies.
The identifiers matter. Information is individually identifiable if it relates to health status, care or payment and could reasonably identify the person. HIPAA's de-identification standard lists eighteen identifiers, including name, geographic subdivisions smaller than a state, all date elements more specific than year, telephone and fax numbers, email address, Social Security number, medical record number, health plan beneficiary number, account numbers, certificate and licence numbers, vehicle and device identifiers, URLs and IP addresses, biometric identifiers, and full-face photographs.
Where ePHI actually lives is broader than most people assume: the EHR, of course, but also email and attachments, text messages, shared drives and cloud storage, backup media, scanners and copiers with internal hard drives, medical devices and imaging equipment, laptops, phones, tablets, USB drives, voicemail systems, and any vendor platform holding patient data.
Two frequent surprises. Multifunction printers and copiers store images on internal drives, and disposing of one without wiping it has produced multi-million-dollar settlements. And a photograph of a screen taken on a personal phone is ePHI the moment it exists, now sitting outside every control the organisation has.
The Security Rule is deliberately technology neutral and scalable. A solo practice and a national health system face the same standards but are expected to implement them proportionately. The mechanism for that flexibility is the distinction between required and addressable implementation specifications.
A required specification must be implemented. There is no discretion. The risk analysis is required. So is a sanction policy, and media disposal, and unique user identification.
An addressable specification is not optional, and this is the single most misunderstood point in the Security Rule. "Addressable" does not mean "if you feel like it." For each addressable specification the entity must assess whether it is a reasonable and appropriate safeguard in its environment, and then either:
The documentation is the point. An organisation that skipped encryption and wrote nothing down has failed the standard. One that assessed encryption, documented a specific reason it was not reasonable in a particular system, and implemented a compensating control has satisfied it.
Encryption is addressable, not required - a fact routinely misquoted in both directions. It must be evaluated, and choosing not to encrypt requires written justification and an alternative.
Administrative safeguards, at 45 CFR 164.308, are the largest section of the Security Rule. They are the policies, procedures and human processes that manage security - and most breaches trace back to a failure here rather than to a technical one.
Two of these fail most often in practice: termination procedures, where departed staff retain active accounts for months, and contingency planning, where backups exist but have never been restored to verify they work.
If one requirement defines Security Rule enforcement, it is this one. 164.308(a)(1)(ii)(A) requires the entity to "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate."
It is a required specification - not addressable - and it is the foundation for everything else. You cannot decide which addressable safeguards are reasonable without knowing what you are exposed to.
An adequate risk analysis identifies where all ePHI is created, received, maintained and transmitted, including vendors and portable media; identifies reasonably anticipated threats and vulnerabilities; assesses current security measures; determines the likelihood and potential impact of each threat; assigns a risk level; and documents the findings.
It is not a one-time exercise. It must be reviewed and updated periodically and whenever the environment changes materially - a new EHR, a new location, a move to cloud hosting, a merger, or a shift to remote working.
Common failures OCR has cited repeatedly: an analysis limited to the EHR that ignores email, laptops and vendors; a vendor's generic questionnaire accepted as an analysis; an analysis performed once years ago and never revisited; and findings documented but never converted into a risk management plan that actually remediates them. Identifying a risk and doing nothing about it is arguably worse than not looking, because it establishes knowledge.
Physical safeguards, at 45 CFR 164.310, address the tangible world: buildings, rooms, equipment and media. They matter because the most common large breaches are still mundane - a stolen laptop, a lost drive, a decommissioned copier.
Disposal is where organisations are most often caught. Deleting a file does not remove it, and formatting a drive does not reliably remove it either. Media containing ePHI must be sanitised to a standard that makes recovery infeasible - secure wiping, degaussing, or physical destruction - and the disposal must be documented.
The devices people forget: copiers and multifunction printers, imaging equipment, network appliances, backup tapes, and any device returned to a leasing company at the end of its term.
Technical safeguards, at 45 CFR 164.312, are the controls built into the systems themselves.
Unique user identification is required, and shared accounts violate it. A generic "frontdesk" login used by six people destroys accountability: audit logs become useless, because no entry can be attributed to a person. This is one of the most common findings in small practices and one of the easiest to fix.
Audit controls are required, but logging is not the whole obligation. 164.308 separately requires reviewing system activity. Logs nobody reads satisfy the letter and defeat the purpose - and inappropriate access by an authorised user, such as a staff member looking up a neighbour's record, is only ever caught by review.
Encryption occupies a peculiar position: it is addressable under the Security Rule, yet it is the single most consequential control an organisation can implement, because of how the Breach Notification Rule treats it.
A breach is defined as the acquisition, access, use or disclosure of PHI in a manner not permitted by the Privacy Rule which compromises its security or privacy. But PHI that has been rendered unusable, unreadable or indecipherable to unauthorised persons - through encryption meeting recognised standards, or through destruction - is not "unsecured PHI".
The practical consequence is decisive. If an encrypted laptop is stolen and the key was not also compromised, there is generally no reportable breach. No individual notifications, no report to HHS, no posting on the public breach portal, no media notice. The same laptop unencrypted is a reportable breach with all of those obligations and the reputational cost attached.
Encryption should be considered in two states. Data at rest - full-disk encryption on laptops and mobile devices, encrypted backups, encrypted portable media. Data in transit - TLS for web traffic and email, secure messaging rather than standard SMS, VPN for remote access.
Because encryption is addressable, an organisation that declines it must document why it is not reasonable and appropriate in that specific environment and implement an equivalent alternative. In 2026, with full-disk encryption built into every major operating system at no cost, that justification is difficult to sustain for portable devices.
Most organisations hand ePHI to other organisations constantly - the billing company, the EHR vendor, the cloud host, the transcription service, the shredding contractor, the IT support firm.
A business associate is a person or entity that creates, receives, maintains or transmits PHI on behalf of a covered entity, or provides services involving disclosure of PHI. Since the HITECH Act and the Omnibus Rule, business associates are directly liable for Security Rule compliance and can be penalised by OCR in their own right - not merely through their contract.
A business associate agreement is required before PHI is shared. It must establish permitted uses and disclosures, require appropriate safeguards, require reporting of security incidents and breaches to the covered entity, require subcontractors to provide the same protections, and provide for return or destruction of PHI when the arrangement ends.
Two points that catch people out. Subcontractors of business associates are themselves business associates, and the chain of agreements must follow the data all the way down. And a conduit that merely transports data without accessing it - the postal service, an ISP - is not a business associate; but a cloud provider that stores ePHI is one, even if it never looks at the data and even if the data is encrypted.
Signing a BAA does not transfer responsibility. The covered entity remains accountable for reasonable diligence in selecting and monitoring vendors, and "our vendor did it" has not succeeded as a defence.
The Breach Notification Rule, at 45 CFR 164.400-414, sets out what must happen when unsecured PHI is compromised.
An impermissible use or disclosure is presumed to be a breach unless the entity demonstrates a low probability that the PHI has been compromised, based on a risk assessment covering at minimum four factors: the nature and extent of the PHI involved including identifiers and likelihood of re-identification; the unauthorised person who used or received it; whether the PHI was actually acquired or viewed; and the extent to which risk has been mitigated. The presumption runs against the entity - it must prove low probability, not the other way round.
Notification requirements:
A breach is treated as discovered on the first day it is known, or by exercising reasonable diligence would have been known, to any person other than the one who committed it. The clock does not begin when management is told - it begins when the organisation should have known.
Breaches affecting 500 or more individuals are published on OCR's public portal, commonly called the "wall of shame", and remain visible.
The Office for Civil Rights enforces both the Privacy and Security Rules, through complaints, breach reports and compliance reviews. State attorneys general may also bring actions under HITECH.
Civil monetary penalties are structured in four tiers based on culpability: the entity did not know and could not reasonably have known; the violation was due to reasonable cause and not willful neglect; willful neglect that was corrected within 30 days; and willful neglect not corrected. Amounts increase sharply across the tiers and are adjusted annually for inflation, with annual caps per identical provision. Criminal penalties apply for knowing wrongful disclosure, rising substantially where the offence involves false pretences or intent to sell or use PHI for commercial advantage or malicious harm.
The tiering carries a practical lesson: correcting a violation promptly moves it into a materially lower penalty tier. Concealing one does the opposite.
What is expected of you:
One honest limitation. This course covers what the Security Rule requires. It cannot cover your organisation's own policies, its named security official, or its incident reporting procedure. Your employer must supply those, and you are entitled to ask.
You've studied the material. The exam is free — pay only when you pass.
START FREE EXAM →