HIPAA Compliance for Software Vendors: Security Rule, BAAs and Breaches

HIPAA compliance is a legal duty for US healthcare organisations and for every vendor that creates, receives, maintains or transmits protected health information (PHI) on their behalf. That second group is large: EHR and practice management software, telehealth platforms, patient apps sold to providers, billing services, cloud hosting, analytics, and IT service firms anywhere in the world that work on systems containing PHI.

This guide explains who HIPAA covers, what makes a vendor a business associate, the Privacy, Security and Breach Notification Rules, the documents and safeguards an audit or a customer will look for, the penalties, and the engineering work behind a product that can be used with PHI. It reflects the rules in force at the review date. HHS proposed a major update to the Security Rule in January 2025; at our last review it had not been finalised, and we will update this guide when it is.

What is HIPAA?

HIPAA is the Health Insurance Portability and Accountability Act of 1996, a US federal statute. Its "Administrative Simplification" provisions told HHS to set national standards for electronic healthcare transactions and for the privacy and security of health information. HHS did so through regulations now found in 45 CFR Parts 160 and 164, usually called the HIPAA Rules:

• Privacy Rule: when PHI may be used and disclosed, the minimum necessary standard, and patients' rights to access, amend and get an accounting of disclosures.
• Security Rule: administrative, physical and technical safeguards for electronic PHI (ePHI).
• Breach Notification Rule: notice to individuals, HHS and sometimes the media after a breach of unsecured PHI.
• Enforcement Rule: investigations, civil money penalties and hearings.

Protected health information is individually identifiable health information held or transmitted by a covered entity or business associate, in any form. It includes demographic data, medical records, test results, insurance details and payment information when linked to health care. Health information that has been de-identified under the Privacy Rule's standards (45 CFR 164.514) is not PHI.

History and why HIPAA was introduced

HIPAA was enacted in 1996, primarily to protect health insurance coverage for workers changing jobs and to reduce administrative costs by standardising electronic transactions. Congress recognised that moving health data into electronic systems created privacy risks, so it required privacy and security standards. HHS issued the Privacy Rule with compliance required from 2003 and the Security Rule with compliance from 2005 for most covered entities.

The HITECH Act of 2009 strengthened HIPAA: it made business associates directly liable for compliance with the Security Rule and parts of the Privacy Rule, created the Breach Notification Rule, and increased penalties. HHS implemented these changes in the 2013 Omnibus Rule, which is why vendor obligations look the way they do today.

In January 2025, HHS published a proposed rule to modernise the Security Rule, including removing the distinction between "required" and "addressable" specifications and adding specific requirements such as asset inventories, multi-factor authentication and encryption. The federal regulatory agenda later moved the expected final rule to 2027. Until a final rule is published and takes effect, the current Security Rule applies.

Who needs to comply with HIPAA?

Covered entities

• Health plans, including health insurers, HMOs and employer group health plans.
• Healthcare clearinghouses.
• Healthcare providers that transmit health information electronically in connection with standard transactions, such as claims.

Business associates

A business associate (45 CFR 160.103) is a person or organisation that performs functions or services for a covered entity involving the use or disclosure of PHI. Subcontractors of business associates that handle PHI are business associates too. For IT companies, this includes:

• SaaS products used by providers or plans with patient data: EHR, scheduling, telehealth, care coordination, billing, patient engagement.
• Cloud service providers hosting ePHI, even if the data is encrypted and the provider has no key. HHS's cloud computing guidance says such a provider is still a business associate.
• Software development and IT support firms with access to systems containing PHI.
• Analytics, AI and data processing vendors working on PHI for a covered entity.

Who is not covered

A consumer health app that people download and use on their own, without a covered entity involved, is generally not covered by HIPAA. That does not mean it is unregulated: the US Federal Trade Commission enforces its Health Breach Notification Rule and unfair practices law against such apps, and state laws may apply. The test is the relationship with a covered entity, not the type of data.

Geography

HIPAA is US law. A vendor outside the US becomes bound by it through business associate agreements and, through HITECH, is directly liable for its obligations as a business associate, although practical enforcement against foreign entities is harder. US covered entities often require offshore vendors to accept additional contractual controls.

Key requirements: the Privacy Rule

• Permitted uses and disclosures: for treatment, payment and healthcare operations, as required by law, and in other listed situations; most other uses need the individual's authorisation.
• Minimum necessary: use, disclose and request only the minimum PHI needed for the purpose, with exceptions such as disclosures for treatment.
• Individual rights: access to their records (generally within 30 days, extendable once by 30 days), amendment, an accounting of certain disclosures, restrictions, and confidential communications.
• Notice of privacy practices from covered entities.
• Business associates may use and disclose PHI only as their contract allows or the law requires.

For software, the Privacy Rule shows up as role-based access that enforces minimum necessary, export functions that support patient access requests, and logs that support accountings of disclosures.

Key requirements: the Security Rule

The Security Rule applies to ePHI and requires covered entities and business associates to ensure its confidentiality, integrity and availability, protect against reasonably anticipated threats, and ensure workforce compliance (45 CFR 164.306). It is flexible: you choose measures appropriate to your size, complexity, capabilities and risks. Implementation specifications are either required or addressable; an addressable specification is not optional, but you may implement an equivalent alternative or document why it is not reasonable and appropriate.

Administrative safeguards (164.308)

• Security management process: risk analysis (required), risk management (required), sanction policy, and information system activity review.
• Assigned security responsibility: a named security official.
• Workforce security and information access management: authorisation, clearance, termination procedures, access granting and modification.
• Security awareness and training, including password management, log-in monitoring and malware protection.
• Security incident procedures: identify, respond, mitigate and document.
• Contingency plan: data backup, disaster recovery and emergency mode operation plans (required), plus testing and criticality analysis (addressable).
• Periodic evaluation of the safeguards.
• Business associate contracts.

Physical safeguards (164.310)

Facility access controls, workstation use and security, and device and media controls, including disposal and re-use. For cloud-hosted products, much of this sits with the hosting provider, but your offices, laptops and removable media remain yours.

Technical safeguards (164.312)

Standard	Specifications	What it means in a product
Access control	Unique user identification (required), emergency access procedure (required), automatic logoff (addressable), encryption and decryption (addressable)	No shared accounts, break-glass access, session timeouts, encryption at rest
Audit controls	Required	Record and examine activity in systems containing ePHI: who viewed or changed which record
Integrity	Mechanism to authenticate ePHI (addressable)	Protect records from improper alteration or destruction; checksums, versioning, write controls
Person or entity authentication	Required	Verify users are who they claim; MFA is the modern expectation
Transmission security	Integrity controls and encryption (addressable)	TLS for all traffic, secure APIs and integrations

Organisational and documentation requirements (164.314 and 164.316)

Business associate contracts must contain specific terms, and policies, procedures and required documentation must be kept in written (which can be electronic) form for six years from creation or last effective date, and reviewed and updated periodically.

Business associate agreements

Before a business associate receives PHI, it must sign a business associate agreement (BAA) with the covered entity (or, for a subcontractor, with the business associate above it). Under 45 CFR 164.504(e) and 164.314(a), the agreement must, among other things:

• State the permitted uses and disclosures of PHI.
• Require appropriate safeguards and compliance with the Security Rule for ePHI.
• Require reporting of uses or disclosures not provided for by the contract, including breaches of unsecured PHI and security incidents.
• Require subcontractors to agree to the same restrictions.
• Make PHI available for patient access and amendment and for accountings of disclosures, where applicable.
• Make internal practices and records available to HHS.
• Require return or destruction of PHI at termination where feasible.

HHS publishes sample BAA provisions. Large customers usually have their own template. Before signing, check that your product and processes can actually meet the reporting deadlines and audit rights the customer asks for, which are often stricter than the regulation.

Breach notification

A breach is an impermissible use or disclosure that compromises the security or privacy of PHI. An impermissible use or disclosure is presumed to be a breach unless a documented four-factor risk assessment shows a low probability that the PHI has been compromised. Breaches of PHI that was encrypted in line with HHS guidance are not "unsecured" and do not require notification.

• Individuals: without unreasonable delay and no later than 60 calendar days after discovery.
• HHS: for breaches affecting 500 or more individuals, at the same time as individual notice; for fewer than 500, within 60 days after the end of the calendar year in which they were discovered.
• Media: for breaches affecting more than 500 residents of a state or jurisdiction.
• Business associates must notify the covered entity without unreasonable delay and no later than 60 days after discovery, with the identities of affected individuals where possible. BAAs often shorten this.

How to implement HIPAA compliance step by step

1. Confirm your status: covered entity, business associate, subcontractor, or none, for each product and customer.
2. Map PHI flows: where PHI enters, where it is stored, who and what can access it, which vendors receive it.
3. Appoint a security official and a privacy official.
4. Run a risk analysis across all ePHI, documenting threats, vulnerabilities, likelihood, impact and current controls. HHS guidance and NIST SP 800-66 Rev. 2 describe the method. OCR enforcement actions repeatedly cite missing or inadequate risk analyses.
5. Write a risk management plan and implement safeguards, documenting decisions on each addressable specification.
6. Build the technical safeguards into the product: unique IDs, role-based access, MFA, session timeouts, encryption at rest and in transit, audit logging of PHI access, integrity controls, secure backups and tested restores.
7. Sign BAAs with customers, and with every vendor that touches PHI: hosting, email, support desk, logging, analytics, AI services. If a vendor will not sign, keep PHI away from it.
8. Write policies and procedures and keep them for six years.
9. Train the workforce and apply sanctions for violations.
10. Prepare incident and breach procedures, including the four-factor assessment and notification templates.
11. Review periodically: re-run the risk analysis when systems change, and evaluate safeguards.

Documentation and policies required

• Risk analysis and risk management plan.
• Security policies and procedures covering each standard in 164.308 to 164.312, with decisions on addressable specifications.
• Privacy policies and procedures (for covered entities, and for business associates as their contracts require).
• Business associate agreements, including with subcontractors.
• Workforce training records and sanction policy.
• Information system activity reviews and audit log retention.
• Contingency plan: backup, disaster recovery, emergency mode operations, and test records.
• Security incident and breach records, including risk assessments for incidents not notified.
• Evaluation reports.

All required documentation must be retained for six years (45 CFR 164.316(b)(2)).

Audits, assessments and certification

There is no official HIPAA certification. HHS states that it does not endorse or recognise private certifications. OCR enforces HIPAA through complaint investigations, compliance reviews (often after a reported breach) and periodic audit programs.

Customers will still want evidence. Common options are an independent HIPAA security assessment, a SOC 2 report (some firms issue "SOC 2+ HIPAA" reports mapping the Security Rule), and HITRUST certification, which many US health systems ask vendors for.

Timeline and cost considerations

There is no transition period: the rules apply as soon as you handle PHI for a covered entity. The effort depends on how much PHI you handle, how many systems and vendors touch it, whether the product was designed with audit logging and access control from the start, and how much documentation exists. Cost drivers include the risk analysis, engineering work on technical safeguards, vendors that offer BAAs (often on higher-priced plans), logging and monitoring tools, training, legal review of BAAs, and optional assessments such as HITRUST or SOC 2.

Benefits and consequences of non-compliance

Compliance is the price of entry to the US healthcare market for software vendors, and the safeguards it requires reduce the likelihood and impact of breaches, which in healthcare are frequent and costly to handle.

Penalties are serious. Civil money penalties are set in four tiers based on culpability, from lack of knowledge to wilful neglect not corrected, with per-violation amounts and calendar-year caps that HHS adjusts for inflation each year (published in 45 CFR 102.3). OCR also settles cases through resolution agreements with payments and corrective action plans that run for years. Criminal penalties under 42 U.S.C. 1320d-6, enforced by the Department of Justice, reach fines of up to 250,000 dollars and up to ten years in prison for offences committed with intent to sell or use PHI for commercial advantage or malicious harm. State attorneys general can also bring civil actions under HITECH.

Common mistakes and challenges for IT companies

• No real risk analysis. A checklist or a vendor's security questionnaire is not a risk analysis of your environment.
• PHI in tools without a BAA. Error trackers, log platforms, support desks, email services and AI APIs often receive PHI in payloads. Scrub data before it leaves, or use vendors that sign BAAs.
• Treating "addressable" as optional. You must implement it, implement an equivalent, or document why neither is reasonable.
• Audit logs that do not capture reads. The audit controls standard is about activity, and viewing a record is activity.
• PHI in non-production environments. Test and staging databases copied from production carry the same obligations. Use synthetic or de-identified data.
• Assuming encryption removes HIPAA. Encryption is a safeguard and can avoid breach notification, but a vendor storing encrypted PHI is still a business associate.
• Calling the product "HIPAA certified". There is no such certification; marketing that implies one invites trouble.

Best practices, tools and technologies

• Host on cloud services covered by the provider's BAA and use only the services listed as eligible.
• Enforce SSO with MFA for staff, and MFA options for customer users.
• Encrypt ePHI at rest with managed keys and in transit with modern TLS; consider field-level encryption for the most sensitive data.
• Build an immutable, queryable audit trail of PHI access and changes, retained for at least six years where documentation rules apply to it.
• Use role-based access with patient-level or organisation-level scoping to enforce minimum necessary.
• Integrate through standards such as HL7 FHIR with OAuth 2.0 scopes rather than shared credentials.
• Scan for PHI in logs, analytics and error reports before they leave your environment.
• Use NIST SP 800-66 Rev. 2 as the reference for mapping safeguards, and a NIST CSF or ISO/IEC 27001 programme to run them.

Our healthcare software work is built around these safeguards, and our integration team handles EHR and FHIR connections.

How HIPAA relates to other frameworks

Framework	Relationship
HITECH Act	Amended HIPAA: business associate liability, breach notification, higher penalties.
HITRUST CSF	Voluntary certifiable framework that includes HIPAA requirements; widely requested by US health systems.
SOC 2	Attestation that can be extended with HIPAA criteria.
NIST SP 800-53 and NIST SP 800-66	NIST maps Security Rule standards to its controls and the CSF.
21 CFR Part 11	FDA rules on electronic records and signatures in regulated activities; separate from HIPAA.
Cures Act information blocking	Rules against unreasonably blocking access to electronic health information; interacts with HIPAA permissions.
GDPR and DPDP Act	Apply to health data of people in the EU and India respectively; HIPAA compliance does not satisfy them.

Real-world enforcement examples

OCR publishes resolution agreements and civil money penalties on the HHS website. One of the largest settlements followed the 2015 cyberattack on Anthem, which exposed the PHI of nearly 79 million people: in 2018 Anthem agreed to pay 16 million dollars and take corrective action. OCR's findings included failure to conduct an enterprise-wide risk analysis and insufficient procedures to review system activity, the same themes that appear in many smaller cases.

OCR has also run enforcement initiatives on the right of access, resolving many cases where providers failed to give patients timely copies of their records, and on risk analysis. For a vendor, the lesson is that the basics (a real risk analysis, activity review, access requests handled on time) are what enforcement checks first.

Next steps

1. Confirm whether you are a business associate for each customer and product.
2. Map PHI and remove it from systems and vendors that do not need it.
3. Run and document a risk analysis.
4. Close gaps in the technical safeguards in your product.
5. Sign BAAs downstream and upstream, then write and train on policies.
6. Get legal advice on BAAs and on state health privacy laws.

If the gaps are in the product, tell us what you are building.

Frequently asked questions

Is there a HIPAA certification?

No. HHS does not certify compliance or endorse private certifications. Vendors show compliance through risk analyses, policies, BAAs and independent assessments such as SOC 2 or HITRUST.

Does HIPAA apply to software vendors?

Yes, when the vendor creates, receives, maintains or transmits PHI on behalf of a covered entity or another business associate. The vendor is then a business associate and must comply with the Security Rule and the terms of its BAA.

Does HIPAA apply to companies outside the United States?

A foreign vendor handling PHI for a US covered entity is a business associate and is bound by its BAA. HITECH makes business associates directly liable, although enforcement abroad is more complicated.

Is a cloud provider a business associate if the data is encrypted?

Yes. HHS guidance says a cloud provider that maintains ePHI is a business associate even if it cannot decrypt the data.

Does HIPAA require encryption?

Encryption is an addressable specification under the current Security Rule. In practice it is expected, and properly encrypted PHI is not "unsecured" for breach notification purposes. The 2025 proposed rule would make encryption required, with limited exceptions.

How quickly must a HIPAA breach be reported?

To individuals without unreasonable delay and within 60 calendar days of discovery. Large breaches are reported to HHS at the same time; smaller ones annually. Business associates must notify the covered entity within 60 days, or sooner if the BAA says so.

Are health apps covered by HIPAA?

Only when they handle PHI for a covered entity or business associate. A direct-to-consumer app is usually outside HIPAA but may fall under the FTC Health Breach Notification Rule and state laws.

What is the difference between required and addressable specifications?

Required specifications must be implemented. Addressable ones must be implemented if reasonable and appropriate; otherwise you implement an equivalent measure or document why neither is reasonable.

How long must HIPAA documentation be kept?

Six years from the date of creation or the date it was last in effect, whichever is later.

What changed with the 2025 proposed Security Rule?

HHS proposed removing the addressable category, requiring an asset inventory and network map, MFA, encryption, vulnerability scanning and penetration testing, and setting restore timelines, among other changes. It is a proposal; check this guide's review date for its status.

Can we use AI services with PHI?

Only if the service provider signs a BAA and its service is eligible under that BAA, and only in line with minimum necessary. Otherwise de-identify the data under 45 CFR 164.514 first.

Does de-identified data fall under HIPAA?

No. Data de-identified by the safe harbor method (removing the listed identifiers with no actual knowledge of re-identification risk) or by expert determination is not PHI.