HIPAA violations resulted in over $145 million in OCR settlements and civil monetary penalties between 2019 and 2023. The Office for Civil Rights resumed its formal audit programme in December 2024, and healthcare organisations — along with the technology vendors that serve them — now face routine enforcement scrutiny, not just investigation triggered by an incident. Compliance is an operational expectation, and the cost of getting it wrong has never been clearer.
The challenge for IT teams is structural. The HIPAA Security Rule describes what must be achieved — administrative, physical, and technical safeguards for electronic Protected Health Information (ePHI) — but leaves the how largely to the organisation. Many IT teams implement the controls they know and overlook the ones they don't. Those gaps tend to surface during audits, during breaches, or when the OCR comes knocking with a corrective action plan that costs more to remediate than prevention ever would have.
This guide is a checklist-based walkthrough of all three safeguard categories, the required versus addressable specification distinction that trips up more organisations than any other compliance question, the 4-factor risk assessment process that is the single most common OCR audit finding when absent, BAA requirements, breach notification timelines, the 10 most common HIPAA violations in practice, and how HIPAA maps to HITRUST and SOC 2. It is written for healthcare IT managers, compliance leads, and MSP teams serving covered entities and business associates.
What Is HIPAA and Who Must Comply
HIPAA — the Health Insurance Portability and Accountability Act — was enacted in 1996 and established national standards for the privacy and security of Protected Health Information. It was substantially strengthened by HITECH (Health Information Technology for Economic and Clinical Health Act) in 2009, which introduced direct liability for business associates, significantly increased civil monetary penalties, and created the mandatory breach notification framework. The Omnibus Rule of 2013 incorporated HITECH's changes into HIPAA regulation, extending Privacy Rule protections and clarifying the definition of business associate to include subcontractors handling ePHI.
HIPAA compliance is mandatory for two categories of organisation. Covered entities include healthcare providers that transmit any health information electronically — hospitals, clinics, physician practices, dentists, pharmacies — as well as health plans (health insurance companies, HMOs, employer group health plans) and healthcare clearinghouses. Business associates are any organisations that create, receive, maintain, or transmit PHI on behalf of a covered entity: cloud service providers hosting PHI, EHR and EMR vendors, medical billing companies, IT managed service providers handling healthcare clients, data analytics companies processing health data, and legal firms with access to patient records. Business associates must sign a Business Associate Agreement and are directly liable under HIPAA since HITECH 2009 — the "we're just the vendor" defence no longer exists.
Protected Health Information (PHI) is any individually identifiable health information in any form — paper, electronic, or verbal — that is created, received, maintained, or transmitted by a covered entity or business associate. Electronic PHI (ePHI) is the specific subject of the HIPAA Security Rule. Penalties range from $100 to $50,000 per violation, up to $1.93 million per violation category per year under the 2024 adjusted figures, enforced by the HHS Office for Civil Rights.
The Security Rule applies specifically to ePHI — PHI that is created, received, maintained, or transmitted electronically. The Privacy Rule covers PHI in all forms. This guide focuses primarily on the Security Rule, which is the primary IT compliance obligation for healthcare technology teams and business associates.
The HIPAA Rules: What Each One Requires
HIPAA is not a single rule — it is a collection of regulations. Understanding which rule applies to which compliance obligation is essential for structuring an IT compliance programme correctly.
The Privacy Rule
The Privacy Rule establishes national standards for the protection of PHI in all forms. It governs how covered entities may use and disclose PHI, patients' rights to access their health information, and the Notice of Privacy Practices that covered entities must provide. The Privacy Rule is primarily a legal and operational compliance matter — IT's role is ensuring that systems support the access and disclosure rights it requires, including patient access portals and request management workflows.
The Security Rule
The Security Rule establishes national standards specifically for ePHI. It requires covered entities and business associates to implement administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of all ePHI they create, receive, maintain, or transmit. The Security Rule is where IT compliance lives — it drives risk assessments, access controls, encryption decisions, audit logging requirements, and workforce security training. The three safeguard categories each contain standards with implementation specifications classified as either Required or Addressable.
The Breach Notification Rule
The Breach Notification Rule requires covered entities to notify affected individuals, the HHS Secretary, and in some cases the media when unsecured PHI is breached. Business associates must notify covered entities. The key timelines are 60 calendar days from discovery for individual and media notification, with reporting to HHS depending on breach size. The encryption safe harbor — which removes the notification obligation when PHI is encrypted to NIST standards — is the single most practical reason to implement encryption even where it is technically an Addressable specification.
The Omnibus Rule (2013)
The Omnibus Rule enacted HITECH changes into HIPAA regulation. It established direct business associate liability, extended Privacy Rule protections to subcontractors, and clarified that any organisation maintaining ePHI on behalf of a covered entity — including cloud storage providers who never access the content — is a business associate subject to HIPAA. The Omnibus Rule is what makes HIPAA directly enforceable against cloud vendors and IT service providers that handle PHI.
Administrative Safeguards Checklist
Administrative safeguards are the largest safeguard category in the HIPAA Security Rule, comprising 9 standards with a combined 18 implementation specifications across required and addressable designations. They govern the policies, procedures, and processes that protect ePHI — the organisational and human layer of compliance.
Security Management Process Required
Implement policies and procedures to prevent, detect, contain, and correct security violations. The four implementation specifications are all Required: Risk Analysis — conduct a thorough, organisation-wide assessment of potential risks and vulnerabilities to ePHI; Risk Management — implement security measures sufficient to reduce identified risks to a reasonable and appropriate level; Sanction Policy — apply appropriate sanctions against workforce members who violate security policies; Information System Activity Review — regularly review records of information system activity including audit logs, access reports, and security incident tracking reports. The risk analysis is the cornerstone of the entire Security Rule — its absence is the most common OCR enforcement finding.
Assigned Security Responsibility Required
Identify a security official responsible for developing and implementing the security policies and procedures required by the Security Rule. This is the HIPAA Security Officer designation — a named individual (not a team title, not a shared inbox) who owns compliance accountability and is the single point of contact for OCR in the event of an investigation. The Security Officer must be identifiable by name and role in your policies.
Workforce Security Addressable
Three addressable specifications govern how workforce access to ePHI is managed: Authorization and/or Supervision — implement procedures for supervising workforce members who work with ePHI; Workforce Clearance Procedure — implement procedures to determine that each workforce member's access to ePHI is appropriate for their role; Termination Procedures — implement procedures for terminating access to ePHI when employment or a contractor relationship ends. All three are addressable but none should be absent without documented justification and an equivalent alternative control.
Information Access Management Required + Addressable
Isolating Healthcare Clearinghouse Functions is Required (for clearinghouses only): if a covered entity operates as or hosts a healthcare clearinghouse, ePHI functions must be isolated from other activities. Access Authorization (Addressable) and Access Establishment and Modification (Addressable) require organisations to implement policies for granting, documenting, reviewing, and modifying user access rights to ePHI systems. In practice, this means a formal access request and approval process, with documented justification for each access grant.
Security Awareness and Training Addressable
All four specifications are Addressable: Security Reminders, Protection from Malicious Software, Log-in Monitoring, and Password Management. The OCR consistently finds violations at organisations with no security training programme — addressable does not mean optional. A security awareness and training programme covering HIPAA obligations, phishing awareness, password policies, and PHI handling requirements is the de facto minimum. Annual completion by all workforce members, with documented records, is the standard that satisfies OCR review.
Security Incident Procedures Required
Implement policies and procedures to address security incidents. The Required specification — Response and Reporting — covers identifying and responding to suspected or known security incidents, mitigating harmful effects to the extent practicable, and documenting security incidents and their outcomes. A documented security incident response procedure is required; the absence of one is a finding in virtually every OCR audit involving a breach.
Contingency Plan Required + Addressable
Three specifications are Required: Data Backup Plan — create and maintain retrievable exact copies of ePHI; Disaster Recovery Plan — establish procedures to restore loss of ePHI data; Emergency Mode Operation Plan — enable continuation of critical business processes protecting ePHI during emergencies. Two specifications are Addressable: Testing and Revision Procedures — implement procedures for periodic testing and revision of contingency plans; Applications and Data Criticality Analysis — assess the relative criticality of specific applications and data in support of other contingency plan components.
Evaluation Required
Perform periodic technical and non-technical evaluations — initially and in response to environmental or operational changes — to determine how well security policies and procedures meet Security Rule requirements. The evaluation standard has no separate implementation specifications: the standard itself is required. Annual evaluation is the accepted practice baseline; evaluations are also triggered by significant system changes, new threat intelligence, or following a security incident.
Business Associate Contracts Required
Covered entities must have written Business Associate Agreements in place with all business associates before any PHI is shared. Business associates must have BAAs with subcontractors who handle ePHI on their behalf. See the Business Associate Agreements section for detailed BAA requirements.
Physical Safeguards Checklist
Physical safeguards govern the physical protection of ePHI — the facilities, workstations, and devices where ePHI is created, received, maintained, or transmitted. Four standards apply, with a mix of required and addressable specifications.
Facility Access Controls Addressable
All four specifications are Addressable: Contingency Operations — establish procedures that allow physical access to facilities housing ePHI systems during emergency operations; Facility Security Plan — implement policies to protect facilities containing ePHI systems from unauthorised physical access, tampering, and theft; Access Control and Validation Procedures — implement procedures to control and validate a person's access to facilities based on their role or function; Maintenance Records — document repairs and modifications to the physical components of facilities related to security. Common implementations include badge access systems, visitor logs, CCTV, and physical security policies covering server rooms and workstation areas.
Workstation Use Required
Implement policies specifying the proper functions to be performed on workstations with access to ePHI, the manner in which those functions are to be performed, and the physical attributes of the surroundings of workstations. This includes policies covering screen timeout, clean desk for printed PHI, prohibition of ePHI access on personal devices, and the physical placement of workstations to prevent unauthorised viewing.
Workstation Security Required
Implement physical safeguards for all workstations that access ePHI to restrict access to authorised users only. This encompasses screen privacy filters for workstations in public-facing locations, physical cable locks for portable equipment, workstation placement policies that prevent PHI from being visible to unauthorised individuals, and clean desk enforcement for printed records containing PHI.
Device and Media Controls Required + Addressable
Two specifications are Required: Disposal — implement policies governing the final disposition of ePHI and the hardware or electronic media on which it is stored (NIST 800-88 standards for media sanitisation; physical destruction for non-wipeable media); Media Re-use — implement procedures for the removal of ePHI from electronic media before re-use. Two specifications are Addressable: Accountability — maintain a record of the movements of hardware and electronic media; Data Backup and Storage — create a retrievable exact copy of ePHI before any movement of equipment.
Technical Safeguards Checklist
Technical safeguards govern the technology and the policies and procedures for its use that protect ePHI and control access to it. Five standards apply, with specifications across both required and addressable designations.
Access Control Required + Addressable
Two specifications are Required: Unique User Identification — assign a unique name or number to each user for tracking identity and activity within systems handling ePHI; Emergency Access Procedure — establish procedures for obtaining necessary ePHI during an emergency when normal access is unavailable. Two specifications are Addressable: Automatic Logoff — implement electronic procedures that terminate a session after a predetermined period of inactivity; Encryption and Decryption — implement a mechanism to encrypt and decrypt ePHI. Note: Encryption is Addressable, but it also triggers the Breach Notification Rule's encryption safe harbor. An organisation that doesn't encrypt ePHI has no protection from mandatory breach notification if that ePHI is compromised. In practice, encryption is a de facto requirement.
Audit Controls Required
Implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI. The standard is Required but the implementation specifications are not further defined — organisations must determine what constitutes sufficient audit logging for their environment. The accepted minimum practice: log all access to ePHI at the application and infrastructure level, retain logs for the required 6-year period, and review logs on a regular schedule. The absence of audit logs is both a Security Rule compliance gap and a practical problem — it prevents demonstrating the scope of a breach or proving that unauthorised access did not occur.
Integrity Addressable
The single addressable specification — Mechanism to Authenticate ePHI — requires implementing electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorised manner. In practice this means checksums or digital signatures for ePHI transmission, write-protection controls for stored ePHI, and version history for modified records. The objective is demonstrating that ePHI arriving at its destination is identical to ePHI that left the source.
Person or Entity Authentication Required
Implement procedures to verify that a person or entity seeking access to ePHI is who they claim to be. Multi-factor authentication (MFA) is not named in the text of the Security Rule, but it is consistently recommended in OCR guidance and is the de facto standard for authentication of any system handling ePHI. Covered entities relying solely on username and password authentication face significant scrutiny in OCR audits, particularly following credential-based breach incidents.
Transmission Security Addressable
Two addressable specifications: Integrity Controls — implement security measures to ensure that electronically transmitted ePHI is not improperly modified in transit; Encryption — implement a mechanism to encrypt ePHI in transit whenever deemed appropriate. In practice, TLS 1.2 or higher for all ePHI transmitted over public networks is the minimum standard. Unencrypted transmission of ePHI over any public network is indefensible in an OCR investigation, regardless of the Addressable designation of the specification.
Document Your HIPAA Controls in CheckFlow
CheckFlow's checklist platform helps healthcare IT teams operationalise HIPAA's Security Rule requirements — with structured workflows for risk assessments, access reviews, vendor management, and security incident response, each producing the timestamped evidence OCR audits require.
Browse Compliance TemplatesRequired vs Addressable Specifications — The Distinction That Trips Organisations Up
The HIPAA Security Rule divides its implementation specifications into Required and Addressable designations. Required specifications are non-negotiable — they must be implemented without exception. Addressable specifications must be implemented if they are reasonable and appropriate for the organisation's environment; if not, the organisation must document why and implement an equivalent alternative that achieves the same security objective.
The most misunderstood word in HIPAA Security Rule compliance is "Addressable." It does not mean optional. It does not mean implement if convenient. It does not mean skip it if it's technically difficult. The OCR has consistently found HIPAA violations at organisations that treated Addressable specifications as though no implementation was required. "Addressable" means evaluate — then implement or formally document your alternative. The documentation of the evaluation is itself a compliance requirement. An undocumented decision not to implement an Addressable specification is a violation.
The practical impact of this distinction is most consequential for encryption. Both the Access Control standard (encryption and decryption of ePHI at rest) and the Transmission Security standard (encryption of ePHI in transit) list Encryption as an Addressable specification. Organisations that interpret this as "we don't need to encrypt" face two simultaneous problems: a potential Security Rule violation for failing to implement an Addressable specification without documented justification, and the loss of the Breach Notification Rule's encryption safe harbor — meaning any impermissible disclosure of that unencrypted ePHI triggers mandatory individual, media, and HHS notification with all associated costs and reputational damage.
2024 regulatory update: A December 2024 Notice of Proposed Rulemaking (NPRM) issued by HHS proposed eliminating the Required/Addressable distinction entirely, making all implementation specifications explicitly required with limited, defined exceptions. Organisations should evaluate their Addressable specification implementations now under the assumption that the distinction may be removed in a final rule.
The following table summarises the Addressable specifications across all three safeguard categories and the common equivalent alternative approach where organisations document non-implementation.
| Standard | Addressable Specification | Common Equivalent Alternative (if not implemented) |
|---|---|---|
| ADMINISTRATIVE SAFEGUARDS | ||
| Workforce Security | Authorization and/or Supervision | Role-based access policy with documented approvals |
| Workforce Security | Workforce Clearance Procedure | Access request process with manager sign-off |
| Workforce Security | Termination Procedures | IT offboarding checklist with timestamped completion |
| Information Access Management | Access Authorization | Formal access control policy with documented approvals |
| Information Access Management | Access Establishment and Modification | Access review process with quarterly recertification |
| Security Awareness and Training | Security Reminders | Annual training programme with periodic communications |
| Security Awareness and Training | Protection from Malicious Software | EDR/antivirus deployment with centrally managed policy |
| Security Awareness and Training | Log-in Monitoring | Failed login alerting via SIEM or directory services |
| Security Awareness and Training | Password Management | Password policy enforced via directory services + MFA |
| Contingency Plan | Testing and Revision Procedures | Annual tabletop exercise with documented findings |
| Contingency Plan | Applications and Data Criticality Analysis | BIA (Business Impact Analysis) identifying critical ePHI systems |
| PHYSICAL SAFEGUARDS | ||
| Facility Access Controls | Contingency Operations | Emergency access procedures documented in DR plan |
| Facility Access Controls | Facility Security Plan | Physical security policy covering badge access and CCTV |
| Facility Access Controls | Access Control and Validation Procedures | Role-based physical access list with access records |
| Facility Access Controls | Maintenance Records | Change log maintained in ITSM or facilities management system |
| Device and Media Controls | Accountability | Asset inventory system tracking device location and assignment |
| Device and Media Controls | Data Backup and Storage | Pre-movement backup policy enforced via MDM and backup tool |
| TECHNICAL SAFEGUARDS | ||
| Access Control | Automatic Logoff | Screen lock policy enforced via GPO or MDM (typically 15 min) |
| Access Control | Encryption and Decryption | Full disk encryption (BitLocker/FileVault) + database-level encryption |
| Integrity | Mechanism to Authenticate ePHI | Checksums and TLS certificate pinning for ePHI in transit |
| Transmission Security | Integrity Controls | TLS 1.2+ with certificate validation for all ePHI transmissions |
| Transmission Security | Encryption (in transit) | TLS 1.2+ enforced for all ePHI transmitted over public networks |
HIPAA Risk Assessment: The 4-Factor Process
The Risk Analysis requirement — a Required specification within the Security Management Process standard — is the single most frequently cited finding in OCR enforcement actions and audit results. Failure to conduct a thorough and accurate risk analysis is the leading cause of HIPAA enforcement actions, not because organisations are intentionally non-compliant, but because the Security Rule's description of what constitutes a sufficient risk analysis is broadly written and easy to satisfy on paper while missing what the OCR is actually looking for in practice.
A compliant risk analysis has four required elements. Each must be documented — the documentation itself is a compliance artefact that must be retained for six years.
Identify and Document the Scope of ePHI
Document all ePHI that the organisation creates, receives, maintains, or transmits. This requires a data flow mapping exercise: where does ePHI enter your systems, where is it stored, where is it transmitted, and where does it exit? The scope assessment must cover all systems, applications, devices, and media — including third-party cloud services that process ePHI on your behalf. A partial risk analysis covering only the EHR system while missing cloud storage, email, mobile devices, and backup infrastructure is the most common form of inadequate risk analysis the OCR finds in practice.
Identify Threats and Vulnerabilities
For each ePHI storage and transmission point identified in the scope assessment, identify the potential threats and the vulnerabilities that could allow those threats to materialise. Threats include natural disasters, hardware or software failure, malicious internal actors, external attackers, and accidental disclosure. Vulnerabilities include missing patches, weak or shared access credentials, unencrypted storage or transmission, absent audit logging, and insufficient physical security controls. This must be a formal, documented list — not a mental assessment retained in a single person's memory. The OCR expects to see a written enumeration of threats and vulnerabilities specific to your environment.
Assess Current Controls and Calculate Likelihood and Impact
Evaluate the security controls currently in place for each identified vulnerability. For each combination of threat and vulnerability, assess the likelihood that the threat will successfully exploit the vulnerability given the existing controls, and the potential impact on ePHI confidentiality, integrity, or availability if it does. Multiply or score these factors to produce a risk level — High, Medium, or Low is the accepted tiering. The resulting risk register is the core output of the risk analysis and the primary document the OCR will review in an enforcement investigation.
Document the Risk Assessment and Implement a Risk Management Plan
The risk assessment must be documented in a format that can be produced for OCR review — a structured spreadsheet, a GRC tool output, or a formal risk assessment report. The Risk Management standard then requires implementing security measures sufficient to reduce identified High and Medium risks to a reasonable and appropriate level. For each risk, document the treatment decision: Mitigate (implement a control), Accept (formally document the business decision and the reasoning), Transfer (insurance or contractual indemnification), or Avoid (discontinue the activity creating the risk). An unmitigated High risk with no documented treatment decision is a Security Rule violation. The risk assessment must be reviewed and updated periodically (annually is the accepted standard), following any significant environmental or operational change, and following any security incident.
Business Associate Agreements (BAAs)
A Business Associate Agreement is a written contract between a covered entity and a business associate — or between a business associate and its subcontractors — that establishes the permitted uses and disclosures of PHI, requires the business associate to implement appropriate safeguards, and establishes notification obligations in the event of a breach. BAAs are mandatory. A covered entity that shares PHI with a vendor without a BAA is in violation of HIPAA regardless of whether the vendor actually misuses the PHI — the absence of the agreement is itself the violation.
A HIPAA-compliant BAA must specify the permitted uses and disclosures of PHI by the business associate; require the BA to implement HIPAA-required safeguards for ePHI; require the BA to notify the covered entity of security incidents and breaches without unreasonable delay and within 60 days of discovery; require the BA to make PHI available to the covered entity for patient rights fulfilment; require the BA to return or destroy all PHI at contract termination; and require the BA to ensure any subcontractors who handle PHI are bound by equivalent restrictions through their own BAAs.
For IT teams onboarding new vendors, the BAA must be executed before any PHI flows into the vendor's systems. The most common BAA violation pattern is a covered entity implementing a new SaaS application — scheduling software, telemedicine platform, billing system, cloud storage — that processes ePHI without first obtaining a signed BAA. No signed BAA before go-live is not a process gap to fix later; it is an active HIPAA violation from the first moment PHI enters the system.
AWS, Microsoft Azure, and Google Cloud all offer HIPAA BAAs. Their standard BAAs cover the infrastructure layer; your organisation is still responsible for application-level HIPAA compliance in the systems you build on top of their infrastructure. A signed AWS BAA does not make your application HIPAA compliant — it means the infrastructure layer is covered. The application layer, access controls, encryption configuration, audit logging, and all other Security Rule requirements remain your responsibility.
Cloud service providers maintain ePHI on behalf of covered entities even when they never access or view the content — simply storing encrypted ePHI makes the provider a business associate under the Omnibus Rule. This means that every cloud storage service, every SaaS application, and every third-party service that handles ePHI — including analytics, monitoring, and operational tooling integrated with PHI systems — requires a BAA. Building a BAA execution requirement into the vendor onboarding checklist is the practical control that prevents this category of violation. For guidance on structuring that process, see our vendor onboarding checklist.
HIPAA Breach Notification Requirements
A breach under HIPAA is the acquisition, access, use, or disclosure of PHI in a manner not permitted under the Privacy Rule that compromises the security or privacy of the PHI. The OCR presumes that any impermissible use or disclosure is a reportable breach unless the covered entity or business associate can demonstrate through a documented 4-factor risk assessment that there is a low probability that the PHI has been compromised — considering the nature and extent of the PHI involved, the person to whom the disclosure was made, whether the PHI was actually acquired or viewed, and the extent to which the risk has been mitigated.
The encryption safe harbor is the most important practical provision of the Breach Notification Rule for IT compliance purposes. If the PHI involved in an impermissible disclosure was encrypted to NIST standards — NIST SP 800-111 for data at rest, FIPS 140-2 validated encryption for data in transit — at the time of the impermissible acquisition, the event is not a reportable breach. This is the single most powerful reason to implement encryption even though both the Access Control and Transmission Security encryption specifications are Addressable. An organisation that encrypts ePHI to NIST standards retains the safe harbor; an organisation that does not must conduct a breach risk assessment for every impermissible disclosure and may face mandatory notification for events that would have been categorically excluded had encryption been implemented.
| Notification Required | Recipient | Timing | Condition |
|---|---|---|---|
| Individual notification | Affected individuals | Within 60 calendar days of discovery | All reportable breaches |
| Media notification | Prominent media outlets in affected state | Within 60 days of discovery | Breaches affecting 500+ individuals in a state |
| HHS notification (immediate) | HHS Secretary (online breach portal) | Within 60 days of discovery | Breaches affecting 500+ individuals |
| HHS notification (annual log) | HHS Secretary (annual log submission) | Within 60 days of calendar year-end | Breaches affecting fewer than 500 individuals |
| BA to covered entity notification | Covered entity | Without unreasonable delay; maximum 60 days from discovery | Any breach of PHI on the BA's systems |
The 60-day clock starts from the date of discovery — including the date when the covered entity or business associate should reasonably have discovered the breach. An organisation that fails to detect a breach for 90 days because it had no audit logging is not protected by the 60-day window. The clock runs from when a reasonable organisation with adequate monitoring would have discovered the breach, not from when the breach was actually detected.
10 Most Common HIPAA Violations
The following violations represent the most frequently cited findings across OCR enforcement actions, corrective action plans, and audit results. Most enforcement cases involve multiple violations simultaneously — the pattern typically begins with an absent or inadequate risk analysis, which in turn means the downstream controls that the risk analysis should have identified as necessary were never implemented.
Violation 1: No risk analysis or inadequate risk analysis. The most common OCR enforcement finding across all audit categories. Many organisations conduct a partial risk analysis — covering only their EHR, for example, or conducting a one-time assessment that was never updated — or complete a generic questionnaire that does not reflect their actual ePHI environment. The Security Rule requires a comprehensive, organisation-wide risk analysis covering all ePHI, including cloud services, mobile devices, business associate systems, and paper-to-electronic conversion processes. Fix: conduct a full ePHI data flow mapping, document the risk analysis using the 4-factor process above, and update it annually and following any significant system change.
Violation 2: No BAA with a vendor who handles PHI. A covered entity implements a new SaaS application that processes ePHI — scheduling software, telemedicine platform, billing system, cloud backup — without obtaining a signed BAA from the vendor. The covered entity is in violation from the first moment PHI enters the system, regardless of whether the vendor misuses the data. Fix: build BAA execution into the vendor onboarding checklist. No PHI-handling system goes live without a signed BAA on file.
Violation 3: Impermissible PHI disclosure. PHI is shared with a third party without patient authorisation or a HIPAA-permitted basis. Common examples: emailing PHI to the wrong recipient, sharing patient information with a family member without documented authorisation, posting PHI to a non-HIPAA-compliant communication platform, or including PHI in unencrypted email. Fix: implement email encryption for any PHI sent externally, train staff on permissible disclosure conditions, and establish a clear policy on which communication platforms are approved for PHI transmission.
Violation 4: Lack of encryption on portable devices. A laptop, USB drive, or mobile device containing unencrypted ePHI is lost or stolen. Because the ePHI is unencrypted, this is a reportable breach triggering all notification obligations — individual, media (if 500+), and HHS. Had the device been encrypted to NIST standards, the encryption safe harbor would apply and the event would not constitute a reportable breach. Fix: full disk encryption on all devices that access ePHI (BitLocker on Windows, FileVault on macOS), enforced and verified via MDM.
Violation 5: Inadequate access controls. Multiple staff members share a single system account, former employees retain access after termination, or staff access patient records outside their treatment relationship without a documented permissible basis. Shared accounts violate the Unique User Identification Required specification directly. Retained access after termination violates the Workforce Security Termination Procedures. Fix: unique user IDs for all accounts (Required specification), role-based access control implementation, and automatic access revocation at termination integrated into the IT offboarding process. See our IT offboarding security checklist for the full process.
Violation 6: No audit logging or inadequate audit log review. The system has no logging of who accessed ePHI, or logs are collected but never reviewed. In enforcement cases, the absence of audit logs prevents the organisation from demonstrating the scope of a breach or proving that unauthorised access did not occur — a problem that regularly turns a containable incident into a maximum-penalty finding. Fix: enable ePHI access logging at the application and infrastructure level, retain logs for 6 years as required, and implement a regular review process (minimum quarterly).
Violation 7: Failure to train workforce on security. Security awareness training is an Addressable specification, but organisations with no training programme consistently fail OCR audits and experience significantly higher rates of social engineering and phishing-related breaches — the primary vector for healthcare data breaches. Fix: implement annual security awareness training at minimum, document completion by each workforce member, and include HIPAA-specific content covering PHI handling obligations, permissible disclosure conditions, incident reporting procedures, and phishing recognition.
Violation 8: Improper PHI disposal. Paper records containing PHI are placed in standard recycling. Hard drives are sold, donated, or discarded without secure wiping. Mobile devices are traded in without a factory reset and MDM unenrolment. Each of these constitutes an impermissible disclosure under the Privacy Rule and a Device and Media Controls violation under the Security Rule. Fix: shred all paper PHI (cross-cut minimum), sanitise drives using NIST 800-88 methods, physically destroy media that cannot be securely wiped, and verify MDM unenrolment before any device disposal.
Violation 9: No documented breach notification procedure. The organisation experiences a potential breach. It has no documented process for conducting the 4-factor breach risk assessment, determining reportability, notifying affected individuals, or reporting to HHS. The 60-day notification clock runs from discovery — and "discovery" can be deemed to have occurred when a reasonably diligent organisation should have detected the breach. Fix: document the breach notification procedure in writing, assign ownership to the HIPAA Security Officer, and test the procedure at least annually through tabletop exercise.
Violation 10: Failure to conduct periodic evaluations. The Evaluation standard requires periodic technical and non-technical security assessments — initially and following environmental or operational changes. Organisations often conduct an initial compliance review at implementation and consider the obligation satisfied indefinitely. New systems are added, staff changes, the threat landscape evolves, and the security posture drifts away from the baseline while the original evaluation sits untouched. Fix: build periodic evaluation into the compliance calendar — annual internal audit as standard, plus triggered evaluation following any significant system migration, vendor change, or regulatory update.
HIPAA vs HITRUST vs SOC 2 — How They Relate
Healthcare IT organisations and business associates frequently encounter all three frameworks simultaneously — HIPAA as a legal obligation, HITRUST from healthcare clients requiring certification evidence, and SOC 2 from covered entities conducting vendor security assessments. Understanding how they relate prevents both conflation and duplication of effort.
| HIPAA | HITRUST CSF | SOC 2 Type II | |
|---|---|---|---|
| Type | US federal law | Certifiable security framework | Audit attestation standard |
| Mandatory? | Yes, for covered entities and BAs | No (voluntary) | No (voluntary) |
| Enforced by | HHS Office for Civil Rights | HITRUST Alliance | AICPA / CPA audit firms |
| Scope | PHI protection | Healthcare + cross-industry security | General security, availability, privacy |
| Healthcare-specific? | Yes | Yes (built for healthcare) | No — general purpose |
| Maps to HIPAA? | Is the law | Yes — designed to map to HIPAA Security Rule | Partial — SOC 2 does not map 1:1 to HIPAA |
| Certification/Report | No certificate — compliance status only | HITRUST r2 Certification | SOC 2 Type II Report |
| Typical use case | Legal compliance obligation | Demonstrating HIPAA compliance rigorously | Business associate relationship assurance |
In practice, many healthcare IT organisations hold both SOC 2 Type II (required by covered entities in vendor security assessments) and are working toward HITRUST r2 certification (considered the gold standard for demonstrating HIPAA Security Rule compliance in a structured, third-party-validated way). HIPAA compliance is the baseline legal requirement — SOC 2 and HITRUST are frameworks that help organisations demonstrate they meet that baseline in an auditable, credentialled form. An organisation can be HIPAA-compliant without HITRUST or SOC 2 certification; it cannot achieve HITRUST r2 certification without being substantially HIPAA-compliant. For organisations pursuing SOC 2 compliance, the controls overlap is significant — particularly across access control, audit logging, incident response, and risk management.
Recurring HIPAA Compliance Tasks
HIPAA Security Rule compliance is not a one-time project — it is an ongoing operational programme. The following calendar translates the Security Rule's recurring requirements into a practical schedule of tasks, mapped to the standard that requires each one. Timestamped completion records for every task in this calendar constitute the audit evidence that demonstrates continuous compliance operation.
| Frequency | Task | Standard |
|---|---|---|
| Daily | Review security incident reports; monitor audit logs for anomalies | Audit Controls (Required) |
| Monthly | Review access logs for ePHI systems; verify MDM compliance for all devices | Access Control (Required) |
| Quarterly | Review and update user access rights; process any role change access modifications | Access Control; Information Access Management |
| Quarterly | Test backup restoration for at least one critical ePHI system; document results | Contingency Plan (Required) |
| Quarterly | Security awareness reminders and phishing simulation to workforce | Security Awareness and Training (Addressable) |
| Annually | Conduct comprehensive risk analysis; update risk management plan | Risk Analysis (Required) |
| Annually | Review and update all HIPAA policies and procedures; obtain management sign-off | Security Management Process |
| Annually | Complete workforce security awareness training; document completion by all staff | Security Awareness and Training (Addressable) |
| Annually | Evaluate all business associate relationships; renew or update BAAs as needed | BA Contracts (Required) |
| Annually | Conduct technical and non-technical security evaluation against Security Rule requirements | Evaluation (Required) |
| Annually | Test contingency plan and disaster recovery procedures; document exercise findings | Contingency Plan (Required + Addressable) |
| Annually | Reconcile BAA list against all vendors and cloud services with access to ePHI | BA Contracts (Required) |
| As triggered | Conduct breach risk assessment within 24 hours of any potential PHI incident | Breach Notification Rule |
| As triggered | Update risk analysis following significant system, process, or environmental changes | Risk Analysis (Required) |
| 6-year retention | Retain all policies, procedures, documentation, agreements, and audit logs | Documentation (Required) |
Turn Your HIPAA Calendar Into a Running Checklist
Stop tracking HIPAA recurring tasks in spreadsheets. CheckFlow schedules and assigns your risk analysis, access reviews, training deadlines, and BAA renewals — with completion records that serve as audit evidence.
Start Free TrialFree HIPAA Compliance Templates
CheckFlow's HIPAA Compliance Audit Checklist gives you a ready-to-run workflow covering the Privacy Rule, Security Rule, and Breach Notification Rule — with administrative, physical, and technical safeguard assessments. Adapt it to your HIPAA compliance programme and it produces the timestamped completion records required for OCR audit evidence. Click the card to view the full template.
Frequently Asked Questions
HIPAA — the Health Insurance Portability and Accountability Act — is a US federal law enacted in 1996 that establishes national standards for the protection of individually identifiable health information, known as Protected Health Information (PHI). Compliance is required for two categories of organisations: covered entities (healthcare providers that transmit PHI electronically, health plans, and healthcare clearinghouses) and business associates (any organisation that creates, receives, maintains, or transmits PHI on behalf of a covered entity).
Business associates include cloud service providers, EHR vendors, billing companies, IT service providers, and any third party that handles PHI. HIPAA compliance is not optional — violations are enforced by the Office for Civil Rights (OCR) within HHS, with penalties ranging from $100 to $50,000 per violation, up to $1.93 million per violation category per year (as of 2024 adjusted figures).
HIPAA Security Rule implementation specifications are classified as either Required or Addressable. Required specifications are non-negotiable — covered entities and business associates must implement them without exception. Addressable specifications allow organisations to assess whether the specification is reasonable and appropriate for their environment. If it is, they must implement it. If it is not, they must document the reasoning and implement an equivalent alternative measure that achieves the same security objective.
Addressable does not mean optional. The OCR has consistently found organisations in violation for treating addressable specifications as if no implementation was needed. Note: a December 2024 NPRM proposed eliminating the Required/Addressable distinction and making all specifications explicitly required, though this had not been finalised as of mid-2026.
HIPAA's Breach Notification Rule requires covered entities to notify affected individuals within 60 calendar days of discovering a breach of unsecured PHI. For breaches affecting 500 or more individuals in a state or jurisdiction, covered entities must also notify prominent media outlets in that state within 60 days. All breaches must be reported to the HHS Secretary — breaches affecting 500 or more must be reported within 60 days; smaller breaches can be compiled in an annual log and reported within 60 days of the end of the calendar year.
Business associates must notify the covered entity of a breach without unreasonable delay and within 60 days of discovery. The encryption safe harbor applies: if PHI was encrypted to NIST standards at the time of the breach, the disclosure is not considered a reportable breach.
The most frequently cited HIPAA violations are: (1) failure to conduct a comprehensive risk analysis — the most common OCR audit finding; (2) impermissible uses and disclosures of PHI; (3) lack of or insufficient safeguards for PHI; (4) failure to have Business Associate Agreements in place with all vendors who handle PHI; (5) failure to implement access controls — unauthorised workforce members accessing PHI; (6) failure to encrypt PHI in transit and at rest or document the equivalent alternative; (7) failure to conduct workforce security training; (8) failure to implement audit controls; (9) failure to have a documented breach notification procedure; (10) disposal of PHI without proper destruction. Many enforcement cases involve several of these violations simultaneously.
HIPAA is a US law — compliance is legally required for covered entities and business associates. HITRUST CSF is a certifiable security framework specifically designed for healthcare that maps to HIPAA requirements as well as other frameworks (NIST, ISO 27001, PCI DSS). HITRUST certification does not equal HIPAA compliance, but it provides a structured approach to demonstrating compliance with HIPAA's technical and administrative requirements. SOC 2 Type II is a general-purpose security assurance framework — it does not map specifically to HIPAA, but covered entities often require their business associates to hold SOC 2 Type II reports as evidence of security controls.
In practice, many healthcare IT organisations pursue SOC 2 for business associate relationships and HITRUST for HIPAA-specific assurance. An organisation can be HIPAA-compliant without HITRUST or SOC 2; it cannot achieve HITRUST r2 certification without being substantially HIPAA-compliant.
Run Your HIPAA Compliance Programme in CheckFlow
Recurring schedules, auto-assigned tasks, timestamped audit records — everything healthcare IT teams need to maintain continuous HIPAA compliance. Free trial, no credit card required.
Get Started Free Book a Demo