HIPAA Vendor Risk Assessment
Review third-party PHI risk before a vendor becomes an avoidable compliance problem
A HIPAA vendor risk assessment is the operational check between a promising product demo and a real third-party relationship. It should clarify what data the vendor touches, whether a BAA is needed, what safeguards support the approval, and how the relationship will be reviewed when scope changes later.
American HIPAA uses this page for teams that want cleaner vendor oversight without pretending a single questionnaire solves the whole problem.
Questions the reviewer should settle clearly
- What PHI the vendor handles, how it enters the service, and which systems are in scope.
- Whether a BAA is required and signed before PHI access begins.
- Which users, admins, support staff, and subcontractors can reach the data.
- What technical and administrative safeguards the vendor can actually describe and support with evidence.
- How incidents, access changes, renewals, and remediation items are documented and reviewed over time.
Assessment workflow
Build the vendor review in the order teams actually need it
Map exactly what the vendor touches
Start with the real workflow, not the sales category. Document what PHI the vendor creates, receives, maintains, or transmits, which systems are involved, and whether access is direct, indirect, temporary, or ongoing.
Review contract, access, and subcontractor exposure
Confirm whether a business associate agreement is required, what services are in scope, which subcontractors are involved, and how access can be limited, monitored, and removed when the relationship changes.
Request proof of safeguards and response discipline
Ask for evidence that matters in operations: access controls, encryption posture, logging, workforce training, incident escalation, and the vendor's ability to support an investigation when something goes wrong.
Assign owners, review cadence, and remediation follow-through
A vendor risk assessment is only useful when someone owns the open items, dates are assigned, approvals are documented, and the vendor is re-reviewed after material changes or renewal.
Risk pillars
The safest review covers scope, controls, evidence, and governance together
Data scope
Know whether the vendor actually handles PHI or just sits nearby
The first mistake is treating every vendor the same. A transcription platform, managed IT provider, claims tool, and marketing plugin create very different HIPAA exposure, so the review should start with actual data flow and system behavior.
Controls
Check the safeguards that make the relationship defensible
Useful reviews focus on authentication, least-privilege access, encryption, workforce practices, auditability, and offboarding control instead of relying on a vague promise that the vendor is 'HIPAA compliant.'
Evidence
Ask for proof you can retrieve later
A real assessment leaves behind evidence: contract terms, security answers, approved exceptions, review notes, and follow-up decisions that still make sense months later during audits, incidents, or renewals.
Governance
Tie the vendor review into approvals and re-checks
Third-party risk gets expensive when a team reviews a vendor once, files the PDF, and never looks again after scope creep, new subcontractors, or access expansion. Governance closes that gap.
Operational view
Review vendors like part of the PHI workflow, not like a generic category
The most common vendor-review mistake is approving a tool by label instead of by actual use. A transcription platform, managed IT provider, claims tool, or implementation partner creates a very different HIPAA exposure than software that never touches protected health information.
That is why the best assessment starts with workflow reality, then moves into contract language, access boundaries, evidence requests, and escalation duties. If those conversations stay disconnected, teams often end up with a signed BAA and very little confidence about what happens when the service changes.
- Map the systems, users, and subcontractors that widen the PHI footprint.
- Confirm that the contract and BAA match the actual service being delivered.
- Ask for evidence tied to access, safeguards, training, and incident support, not just badge language.
- Document owners, open items, and re-review triggers before the vendor becomes critical infrastructure.
Questions the reviewer should answer
- What PHI the vendor handles, how it enters the service, and which systems are in scope.
- Whether a BAA is required and signed before PHI access begins.
- Which users, admins, support staff, and subcontractors can reach the data.
- What technical and administrative safeguards the vendor can actually describe and support with evidence.
- How incidents, access changes, renewals, and remediation items are documented and reviewed over time.
Checklist areas
These are the vendor controls most teams need to document before approval
Business associate status and contract fit
Confirm whether the vendor is acting as a business associate, whether a BAA is in place before PHI access begins, and whether the contract language actually matches the service being delivered.
Systems, integrations, and access boundaries
Review where the vendor connects, which users can reach PHI, how access is approved, whether MFA and role-based controls are in place, and how accounts are disabled when work ends.
Subcontractors and hosting dependencies
Ask whether the vendor relies on subprocessors, offshore support, managed infrastructure, or downstream service providers that may widen the PHI footprint beyond the primary contract.
Security safeguards and evidence requests
Request the proof appropriate for the risk level, such as policy summaries, access-control descriptions, incident-response expectations, training records, encryption details, and audit or questionnaire responses.
Incident reporting and investigation support
Define how quickly the vendor must escalate suspected incidents, who receives notice, what facts must be preserved, and how the vendor will support breach-risk review if an event affects PHI.
Renewal cadence and remediation tracking
Document review dates, open issues, compensating controls, owner names, and what triggers a fresh assessment so the organization can prove vendor oversight is active instead of ceremonial.
Best fit
Who usually needs this page most urgently
Practice operations
You are onboarding a new vendor that will touch patient data quickly
Teams often feel pressure to sign fast when the tool solves a real workflow problem. The assessment keeps that urgency from outrunning contract checks, access limits, and evidence collection.
Security and compliance
You need a repeatable third-party review instead of ad hoc questionnaires
A stronger process gives reviewers one checklist for BAAs, access scope, subcontractors, controls, and follow-up so each vendor is not judged by whoever happened to answer email that week.
Audit and incident readiness
You need to show why this vendor was approved and what happens if risk changes
That means keeping review notes, remediation decisions, and escalation paths in one retrievable record set instead of rebuilding the story after a breach, customer request, or renewal review.
Practical next step
Standardize vendor reviews before they turn into incident reviews
Guide
HIPAA Vendor Risk Assessment Checklist
Use the blog guide as the plain-English companion to this page when you need a quick walkthrough before formalizing the review process.
Read the checklist guideDocumentation
Vendor BAA Kit
Pair the assessment with editable BAA documentation so contract review and third-party oversight stay aligned.
See the BAA kitIncident response
HIPAA Breach Risk Assessment
Connect vendor incidents to the four-factor breach review workflow before a third-party event forces a rushed decision.
Review breach workflowSupport
Get compliance help
Talk through vendor onboarding, BAAs, evidence requests, and remediation planning when the review needs more than a checklist.
Talk to American HIPAAWhat is a HIPAA vendor risk assessment?
It is a structured review of a third party that may create, receive, maintain, or transmit protected health information. The goal is to understand data scope, contract requirements, safeguards, subcontractor exposure, and incident responsibilities before or during the relationship.
Does every vendor need the same HIPAA review?
No. The review depth should match the real risk. A vendor with direct PHI access, integrations, support privileges, or subcontractor exposure deserves a stronger assessment than a tool that never touches patient data.
When is a business associate agreement required?
A BAA is generally required when the vendor is acting as a business associate by handling PHI on behalf of a covered entity or another business associate. The contract should be in place before PHI is shared, not after deployment is already underway.
What proof should we ask the vendor for?
Ask for evidence tied to the real risk: access-control explanations, security questionnaires, incident-response expectations, workforce training practices, encryption details, subcontractor disclosures, and contract terms that match the workflow.
How often should a vendor risk assessment be reviewed?
At minimum, review it during onboarding and renewal, and again when there are material changes such as new integrations, expanded PHI scope, new subcontractors, security events, or access-model changes.
Does a vendor assessment by itself make the relationship HIPAA compliant?
No. It is one important control inside broader vendor oversight. Organizations still need contract management, access governance, incident response, workforce training, and ongoing documentation that shows the review actually influenced operations.
Need a cleaner vendor review process?
Turn third-party risk review into a documented workflow
Looking for adjacent guidance? Visit the compliance library, review the breach risk assessment workflow, or compare documentation kits that support vendor oversight and audit-ready records.