Vendor risk for PHI and ePHI

Govern Business Associates Through Contracts, Access Evidence, and Continuous Oversight

Healthcare practices depend on vendors. HIPAA risk grows when vendors can access PHI but agreements, access controls, security expectations, and incident notification duties are unclear.

Match diligence depth to PHI access and operational dependency.
Map subcontractors and support paths—not only the direct vendor.
Preserve implementation evidence beyond the signed BAA.
\n
Vendor control dossier

A BAA Should Sit Inside a Complete Vendor Risk File

The agreement establishes required terms, but the operating relationship determines exposure. A useful dossier shows why the vendor is needed, what PHI it handles, how access works, which subcontractors participate, how incidents and outages are handled, and how the relationship ends.

Service and data scope
Describe the business function, systems used, PHI categories, volume, data subjects, locations, retention, transmission paths, and whether the vendor creates, receives, maintains, or transmits PHI. Note whether access is routine, support-only, emergency, or technically possible.
Identity and remote access
Record named and shared accounts, privileged roles, MFA, support tooling, approval, session logging, time restrictions, termination, emergency access, and customer visibility. Identify service accounts and API credentials that remain active without an interactive user.
Architecture and subprocessors
List hosting, cloud, support, backup, analytics, notification, and other subcontractors involved in the service. Record regions, data flow, responsibility boundaries, notification of change, and how downstream BAA obligations are managed.
Security and resilience
Evaluate encryption, vulnerability management, logging, incident response, backup, recovery objectives, test evidence, business continuity, secure development where relevant, and independent reports. Confirm that evidence covers the service actually purchased.
Contract and incident terms
Track BAA version, service agreement, order form, data-processing terms, notification timing, cooperation, evidence preservation, individual identification, costs, insurance, audit rights, return or destruction, and conflicts between documents.
Ongoing oversight
Assign a business owner and technical owner; define review cadence, risk tier, open findings, exceptions, performance issues, access reviews, incident history, material changes, and approval to renew. Record why residual risk is acceptable.
Termination plan
Before termination, identify export format, validation, migration, account and token removal, support shutdown, retained copies, legal holds, backups, deletion confirmation, hardware return, and continuity measures. Avoid discovering data portability limits after notice is given.

Escalate on material change

Trigger reassessment after acquisition, hosting-region change, major subprocessor change, new AI or analytics function, new remote-support model, security incident, recurring outage, contract revision, integration expansion, or a change in the type or volume of PHI.

Tier by exposure and dependency

A vendor with broad ePHI access, privileged administration, irreplaceable clinical function, large data volume, or difficult recovery deserves deeper diligence and more frequent review than a low-volume service with narrow access and easy replacement.

Evidence should match the purchased service

A certification, report, or questionnaire for a parent company or unrelated product may not cover the environment handling your PHI. Confirm scope, period, exceptions, complementary customer responsibilities, subservice organizations, and the remediation status of relevant findings.

Vendor review mechanics

Ask for Evidence That Answers the Service-Specific Risk

Access evidence

Request user and privileged-account structure, MFA and remote-support design, approval and termination process, representative session or access logs, service-account governance, and customer controls. Focus on the environment and support model used for your service.

Incident evidence

Review incident-response roles, customer-notification workflow, evidence preservation, subcontractor coordination, exercises, and lessons from material events when available. Confirm contract timelines and the facts the vendor must supply for your breach analysis.

Resilience evidence

Review architecture, redundancy, backup scope, recovery objectives, restoration tests, dependency mapping, customer responsibilities, downtime communications, and recent availability issues. A generic continuity policy does not prove recovery of the purchased product.

Assurance reports and certifications

Confirm entity, product, location, period, control scope, subservice organizations, exceptions, complementary customer controls, and management response. Track whether relevant findings are resolved and whether the report period leaves a material gap.

Privacy and data lifecycle

Document permitted uses, data location, retention, support copies, logs containing PHI, analytics, de-identification claims, AI use if any, individual-rights support, return or destruction, backups, and legal holds.

Customer configuration duties

Many controls require customer action: MFA enforcement, role assignment, log review, secure integration, retention settings, backup choice, incident contacts, and user termination. Put these duties into the internal remediation register rather than assuming the vendor performs them.

When evidence is unavailable, document the limitation, risk implication, compensating safeguards, alternative evidence, contract leverage, decision owner, and review date. Lack of transparency can itself change the vendor’s risk tier.

\n

Vendors to Review

Vendor categories that may touch PHI

Review EHR vendors, dental software vendors, billing companies, clearinghouses, cloud backup providers, IT support companies, MSPs, phone and messaging platforms, answering services, shredding providers, marketing vendors, consultants, accountants, attorneys, transcription services, and remote support tools when PHI may be involved.

Know access purpose, approval, and removal

The practice should know what each vendor can access, why they need it, how access is approved, how access is removed, and what happens if the vendor has an incident.

Anchor Contracts and Oversight in HHS Guidance

Use the HHS business associate materials to understand required relationships and contract provisions, then apply risk-based diligence to the actual service.

Business associate guidance

HHS explains business associate functions, contracts, permitted uses, safeguards, reporting, and subcontractor relationships. Review HHS guidance

Business associate contracts

HHS provides contract guidance and sample provisions for covered entities and business associates. Review sample BAA provisions

Business Associate and Vendor Oversight Questions

Is a BAA enough by itself?

No. A BAA is important, but safeguards, access control, vendor review, and incident-response expectations are also needed.

Do cloud vendors need review?

Yes. Cloud services that store or process PHI should be reviewed for agreement coverage, security controls, access, retention, and incident notification.

Should IT support have a BAA?

If IT support can access systems containing PHI, the relationship should be reviewed for business associate obligations.

Replace Vendor Assumptions With a Reviewable Risk File

OC Security Audit can map PHI vendors, tier risk, examine access and evidence, review technical and operational gaps, and organize remediation and reassessment records.

IT Perfection can support implementation involving identity, remote access, Microsoft 365, endpoints, backup, servers, networks, monitoring, and vendor-transition projects.