I treat an internal HIPAA audit as a test of how PHI is protected - not a compliance certificate. My starting point: confirm the rules that apply, assign owners, and define what to test. This often requires a unified RiskOps approach to coordinate departments. For each finding, I record the gap, risk, owner, deadline, and retest method.
Here’s the 10-step workflow I use:
- Set the scope: Define systems, requirements, samples, and testing limits.
- Map ePHI: Trace where data moves, stays, and gets deleted.
- Review risks: Check risk ratings, mitigation plans, and accepted risks.
- Test safeguards: Check staff procedures, physical security, and system settings.
- Validate records: Confirm that audit records support results for the period reviewed.
- Check access and logs: Review permissions, account removal, and suspicious activity.
- Compare policy with practice: Test whether staff follow written procedures.
- Check training: Review completion records and test staff understanding.
- Test response and recovery: Check incident handling, breach decisions, and actual restoration.
- Verify fixes: Retest controls before closing findings.
HIPAA does not require annual internal audits. I set the schedule based on risk and major changes, and retain required Security Rule documentation for six years from creation or its last effective date, whichever is later.
The goal is simple: <u>test what works, fix what doesn’t, and verify the fix</u>.
10-Step Internal HIPAA Audit Workflow
Confirm HIPAA Requirements and Assign Audit Roles
Organize the audit by HIPAA rule. Map each requirement to its citation, owner, evidence, and test method.
Determine whether the organization is a covered entity, business associate, or both. Then check BAA terms for permitted uses, safeguards, incident and breach reporting, and subcontractor flow-downs. A business associate must notify the covered entity of a breach without unreasonable delay and within 60 calendar days of discovery, or sooner if the contract sets a tighter deadline.[11][4][8]
Build the requirements matrix using current HHS guidance and OCR’s Audit Protocol. Check the latest HHS and Federal Register materials to confirm which requirements are effective as of October 9, 2026.[1][6] Label each item as effective, proposed, final but not yet effective, or future-dated so the team knows what applies to this review. Track proposed changes and future deadlines in a readiness register - not as current audit failures.
Name the privacy official, security official, and audit lead in the charter. Use a RACI matrix to assign responsibility for evidence collection, control validation, corrective-action approval, and escalation. Use that same matrix to route evidence requests and remediation approvals.
HIPAA does not require annual internal audits.[9][1] Set a risk-based audit schedule that accounts for current risks and major changes. Once scope and roles are set, identify the systems and ePHI data flows to test.
sbb-itb-535baee
1. Set the Audit Scope and Criteria
Purpose and Requirements
Use the requirements matrix to define what the audit covers - and what it leaves out. Write a scope statement that identifies the tests, exclusions, limitations, and testing boundaries. Missing evidence is an audit limitation, not proof that a control works. Use the scope to identify the systems and data flows to test.
Controls and Workflows
Include every in-scope system, third-party vendor, and business associate that creates, receives, stores, or transmits ePHI. Reset the scope after mergers, acquisitions, or the introduction of new clinical applications.[14] Use these systems and their dependencies as the basis for the ePHI map.
Evidence to Collect
Specify what evidence each control requires, such as asset inventories, data-flow diagrams, encryption validation reports, and incident response logs. Before testing begins, define the sampling approach, which records it covers, and why you chose it.[14]
Testing and Common Gaps
Define how reviewers will inspect configurations and sample logs. Cross-check inventories against data-flow diagrams to find omitted cloud services, legacy databases, removable media, backup media, mobile devices, and third-party systems. Record any missing evidence as a testing limitation.[14]
2. Map ePHI Systems and Data Flows
Purpose and Requirements
Map where ePHI is created, stored, transmitted, and disposed of across every in-scope system, vendor, and device. Start with the approved scope. Include EHRs, clinical applications, patient portals, laboratory and imaging systems, medical devices, cloud platforms, backups, email, file shares, and vendor-hosted services. HHS requires the risk analysis to identify where ePHI is stored, received, maintained, or transmitted.[9]
Controls and Workflows
Assign an owner to each system, repository, interface, and external connection. Record its location, owner, data type, connected systems, users, retention period, and function - whether it stores data, transmits it, or does both.
For each data flow, document the source, destination, transmission method, data elements, encryption, authentication, and retention or deletion rule. For external parties and devices, record the connection, data exchanged, vendor support access, hosting location, owner, BAA status and third-party risk, and key safeguards.[10]
Evidence to Collect
Keep the approved asset inventory; network, architecture, and data-flow diagrams; vendor lists; configuration exports; and system-owner attestations. Tag each item with its source, date, owner, scope, and version or hash.
Validate the map with system-generated records - not screenshots alone. HHS recommends inventories of hardware, software, and data assets, along with communication and data-flow mapping.[15] Use this map as the baseline for the control tests that follow.
Testing and Common Gaps
Trace selected workflows in both directions: from the clinical source to each recipient, then back to the originating system. Compare the inventory against technical discovery and records of system activity, including network traffic, identity-provider logs, cloud registrations, endpoint scans, mobile-device records, backup jobs, help-desk tickets, and staff interviews.
Look for unapproved cloud storage, personal email, local files, shared spreadsheets, messaging apps, legacy interfaces, and test environments containing production data. Reconcile every asset and material data flow with the risk analysis. Flag missing entries, connections without owners, and retired systems that still hold accessible ePHI.
3. Check Risk Analysis and Mitigation Plans
Purpose and Requirements
Check that the risk analysis covers confidentiality, integrity, and availability - not just privacy. Link each risk to a mapped system, interface, or data flow. For every material risk, record the threat, vulnerability, existing safeguards, likelihood, impact, and risk rating. Define the ratings and use them consistently. HIPAA does not require a specific scoring formula.
Controls and Workflows
Give each material risk a treatment decision, owner, resources, deadline, and effectiveness check. Record accepted risks with the rationale, residual risk, approver, compensating controls, and review or expiration date. Accepting a risk does not remove the duty to reduce it to a reasonable and appropriate level.
Require reassessment after material changes, such as new cloud services, connected medical devices, security incidents, or other major changes to how systems operate. Add a change-management gate that requires a security and privacy risk review before production deployment. Follow it with a post-implementation review.
Evidence to Collect
Collect the approved methodology, risk-register exports, mitigation plans, project tickets, acceptance approvals, governance minutes, and control-test results. Trace each risk to its corrective action and evidence of closure.
Track overdue high-risk items, remediation time, repeat findings, and the percentage of closed actions that passed independent validation.
Testing and Common Gaps
Sample high- and medium-risk entries, tracing them from assessment through residual-risk review. Independently inspect patch reports, access settings, or restoration-test results. A “complete” status alone is not enough.
Flag unsupported ratings, missing owners, overdue actions without escalation, undocumented acceptance, and assessments that were not updated after major changes to how systems operate.
Use the validated risk register to target the safeguard tests that follow.
4. Test Administrative, Physical, and Technical Safeguards
Purpose and Requirements
Use the validated risk register to prioritize testing of the highest-risk safeguards. Check that they work as intended in daily use - not just on paper. Addressable specifications still require a documented decision: record whether you implemented the safeguard, did not implement it, or used an equivalent control. Document automatic logoff and encryption decisions here. [14]
Controls and Workflows
Briefly check that staff understand security procedures and know how to report incidents. Walk through clinical areas to inspect badge access, workstation placement, and unsecured portable media, such as USB drives.
Review technical settings to confirm that automatic logoff and encryption are configured correctly. Spot-check active and terminated accounts to verify role-based access and timely removal of access. [14]
Evidence to Collect
Collect training records, access-review records, facility access logs, and encryption status reports for laptops, backups, and cloud storage. Include media destruction records with dates, methods, and staff signatures. Link each record to the asset or control tested. [14]
Testing and Common Gaps
Compare staff interview responses with written procedures, observed behavior, and system settings. Check for former employees’ accounts that remain active, unsafe workstation placement, unencrypted portable media, and unread unusual-access alerts.
Conduct quarterly access reviews and weekly high-risk log reviews, and review unusual-access alerts promptly. [14]
Use these control results to focus the evidence review in the next step.
5. Collect and Validate Audit Evidence
Purpose and Requirements
After control testing, gather records that support each result. Evidence must show what happened during the audit period. Keep required Security Rule documentation for six years from its creation or last effective date, whichever is later.[18]
Controls and Workflows
For each artifact request, specify the timeframe, format, and due date. In an evidence register, track the source, owner, collection date, reviewer, test date, and related control or finding.
Store originals in an approved repository with restricted access. Preserve export metadata, record any filters used, and mask unnecessary PHI and credentials before sharing.
Evidence to Collect
Use this matrix to assign responsibility for collecting and validating evidence.
| Evidence category | Typical artifact | Control owner | Validation check |
|---|---|---|---|
| Policies | Policy and version history | Privacy or security officer | Approval, effective date, and applicable version |
| Risk analysis | Risk analysis and mitigation plan | Security officer | System coverage, risk ratings, and approvals |
| Configurations | Dated configuration export | IT or application owner | Authoritative source, timestamp, and coverage |
| Incidents | Incident file | Incident-response or privacy lead | Timeline, decisions, and outcome |
| Training | Training report | HR or compliance | Workforce coverage, dates, and overdue records |
| Vendor documentation | BAA and assessment | Vendor-risk owner | Signed agreement, service scope, and unresolved issues |
| Corrective actions | Remediation ticket and retest | Finding owner | Link to finding, implementation, and closure approval |
Testing and Common Gaps
Check the source, date, approval, and completeness before using evidence. Reconcile report populations with system inventories, and document sampling methods and limitations. A current export supports historical testing only if it includes records from the audit period. A new policy does not prove past compliance.
Flag missing timestamps, excluded contractors, incomplete incident outcomes, and remediation tickets closed without retesting. Label recreated records retrospective and preserve their creation history. Log an exception when no reliable source exists. Security incidents and their outcomes must be documented.[10][13]
Use the validated evidence set to check access rights and log review in the next step.
6. Check Access Rights and Logs
Purpose and Requirements
Check who should have access, what they can do, and what they actually accessed. HIPAA requires authorized ePHI access, system activity review, and regular log review.[10][18] Apply minimum-necessary limits where applicable. Approved roles should specify which PHI each role can access and under what conditions.[19] Review permitted exceptions separately. Emergency treatment or approved support access should not automatically count as inappropriate access.
Controls and Workflows
Use the validated evidence set from the prior step to check accounts and logs. Match active accounts against employee, contractor, volunteer, and authorization records. Include privileged, vendor solutions, temporary, and service accounts.
Sample hires, transfers, and terminations. Verify that access begins only after approval and that role changes remove permissions no longer needed. For departures, check that access is disabled across the EHR, identity provider, VPN, remote access tools, and badges. HHS recommends ending physical and electronic access before departure when feasible.[20]
Evidence to Collect
Collect account inventories, role-permission matrices, workforce-status reports, approval tickets, disablement timestamps, and emergency-access records.
For logs, collect user identity, timestamp, action, affected resource, and outcome. Check time synchronization, protection against unauthorized changes, and coverage of record views, exports, privileged actions, and remote connections. Set log-retention and review schedules based on risk. The Security Rule does not set one universal retention period.[10][18]
Testing and Common Gaps
Query logs for post-termination activity, bulk exports, repeated break-glass use, and access outside assignments or scheduled shifts. Compare results with schedules, tickets, and incident records before deciding whether access was inappropriate. Trace selected alerts through investigation and documented disposition. Confirm that emergency access served a legitimate purpose and received retrospective review.
Flag stale accounts, shared credentials, service accounts without owners, missing read-access logs, and alerts without documented outcomes. Measure the percentage of sampled permissions that match approved roles and terminated accounts disabled within your organization’s deadline - not an assumed HIPAA-wide deadline. Assign each gap an owner, due date, and retest requirement.
Use these results to compare written access policies with daily practice.
7. Compare Policies With Actual Practices
Purpose and Requirements
Compare the approved policy or procedure with what staff do day to day. Check its owner, version, approval and effective dates, and review schedule. Confirm that staff who perform the process can access it.
Controls and Workflows
Use the access, log, and evidence results from earlier steps to check whether written procedures match daily work. Build a policy-to-practice matrix that links each requirement to its owner, expected evidence, and test result.
Walk through high-risk processes with the staff who perform them, including incident reporting, secure disposal, and clinical downtime. Check each control’s design, confirm it has been put in place, and test whether it works as written. After upgrades or process changes, compare workflows across departments to spot workarounds and local differences.
Evidence to Collect
Collect approved policies, superseded versions, communication records, and dated notes from observed workflows. Link each item to the requirement it supports.
Check exception records for the business or clinical reason, risk assessment, authorized approver, compensating safeguards, expiration date, and closure evidence. Test whether those safeguards work. Use the records to distinguish policy gaps from failures in how users perform the workflow.
Testing and Common Gaps
Test both routine activities and higher-risk exceptions. Expand testing when failures recur or records don’t match. Look for procedures staff can’t access, conflicting department instructions, outdated system references, and permanent workarounds labeled as temporary exceptions. Policy acknowledgments do not prove compliance; test behavior and records.
Determine whether the procedure is flawed or staff aren’t following a workable one. Record the requirement, observed practice, evidence, risk, and root cause. Assign an owner and due date, then retest the workflow after the correction. Escalate repeated exceptions as control failures - not documentation issues.
8. Check Staff Training and Awareness
Purpose and Requirements
After comparing policy with practice, check that every workforce member received training suited to their duties and risks. The Privacy Rule requires role-based training, while the Security Rule requires security awareness training for all workforce members.[22][5][21] Completing a course doesn’t prove someone understands it.
Controls and Workflows
Match HR, contractor, and active account rosters against learning-management records using each worker’s unique ID. Check assignment dates, completion dates, roles, and access status.
Review onboarding and role transfers for missed training assignments. Confirm that clinicians, billing staff, and privileged administrators received training for their specific roles. Require refresher training after policy changes, incidents, or failed assessments, with clear deadlines and retesting.[22][23][16]
Evidence to Collect
Each training record should show the learner, assigned course, assignment date, completion date, and result. For classroom sessions, include proof of attendance.
Keep the role matrix, course versions, completion records, scores, overdue notices, and retraining records together in the audit file.
Testing and Common Gaps
Sample new hires, contractors, remote workers, and privileged users. Start with the highest-risk groups identified in earlier control reviews.
Ask staff to identify the reporting channel for suspected phishing, lost devices, or accidental disclosures - and explain which details they should preserve. Record answer accuracy, reporting time, and escalation errors. Use controlled phishing or reporting exercises to check whether staff report suspected incidents promptly instead of investigating on their own.[16]
Report completion and overdue rates by workforce group. Check for active users without training, missing classroom records, outdated role assignments, and repeated assessment failures. Assign an owner, deadline, and retest method for each gap.
9. Test Incident Response and Contingency Plans
Use training results to check whether staff can carry out incident response and downtime procedures under pressure.
Purpose and Requirements
Verify incident response, breach documentation, backups, disaster recovery, and emergency-mode operations. Recovery priorities must reflect patient care and safety.[5][10]
Controls and Workflows
Apply the ownership, logging, and escalation practices from earlier steps to incident response and recovery tests. Assign owners for escalation, containment, breach assessment, notification, and system restoration. Compare incident timelines and vendor notice records against BAA requirements.[13]
For a potential breach, check that the risk assessment addresses the PHI involved, who used or received it, whether it was acquired or viewed, and how risk was reduced.[24] Verify that notifications met the required timeline.[12]
Confirm that clinical leaders set recovery priorities. Review downtime procedures for patient identification, orders, medication reconciliation, paper documentation, and paper-to-EHR reconciliation. Document recovery time objectives and recovery point objectives for critical systems.[5][25] Then test whether recovery actions follow the plan and meet those requirements.
Evidence to Collect
Collect approved plans, escalation contacts, incident timelines, breach assessments, notification records, backup reports, and restoration logs. Include system criticality rankings, recovery objectives, exercise results, and corrective-action records. The evidence should show whether recovery met its targets.[10][25]
Testing and Common Gaps
Test restoration - not just backups. Put the plan into practice rather than relying on a paper review. Observe the restoration of a critical application, checking data completeness, integrity, access controls, and elapsed recovery time. Test emergency workflows with clinicians and relevant vendors.[25][17]
Flag missing keys, outdated contacts, untested dependencies, and recovery targets that conflict with patient safety. Give each gap an owner, a deadline, and an interim safeguard. Retest before closing it.[25]
10. Report Findings and Verify Corrective Actions
Turn each gap supported by tested evidence into a tracked finding with an owner, deadline, and retest plan.
Purpose and Requirements
Classify each finding as a documentation gap, control design failure, control performance failure, or mixed failure. Base the classification on the root cause - not just missing paperwork. Record the requirement tested, observed condition, supporting evidence, risk, root cause, and corrective action.
Controls and Workflows
Assign an accountable owner, measurable completion criteria, and a deadline. Rate each finding based on likelihood, ePHI sensitivity and volume, safeguards, and patient-care impact. Escalate active threats and overdue high-risk findings to leadership. Include the interim protections and the decision needed.
Track each finding in a log linked to its finding record. Include risk rating, control area, evidence, owner, deadline, status, and retest result. Do not store PHI in the tracker.
Evidence to Collect
Keep dated, source-linked evidence that shows the corrective action was implemented and the control works. This includes approved changes, configuration exports, completed reviews, and retest workpapers. Link each item to the original finding, corrective-action plan, residual-risk decision, and closure approval. Restrict access and leave out unnecessary PHI or credentials.
Retain required Security Rule documentation for six years from creation or the last effective date, whichever is later. Apply other legal, contractual, organizational, and legal-hold requirements as applicable.[10][26]
Testing and Common Gaps
A closed ticket is not closure. Before closing a finding, have an auditor independently verify the change, test a representative population or operating period, and document exceptions and results. A rewritten procedure alone does not prove the control works.
Keep failed items open. Record any approved residual-risk acceptance separately and include a review date. Update the risk analysis and risk-management plan. Adjust future audit coverage when repeated failures call for broader samples or more frequent testing.[7]
Use verified closures and repeat findings to guide the final control-improvement review.
Conclusion: Turn Audit Findings Into Control Improvements
Let audit findings guide the next risk-based cycle. Focus more attention on high-risk controls. Revisit coverage after a cloud migration, a new clinical application, a major incident, or a new business associate.[3][27] Use those priorities to set sample sizes and review frequency for the next cycle.
Compare findings across reviews to identify systemic root causes. Track repeat exceptions and time to closure so leadership can tell an isolated lapse from a process that needs redesign. Add those patterns to the remediation tracker.
Keep the audit plan, workpapers, and management responses in a protected repository with access tracking and version history.[10] Retain these records to support evidence validation and continued control improvements.
Use those records to start the next cycle: name an audit lead, confirm scope, build the evidence list, and open the remediation tracker. Request risk analyses, system inventories, access records, logs, training records, recovery tests, and vendor assessments. Use this evidence to improve policies, training, technical controls, and vendor oversight.
FAQs
How do I choose HIPAA audit sample sizes?
There’s no single required sample size. Choose your sample based on risk, giving priority to access control, log monitoring, and vendor management. Review enough records to check that policies are applied consistently and that technical safeguards, such as encryption and multi-factor authentication, work as intended.
Review access log samples regularly to confirm that users have the right access levels and that access is removed when needed.
How can a small team ensure audit independence?
Document roles, responsibilities, and direct reporting lines to senior leadership. Keep accountability clear, even when one person serves as both Privacy and Security Officer [1].
Set up a compliance committee with representatives from IT, security, legal, clinical operations, and HR to oversee compliance [1]. Enforce separation of duties to strengthen accountability and prevent conflicts of interest. For example, administrators should not be able to alter their own logs [2].
Which audit findings should I fix first?
Put high-impact risks to protected health information first, especially when resources are limited. Focus on missing risk analyses, unencrypted devices, weak authentication, unpatched systems, and poor access controls.
Group findings by HIPAA rule and severity. Identify root causes so you can fix system-wide problems instead of relying on temporary patches.
For each corrective action, document the risk level, responsible party, milestones, and evidence of completion. These records help maintain a clear audit trail.
