HIPAA Vendor Review Steps for Patient Mentorship SaaS
Key Takeaways
Author
I would not give a mentorship vendor access to PHI until its HIPAA role, required BAA, and security controls check out. Health data is not always PHI, so I start by mapping whose data the service handles and who can see it.
My review covers four steps:
- Define the scope: Map patient data, mentor roles, integrations, subcontractors, and retention.
- Check the contracts: Review the BAA, permitted uses, deletion terms, and incident duties. I seek a 24- or 48-hour initial notice deadline - separate from HIPAA’s breach-reporting rule of no unreasonable delay and no more than 60 calendar days after discovery.
- Test the controls: Check access limits, staff training, encryption, backups, audit logs, and incident response.
- Record the decision: Assign fixes, document approval, schedule reassessments, and plan offboarding.
My bottom line: <u>close material gaps before PHI access</u>. A signed contract or SOC 2 report alone is not enough.
HIPAA Vendor Review: 4 Steps Before PHI Access
Healthcare Vendor ePHI Questionnaire (36 Questions) | TPRM | SAFE Security
sbb-itb-8f61039
Step 2: Review the BAA and Reporting Terms
Before allowing PHI access, compare the BAA, service agreement, privacy policy, and security exhibit side by side. Use a contract crosswalk to record each duty, owner, deadline, and remedy. Resolve conflicts over analytics, retention, incident reporting, and liability. Commercial terms cannot override HIPAA. Then use the data map from Step 1 to check each workflow against the contract terms.
Define Permitted Uses and Subcontractor Duties
Spell out permitted mentorship functions, minimum-necessary access, safeguards, reporting duties, assistance with individual rights, and termination rights. Address analytics, marketing, AI training, and de-identification separately.
Require written subcontractor agreements that carry the same core HIPAA duties, including reporting and cooperation. Negotiate advance notice of subcontractor changes and the right to object or terminate over material compliance concerns. Set deadlines for returning or destroying PHI. Document retention exceptions, how backups will be handled, and which protections must continue.
Set Incident Reporting Deadlines and Response Duties
Make clear distinctions between security incidents, impermissible uses or disclosures, and breaches. Require preliminary notice of suspected events before the vendor finishes its breach assessment. Set a 24- or 48-hour initial notice deadline after discovery or reasonable suspicion. HIPAA requires business associates to report breaches of unsecured PHI without unreasonable delay and no later than 60 calendar days after discovery.
Name 24-hour incident contacts. Require the vendor to share available facts about affected individuals and PHI, incident dates, containment, and mitigation. Set an update schedule, preserve logs and other evidence, and require subcontractor escalation and investigation support.
Assign responsibility for patient, HHS, state-law, and media notices, along with investigation and notification costs. These contract terms do not waive either party’s statutory duties. Use the notice and cooperation terms as the baseline for the access and control checks in Step 3.
Step 3: Test Access, Workforce, and Security Controls
After reviewing the contract, test whether the vendor can enforce its controls. Ask for a demo in a test environment or controlled test account, and document each result. Label each control as HIPAA-required, risk-based, or contractual. Use the rules and HHS guidance in effect on the review date.
Check Minimum-Necessary Access and Workforce Safeguards
Ask for an access matrix covering mentors, support staff, administrators, client users, developers, and machine accounts. For each, record the PHI categories, actions, purpose, owner, authentication, and access type across messaging, matching, and support workflows. Test whether searches, URLs, APIs, or exports allow access across participants or clients. Mentors should see only assigned records and the PHI their role requires. Document any treatment-related exceptions.
Verify individual user IDs, privileged-access MFA, session timeouts, access reviews, and machine-account ownership. Treat specific MFA and session settings as procurement safeguards unless applicable rules require them. Review role-based training, confidentiality agreements, supervision, sanctions, and background checks where lawful. Compare recent departures against application, VPN, cloud, and API access records to confirm prompt offboarding. Also test whether access ends when a mentor is reassigned.
Verify Encryption, Key Management, and Recovery
Check how the vendor protects data in transit, at rest, and during recovery. Verify encryption across browsers, APIs, integrations, admin connections, databases, files, snapshots, and backups. Inspect key-access permissions, rotation records, secrets storage, vulnerability findings, patching, and secure-development evidence.
For addressable safeguards, document why the selected control is reasonable and record any alternative safeguards. Request a restoration-test report that identifies the backup used, recovery time, data-integrity checks, and corrective actions. The report should also confirm whether messages, assignments, consent records, and audit evidence were restored. Compare the results with contractual recovery commitments.
Review Audit Logs and Monitoring
Verify that the audit trail can help detect misuse. Sample logs for authentication, participant PHI views, searches, exports, edits, mentor message access, privilege changes, and API activity. Check user identity, synchronized timestamps, tamper protection, and retention.
Logs should identify the action and affected record - not full message bodies, diagnoses, or attachments unless an investigation requires them. Ask who reviews alerts, how suspicious access is investigated, and how evidence is preserved. HIPAA’s six-year documentation rule does not set a universal log-retention period. Document a separate rationale for operational logs.
Step 4: Record Findings and Plan Reassessments
Create a Review Evidence Table
Use the Step 3 control tests to build the approval file, turning each finding into a dated approval record. Document results from the access, encryption, logging, and incident checks. For every row, record the reviewer, severity, remediation owner, due date, remaining risk, and decision: approved, approved with conditions, deferred, or rejected. Keep these records in a dated review file.
| Review area | Evidence to request | Acceptance criteria | Follow-up action |
|---|---|---|---|
| BAA provisions | Executed BAA and completed contract crosswalk | Required terms are documented and gaps are resolved | Compliance confirms completion before PHI access |
| Risk records | Current risk analysis, risk register, remediation plan, system inventory, data-flow map | Findings cover the mentorship environment, including threats, vulnerabilities, remaining risk, and control owners | Security assigns risk treatment and a decision owner |
| Access matrices | Role-permission matrix, privileged-access list, access-review records | Permissions match approved duties and stay within the minimum necessary operational scope | Security closes excess-access findings and records verification |
| Workforce training | Completion records, role-specific content, sanctions policy | Personnel complete relevant training before handling PHI | Compliance closes exceptions before granting access |
| Encryption | Encryption standards, key-management procedures, backup and recovery evidence | Data is protected in transit and at rest; key access and recovery are controlled and tested | Security tracks gaps separately and verifies fixes |
| Audit logs | Sample sanitized logs, retention settings, monitoring records | Logs support investigations and include relevant user and administrative events | Security verifies fixes for missing events or monitoring gaps |
| Incident procedures | Response plan, escalation contacts, exercise results, notification workflow | Response, evidence preservation, cooperation, and mitigation duties are assigned | Program and security owners resolve response gaps |
| Breach-reporting clauses | BAA notice terms, reporting deadlines and escalation steps | Deadlines, recipients, required information, and cooperation duties are clear | Procurement documents reporting deadlines, recipients, required facts, and cooperation duties |
A shorter initial-notice deadline adds a contractual safeguard. It does not change the federal HIPAA deadline for reporting breaches of unsecured PHI: without unreasonable delay and no later than 60 calendar days after discovery.
SOC 2 reports and certifications can support findings, but they do not establish HIPAA compliance on their own. Before accepting them as evidence, check their scope, testing dates, exclusions, and customer responsibilities.
Once the table is complete, set the next review date.
Set Review Dates and Reassessment Triggers
Base review intervals on exposure rather than a fixed calendar. Vendors with broad PHI access may need quarterly access and remediation reviews, plus annual safeguard and subcontractor reviews.
Reassess when incidents, new integrations, expanded PHI uses, hosting or subcontractor changes, or material product changes alter PHI exposure. Overdue remediation and relevant regulatory developments also call for reassessment. Review planned changes before new PHI exposure begins.
Before launch, get written approval from compliance, security, procurement, and the mentorship program owner. Assign someone to fix each gap and someone to verify closure. Record the affected PHI, likelihood, impact, compensating controls, remaining risk, due dates, and escalation paths. The designated approver must accept material remaining risk; informal agreement among project staff is not enough.
Include offboarding in the approval record. Revoke accounts and API tokens, remove subcontractor access, and return or destroy PHI where feasible. Keep data export and closure evidence, including records of account revocation, subcontractor access removal, backup and replica handling, retention exceptions, and final disposal. If retention is required or destruction is infeasible, document the reason, the data retained, continuing safeguards, and permitted uses.
Conclusion: Close Material Gaps Before PHI Access
Use the completed review file to decide whether the vendor can safely handle patient mentorship PHI.
PHI access is a go/no-go decision. Approve access only when the file documents roles, a signed BAA, and controls for access, workforce conduct, encryption, logs, and incident response. A gap is material if it could expose PHI, prevent an investigation, weaken required protections, or delay breach response.
Link Warning Signs to Procurement Decisions
Connect each warning sign to a procurement action and a clear condition for approval.
| Warning sign | Procurement action | Condition for approval |
|---|---|---|
| Refusal to sign a required BAA | Pause onboarding and escalate to legal and privacy. Reject the vendor if refusal continues. | The required BAA is signed and covers the actual service. |
| Shared accounts | Block PHI access until separate accounts for each user are verified. | Activity can be traced to individual users, with role-based permissions and appropriately restricted support access. |
| Undisclosed ePHI subcontractors | Pause onboarding until the vendor provides a complete subcontractor register and contractual commitments. | Data flows are documented, and written agreements pass applicable HIPAA obligations to subcontractors. |
| Missing audit evidence | Require sample access and administrator logs, retention settings, and review records. Reject the vendor if it cannot show that the controls work. | Logs identify who accessed or changed ePHI and remain retrievable for investigations throughout the required retention period. |
| Unclear encryption coverage | Require records of encryption coverage and key management. Pause access for material gaps. | Encryption is documented for data in transit and at rest, including backups and exports, and matches the approved risk analysis. |
| Vague incident deadlines | Hold approval until notice, update, and cooperation terms are firm. | The contract sets a firm internal deadline shorter than the legal limit and preserves HIPAA reporting duties. |
Limit conditional approval to nonmaterial fixes, each with a named owner, deadline, interim control, and evidence of closure. Risk acceptance cannot waive a required BAA, required safeguards, or HIPAA reporting duties.
FAQs
How do I determine whether mentorship data is PHI?
Mentorship data counts as protected health information (PHI) when it contains individually identifiable health information that a covered entity or its business associates create, receive, maintain, or transmit. Check for patient identifiers tied to diagnoses, treatment details, call notes, or inferred health signals.
Map where the data is collected, shared, and stored. Use that map to classify it as PHI, electronic PHI (ePHI), or non-PHI.
How do I classify patient mentors under HIPAA?
Under HIPAA, patient mentors are part of your organization’s workforce. They must follow the same privacy and security requirements as other staff who handle protected health information (PHI).
Require HIPAA training and enforce the minimum necessary standard. Give mentors access only to the PHI they need for assigned patient interactions, such as first names or treatment context. Restrict access to full medical records and sensitive financial data.
What if my vendor cannot share security evidence?
Stop the technical evaluation immediately if the vendor can’t provide the required security evidence or refuses to sign a Business Associate Agreement (BAA). Sending protected health information (PHI) through a service without a signed BAA violates HIPAA.
Before integration, get a signed BAA or put a documented compensating control in place, such as redacting PHI before it leaves your environment. If neither option is possible, choose another vendor.