Module 03 · Free · 5:30
HIPAA Security Rule
The Security Rule, mandatory risk assessment, Security Officer designation, secure networks, BAAs, MFA, encryption, secure device use (registered devices, screen time-outs, password rotation), and staff-training cadence.
The Security Rule establishes national standards to protect electronic Protected Health Information. Where the Privacy Rule covers all forms of patient information, the Security Rule applies specifically to ePHI — through administrative, physical, and technical safeguards designed to ensure confidentiality, integrity, and availability. This module covers the required risk assessment, the Security Officer designation, and the technical and operational practices workforce members should understand — distinguishing where the rule mandates a specific control from where it treats a specification as addressable (implement, or document why an equivalent is reasonable and appropriate).
Regulatory anchors
- 45 CFR §164.306
- 45 CFR §164.308(a)(1)(ii)(A)
- 45 CFR §164.308(a)(2)
- 45 CFR §164.308(a)(5)
- 45 CFR §164.308(b)
- 45 CFR §164.312
- 45 CFR §164.312(a)(2)(iv)
Hosted on the Patient Protect YouTube channel
HIPAA Security Rule Explained: How to Protect ePHI in Your Practice
The Security Rule is the part of HIPAA that governs electronic Protected Health Information — the ePHI a practice creates, receives, maintains, or transmits through any electronic system. It exists because paper and verbal PHI already have a home in the Privacy Rule, but electronic information adds risks the Privacy Rule alone does not address: an unencrypted laptop, an ex-employee's active login, an EHR without an audit trail, a texting workflow that no one can produce evidence of. For a workforce member, the Security Rule is what turns "our IT handles it" into a shared responsibility — the practice can buy encryption, but a workstation that never gets locked when unattended breaks the safeguard the encryption was meant to support. This module builds the recognition; the reference layer on the Patient Protect site handles the deeper technical detail.
Learning objectives
What the workforce should be able to do after this module.
- Define and understand the HIPAA Security Rule
- Learn how to implement security measures to protect ePHI
- Understand the importance of risk assessments and the assigned security-officer role
- Identify best practices to maintain compliance and prevent breaches
Assessment: 5 knowledge-check questions per module, 80% passing standard.
Module outline
Section-by-section walkthrough.
01
What the Security Rule is
As defined by HHS, the Security Rule establishes national standards to protect ePHI through administrative, physical, and technical safeguards. Its aim is to ensure the confidentiality, integrity, and availability of patient data. Unlike the Privacy Rule — which applies to all forms of patient information — the Security Rule applies only to electronic data.
02
Risk Assessment — required
Completion of a risk assessment is required under HIPAA. It identifies potential vulnerabilities in how the practice stores, accesses, and transmits ePHI. Every subsequent safeguard decision flows from the results of this assessment.
03
Assigning a Security Officer
Each practice must designate a Security Officer responsible for overseeing the implementation and enforcement of security policies, ensuring safeguards are in place, and maintaining compliance across the organization.
04
Secure networks and Business Associate Agreements
The practice must use secure, protected networks whenever accessing or transmitting ePHI. Any vendor or third party that handles ePHI must have a signed Business Associate Agreement in place, ensuring the vendor is also bound by HIPAA obligations.
05
MFA and encryption — recommended baseline, addressable under the current rule
Multi-Factor Authentication (MFA) adds a verification layer beyond the password before granting access to systems containing ePHI. Encryption converts ePHI into unreadable data during transmission and storage, protecting against breach even when a device is lost or a network is intercepted. Under the current Security Rule, authentication (§164.312(d)) is technology-neutral and encryption (§164.312(a)(2)(iv) and (e)(2)(ii)) is an addressable implementation specification — a practice must implement encryption or document why an equivalent alternative is reasonable and appropriate. Both are widely-adopted baseline practices and both would be elevated to explicit requirements under the January 2025 NPRM if that rule is finalized.
06
Secure use of office technology
All devices used to access ePHI must be properly secured and monitored. Recommended baseline practices include registering devices in a centralized system, configuring automatic logoff (an addressable Security Rule specification at §164.312(a)(2)(iii)), and applying a documented password-management policy. Access to ePHI should be role-based — the minimum-necessary standard requires that staff have access only to the information needed for their job duties. Note: current NIST guidance (SP 800-63B) no longer recommends forced periodic password rotation without cause; strong, uncompromised credentials plus MFA are more effective than frequent forced changes.
07
Staff training — cadence and onboarding
Ongoing staff training is essential. The Security Rule (§164.308(a)(5)(i)) requires a security awareness and training program for all workforce members but does not specify a frequency; the Privacy Rule (§164.530(b)(1)) requires training "as necessary and appropriate" for workforce members to carry out their functions. Many practices adopt an annual cadence as a working default and retrain whenever policies change materially or a role gains new access. All new hires should complete HIPAA training as part of onboarding.
08
The three safeguard categories
The Security Rule is built on three main safeguard categories — administrative, physical, and technical. Every step in this module supports at least one of these categories and, together, they create a secure environment for ePHI.
What the Security Rule protects — and why it exists as its own regulation
The Security Rule (45 CFR Part 164, Subpart C) protects the confidentiality, integrity, and availability of electronic Protected Health Information. Confidentiality means ePHI is not disclosed to unauthorized people or processes. Integrity means it is not altered or destroyed in an unauthorized way. Availability means it is accessible when authorized people need it.
The rule is a separate regulation from the Privacy Rule because the risks are different. A paper chart is not going to be stolen by a ransomware group and posted to a data-leak site. An encrypted database in a locked server room can still be exfiltrated by an ex-employee whose credentials were never revoked. A backup that never gets tested may be intact, but the ability to actually restore it is what matters when an incident happens.
The Security Rule is intentionally scalable — a solo practice and a large hospital system apply the same rule at very different scales. HHS structured the requirements as "required" specifications every covered entity must implement, and "addressable" specifications that can be implemented as written, replaced with an equivalent measure documented in writing, or — if neither is reasonable — addressed via a documented analysis explaining why. "Addressable" is not "optional" — it is a documented judgment call.
The three safeguard categories
Every Security Rule requirement falls into one of three categories. A useful mental map for workforce members: administrative safeguards are about people and process, physical safeguards are about facilities and devices, and technical safeguards are about the systems themselves.
| Category | What it governs | Examples the workforce sees |
|---|---|---|
| Administrative (§164.308) | The people, policies, and processes around ePHI | Risk analysis, security officer designation, workforce access management, security-awareness program, sanction policy, incident-response procedure |
| Physical (§164.310) | The facilities and devices where ePHI lives | Facility access controls, workstation placement and use policy, device and media disposal, backup storage location |
| Technical (§164.312) | The systems that store and transmit ePHI | Unique user identifiers, automatic logoff, encryption at rest and in transit, audit controls, integrity controls, authentication |
The Security Risk Analysis — the requirement everything else flows from
The first administrative safeguard the Security Rule requires (§164.308(a)(1)(ii)(A)) is an accurate and thorough assessment of the risks and vulnerabilities affecting the confidentiality, integrity, and availability of the ePHI the practice creates, receives, maintains, or transmits. This is the Security Risk Analysis, or SRA. Every other decision about safeguards — what to encrypt, whose access to revoke, which vendor requires a BAA, how frequently to review audit logs — should reference back to what the SRA identified.
OCR treats a missing or inadequate SRA as one of its most common findings. HHS does not prescribe a specific frequency; the process is expected to be ongoing, and the analysis should be updated when material changes to the environment occur (a new EHR, a new location, a change in workforce, a new vendor with system access, a merger).
The SRA is not a five-minute readiness quiz. It is a documented assessment of the ePHI surface — what systems hold ePHI, how it moves between them, where it is transmitted externally, who has access, what could go wrong, and what the practice has done or plans to do about it. A completed SRA leaves a paper trail an auditor can follow.
Where the workforce actually intersects the Security Rule
Most Security Rule work happens at the platform / IT layer. But a handful of workforce behaviors are what keep the technical safeguards from being defeated in practice.
Unique credentials, no sharing
The Security Rule requires unique user identification (§164.312(a)(2)(i)). A shared login means the audit trail cannot answer "who accessed this record" — the single question that matters most after an incident.
Security Rule referenceWorkstation lock when stepping away
Automatic logoff (§164.312(a)(2)(iii)) is an addressable safeguard. Manual workstation lock is the human backstop — it protects the ePHI on screen the instant the user walks away, regardless of the automatic timer.
See the unlocked-workstation scenarioReporting suspicious activity
The rule requires procedures to identify and respond to suspected or known security incidents (§164.308(a)(6)). Those procedures depend on workforce members recognizing anomalies (a login they didn't make, a phishing attempt, a device acting strangely) and reporting.
Breach response playbookUsing approved systems for PHI
Every unmanaged channel — personal email, personal messaging apps, consumer AI tools — is a system without a BAA, without audit logging, and without administrative oversight. Move PHI onto the approved system and the technical safeguards can actually protect it.
HIPAA-compliant messagingEncryption and "secured" PHI
Encryption is an addressable technical safeguard (§164.312(a)(2)(iv) at rest, §164.312(e)(2)(ii) in transit). It is also the mechanism that renders ePHI "secured" for purposes of the Breach Notification Rule — meaning a device that is lost or stolen may not trigger breach obligations if the ePHI on it was encrypted to the HHS-recognized standard.
Two things follow. First, encryption at rest (on the device, in the database) protects against physical loss — a stolen laptop, a discarded hard drive. Second, encryption in transit (TLS 1.2 or better) protects data as it moves between systems — an email between servers, a query between the EHR and the imaging system. Both matter. Neither alone is enough.
"We use encryption" is not a complete answer. What matters is whether encryption is applied everywhere ePHI actually lives — backups, exports, portable devices, cloud storage, email attachments — and whether the practice can produce evidence of that configuration if asked. This is where documentation and the SRA meet.
Multi-factor authentication and access hygiene
Person or entity authentication (§164.312(d)) is a required technical safeguard. In modern practice that means multi-factor authentication (MFA) for any system holding ePHI — a password plus a second factor (an authenticator app, a hardware token, or a text-code as a last resort).
MFA is only effective if it is applied consistently. A workforce member who has MFA on the EHR but not on the email account that gets password-reset links has a weak point in the middle. The current January 2025 NPRM would elevate MFA from an addressable safeguard to a required one, subject to specific limited exceptions; the current Security Rule already treats authentication as required.
Beyond MFA, access hygiene means the practice removes access the moment it is no longer needed. A workforce member who leaves the practice should lose access before they leave the parking lot. A vendor whose engagement ends should have credentials disabled the same day. HHS enforcement records include multiple settlements involving ex-employees whose accounts remained active for months or years.
In practice
Security Rule situations in normal office workflow
Each of these ordinary moments touches a specific Security Rule safeguard. Recognizing which one is the workforce skill this module builds.
The office is switching to a new practice management system. Migration will pull records from the current EHR into the new database.
Both the current EHR vendor, the new system vendor, and any migration contractor are handling ePHI on the practice's behalf. Signed BAAs need to be in place with each before ePHI moves. The migration itself should use encrypted transmission, and the practice should update its SRA to reflect the new ePHI surface.
A hygienist finishes charting and walks away from the operatory workstation to greet the next patient. The screen stays open on the completed chart.
This is exactly the situation automatic logoff and manual workstation lock exist to prevent. The habit — lock the screen when stepping away — is the human component of a technical safeguard.
The practice receives a phishing email asking the office manager to update payroll direct-deposit information for a doctor. The email is convincing.
This is a suspected security incident under §164.308(a)(6). The practice's incident-response procedure should have a clear escalation path — do not click, do not reply, report through the designated channel, and let whoever handles security review the email before any action is taken.
A doctor asks the office manager to add a new AI transcription vendor to the workflow. The vendor promises to summarize clinical notes.
That vendor is handling ePHI. It needs a signed BAA before any patient information flows. The practice should also update its SRA to reflect the new system, and the Security Officer should verify what the vendor does with the data — retention, training-data use, subcontractors, and encryption in transit.
A dentist wants to check a patient's chart from home over the weekend to prepare for Monday.
Remote access to ePHI is permitted when the technical safeguards travel with it — a managed device or a secure remote-access method (a VPN or a browser-based EHR with MFA), not a personal laptop screenshotting the chart. The practice's remote-access policy should say what is allowed; if it doesn't, that is a gap the Security Officer should close.
Sample knowledge check
A representative question from this module.
Sample question · 5 per module in the live series
An office is signing up for a new cloud EHR vendor that will store ePHI. According to the Security Rule requirements covered in this module, which of the following MUST the practice have in place before using the vendor?
- A.Only a workforce training refresher on the new system.
- B.A signed Business Associate Agreement (BAA) with the vendor.
- C.A written acceptable-use policy signed by all staff.
- D.Notification to affected patients that a new vendor is being used.
Show explanation
Correct answer: B. Any vendor or third party that handles ePHI must have a signed Business Associate Agreement in place, ensuring the vendor is also bound by HIPAA obligations. This is one of the specific implementation requirements covered in the Security Rule module.
Common questions
Follow-up questions this module tends to raise.
Does the Security Rule apply to a solo-practice office?
Yes. The rule scales to the size of the practice, but every covered entity that maintains or transmits ePHI is subject to it. The specific implementation looks different — a solo practice may not need enterprise-grade identity management — but the Risk Analysis, the safeguards, and the documentation are required regardless of size.
How often does the Security Risk Analysis need to be updated?
HHS does not prescribe a fixed frequency. The rule expects an ongoing process, with the analysis updated when material changes to the environment occur — a new EHR, a new location, a merger, a significant workforce turnover, a new vendor with ePHI access. Many practices adopt an annual review cadence, but the test is whether the analysis still reflects the current environment.
What is the difference between "required" and "addressable" safeguards?
Required means the safeguard must be implemented as written. Addressable means the covered entity must either implement the safeguard as written, implement an equivalent measure and document that decision, or — if neither is reasonable — document why not and how the risk is otherwise addressed. Addressable is not optional; it is a documented judgment call. The current January 2025 NPRM would eliminate the distinction if finalized, making all current addressable specifications required (subject to specific limited exceptions).
Is a Business Associate Agreement enough to make a vendor "HIPAA compliant"?
No. A BAA is required, but it is a contract about accountability — it is not evidence that the vendor's technical, physical, and administrative safeguards are actually adequate. Whether the vendor's controls fit the risk of the data it is handling is a separate question the practice's Security Officer should evaluate before the vendor is onboarded.
What happens if my practice loses an unencrypted device with patient data on it?
The loss of an unencrypted device holding unsecured ePHI triggers the Breach Notification Rule analysis — the topic of Module 4. Encryption at the HHS-recognized standard is one of the two things (along with proper destruction) that renders ePHI "secured," meaning a lost encrypted device generally does not carry the same notification obligations as an unencrypted one.
Primary sources and further reading
Where the content on this page comes from.
- 45 CFR Part 164, Subpart C — Security Rule
The full text of the Security Rule, including the required and addressable specifications.
- HHS — Security Risk Assessment resources
The government's Security Risk Assessment Tool and companion materials.
- OCR — HIPAA Security Guidance
Federal guidance on specific Security Rule topics — remote access, encryption, mobile devices, cybersecurity.
- Patient Protect — HIPAA Security Rule reference
Deep reference layer covering current Security Rule requirements plus the January 2025 NPRM changes, if finalized.
Continue learning
Where to go next.
Related Patient Protect resources
HIPAA Security Rule reference
Deeper coverage of every safeguard, plus how the January 2025 NPRM would change things.
Free Risk Assessment
A structured Patient Protect Score that maps to the Security Rule categories and gives you a starting point for the SRA.
HIPAA-compliant messaging
Where SMS, iMessage, and consumer email fall short of the Security Rule and what a defensible workflow looks like.
Breach Notification training (next module)
What happens when a Security Rule safeguard fails — the incident-versus-breach analysis and the notification obligations.
Up to 50independent practices receive one year of complete HIPAA Foundations training — free.
Selected offices receive all 19 modules, 95 knowledge checks, administrator tracking, and QR-verifiable Certificates of Completion for up to 25 personnel. No hidden conversion. No public review required. Applications close November 30.
See the initiativeModule 03 of the HIPAA Foundations series
Every learner. Every module. One office price.
When you are ready to train the whole practice, the complete 19-module HIPAA Foundations series unlocks for up to 25 personnel at $39/office/month — with per-learner assessment scores, verifiable Certificates of Completion, and workforce-wide tracking.
Free tools stay free — no account needed. The 14-day platform trial asks for a card for identity verification; no charge before day 14, cancel any time.