Skip to main content

​
Introduction

This module provides comprehensive checklists and frameworks to validate your organization’s compliance readiness. Use these as both a planning tool and an ongoing compliance verification resource.
HIPAA compliance checklist showing administrative, physical, technical safeguards and BAAs

HIPAA Compliance Readiness Checklist

Audit-Ready DocumentationThese checklists are designed to be audit-ready. Complete them thoroughly and maintain evidence for each item.

​
Business Associate Agreements (BAA)

​
Understanding BAAs

A Business Associate Agreement is a legally binding contract that ensures all parties handling PHI maintain appropriate safeguards.
Critical RequirementYou MUST have signed BAAs with EVERY vendor that can access, store, process, or transmit PHI before sharing any data with them.

​
When You Need a BAA

​
Common Vendors Requiring BAAs

​
BAA Essential Clauses Checklist

​
BAA Template Structure

​
Risk Assessment Framework

​
HIPAA Risk Assessment Checklist

HIPAA requires documented risk assessments. Use this comprehensive framework:
1

Scope Definition

Document what systems, applications, and processes handle PHI:
2

Threat Identification

Identify potential threats to PHI:
3

Vulnerability Assessment

Document current vulnerabilities:
4

Risk Analysis

Calculate risk levels:
5

Mitigation Planning

Create remediation plans for identified risks:

​
Technical Compliance Checklist

​
Access Control Checklist

​
Encryption Checklist

​
Audit Logging Checklist

​
Network Security Checklist

​
PDPL Compliance Checklist

​
Saudi PDPL Specific Requirements

​
Vendor Assessment Checklist

​
Pre-Engagement Security Assessment

​
Ongoing Vendor Monitoring

​
Incident Response Checklist

​
Breach Response Procedure

​
Breach Notification Templates

​
Compliance Documentation Inventory

​
Required Documentation Checklist

​
Compliance Calendar

​
Annual Compliance Activities

​
Quick Reference Cards

​
Emergency Contact Card

​
Developer Quick Reference

​
Module Summary

BAAs Protect You

Every vendor with PHI access needs a signed BAA before any data is shared

Risk Assessment

Regular, documented risk assessments are required, not optional

Documentation

If it’s not documented, it didn’t happen—maintain comprehensive records

Continuous Process

Compliance is ongoing—use the calendar to stay on track

​
Next Steps

1

Conduct Initial Assessment

Use the checklists to identify gaps in your current compliance posture
2

Prioritize Remediation

Focus on high-risk items first: encryption, access controls, BAAs
3

Build Documentation

Create all required policies and procedures
4

Implement Controls

Deploy technical controls following the implementation guide
5

Establish Ongoing Processes

Set up the compliance calendar and monitoring
Certification ConsiderationFor formal compliance validation, consider pursuing HITRUST certification, which combines HIPAA, NIST, and other frameworks into a single assessment.
Congratulations! You’ve completed the HIPAA Compliance course. You now have the knowledge and tools to build healthcare-ready applications that protect sensitive patient data.

​
Interview Deep-Dive

Strong Answer:
  • The five highest-priority items, based on OCR enforcement patterns: (1) A current, comprehensive risk assessment. This is the single most cited deficiency in OCR enforcement actions. If your risk assessment is more than 12 months old or does not cover all systems that handle ePHI, update it immediately. (2) Signed BAAs with every vendor that touches PHI. Pull the vendor inventory, match it to BAAs on file, and identify any gaps. A missing BAA is an easy finding for an auditor and demonstrates systemic negligence. (3) Policies and procedures documentation. HIPAA requires written policies covering all administrative, physical, and technical safeguards. These must be current (not from 2019), specific to your organization (not generic templates), and actually implemented (not just documented). (4) Workforce training records. Every employee who handles PHI must have documented HIPAA training, and it must be current (within the last 12 months). The auditor will ask to see training completion records. (5) Incident response documentation. Even if you have not had a breach, you need a written incident response plan, evidence of tabletop exercises or drills, and documentation of any security incidents and how they were handled.
  • The documentation package: risk assessment report with remediation tracker, complete vendor inventory with BAA status, policies and procedures manual, workforce training records with completion dates, incident response plan and drill records, system inventory showing all ePHI locations, access control documentation (who has access to what and why), audit log samples and integrity verification reports, and encryption documentation (what is encrypted, with what algorithm, key management procedures).
  • The 6-week timeline: weeks 1-2, conduct the gap analysis and prioritize findings. Weeks 3-4, remediate the highest-risk gaps (missing BAAs, outdated risk assessment, training gaps). Weeks 5-6, organize documentation, conduct a mock audit with an internal team, and prepare staff for auditor interviews.
Follow-up: The auditor asks to interview a random selection of your employees about HIPAA policies. What are you most worried about?I am most worried about frontline clinical staff (nurses, medical assistants, front desk) who may not articulate the policies even if they follow them in practice. The biggest exposure points: Can they explain what PHI is and give examples? Do they know the procedure for reporting a suspected breach (even a misdirected fax)? Can they describe who to contact if they witness a colleague accessing records improperly? Do they know the organization’s minimum necessary policy? The most damaging interview answer is not “I don’t know the exact policy” — it is “What training?” or “I’ve never heard of that.” To prepare, I would run a brief refresher session for all staff covering the top 10 things an auditor might ask, emphasizing practical knowledge over regulatory citations. I want every employee to be able to say: “I completed my annual HIPAA training on [date], I know to report incidents to [person], and I only access the patient information I need for my job.”
Strong Answer:
  • The key insight is that HIPAA and PDPL have significant overlap but critical differences, and you need to design for the superset of requirements — the stricter rule wins in each area.
  • Where they overlap (implement once): both require encryption for sensitive data, access controls, audit logging, breach notification, risk assessments, and workforce training. Your core security architecture (encryption, RBAC, audit logging) satisfies both.
  • Where PDPL is stricter: consent management. HIPAA allows PHI use for Treatment, Payment, and Operations without patient authorization. PDPL requires explicit consent for most processing, including healthcare. You need a consent management framework that tracks purpose-specific consent for Saudi patients even when US patients do not require it. Data localization: PDPL requires personal data of Saudi citizens to be stored within Saudi Arabia unless specific conditions are met. You may need a Saudi-region deployment (AWS Bahrain region or Azure UAE) with data residency controls. Right to erasure: PDPL grants a right to erasure that HIPAA does not (HIPAA has record retention requirements that may conflict). Your system needs the capability to delete Saudi patient data on request while retaining US patient data per HIPAA retention rules. Breach notification timeline: PDPL requires notification to the authority within 72 hours; HIPAA allows 60 days. Build to the 72-hour standard.
  • Where HIPAA is stricter: the 18-identifier PHI definition is more comprehensive than PDPL’s personal data definition in some aspects. HIPAA’s minimum necessary standard has no direct PDPL equivalent but is good practice regardless. HIPAA’s specific technical safeguard requirements (audit controls, integrity, transmission security) are more prescriptive.
  • Architecture approach: use a policy layer (OPA or similar) that evaluates patient jurisdiction and applies the appropriate rule set. Tag each patient record with its governing regulation. Implement consent as a first-class data model that tracks purpose, status, and withdrawal timestamp.
Follow-up: A Saudi patient requests that all their data be deleted under PDPL’s right to erasure. But HIPAA requires you to retain medical records. How do you resolve this conflict?This is one of the hardest cross-jurisdictional conflicts. The resolution depends on which regulation governs this specific patient. If the patient is in Saudi Arabia and the data is subject to PDPL, the PDPL right to erasure takes precedence for the Saudi entity. However, if the same data is held by a US entity subject to HIPAA, the retention requirement may override the erasure request. The practical approach: for the Saudi deployment, implement the erasure and document it. For any US copies, apply HIPAA’s retention rules and inform the patient that certain records are retained per US federal law. If both laws apply simultaneously (which is uncommon but possible in a truly multinational operation), consult legal counsel in both jurisdictions. The architectural mitigation is data sovereignty: Saudi patient data lives exclusively in the Saudi deployment and is governed solely by PDPL, while US patient data lives in the US deployment and is governed solely by HIPAA. Cross-border data sharing between the two deployments requires explicit patient consent under PDPL and a documented legal basis.
Strong Answer:
  • This checklist covers five dimensions: data handling, vendor compliance, access controls, documentation, and patient rights.
  • Data handling: What PHI enters the LLM? (Symptom descriptions, patient demographics, medical history.) Is the LLM hosted on-premise, in a BAA-covered cloud, or via a third-party API? If third-party, does the provider sign a BAA? Is PHI used for model training? (Must be prohibited or require explicit authorization.) Is data encrypted in transit to the LLM and at rest in any LLM storage? Is there a data retention policy for LLM inputs and outputs? Can you guarantee that PHI is not persisted in LLM logs or training data?
  • Vendor compliance: If using OpenAI, Anthropic, or similar — do they offer a BAA? What is their data retention policy? Is processing within the US or does it cross borders? Have they completed a SOC 2 Type II audit? What happens to data if the vendor is acquired or goes bankrupt?
  • Access controls: Who can use the symptom checker? (Only authenticated patients.) How is the LLM’s output handled? (It is not a medical diagnosis — proper disclaimers required.) Can the LLM access patient records beyond what the patient provides? (Should be limited to the current conversation.) Is there a human-in-the-loop for clinical recommendations?
  • Documentation: Risk assessment updated to include the AI feature. Data flow diagram showing PHI movement through the LLM pipeline. Privacy impact assessment. Updated Notice of Privacy Practices if AI processing was not previously disclosed. Updated BAA with the LLM provider. Audit logging for all AI interactions (who asked what, what was returned, when).
  • Patient rights: Can patients opt out of AI-assisted features? Are patients informed that their input is processed by AI? Can patients request deletion of their AI interaction history? Is there an accounting of disclosures that includes AI processing?
  • The launch gate: all items must be verified and documented before the feature goes live. Any open item is a launch blocker, not a follow-up.
Follow-up: The LLM occasionally hallucinates and provides medically inaccurate information. Is this a HIPAA issue or purely a clinical safety issue?It is primarily a clinical safety and medical malpractice issue, but it has HIPAA dimensions. If the LLM generates inaccurate health information and that information is stored in the patient’s record (because a clinician acts on it), you have integrity issues — the patient’s record now contains inaccurate data, and the patient has a right to request amendment. If the hallucinated response is disclosed to the patient as medical guidance, there are liability implications beyond HIPAA. From a HIPAA compliance perspective, the audit log must capture the LLM’s output separately from clinician-verified documentation, so you can distinguish AI-generated content from clinical assessments. The risk assessment for the feature must document hallucination as a known risk with mitigations: disclaimers to patients, human review before clinical action, confidence thresholds below which the AI defers to a provider, and monitoring for systematically inaccurate outputs.