HIPAA compliance,
from risk analysis to BAA.

HIPAA is a 1996 US federal law. Its Administrative Simplification rules, written by the Department of Health and Human Services (HHS), set national standards for protecting health information: the Privacy Rule (in force since 2003), the Security Rule (since 2005), the Breach Notification Rule (added after the HITECH Act of 2009) and the Enforcement Rule. HIPAA compliance means having the safeguards, policies, contracts and records those rules require, and being able to show them to the HHS Office for Civil Rights (OCR), which enforces them. State Attorneys General can enforce HIPAA too.

• Covered entities: health plans, healthcare clearinghouses, and healthcare providers that conduct standard transactions, such as billing insurers, electronically.
• Business associates: anyone that creates, receives, maintains or transmits protected health information on a covered entity's behalf. That includes cloud hosting, EHR and practice-management software, billing companies, IT providers and many SaaS tools. Since the 2013 Omnibus Rule, business associates are directly liable, and so are their subcontractors.

A consumer health app that people use on their own, with no covered entity involved, is often outside HIPAA, though state laws and the FTC may still apply. Our Do I need HIPAA? checker walks through the tests.

The Privacy Rule controls how PHI is used and disclosed. Uses for treatment, payment and healthcare operations are allowed without the patient's authorisation; most others, such as marketing, need it. The minimum necessary standard (164.502(b)) requires limiting PHI to what a task needs, which in practice means role-based access. Covered entities must give patients a notice of privacy practices and honour their rights, including access to their records within 30 days, extendable once by 30 days (164.524).

The risk analysis is the first required specification of the Security Rule (164.308(a)(1)(ii)(A)) and a failure OCR cites again and again in its settlements. It must be accurate and thorough, and cover all ePHI:

1. Find every place ePHI lives or moves: systems, databases, backups, laptops, vendors and integrations.
2. Identify threats and vulnerabilities for each, from ransomware and misconfiguration to lost devices and insider misuse.
3. Assess current controls, then rate likelihood and impact to get a risk level.
4. Write a risk management plan (164.308(a)(1)(ii)(B)) that reduces each risk to a reasonable and appropriate level, with owners and dates.
5. Document and repeat regularly and whenever systems change. A risk register keeps it current; see also risk assessment.

An impermissible use or disclosure of unsecured PHI is presumed to be a breach unless a documented four-factor risk assessment shows a low probability that the data was compromised (164.402). PHI encrypted to HHS guidance is not "unsecured". After a breach:

• Individuals: without unreasonable delay and no later than 60 calendar days after discovery.
• HHS: at the same time for breaches affecting 500 or more people; smaller breaches can be logged and reported within 60 days of the end of the calendar year.
• Media: prominent outlets when more than 500 residents of one state or jurisdiction are affected.
• Business associates must tell the covered entity within 60 days of discovery; most BAAs set a much shorter limit.

See incident management, the free incident response plan and the breach deadline calculator.

A covered entity may share PHI with a business associate only under a written contract that meets 164.504(e). A BAA must, among other things, limit the vendor's use of PHI to the contracted services, require Security Rule safeguards, require reporting of breaches and security incidents, flow the same terms down to subcontractors, support patients' access and amendment rights, make records available to HHS, and require return or destruction of PHI at the end. If you are a SaaS vendor selling to US healthcare, expect a customer's BAA in the first contract, and check that each of your own subprocessors that touches PHI has signed one with you. See vendor risk management.

1. Decide whether you are a covered entity, a business associate, or neither.
2. Name a privacy official and a security official.
3. Map where PHI and ePHI are created, stored and sent, including vendors.
4. Run and document the Security Rule risk analysis, and a risk management plan.
5. Implement the administrative, physical and technical safeguards: access control, MFA, encryption, audit logging, backups and a tested contingency plan.
6. Write the policies and procedures, and keep them for six years.
7. Train the workforce on hire and periodically, and apply sanctions for violations.
8. Sign BAAs with every business associate and subcontractor that touches PHI.
9. Apply minimum necessary access, and (covered entities) publish the notice of privacy practices.
10. Set up breach response with the 60-day clocks and the four-factor assessment.
11. Handle patient access requests within 30 days.
12. Evaluate the programme periodically and after major changes.

HIPAA is a law; SOC 2 is a voluntary attestation by a CPA firm. Healthcare customers often ask vendors for both: a signed BAA for the legal duty, and a SOC 2 report as independent evidence that controls work. The controls overlap heavily, so one control set can serve both.

HIPAA's requirements are modelled in TryTrustable's shared control library, mapped to the same controls as SOC 2, ISO 27001 and the other frameworks you run. Evidence from GitHub, AWS and GCP lands in a timestamped evidence ledger, policies live alongside the controls they support, risks sit in a register with owners and dates, and the vendor register tracks tiers, reviews and the evidence on file for each supplier. See framework coverage and the platform. A tool supports the programme; it does not make you HIPAA compliant by itself.