I use seven steps to turn a healthcare privacy risk assessment into a plan for protecting patient data. For each finding, I document the risk, assign an owner and deadline, and check that the fix works - not just that the ticket is closed.
Here’s the process:
- Set the scope and team: Identify covered systems, locations, vendors, and decision-makers.
- Map patient data: Track where protected health information (PHI) goes, who uses it, and how it is stored and discarded.
- Check handling rules: Compare daily work with HIPAA, state law, contracts, and patient rights.
- Test risks and safeguards: Assess threats, check controls, and consider harm to patients and care delivery.
- Record and rank gaps: Keep findings, supporting records, priorities, and owners in one risk register.
- Verify corrective actions: Track fixes, test results, and remaining risk before approving closure.
- Schedule reviews and reporting: Reassess after changes and give leaders clear decisions to make.
My focus is <u>proof that safeguards work</u>. HIPAA requires an ePHI risk analysis, but it does not prescribe an annual review schedule. An assessment is the starting point - not proof of full compliance.
Healthcare Privacy Risk Assessment: 7 Steps
OCR Webinar: The HIPAA Security Rule Risk Analysis Requirement
sbb-itb-535baee
Step 1: Define the Scope and Assign the Team
Create an assessment charter that lists the legal entities, affiliated practices, facilities, departments, systems, devices, vendors, workforce groups, and workflows the assessment will cover. Include every location where the organization creates, receives, maintains, processes, or transmits ePHI. Account for workforce members, contractors, clinicians, students, volunteers, temporary staff, and administrators with elevated access. Cover physical, administrative, and technical settings, including remote access, telehealth, cloud services, backups, and removable media.[2][6]
Label each item in scope, out of scope, or pending validation. For each exclusion, document the reason, decision owner, supporting evidence, review used to justify it, and conditions for reconsideration. A vendor-hosted system isn't automatically out of scope.
Check these boundaries through clinical and administrative walkthroughs. Ask where PHI gets copied, who can access it, what happens during downtime, and where records stay after a workflow ends. The charter sets the baseline for the PHI inventory and flow map in Step 2.
Name one accountable assessment owner and an executive sponsor to lead Censinet RiskOps for healthcare with authority to approve boundaries, risk tolerance, resources, and escalations. Assign responsibilities across the team:
- Privacy, security, compliance, and legal: Privacy interprets obligations and permissible uses. Security evaluates threats and safeguards. Compliance maps requirements. Legal reviews regulatory, contractual, and privilege considerations.
- Clinical operations and health information management: Clinical operations validates workflows. Health information management confirms record, disclosure, retention, and release-of-information practices.
- IT and vendor management: IT supplies architecture, asset, identity, and configuration evidence. Vendor management identifies third parties, contracts, business associate agreements, and supplier dependencies.
Document who can make decisions and whom to contact for escalations. HIPAA requires a security official, but it doesn't require this exact team structure.[3][8]
Approve the Assessment Method
Before fieldwork begins, attach the initial system inventory, team assignments, evidence requirements, scoring rules, and reporting template to the charter. Require each piece of evidence to identify its source, owner, collection date, coverage, and limitations.
Set scoring rules for ranking privacy gaps and remediation priorities. One option is to score likelihood and impact from 1–5, then multiply the two scores. This approach isn't a HIPAA requirement. Also specify how assessors will evaluate existing controls and residual risk, including effects on patient safety and clinical availability.[7]
Get documented sign-off from the sponsor and participating functions. Keep the charter under version control and include target dates. After sponsor approval, carry unresolved scope questions forward with assigned owners and deadlines. Use the charter to begin the PHI inventory and flow mapping.
Step 2: Inventory Patient Data and Map PHI Flows
Use the approved scope from Step 1 to build a PHI inventory tied to a data-flow map. Include electronic health records, registration and scheduling data, claims and billing files, laboratory and pharmacy data, diagnostic images, portal messages, email, texts, call recordings, care-management records, research datasets, paper records employees can access, and connected-device data.
Don’t stop at primary systems. Include exports, spreadsheets, temporary files, backups, test environments, and other nonproduction copies. Identify direct identifiers, limited data sets, and other data that could be re-identified. HHS guidance says a HIPAA risk analysis must identify where ePHI is created, received, maintained, or transmitted.[1][2]
Trace collection, access, modification, disclosure, transmission, storage, archiving, and disposal. Record sources, destinations, data elements, transfer methods, frequency, and controls. This makes privacy exposure points visible before the threat review.
Cover applications, APIs, integration engines, cloud services, medical devices, paper records, and manual transfers. Also document transformations such as redaction and de-identification. Record the method used before treating any data as de-identified.
Validate the Data-Flow Inventory
Use the fields below for each workflow. Replace broad system labels with actual application names, environments, locations, and named owners. Add supporting evidence, validation dates, backup locations, and disposal methods.
Retention and disposal need separate fields. Retention should identify the governing schedule. Disposal should explain how paper, media, devices, backups, and vendor-held copies are securely destroyed.[10][12]
| Data type | System | Location | Movement | Business purpose | Owner | User groups | Retention period | External recipient | Controls |
|---|---|---|---|---|---|---|---|---|---|
| Clinical notes and diagnoses | EHR | Production database and encrypted backup | Clinician entry → EHR → referral and billing interfaces | Care delivery and reimbursement | Application owner | Clinicians, coding, authorized support staff | Medical-record retention schedule | Payer, referral provider | Role-based access, audit logs, encryption, release approval |
| Diagnostic images | PACS and modality devices | Imaging department, cloud archive, disaster-recovery copy | Modality → PACS → radiologist workstation → referring provider | Diagnosis and treatment | Radiology IT owner | Radiologists, technologists, authorized clinicians | Medical-record schedule | Referring provider and patient-designated recipient | Access controls, secure DICOM transfer, logging |
| Patient portal messages | Patient portal and messaging service | Portal database and vendor-hosted infrastructure | Patient → portal → care team or external specialist | Care coordination and patient communication | Digital-health owner | Patients, care teams, support staff | Messaging-retention schedule | Specialist, interpreter, or service provider | Authentication, encryption, message audit trail |
| Claims data | Billing platform and clearinghouse | Revenue-cycle systems and vendor environment | EHR → billing system → clearinghouse → payer | Claims submission and payment | Revenue-cycle owner | Billing staff, clearinghouse, payer | Financial-record retention schedule | Clearinghouse and payer | BAA, secure transmission, least privilege, reconciliation |
| Research dataset | Research database or approved analytics environment | Segregated research environment | EHR or registry → de-identification or limited-data workflow → researchers | Approved research or quality improvement | Privacy or research-data officer | Approved research personnel | Research-record retention schedule | Institutional review board-approved collaborators | Data-use agreement, access approval, de-identification, monitoring |
Have workflow owners check entries against API gateway records, file-transfer logs, cloud-storage reports, backup catalogs, vendor invoices, transaction traces, and access records. Include frontline walkthroughs of downloads, printed worklists, and fax queues. Mark each entry confirmed, partially confirmed, or unknown.
For each external recipient, verify what PHI they receive, why they receive it, contract status, hosting or support subcontractors, and return or destruction obligations.[9][11] Log missing agreements and undocumented transfers as gaps. Assign an owner and deadline to each open question, and resolve unknown repositories and recipients before calling the inventory complete.
Keep the validated map and supporting evidence for Step 3, where actual PHI handling is compared with applicable requirements.
Step 3: Review PHI Handling Requirements
For each mapped workflow, document the permitted purpose, the PHI involved, and the requirements that apply under HIPAA, state law, contracts, and internal policies.[15][17] HIPAA generally limits PHI uses, disclosures, and requests to the minimum necessary for the intended purpose, with exceptions for treatment and authorized disclosures.[14][15] Check that each authorization covers the actual recipient, purpose, information released, and expiration terms.
Compare vendor agreements with the services vendors actually provide. Confirm permitted uses, subcontractor duties, breach reporting, and return-or-destruction terms. For secondary uses, such as analytics or model training, verify a valid legal basis and explicit limits on reuse. A BAA does not make an impermissible use lawful.[14][16]
Compare Policies With Daily Workflows
Review access logs, disclosure logs, authorization forms, incident tickets, and disposal certificates from departments and vendors. Compare what the rules permit with what happens in daily work. Record the sample period, selection method, evidence location, and exceptions so an auditor can trace the review.
Keep medical-record retention separate from HIPAA documentation retention. HIPAA sets no general medical-record retention period; state law and other obligations control.[13] HIPAA documentation must be kept for six years from creation or the last effective date, whichever is later. Check retention schedules, legal holds, and disposal procedures against the applicable requirements.
Test how teams handle patient-rights requests, including identity checks, deadlines, fees, permitted denials, and documented outcomes. Cover access, amendments, restrictions, confidential communications, and accounting of disclosures where applicable.
Mark this step complete only when each sampled workflow has a documented purpose, PHI recipients, applicable requirements, and evidence of follow-through. Log exceptions as privacy gaps, each with a severity level, owner, and target date. A written policy alone is not evidence of compliance. Carry those gaps into Step 4 to rate likelihood and impact.
Step 4: Assess Threats, Weaknesses, and Controls
Once PHI handling requirements are mapped, turn each PHI flow into a failure scenario. Cover access without permission, device loss, phishing, ransomware, insider misuse, third-party compromise, outages, and AI misuse. Identify the affected data, system, and users, how the failure could happen, and its effect on patients or operations. Assess both information exposure and care disruption, including the loss of medication lists, allergies, or diagnostic results.[2]
Test safeguards directly. Compare account permissions with job duties. Check MFA enforcement and exceptions, and verify encryption for devices, exports, backups, and vendor-held data. Review monitoring for unusual access and bulk exports. Check training results, incident-response exercises, and disposal records. For AI tools, check controls over PHI inputs, retention, permissions, and output validation. Verify critical vendor claims with supporting evidence - not third-party vendor risk questionnaires alone.[2]
Use read-only configuration checks, sampled access reviews, log analysis, and tabletop exercises. Restore backups in an isolated environment, then compare recovery times with clinical needs. Agree on testing windows and escalation contacts with clinical owners. Do not run destructive simulations or test medical-device controls without clinical and biomedical engineering approval.[18][19]
Rate Risk Before and After Controls
Use the assessment method approved in Step 1. Rate inherent risk first, then rate residual risk on the same scale after testing controls. Consider confidentiality, integrity, availability, and patient safety. Include privacy harms such as discrimination, identity theft, and secondary use without permission. Account for data sensitivity, the affected population, and how quickly harm could occur.[2]
For each scenario, record the ratings, evidence source and date, test coverage, limitations, and reviewer approval. Judge whether controls are properly designed, implemented, and working - not just documented. Do not lower a rating for an untested safeguard without recording the uncertainty. This step is complete when every scenario has evidence-backed ratings and a judgment on control effectiveness. Carry unresolved weaknesses and unacceptable residual risks into Step 5.[1][5]
Step 5: Record and Prioritize Privacy Gaps
Turn each unresolved finding from Step 4 into a tracked remediation item using its residual risk. Label it as a control-design gap, control-operating failure, or documentation gap. The label tells you what needs fixing: the safeguard, the process, or the records.
Prioritize findings by patient safety, PHI sensitivity, exposure likelihood, exploitability, and regulatory duty - not technical severity alone. Use critical for immediate exposure or safety risk, high for material PHI or operational risk, moderate for meaningful weaknesses with limited exposure, and low for minor weaknesses with minimal foreseeable impact.
Explain any change to the Step 4 rating, including urgency tied to a legal deadline. This ranking sets the order of repairs.
Build a Risk Register With Supporting Evidence
Create one register entry per finding. Combine duplicates without losing affected systems or accountable owners. Any format works if it keeps a clear audit trail. Record each finding once and use that same entry throughout remediation.
| Register field | What to record |
|---|---|
| Finding and scope | Finding ID, gap type, condition, cause, impact, PHI categories and volume, systems, processes, locations, and third parties |
| Threat, weakness, and controls | Exposure path, exploitability, vulnerability, existing safeguards, and control performance |
| Applicable requirements | Specific HIPAA provision, policy, contract term, state requirement, or retention obligation |
| Supporting evidence | Dated configuration records, access reviews, logs, or test results; controlled evidence reference and reviewer |
| Risk and priority | Likelihood, impact, inherent risk, residual risk, critical/high/moderate/low priority, and supporting rationale |
| Ownership and action | Accountable owner, corrective action, due date, status, dependencies with assigned owners, and interim safeguard |
| Closure criteria | Required implementation, testing, reviewer approval, and dated completion evidence |
Make blocking dependencies visible. When one fix depends on another, record the required sequence and completion date. A lower-rated task may need urgent attention if it blocks a critical correction. Assign an interim safeguard while the dependency remains unresolved.
Keep full PHI out of the register. Use data categories, aggregate counts, and redacted evidence instead. Store sensitive attachments separately with least-privilege access, multifactor authentication, encryption, version history, retention rules, and audit logging.
Before moving to Step 6, check that every finding includes a clear condition, cause, impact, affected assets and PHI category, applicable requirement, evidence reference, likelihood, residual-risk rating, owner, and priority rationale. Any accepted risk needs an authorized approver and an expiration date. In Step 6, use this register to assign corrective actions and verify closure.
Step 6: Assign and Verify Corrective Actions
Turn each Step 5 risk-register entry into an action with a named owner, deadline, dependencies, target control, residual-risk target, and verification method. Separate immediate containment from long-term remediation when permanent fixes depend on procurement, vendors, or clinical validation. Attach the original finding evidence and approvals to the action. Keep the same register as the source of truth until closure.
Record the treatment decision: mitigate by improving safeguards; avoid by stopping the risky activity or removing the PHI flow; transfer part of the operational or financial exposure through contracts or insurance; or accept legally permissible residual risk with authorized approval and a review date. Neither transfer nor acceptance removes HIPAA, state, breach-notification, contractual, or professional duties.
Track Fixes Through Verified Closure
A closed ticket is not proof that a control works. Have an independent tester check both control design and operating effectiveness. Verification may include configuration screenshots, access-control reports, audit-log samples, policy approval records, workforce-training completion data, vendor attestations, observed workflow testing, or a repeat data-flow review. Keep dated evidence and reviewer approval. Then compare the resulting risk with the approved target using the same likelihood and impact criteria.
Keep status, deadlines, evidence, exceptions, and residual risk in one record. Use these fields to verify closure - not just task completion.
| Tracking field | Required entry |
|---|---|
| Status | Open, In progress, Blocked, Pending validation, Closed, Exception approved, or Reopened |
| Deadlines | Due date, next milestone, blocking dependency, and justification for any extension |
| Completion evidence | Evidence reference, test scope, pass criteria, results, validator, and test date |
| Exceptions | Reason, compensating controls, named owner, approving authority, and expiration or review date |
| Residual risk | Post-remediation rating, comparison with the target, and authorized decision |
Escalate overdue high- or critical-risk actions to privacy and security leaders immediately. Take unresolved material risks to the executive risk committee. When work is blocked, identify who can remove the dependency and what safeguards can be used in the meantime.
Reopen findings when testing fails, evidence expires, controls stop working, the system changes, or a new incident shows the original risk remains. If post-remediation risk remains above tolerance, keep the item open and add actions rather than closing it. Approve only legally permissible, time-limited exceptions, with documented alternatives and all exception details listed above.
Step 7: Schedule Reviews and Executive Reporting
Use the risk register from Step 6 to build an approved, risk-based review calendar. Include named owners, planned start and completion dates, an approver, and escalation rules for missed deadlines.
An annual review is a practical baseline - not a HIPAA requirement. HHS guidance ties risk-analysis frequency to the organization’s environment and changes affecting ePHI.[2][1] Review more often when unresolved critical findings, major technology changes, or major third-party dependencies call for closer oversight. Use the verified closure record from Step 6 to decide what needs another look at the next review.
Define Review Triggers and Reporting Deadlines
Require business owners to notify privacy, security, compliance, and risk teams when a trigger occurs. The schedule below is an internal control, not a legal deadline. These triggers help teams move from routine reviews to event-driven reassessments.
| Review or trigger | Primary owner | Reassessment actions | Reporting deadline |
|---|---|---|---|
| Annual baseline review | Privacy officer with security, compliance, IT, clinical, and legal representatives | Revalidate PHI maps, inventories, vendor dependencies, threats, controls, open findings, exceptions, and residual risk | Executive summary within 30 days of approval |
| Suspected privacy or security incident | Incident-response lead and privacy officer | Preserve evidence; update affected PHI maps, controls, risk-register findings, and response plans | Initial leadership notification per the incident plan; breach notifications follow applicable deadlines |
| Acquisition or merger | Integration executive and privacy officer | Extend existing maps, inventories, control reviews, and the risk register to inherited systems, vendors, and obligations | Pre-close or pre-integration risk briefing; unresolved high risks reported to the executive sponsor |
| Major implementation or migration | Program owner, security, privacy, and clinical informatics | Revalidate affected data flows, access, interfaces, logging, downtime controls, and register entries | Risk acceptance before go-live; post-implementation review within a defined period |
| Material vendor or workflow change | Vendor or process owner and privacy/security teams | Update affected PHI flows, vendor responsibilities, controls, contract terms, and register entries | Approval before the change where feasible; exceptions escalated by the change deadline |
| Relevant regulatory or legal change | Compliance and legal | Update applicable requirements, controls, and risk-register actions | Impact assessment and executive decision by the compliance implementation deadline |
Every review must revalidate the current PHI map, open findings, and control status, then document what changed.
Give executives a concise dashboard backed by the risk register. Show open risks by severity, overdue actions, accepted exceptions, residual exposure, and changes since the last review. For each material risk, name the owner, deadline, effects on operations, and any decision or funding needed. Track overdue high-risk actions weekly. Escalate critical exposure immediately when supported by evidence - don’t wait for the next scheduled meeting.
Store the assessment method, evidence, approvals, decisions, and remediation history in a controlled repository. Retain prior versions so reviewers can trace changes. Between reviews, keep the calendar, triggers, evidence, and dashboard up to date so the assessment stays current and the next cycle starts from a verified baseline.
Conclusion: Keep Assessments Current
Treat privacy risk assessment as a continuous loop, not a one-time checklist.[2][4] Use the review schedule to begin the next cycle with up-to-date evidence.
Protect patient privacy and patient safety by basing decisions on exposure evidence and the impact on care - not policy alone. Keep PHI maps and remediation records aligned with how work actually happens, so the assessment reflects daily workflows rather than static documents.
Before closing the assessment, confirm that every material finding has an accountable owner and proof that the fix works. For any remediation still open, document compensating controls, an exception expiration date, and executive acceptance of legally permissible residual risk.
FAQs
How does a privacy assessment differ from a HIPAA security risk analysis?
A HIPAA security risk analysis is a required, structured review of threats and vulnerabilities to electronic protected health information (ePHI) under the HIPAA Security Rule.
A privacy assessment takes a broader view. It reviews how protected health information (PHI) moves, the privacy risks it faces, and the safeguards in place throughout its lifecycle. It goes beyond technical security to address patient privacy, help organizations meet compliance requirements, and reduce a broader range of privacy risks.
How can a small practice scale this seven-step process?
A small practice can scale this seven-step process by automating repetitive tasks, focusing on high-risk areas, and using a standard assessment process. Tools such as Censinet RiskOps™ can simplify data collection, vulnerability documentation, and vendor assessments.
Train current staff to take on multiple roles, bring risk monitoring into one place, and set up shared workflows. This helps small teams oversee all risk areas and maintain compliance without hiring more staff.
What should we do if a vendor won't share control evidence?
Enforce expectations through Business Associate Agreements (BAAs) that define audit rights. Use structured questionnaires to request specific documents - not just yes/no answers. If the evidence still falls short, consider on-site audits, especially for high-priority vendors. Include staff interviews and technical configuration assessments.
Record gaps in your risk register and assign someone to resolve each one. Obtain formal leadership sign-off on any acceptance of residual risk to show due diligence.
