> regulation: HIPAA —— jurisdiction: United States (extraterritorial reach) —— scope: protected health information —— penalties: up to $2.13M per violation category per year —— status: if you handle US healthcare data, this applies to you<span class="cursor-blink">_</span>_
The Health Insurance Portability and Accountability Act — universally known as HIPAA — is the United States federal law that governs the privacy, security, and handling of protected health information (PHI). Enacted in 1996, HIPAA established national standards for how healthcare data must be protected, who may access it, how it may be shared, and what happens when those protections fail. It is enforced by the US Department of Health and Human Services (HHS) Office for Civil Rights (OCR), which has the authority to investigate complaints, conduct audits, and impose substantial financial penalties for non-compliance.
If your organisation is based outside the United States, you might reasonably assume HIPAA does not apply to you. That assumption is often wrong. HIPAA's reach extends to any organisation that creates, receives, maintains, or transmits protected health information on behalf of a US healthcare entity — regardless of where that organisation is physically located. A UK-based cloud hosting provider that stores patient records for a US hospital is subject to HIPAA. A software development company in Europe that builds applications processing US patient data is subject to HIPAA. A penetration testing firm that accesses systems containing PHI during an engagement is handling PHI — and the contractual obligations that flow from HIPAA will apply.
HIPAA is not a single rule. It is a framework comprising several interconnected regulations, each addressing a different aspect of healthcare data protection. Understanding which rules apply, what they require, and how they interact is essential for any organisation that touches US healthcare data — whether as a healthcare provider, an insurer, a technology vendor, or a professional services firm.
HIPAA defines two categories of organisation that are subject to its requirements: Covered Entities and Business Associates. Understanding which category your organisation falls into — or whether you fall into either — determines which obligations apply.
| Category | Definition | Examples |
|---|---|---|
| Covered Entities | Organisations that directly provide healthcare, process health insurance claims, or act as healthcare clearinghouses. These are the primary subjects of HIPAA — the organisations that generate and hold patient data as part of their core operations. | Hospitals, GP practices (physician offices), dental practices, pharmacies, health insurance companies (health plans), Medicare/Medicaid programmes, healthcare clearinghouses that process claims data. |
| Business Associates | Any person or organisation that performs a function or activity on behalf of a Covered Entity that involves access to protected health information. This is the category that catches organisations by surprise — because it extends HIPAA's reach far beyond the healthcare industry itself. | Cloud service providers hosting PHI, IT managed service providers with access to healthcare systems, software vendors whose products process patient data, billing and claims processing companies, consultancies with access to PHI, legal firms handling healthcare cases, accountancy firms auditing healthcare organisations, penetration testing firms that may encounter PHI during engagements, data analytics companies processing health data, document shredding and destruction services. |
| Business Associate Subcontractors | Since the HITECH Act of 2009 and the Omnibus Rule of 2013, Business Associate obligations cascade downstream. If a Business Associate engages a subcontractor who will have access to PHI, that subcontractor is also directly subject to HIPAA's Security Rule and Breach Notification Rule — and must sign a Business Associate Agreement (BAA) with the Business Associate. | A cloud provider (Business Associate) that uses a third-party data centre (subcontractor). A software vendor (Business Associate) that uses a cloud database service (subcontractor). A managed security provider (Business Associate) that subcontracts SOC operations (subcontractor). The chain extends as far as PHI access extends. |
The practical implication is significant: HIPAA does not only apply to hospitals and insurers. It applies to their entire supply chain — every vendor, contractor, and service provider that touches protected health information. The mechanism that makes this enforceable is the Business Associate Agreement (BAA), a legally binding contract between a Covered Entity and a Business Associate (or between a Business Associate and its subcontractor) that specifies how PHI will be handled, what security measures will be applied, how breaches will be reported, and what liability each party accepts. Without a BAA in place, a Covered Entity cannot lawfully share PHI with a third party — and the absence of a BAA is itself a HIPAA violation.
HIPAA protects a specific category of data: Protected Health Information (PHI). PHI is any individually identifiable health information that is created, received, maintained, or transmitted by a Covered Entity or Business Associate. The definition is broad and encompasses far more than medical records.
PHI includes any information that relates to an individual's past, present, or future physical or mental health condition, the provision of healthcare to the individual, or the past, present, or future payment for healthcare — when that information can be linked to a specific individual. The linkage is the critical element. A database of anonymised health statistics is not PHI. The same data linked to names, dates of birth, or medical record numbers is PHI and falls under HIPAA's full protection.
HIPAA defines 18 specific identifiers that, when associated with health information, make it PHI. These identifiers are the elements that connect health data to a specific individual:
When PHI is held or transmitted electronically — in databases, email systems, EHR platforms, cloud storage, mobile devices, or any digital medium — it becomes electronic Protected Health Information (ePHI), which is specifically subject to HIPAA's Security Rule. Given that virtually all modern healthcare data is electronic, the Security Rule is the regulation most relevant to information security professionals, penetration testers, and technology providers.
HIPAA's requirements are structured across three principal rules, each addressing a different dimension of healthcare data protection. Together, they form a comprehensive framework that governs how PHI is used, how it is secured, and what happens when those protections fail.
The Security Rule is the regulation most directly relevant to security engineering, IT operations, and penetration testing. It defines three categories of safeguards, each containing specific implementation specifications. Understanding these categories is essential for mapping HIPAA requirements to practical security controls and assessment activities.
| Safeguard Category | Scope | Key Requirements |
|---|---|---|
| Administrative Safeguards (§ 164.308) |
Policies, procedures, and organisational measures that manage the selection, development, implementation, and maintenance of security measures to protect ePHI. | Risk Analysis (Required) — conduct an accurate and thorough assessment of potential risks and vulnerabilities to ePHI. Risk Management (Required) — implement security measures sufficient to reduce risks to a reasonable and appropriate level. Sanction Policy (Required) — apply appropriate sanctions against workforce members who fail to comply. Information System Activity Review (Required) — regularly review audit logs, access reports, and security incident tracking. Workforce Security (Addressable) — implement procedures for authorisation and supervision of workforce access to ePHI. Security Awareness and Training (Addressable) — security reminders, protection from malicious software, login monitoring, and password management training. Contingency Plan (Required) — data backup, disaster recovery, and emergency mode operation plans. |
| Physical Safeguards (§ 164.310) |
Physical measures, policies, and procedures to protect electronic information systems, buildings, and equipment from natural and environmental hazards and unauthorised intrusion. | Facility Access Controls (Addressable) — contingency operations, facility security plan, access control and validation procedures, and maintenance records. Workstation Use (Required) — policies specifying the proper functions to be performed and the manner in which those functions are performed at workstations accessing ePHI. Workstation Security (Required) — physical safeguards that restrict access to authorised users. Device and Media Controls (Required/Addressable) — disposal, media reuse, accountability, and data backup and storage procedures for hardware and electronic media containing ePHI. |
| Technical Safeguards (§ 164.312) |
Technology and the policies and procedures for its use that protect ePHI and control access to it. These are the controls most directly assessed during penetration testing and security assessments. | Access Control (Required) — unique user identification, emergency access procedures, automatic logoff, and encryption and decryption of ePHI. Audit Controls (Required) — hardware, software, and procedural mechanisms to record and examine activity in systems containing ePHI. Integrity Controls (Addressable) — mechanisms to authenticate ePHI and protect it from improper alteration or destruction. Authentication (Required) — verify that a person or entity seeking access to ePHI is who they claim to be. Transmission Security (Addressable) — integrity controls and encryption to protect ePHI during electronic transmission. |
This is the most commonly misunderstood aspect of the HIPAA Security Rule. An 'addressable' implementation specification must still be assessed. The organisation must determine whether it is a reasonable and appropriate safeguard in its environment. If it is, it must be implemented. If it is not, the organisation must document why it is not reasonable and appropriate and implement an equivalent alternative measure that achieves the same protection objective. 'We decided not to implement it' is not compliant — 'We assessed it, determined it was not appropriate because [documented rationale], and implemented [alternative measure] instead' is compliant.
The HIPAA Security Rule's single most important requirement is the Risk Analysis (§ 164.308(a)(1)(ii)(A)). It is required, not addressable. It is the foundation upon which every other security control decision rests. And it is, by a significant margin, the most frequently cited deficiency in HHS enforcement actions.
The risk analysis must be accurate and thorough — not a checkbox exercise, not a one-time event, and not a document that sits in a drawer until an auditor asks for it. HHS expects the risk analysis to identify all systems that create, receive, maintain, or transmit ePHI; identify and assess all reasonably anticipated threats and vulnerabilities to those systems; assess the likelihood and impact of each identified threat exploiting each identified vulnerability; determine the level of risk to ePHI based on that assessment; and document the analysis, including the methodology used and findings produced.
The risk analysis must also be ongoing. HIPAA does not specify a frequency — it says the risk analysis must be updated 'periodically' and whenever there are significant changes to the environment. In practice, this means the analysis should be reviewed at least annually and updated whenever new systems are deployed, significant infrastructure changes occur, new threats emerge, or a security incident reveals previously unidentified risks. An organisation whose most recent risk analysis is three years old and does not account for its current cloud infrastructure, remote working environment, or recent security incidents has a significant compliance gap — and it is exactly this gap that HHS investigators look for first.
This is where penetration testing connects directly to HIPAA compliance. A penetration test is one of the most effective methods for identifying threats and vulnerabilities to systems containing ePHI — the exact activity that the risk analysis requires. While HIPAA does not explicitly mandate penetration testing by name, the requirement to conduct an accurate and thorough risk analysis, to identify vulnerabilities, and to test security controls effectively necessitates technical assessment activities that include, or are equivalent to, penetration testing. HHS guidance and enforcement patterns make clear that organisations relying solely on paper-based risk assessments without technical validation are not meeting the standard.
HIPAA does not use the term 'penetration testing' anywhere in its regulatory text. This leads some organisations to conclude that penetration testing is not required. That conclusion is incorrect — not because HIPAA mandates penetration testing by name, but because the security activities HIPAA does mandate cannot be adequately fulfilled without technical testing that includes, at minimum, vulnerability assessment and, for any reasonably mature programme, penetration testing.
| HIPAA Requirement | What It Demands | How Penetration Testing Fulfils It |
|---|---|---|
| Risk Analysis § 164.308(a)(1)(ii)(A) |
Conduct an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. | Penetration testing identifies real, exploitable vulnerabilities in systems that store, process, or transmit ePHI — providing empirical evidence of risk that a paper-based assessment cannot. A penetration test against an EHR system that reveals an SQL injection vulnerability exposing patient records is a finding that directly informs the risk analysis with concrete, validated evidence. |
| Risk Management § 164.308(a)(1)(ii)(B) |
Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. | Penetration testing validates whether implemented security measures actually work in practice — not just whether they exist in policy. A firewall rule that should prevent access to an ePHI database can be verified through testing. Retesting after remediation confirms that fixes are effective. |
| Evaluation § 164.308(a)(8) |
Perform a periodic technical and non-technical evaluation to establish the extent to which security policies and procedures meet the requirements of the Security Rule. | Penetration testing is the definitive form of technical evaluation — it tests the security posture of ePHI systems against realistic attack scenarios, revealing gaps between policy (what should be protected) and practice (what is actually protected). This directly satisfies the requirement for periodic technical evaluation. |
| Access Control § 164.312(a)(1) |
Implement technical policies and procedures to allow access to ePHI only to those persons or software programmes that have been granted access rights. | Penetration testing verifies access controls by attempting to access ePHI without proper authorisation — testing authentication mechanisms, privilege escalation paths, session management, and segregation of duties. Findings reveal whether access controls function as intended under adversarial conditions. |
| Audit Controls § 164.312(b) |
Implement hardware, software, and procedural mechanisms to record and examine activity in systems containing ePHI. | Penetration testing reveals whether audit controls detect security-relevant events. If a tester achieves unauthorised access to ePHI and no audit log records the access, the audit control has failed — a finding that is only discoverable through active testing. |
| Transmission Security § 164.312(e)(1) |
Implement technical security measures to guard against unauthorised access to ePHI being transmitted over an electronic communications network. | Penetration testing assesses transmission security by attempting to intercept or access ePHI in transit — testing encryption implementation, certificate validation, protocol security (TLS versions and cipher suites), and network segmentation that protects ePHI data flows. |
Beyond these specific mappings, HHS enforcement actions consistently reference the absence of technical testing as evidence of non-compliance. Settlement agreements and Corrective Action Plans frequently require organisations to conduct or commission independent technical assessments — including vulnerability scanning and penetration testing — as part of their remediation. The regulatory expectation, even if not expressed as a named mandate, is clear: if you hold ePHI, you must technically validate the security of the systems that hold it.
HIPAA enforcement is conducted by the HHS Office for Civil Rights, which investigates complaints, conducts compliance reviews, and has the authority to impose civil monetary penalties. Enforcement has intensified significantly since the HITECH Act of 2009, which increased penalty amounts, extended liability to Business Associates, and introduced a tiered penalty structure based on the level of culpability.
| Penalty Tier | Knowledge Level | Penalty Per Violation | Annual Maximum |
|---|---|---|---|
| Tier 1 | The entity did not know and, by exercising reasonable diligence, would not have known that a violation occurred. | $137 – $68,928 | $2,067,813 |
| Tier 2 | The violation was due to reasonable cause and not wilful neglect. | $1,379 – $68,928 | $2,067,813 |
| Tier 3 | The violation was due to wilful neglect that was corrected within 30 days of discovery. | $13,785 – $68,928 | $2,067,813 |
| Tier 4 | The violation was due to wilful neglect that was not corrected within 30 days. | $68,928 – $2,067,813 | $2,067,813 |
These penalty amounts are adjusted annually for inflation (the figures above reflect 2024 adjustments) and apply per violation category per year. A single breach can involve multiple violation categories — for example, failure to conduct a risk analysis, failure to implement access controls, failure to encrypt ePHI, and failure to notify affected individuals within 60 days. Each of these is a separate violation category with its own penalty calculation. Large-scale breaches involving multiple years of non-compliance can result in settlements measured in millions of dollars.
Beyond financial penalties, HHS frequently requires Corrective Action Plans (CAPs) — multi-year agreements that mandate specific remediation activities, ongoing monitoring, and regular reporting to HHS. A typical CAP requires the organisation to conduct a comprehensive risk analysis, develop and implement a risk management plan, revise policies and procedures, implement technical safeguards including independent security assessments, train all workforce members, and submit regular compliance reports to HHS for a period of two to three years. The operational burden of a CAP often exceeds the financial penalty in terms of cost and resource commitment.
For the most egregious violations — particularly those involving wilful neglect or criminal conduct — the Department of Justice can pursue criminal prosecution. Criminal penalties include fines up to $250,000 and imprisonment up to ten years for offences committed with intent to sell, transfer, or use PHI for commercial advantage, personal gain, or malicious harm.
Analysis of HHS enforcement actions, settlement agreements, and published breach investigations reveals a consistent pattern of failures. These are not exotic, sophisticated security failures — they are fundamental control gaps that persist because organisations either do not understand their obligations or do not invest sufficient effort in meeting them.
Organisations subject to HIPAA are frequently also subject to other regulatory and industry frameworks. Understanding the overlaps and differences helps organisations build unified compliance programmes rather than duplicating effort.
| Framework | Relationship to HIPAA | Key Differences |
|---|---|---|
| UK/EU GDPR | Significant overlap in principles — both require lawful basis for processing, data minimisation, security measures, breach notification, and individual rights. An organisation processing health data of EU/UK residents for a US healthcare entity may be subject to both HIPAA and GDPR simultaneously. | GDPR has broader scope (all personal data, not just health data), stricter consent requirements, a more prescriptive breach notification timeline (72 hours vs 60 days), the right to erasure (which can conflict with HIPAA record retention requirements), and extraterritorial application based on data subject location rather than entity type. GDPR also classifies health data as a special category requiring additional protections. |
| PCI DSS | Minimal regulatory overlap — PCI DSS governs payment card data, HIPAA governs health data. However, healthcare organisations that process payments (patient billing, insurance co-payments) may be subject to both. The security controls required by each have significant overlap in practice: access control, encryption, audit logging, vulnerability management, and penetration testing. | PCI DSS is prescriptive about specific technical requirements (quarterly vulnerability scans, annual penetration tests by qualified assessors). HIPAA is performance-based — it says what outcomes must be achieved but allows flexibility in how. PCI DSS explicitly mandates penetration testing; HIPAA effectively requires it through its risk analysis and evaluation provisions without naming it. |
| NIST Cybersecurity Framework | HHS has published a crosswalk mapping HIPAA Security Rule requirements to the NIST Cybersecurity Framework (CSF). Many healthcare organisations use NIST CSF as their implementation framework for achieving HIPAA compliance, as NIST's controls provide the specific technical guidance that HIPAA's performance-based requirements leave to the implementer. | NIST CSF is a voluntary framework (unless mandated by contract or regulation), while HIPAA is legally binding. NIST provides more granular, actionable technical guidance. Using NIST CSF as the implementation mechanism for HIPAA compliance is a widely accepted and recommended approach. |
| SOC 2 | Many Business Associates pursue SOC 2 Type II attestation to demonstrate their security posture to healthcare clients. SOC 2's Trust Service Criteria (security, availability, processing integrity, confidentiality, privacy) overlap substantially with HIPAA's security requirements. A SOC 2 report provides independent assurance — but it does not replace HIPAA compliance. | SOC 2 is an attestation based on an auditor's assessment against defined criteria. HIPAA compliance is a legal obligation assessed against specific regulatory requirements. A SOC 2 report can support HIPAA compliance by providing evidence of controls, but it is not a HIPAA certification (no such certification exists) and does not guarantee HIPAA compliance. |
| HITRUST CSF | HITRUST Common Security Framework was specifically designed to harmonise healthcare compliance requirements. It incorporates HIPAA, NIST, ISO 27001, PCI DSS, and other frameworks into a single certifiable framework. HITRUST certification is increasingly requested by healthcare organisations as evidence of Business Associate compliance. | HITRUST provides the prescriptive control requirements that HIPAA lacks — specifying exactly what must be implemented rather than just what outcomes must be achieved. HITRUST certification requires independent assessment and is valid for two years. It is the closest thing to a 'HIPAA certification' that exists, though it encompasses requirements beyond HIPAA alone. |
UK-based organisations are increasingly encountering HIPAA obligations as they provide services to US healthcare entities. The scenarios where HIPAA applies to a UK organisation are more common than many assume.
For UK organisations subject to both HIPAA and UK GDPR, the practical approach is to implement the stricter requirement in each area — which varies by control. GDPR is stricter on consent and individual rights. HIPAA is more specific on security safeguards and breach risk assessment. Both require security measures appropriate to the risk, both require breach notification (GDPR's 72-hour timeline is significantly tighter than HIPAA's 60-day window), and both impose substantial penalties for non-compliance. Organisations that build their security programme to satisfy the more demanding requirement in each category will typically achieve compliance with both.
HIPAA compliance is not a one-time project — it is an ongoing programme that must be maintained, reviewed, and updated as the environment, threat landscape, and regulatory expectations evolve. The following guidance provides a practical starting point for organisations that are building or improving their HIPAA compliance programme.
HIPAA is the US federal framework for protecting healthcare data — but its reach extends far beyond US borders and far beyond the healthcare industry itself. Any organisation that creates, receives, maintains, or transmits protected health information on behalf of a US healthcare entity is subject to HIPAA's requirements, regardless of location. The Business Associate mechanism ensures that HIPAA obligations cascade through the entire supply chain, from the hospital to the cloud provider to the cloud provider's subcontractor.
The Security Rule is the component most relevant to information security professionals. Its requirements for risk analysis, access control, audit logging, encryption, transmission security, and periodic evaluation map directly to security testing activities — and while HIPAA does not mandate penetration testing by name, the standard of security assessment it requires effectively necessitates technical testing as part of any credible compliance programme. HHS enforcement actions consistently cite absent or inadequate risk analysis, missing technical safeguards, and failure to validate security controls as the basis for penalties — failures that competent penetration testing and vulnerability assessment would identify and enable the organisation to remediate.
The penalties for non-compliance are substantial — up to $2.13 million per violation category per year, plus criminal prosecution for egregious offences. But the reputational and operational impact of a healthcare data breach often exceeds the regulatory penalty. Patient trust, once lost, is exceptionally difficult to rebuild. HHS publishes all major breaches on a permanent public portal. Corrective Action Plans impose years of mandated remediation and reporting. The cost of non-compliance, measured in financial penalties, operational disruption, reputational damage, and regulatory oversight, vastly exceeds the cost of building and maintaining a robust compliance programme. For organisations that handle US healthcare data, HIPAA compliance is not optional — and the foundation of that compliance is understanding what the regulation requires, conducting thorough and ongoing risk assessment, and technically validating that the security measures you have implemented actually protect the data they are supposed to protect.
Our penetration testing and security assessment services map directly to HIPAA Security Rule requirements — providing the technical validation that demonstrates your controls protect ePHI and that your risk analysis reflects reality, not assumption.