What the HIPAA Security Rule is
The HIPAA Security Rule establishes the administrative, physical, and technical standards organizations must follow to protect electronic protected health information, or ePHI. It is codified at 45 CFR Parts 160 and 164, Subparts A and C, and is enforced by the U.S. Department of Health and Human Services through its Office for Civil Rights (OCR).
PHI and ePHI are related but have different scopes. Protected Health Information (PHI) includes protected health information in any form, including paper records. The Security Rule specifically applies to the electronic subset: ePHI.
A paper medical chart stored in a filing cabinet, for example, is governed primarily by the HIPAA Privacy Rule. The electronic version of that same patient information stored in an electronic health record, server, cloud application, backup system, or other electronic platform falls within the Security Rule.
The Security Rule works alongside several other important HIPAA requirements.
- The Privacy Rule governs how PHI may be used and disclosed.
- The HITECH Act, passed in 2009, extended many HIPAA obligations and direct liability to business associates.
- The Breach Notification Rule establishes notification requirements when unsecured PHI is compromised.
Together, these requirements create the regulatory framework healthcare organizations and the vendors that support them must operate within.
Who must comply
Covered entities
Covered entities generally include:
- Healthcare providers that transmit health information electronically in connection with standard HIPAA transactions
- Health plans
- Healthcare clearinghouses
Business associates
A business associate is a person or organization that creates, receives, maintains, or transmits PHI on behalf of a covered entity while providing a service or performing a function.
That category frequently includes technology providers.
An IT service provider, managed service provider, cloud provider, backup provider, software company, or other technology vendor may become a business associate when its services involve maintaining, managing, processing, storing, or otherwise handling systems or data containing ePHI.
Since HITECH, business associates can have direct liability under HIPAA. OCR can investigate and take enforcement action against a business associate independently of the healthcare organization it serves.
Not every technology provider automatically qualifies as a business associate.
HIPAA recognizes a narrow conduit exception for organizations that provide transient transmission services without maintaining the information beyond what is necessary to transmit it. Traditional telecommunications carriers and certain internet service providers can fall into this category.
An MSP that stores, backs up, maintains, manages, or has ongoing operational responsibility for systems containing ePHI generally does not fit within that exception.
MIS’S TAKE
Small businesses should pay much more attention to their BAAs
For small and midsize healthcare organizations, one of the most overlooked elements of HIPAA compliance is not necessarily a firewall or security product. It is the Business Associate Agreement itself.
In our experience, SMBs frequently sign BAAs without thoroughly reviewing what they are agreeing to.
A BAA is not simply a HIPAA checkbox. It is a legal agreement that can define responsibilities, notification obligations, indemnification requirements, insurance expectations, and financial liability between organizations.
We regularly see agreements containing provisions such as:
- Broad or potentially uncapped liability
- Indemnification requirements that place disproportionate responsibility on one party
- Security obligations that go well beyond what the provider reasonably controls
- Notification deadlines that are significantly more aggressive than regulatory requirements
- Requirements that conflict with the underlying service agreement
- Obligations that a provider may be contractually accepting without having an operational process capable of satisfying them
This can be particularly problematic for smaller organizations that do not have dedicated legal, compliance, and information-security teams reviewing every vendor agreement.
A business should understand not only whether it needs a BAA, but what the BAA actually requires it to do.
For important vendor relationships, the BAA, service agreement, cybersecurity requirements, insurance provisions, and operational responsibilities should be reviewed together. If contractual language creates unusual liability or legal obligations, qualified legal counsel should be involved before the agreement is signed.
HIPAA compliance is not simply about having a signed BAA on file. It is about making sure the organizations involved understand and can actually fulfill the responsibilities that agreement assigns to them.
Current rule and proposed changes
The most significant substantive update to the original Security Rule came through the 2013 HIPAA Omnibus Rule, which incorporated changes made by HITECH and expanded the direct obligations of business associates.
A much larger modernization effort is currently moving through the federal rulemaking process.
In January 2025, HHS published a Notice of Proposed Rulemaking proposing significant changes to the HIPAA Security Rule. Among other things, the proposal would strengthen requirements involving:
- Multi-factor authentication
- Encryption of ePHI at rest and in transit, with limited exceptions
- Technology asset inventories
- Network diagrams
- More detailed risk analyses
- Vulnerability scanning
- Penetration testing
- Network segmentation
- Configuration management
- Backup and recovery
- Security testing
- Business-associate oversight
The proposal would also establish additional time-sensitive obligations between covered entities and business associates in certain circumstances.
These proposals are important, but they are not yet the current HIPAA Security Rule.
Until HHS publishes a final rule and establishes an effective or compliance date, covered entities and business associates remain responsible for complying with the existing Security Rule.
However, the proposal provides a useful indication of where federal regulators believe cybersecurity practices should be heading.
Key requirements
The Security Rule organizes its requirements into three primary safeguard categories:
- Administrative safeguards
- Physical safeguards
- Technical safeguards
Implementation specifications under those standards are categorized as either Required or Addressable.
Required
A required implementation specification must be implemented as written.
Addressable
Addressable does not mean optional.
An organization must evaluate whether the implementation specification is reasonable and appropriate based on its environment, risks, capabilities, and circumstances.
If the organization determines that the specification is not reasonable and appropriate, it must document that determination and, where reasonable and appropriate, implement an equivalent alternative measure.
Simply ignoring an addressable requirement is not an acceptable compliance strategy.
Administrative safeguards (§164.308)
Administrative safeguards establish the policies, processes, and responsibilities used to manage the protection of ePHI.
Standard | Covers | Status |
|---|---|---|
Security Management Process | Risk analysis, risk management, sanction policy, activity review | Required |
Assigned Security Responsibility | Designates responsibility for security | Required |
Workforce Security | Authorization, supervision, clearance, termination | Addressable specifications |
Information Access Management | Controls authorization and access to ePHI | Required and addressable specifications |
Security Awareness and Training | Security training, malware protection, login monitoring, password management | Addressable specifications |
Security Incident Procedures | Identification and response to security incidents | Required |
Contingency Plan | Backup, disaster recovery, emergency operations | Required and addressable specifications |
Evaluation | Periodic technical and nontechnical review of security controls | Required |
Business Associate Contracts | Required agreements governing business associates | Required |
Physical safeguards (§164.310)
Physical safeguards govern the facilities, equipment, workstations, devices, and media used to access or store ePHI.
Standard | Covers | Status |
|---|---|---|
Facility Access Controls | Physical access to systems and facilities containing ePHI | Addressable specifications |
Workstation Use | Appropriate functions and environments for workstations | Required |
Workstation Security | Protection against unauthorized physical access | Required |
Device and Media Controls | Disposal, reuse, accountability, and backup of hardware and media | Required and addressable specifications |
Technical safeguards (§164.312)
Technical safeguards govern how systems control, monitor, protect, and transmit ePHI.
Standard | Covers | Status |
|---|---|---|
Access Control | Limits ePHI access to authorized users | Required and addressable specifications |
Audit Controls | Records and examines activity involving systems containing ePHI | Required |
Integrity | Protects ePHI from improper alteration or destruction | Addressable |
Person or Entity Authentication | Verifies that a person or system is who it claims to be | Required |
Transmission Security | Protects ePHI moving across electronic networks | Addressable specifications |
MIS’S TAKE
Access and auditing are where controls often break down
For SMB organizations, two areas repeatedly create practical security problems: overprivileged access and inadequate auditing.
Both can exist even when an organization believes it has strong security.
Overprivileged access
Many smaller organizations accumulate access rights over time.
An employee changes departments but keeps their old permissions. An administrator receives broad access to troubleshoot a problem and never has it removed. A vendor account is created with domain-wide privileges because it is easier than determining exactly what access is necessary.
Eventually, an organization can reach a point where far more people and systems have access to sensitive information than the business realizes.
The problem is not simply whether an account has a password or multi-factor authentication.
The more important question is:
Should this account have access to this information in the first place?
Organizations should regularly evaluate:
- Who has administrative privileges
- Which employees can access systems containing ePHI
- Whether former employees and vendors have been fully removed
- Whether service accounts have more rights than they require
- Whether permissions continue to match current job responsibilities
- Whether privileged access is reviewed periodically
For an SMB, the objective should be straightforward: provide the access required to perform the job, but no more.
Poor audit procedures
The second major issue is auditability.
Organizations frequently have security logs but do not actually review them.
Logging an event and auditing an event are not the same thing.
Servers, firewalls, Microsoft 365, security platforms, identity systems, applications, and endpoints can produce enormous quantities of information. Without an established process for reviewing that activity, potentially important events can disappear into millions of log entries.
A mature process should establish:
- What activity is logged
- Where those logs are retained
- How long they are retained
- Who reviews security events
- How unusual activity is identified
- How alerts are investigated
- How corrective actions are documented
- How the organization demonstrates that review actually occurred
This is particularly important for SMBs because they often do not have a dedicated internal security operations team.
Technology can automate much of the monitoring, but someone must still own the process.
A good security control must answer two questions: can we detect when something inappropriate happens, and can we demonstrate afterward that the control was working?
If the answer to either is no, there is likely a gap.
The HIPAA risk analysis
The risk analysis required under §164.308(a)(1) is one of the foundations of the HIPAA Security Rule.
An organization must identify:
- Where ePHI exists
- Which systems create, receive, maintain, or transmit it
- Threats to those systems and information
- Vulnerabilities that could allow those threats to cause harm
- The likelihood and potential impact of identified risks
- Measures used to reduce those risks
OCR enforcement actions repeatedly demonstrate the importance regulators place on an accurate and thorough risk analysis.
For SMB organizations, one of the most common mistakes is treating a vulnerability scan as a risk analysis.
They are not the same thing.
A vulnerability scan may identify missing patches, outdated software, insecure configurations, or exposed services. Those findings can contribute to a risk analysis, but a true HIPAA risk analysis examines the organization much more broadly.
It should consider areas such as:
- Microsoft 365
- Electronic health record platforms
- Servers and endpoints
- Cloud applications
- Backups
- Remote access
- Mobile devices
- Vendors and business associates
- Privileged accounts
- Physical systems
- Business processes involving ePHI
The organization must then determine how the identified risks will be managed.
A risk analysis that produces a list of findings but no remediation process is incomplete from a practical security perspective.
Assessment and documentation
OCR’s audit protocol provides useful guidance about the policies, technical controls, procedures, and documentation regulators may examine when assessing compliance.
Documentation matters because HIPAA compliance requires more than simply deploying cybersecurity tools.
An organization should be able to demonstrate:
- What controls exist
- Why they exist
- Who is responsible for them
- How they are monitored
- When they were last evaluated
- What risks were identified
- What remediation was performed
- What risks were accepted and why
The Business Associate Agreement operates at another level of this process.
The BAA establishes contractual obligations between organizations and should generally be in place before a business associate begins handling ePHI.
Organizations should therefore evaluate technical controls and contractual obligations together, rather than treating them as completely separate compliance exercises.
Enforcement
OCR enforces HIPAA through investigations, settlements, corrective action plans, and civil monetary penalties, organized into four tiers based on culpability. As of January 28, 2026, the current figures are: Tier 1 (the organization couldn’t have known about the violation) runs $145 to $73,011 per violation. Tier 2 (reasonable cause, not willful neglect) runs $1,461 to $73,011. Tier 3 (willful neglect, corrected within 30 days) runs $14,602 to $73,011. Tier 4 (willful neglect, not corrected) runs $73,011 to $2,190,294. Every tier carries the same annual cap: $2,190,294 per identical violation. HHS adjusts these figures for inflation, typically each January.
Criminal violations go to the Department of Justice, not OCR. Knowingly obtaining or disclosing PHI carries up to $50,000 and one year in prison. Doing so under false pretenses raises that to $100,000 and five years. Doing so for commercial advantage, personal gain, or malicious harm raises it again, to $250,000 and ten years.
Recent OCR enforcement activity reinforces an important principle:
A cybersecurity incident and a HIPAA compliance failure are not necessarily the same thing.
Organizations can experience sophisticated attacks despite maintaining reasonable security controls. The regulatory question is often whether the organization had performed the required risk analysis, implemented reasonable safeguards, maintained required policies and procedures, and responded appropriately.
OCR’s Risk Analysis Initiative shows what actually triggers enforcement in practice. On March 5, 2026, OCR settled with MMG Fusion, a dental-technology business associate, after a 2020 breach exposed data for roughly 15 million people. On April 23, 2026, four separate ransomware investigations settled for a combined $1,165,000. In each case, OCR’s finding was the same: no accurate risk analysis had been conducted before the breach.
The ransomware attack itself was not necessarily the compliance failure. The absence of appropriate risk management often was.
MIS’S TAKE
SMB compliance has to be operational
Large healthcare systems may have dedicated compliance departments, internal counsel, security teams, risk managers, and audit personnel.
Most small and midsize organizations do not.
That means a HIPAA security program designed for an enterprise can easily become unrealistic for an SMB.
The objective should not be to create hundreds of pages of policies that nobody uses.
The objective should be to create repeatable security processes that the organization can actually operate and demonstrate.
For an SMB, that means being able to answer practical questions such as:
- Do we know everywhere ePHI exists?
- Do we know who can access it?
- Are privileged accounts reviewed?
- Are terminated employees removed promptly?
- Are backups tested?
- Is security activity monitored?
- Are security alerts investigated?
- Can we demonstrate that those reviews occurred?
- Have identified risks been documented and addressed?
- Do we understand what our vendors can access?
- Do we have appropriate BAAs in place?
- Have we actually read the agreements we signed?
- Could we prove to an auditor that our security program is operating as intended?
That last question is particularly important.
Security controls should not exist only on paper.
For SMB organizations, simple controls that are consistently implemented, reviewed, documented, and improved are generally far more valuable than sophisticated policies that nobody follows.
Relationship to related frameworks
The Security Rule operates alongside several related laws, regulations, and cybersecurity frameworks.
HITECH Act
HITECH expanded HIPAA’s reach and created direct obligations and liability for business associates.
HIPAA Breach Notification Rule
The Breach Notification Rule governs what happens after certain breaches of unsecured PHI and ePHI, including notification requirements and reporting obligations.
NIST SP 800-66
NIST SP 800-66 provides cybersecurity guidance designed to help regulated organizations implement the HIPAA Security Rule.
HITRUST CSF
HITRUST builds on HIPAA and other security standards to provide a broader control and certification framework frequently used by healthcare organizations and their vendors.
State data-breach laws
Organizations must also evaluate applicable state laws.
A breach involving a Georgia organization or Georgia residents, for example, can trigger obligations that exist independently of HIPAA.
Frequently asked questions
What does “addressable” mean under the HIPAA Security Rule?
Addressable does not mean optional.
The organization must determine whether the implementation specification is reasonable and appropriate for its environment.
If it determines that the specification is not reasonable and appropriate, that conclusion should be documented and, where reasonable and appropriate, an equivalent alternative measure should be implemented.
Is an IT provider or MSP a business associate under HIPAA?
It can be.
An MSP that creates, receives, maintains, or transmits ePHI on behalf of a covered entity, or has ongoing responsibility for environments containing ePHI, will generally qualify as a business associate.
A company that merely provides transient transmission services may qualify for the narrow conduit exception, but organizations that store, maintain, back up, manage, or administer systems containing ePHI generally do not.
What happens if an organization hasn’t conducted a HIPAA risk analysis?
A missing or inadequate risk analysis can itself create a compliance problem, whether or not the organization has experienced a data breach.
OCR has repeatedly identified inadequate risk analysis in HIPAA enforcement actions.
Organizations should therefore treat risk analysis as an ongoing security-management process rather than a document produced once and placed in a file.
How often should a HIPAA risk analysis be conducted?
HIPAA doesn’t set a fixed frequency. The regulation requires the analysis periodically, not once and done. OCR and NIST SP 800-66 both recommend at least an annual review, plus an updated analysis after any material change: a new system, a new vendor or business associate, a security incident, or a merger. The pending 2025 NPRM would turn “at least annually” from guidance into a formal requirement.
What’s the difference between the HIPAA Security Rule and Privacy Rule?
The Privacy Rule generally governs how PHI may be used and disclosed.
The Security Rule focuses specifically on protecting electronic PHI through administrative, physical, and technical safeguards.
Both are important components of HIPAA compliance, but they address different aspects of protecting health information.
Resources
Organizations looking for authoritative information about the HIPAA Security Rule should begin with the U.S. Department of Health and Human Services and the Office for Civil Rights.
Additional resources include:
- HHS HIPAA Security Rule guidance
- OCR enforcement and resolution agreements
- OCR breach reporting information
- NIST SP 800-66
- Applicable state breach-notification statutes
For organizations evaluating how these requirements translate into an operational IT and cybersecurity environment, MIS Solutions can help assess security controls, access management, audit capabilities, vendor responsibilities, risk-management practices, and the technology infrastructure used to protect ePHI.
