I use a hybrid vendor assessment to check both a vendor’s answers and the proof behind them before approving PHI access. A signed Business Associate Agreement (BAA) sets the legal terms; it does not prove that safeguards work.
I organize the review into 3 steps:
- Define the scope: Identify PHI, access permissions, data flows, and subcontractors. Map each required safeguard to a control and the proof needed to check it using standard assessment questions.
- Check and score: Review supporting records, document gaps, assess residual risk, and assign fixes with owners and deadlines. Missing proof means unverified, not automatically failed.
- Approve and reassess: Confirm required agreements and safeguards before access begins. Record approval conditions, review dates, and changes that trigger another assessment.
My rule: <u>keep one documented decision trail</u> from scope to approval and later reviews. HIPAA does not set a fixed vendor review schedule; I base review timing on risk and service impact.
PHI Vendor Assessment: From Scope to Reassessment
Step 1: Define PHI Scope and Map Controls
Identify Vendor Roles and Assessment Boundaries
Write a scope statement that names the vendor service, PHI/ePHI types, service criticality, and internal and vendor owners. Determine whether the vendor is a business associate or business associate subcontractor. Document BAA obligations for permitted uses, safeguards, breach response, and subcontractors.
Keep access exposure separate from service criticality. Read-only, export, modification, and administrator permissions describe exposure. Your dependence on the service describes the impact of a disruption.
Scope systems, interfaces, support channels, locations, personnel, and subcontractors. Look beyond production: check test environments, support tickets, screenshots, logs, and backup repositories. A cloud provider that maintains ePHI on behalf of a covered entity or business associate belongs in scope even if it cannot read the encrypted data.
Use this scope to decide which data flows belong in the matrix and which controls to score.
Map How PHI Moves and Where It Stays
Trace PHI from collection through APIs, file transfers, processing, storage, remote support, backups, recovery, retention, and return or destruction.
For each connection, record the data category, source, destination, transfer method, encryption, authentication, access role, processing location, retention period, logging source, and owner. Flag privileged access and every downstream party that handles PHI (fourth-party risk).
Ask the vendor to validate the map, including temporary copies and support paths. Then use confirmed flows to select control questions:
Persistent storage requires storage and recovery controls; remote access requires session, endpoint, and copy restrictions.
Carry only confirmed flows into the control matrix.
Build a HIPAA-Based Control Matrix
Create one row per control objective, linked to a specific flow or asset. Cover administrative, physical, technical, privacy, contractual, resilience, application, infrastructure, and downstream-party controls.
Separate mandatory obligations under HIPAA, state law, the BAA, and the contract from added risk-based controls.
Treat customer-managed keys and tighter recovery objectives as organization-specific requirements, not default HIPAA mandates.
Each row should include the objective, requirement source, vendor response, evidence citation and date, reviewer, status, inherent and residual risk ratings, remediation owner, and due date. Match the evidence to the control in scope:
Access configurations for permissions, sample logs for monitoring, restoration results for recovery, and downstream agreements for subcontractor obligations.
Mark unverified controls insufficient evidence. Record what evidence is missing, then move each control row into Step 2 for scoring.
sbb-itb-535baee
OCR Webinar: The HIPAA Security Rule Risk Analysis Requirement
Step 2: Check Evidence and Score Risk
Use the control matrix from Step 1 as your checklist for reviewing evidence and scoring risk.
Pair Questionnaires With Evidence Reviews
Use the questionnaire to record stated controls and exceptions. Then check those claims against evidence. An updated answer alone does not close a finding.
After reviewing the evidence, score each control row for exposure and verified effectiveness.
Score Exposure and Control Effectiveness
Set scoring criteria and weights before starting the review. Weight PHI volume, PHI sensitivity, and critical-system access, and give higher-exposure vendors a deeper review.
Score control effectiveness separately, using validated evidence. Missing evidence means a control is unverified - not that it has failed.
Set Residual Risk and Approval Thresholds
Use exposure and verified control effectiveness to determine the residual risk score. Lower it when gaps are closed, and increase it again if vendor proof or agreements expire.
Define thresholds for routine approval, conditional approval with tracked restrictions, escalation, or withholding PHI access. Turn unresolved gaps into tracked remediation items before setting approval status.
Track Findings and Confirm Fixes
Put vendor findings in the same prioritized remediation queue as internal risk findings, scans, and policy gaps. Use one shared workflow to assign internal and vendor owners, due dates, and evidence needed for closure.
Close items only after validating the fixes. Reopen closed findings when supporting security documentation or BAAs expire. [1]
Step 3: Approve PHI Access and Review Changes
Check Requirements Before Granting PHI Access
Once scope, evidence, and residual risk are set, get formal approval before PHI access begins.
Treat PHI access as a formal approval gate. Grant access only when the scored control matrix shows acceptable residual risk, evidence confirms required safeguards, and the proposed service matches the assessed scope. A HIPAA-compliant BAA must also be executed where required, with applicable obligations passed down to subcontractors handling PHI. Confirm that scope covers PHI types, systems, users, integrations, privileges, processing locations, and subcontractor roles. [3][5][6]
Tie the approval matrix to risk and service impact. Check permitted uses and disclosures, ePHI safeguards, incident and breach reporting, subcontractor duties, and PHI return or destruction at termination, as required by the agreement. Also address retention limits, audit rights, and termination assistance.
Assign approval responsibilities clearly:
- Procurement: Vendor-service match.
- Privacy or compliance: HIPAA roles and BAA requirements.
- Information security: Safeguards and residual cyber risk.
- Legal: Contract terms and liability.
- Business or clinical owner: Operational need and patient-care impact.
Escalate material gaps to the authorized risk committee or executive approver. [2][3][8]
Set Contract and Service Change Triggers
After approval, define which changes invalidate the decision or require another review.
Require notice and review when the assessed service changes its PHI types or volume, permitted uses, integrations, privileges, authentication, hosting, processing locations, subcontractors, architecture, or criticality.
Also trigger review after major security or privacy incidents, repeated control failures, regulatory or audit findings, ownership or acquisition changes, financial distress, and contract renewals or amendments that affect risk. Include requirements for notice, updated evidence, and cooperation with remediation in contracts and vendor procedures. [7][9]
Assign Reassessment Owners and Deadlines
Give each trigger one accountable owner, one deadline, and one review path.
Keep a trigger register for the assessed service that records the change, accountable owner, review depth, approval authority, deadline, and access decision. Use targeted reviews for changes with limited scope. Use broader reviews when PHI exposure or patient-care impact changes materially.
Triage suspected breaches immediately. Review new integrations before production deployment, and schedule contract reviews before renewal. Hold expanded PHI access until approval unless an emergency exception specifies its scope, compensating controls, expiration, and retrospective review.
Update the assessment version, data flows, evidence dates, contract terms, residual risk, and next review date. Set review intervals based on residual risk and service criticality - for example, quarterly evidence checks for high-risk clinical vendors, or semiannual or annual reviews for moderate-risk vendors. HIPAA does not set fixed review periods. [4][7]
Conclusion: PHI Vendor Assessment Checklist
After approval and reassessment planning, close the file with a complete assessment record. Use questionnaires to keep assessments consistent, but check answers against the PHI workflow, evidence, and risk decision. Keep one decision trail from scope through reassessment.
Before closing the assessment, confirm these seven records:
- Scope statement: Vendor role, services, PHI types, systems, locations, subcontractors, and boundaries.
- Data-flow map: Where PHI is created, received, accessed, transmitted, stored, backed up, deleted, and logged.
- Control matrix: Risks mapped to HIPAA safeguards, owners, responsible parties, and exceptions.
- Evidence record: Evidence requested, received, and reviewed, plus the coverage period, reviewer, date, and limitations.
- Issue register: Findings, ratings, owners, due dates, status, interim protections, and validation results.
- Approval record: Residual-risk acceptance, conditions, approvers, and authorization date.
- Reassessment triggers: Contract, service, technology, ownership, incident, and regulatory triggers, with owners and deadlines.
Mark each record complete only when it has an owner, date, and supporting records. The documentation must let a reviewer trace why PHI access was approved, restricted, or delayed - without relying on undocumented conversations.
FAQs
What if a vendor won’t share security evidence?
Treat the refusal as a serious contract and compliance risk, not a paperwork issue. Escalate it to legal and procurement. Put compensating controls, such as network segmentation, in place to reduce exposure until the issue is resolved.
Document the refusal, gaps in evidence, and your organization’s response to show oversight during audits. The refusal should also trigger a formal review to assess whether emergency contract termination is warranted.
Which PHI risks should block vendor approval?
Block vendor approval if the security and privacy review is incomplete, MFA or encryption isn’t enforced, application-level PHI access logs are unavailable, or mismatches between subprocessor lists and Business Associate Agreement coverage remain unresolved.
Missing or expired mandatory evidence - SOC 2 Type 2 reports, HITRUST certifications, or penetration test summaries - requires blocking approval or escalating the issue. Vendors with unknown PHI status must not go live.
When is a targeted reassessment enough?
A targeted reassessment is enough when an event changes a vendor’s risk profile between scheduled reviews. Start an immediate, focused review after a data breach, major service outage, or security incident.
Also review major changes to infrastructure or architecture, subcontractor relationships, ownership, or the scope of PHI access. These off-cycle reviews let you respond to changes in risk without waiting for the next scheduled assessment.
