The Privacy Rule defines what health data must be protected and who is allowed to handle it. The Security Rule explains how electronic protected health information must be safeguarded. In practice, privacy is about permissible use and disclosure, while security is about the technical and procedural controls that restrict access, preserve integrity, and protect transmission.
What each rule is trying to control
The Privacy Rule and Security Rule are often discussed together, but they solve different problems. The Privacy Rule is about permissible use, disclosure, and individual rights over protected health information. The Security Rule is narrower in data type but deeper in control, because it governs how electronic protected health information is safeguarded through administrative, physical, and technical measures.
That difference matters in operations. A Privacy Rule question usually asks whether a use or disclosure is allowed, while a Security Rule question asks whether the organisation has the controls to protect ePHI against unauthorised access, alteration, loss, or exposure. In practice, the first is a legal-use question and the second is a protection-design question.
Where the boundary sits in real workflows
In the same workflow, both rules can apply, but they answer different questions. If a team is deciding whether it may share patient information with a contractor, the Privacy Rule is the primary lens. If the team is deciding how that contractor authenticates, what devices can reach the system, or how transmissions are protected, the Security Rule is the primary lens.
This is why a policy can be privacy-compliant and still be insecure, or technically secure and still use data in ways the Privacy Rule does not allow. The Privacy Rule sets the permission boundary, and the Security Rule sets the protection boundary. Organisations need both because one without the other leaves either legal exposure or security exposure.
- Privacy Rule: who may use or disclose PHI, for what purpose, and under what conditions.
- Security Rule: how electronic PHI is protected in storage, use, and transmission.
- Operational overlap: minimum necessary, role design, access restriction, logging, and workforce handling of patient data.
How to tell which rule drives the control decision
When a decision is about consent, authorisation to disclose, or whether a use fits an exception, the Privacy Rule is doing the heavy lifting. When a decision is about safeguarding systems, accounts, endpoints, networks, or transmissions that handle ePHI, the Security Rule is the controlling requirement. That distinction prevents teams from using technical controls as a substitute for a lawful basis to use or disclose data.
Many controls support both rules, but they do not collapse them into one requirement. Access control, auditability, workforce training, and incident response may support privacy compliance, yet the implementation detail changes depending on whether the question is “may we use this data?” or “how do we protect this data once we do?”
For practitioners who want the Security Rule side of the split explained in more depth, the HIPAA Security Rule Guide is useful because it breaks the rule into administrative, physical, and technical safeguards. For organisations handling patient data through cloud systems or shared platforms, the Healthcare Identity Security Guide helps connect HIPAA obligations to access control, clinician workflows, and shared-workstation risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.34 — Privacy and protection of PII | HIPAA privacy handling overlaps with privacy governance and lawful processing controls. |
| Recommendation — Map PHI handling rules to privacy governance and document approved disclosure conditions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | HIPAA Security Rule access restriction aligns with limiting ePHI access to what users need. |
| SC-8 — Transmission Confidentiality and Integrity | HIPAA Security Rule explicitly concerns protecting ePHI in transit. | |
| AU-2 — Event Logging | Logging supports HIPAA Security Rule accountability and investigation of ePHI access. | |
| Recommendation — Apply least privilege to restrict ePHI access to only authorised workforce roles. Protect ePHI transmissions with confidentiality and integrity safeguards. Log ePHI access and security-relevant events so misuse can be reviewed and traced. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Authentication strength materially affects security of systems that hold ePHI. |
| Recommendation — Use phishing-resistant authentication where ePHI access is a material risk. | ||
Practitioner Guidance
What to verify: Separate policy review from control review. If the question is “can we do this?”, check the Privacy Rule basis first; if the question is “is the data protected?”, check the Security Rule implementation. Teams get into trouble when they treat a technical safeguard as proof that a disclosure is permitted.
Decision rule: If the issue involves permissible use, disclosure, patient rights, or notice, route it through privacy governance. If it involves authentication, access restriction, transmission security, audit logging, or workstation/device protection for ePHI, route it through security operations and control ownership.
What good looks like: Privacy and security reviews should produce different artefacts. A privacy review should show the permitted use case and limitation logic; a security review should show the safeguard design, control ownership, and evidence that ePHI is actually protected in the systems that process it.
Practitioner takeaway: The cleanest mental model is that privacy governs whether PHI may be used or disclosed, while security governs how electronic PHI is protected once the organisation stores, processes, or transmits it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org