These questions arise from the gap between vendor marketing and operational reality. Your procurement team sees a "HIPAA compliant" badge. Your privacy officer asks what that means for the appointment reminder workflow. Your IT lead wants to know if the analytics add-on is covered. Your legal counsel points out that the BAA names a different legal entity than the one on the invoice.
A vendor evidence register answers these questions before they become assumptions. Here's what compliance teams actually ask when they're trying to document a SaaS decision.
Do We Have a BAA for the Actual Thing We're Buying?
Yes, but probably not the way you think.
A vendor may offer a BAA for certain products, plans, or configurations. The enterprise tier might be covered; the standard tier might not be. The core scheduling platform might have a signed agreement; the email notification service it uses might be provided by a separate company with no agreement at all.
Record the exact legal entity named in the BAA, the specific products and features it covers, and the plan tier you're purchasing. If your workflow includes an integration, a browser extension, a mobile app, or an AI feature, confirm whether each component is named in the agreement. HHS guidance on cloud computing makes clear that covered entities and business associates must understand the cloud environment they're using to conduct their own risk analysis and enter into appropriate agreements.
Don't write "BAA signed" in your register. Write "BAA covers Enterprise plan for Scheduler B; analytics add-on not mentioned; vendor confirmation pending."
How Do I Know if the SOC 2 Report Actually Covers Our Workflow?
You read the system description.
A SOC 2 report describes specific systems, controls, and time periods. It may include exceptions or carve out subservice organizations. It doesn't establish that the vendor will sign a BAA, that your intended product is included in the BAA, or that your configuration meets your own security requirements.
Look at the report period. If it ended eight months ago and the vendor has since added a new AI feature that processes patient intake forms, the report doesn't cover that feature. Check whether important sub-processors are included or carved out. Note any complementary customer controls, those are things you're responsible for configuring.
Record the report type, review period, relevant exceptions, and whether the system description matches the service you're actually deploying. A SOC 2 report is security-assurance evidence, not contractual evidence. Keep them separate.
What Happens When We Add an Integration?
The workflow changes, so your evidence needs to change.
You approved a scheduling platform. Then someone connects it to an email service for appointment reminders, a CRM for patient outreach, and an analytics tool for no-show tracking. You now have four or five services in the data path, not one.
Write down the workflow: "Patients submit contact and appointment information through Form A; the data is stored in Scheduler B; staff members access it through managed accounts; appointment reminders are sent through Service C; no PHI is sent to analytics." If you can't write that sentence with confidence, you don't know enough to approve the workflow yet.
Set an event-based review trigger for new integrations. Each one brings a new legal entity, a new set of sub-processors, and new operational questions about access, logging, and retention.
Who Actually Gets Access to the PHI in This System?
More people than you think.
Administrators and support personnel may have access. Emergency support procedures may bypass normal logging. Sub-processors may create, receive, maintain, or transmit PHI as part of backup, analytics, or infrastructure services.
Ask how support staff obtain access, whether that access is logged, and how the vendor handles urgent support requests. Confirm whether sub-processors are named in the BAA and whether their own agreements flow down the same protections. Review the incident-response language: who receives notice of a security incident, what timing applies, and whether the vendor's cooperation terms match your Breach Notification Rule obligations.
Customer-side safeguards also matter. Identity management, multifactor authentication, role design, device controls, logging, staff training, and offboarding procedures are your responsibility. A signed BAA doesn't configure the product. HHS risk-analysis guidance requires you to identify potential risks and vulnerabilities to all ePHI you create, receive, maintain, or transmit.
Can I Just Mark This Vendor "Compliant" and Move On?
No. Use evidence states instead.
A binary "compliant" field hides conditional, incomplete, or conflicting information. Try these states instead:
- Supported: the source directly supports the conclusion for the identified scope
- Conditional: the conclusion depends on a plan, configuration, contract, or customer action
- Missing: the needed source hasn't been obtained
- Conflicting: two sources disagree or describe different scopes
- Stale: the source no longer reflects the current product or workflow
These are evidence states, not compliance determinations. They route open questions to the right owner and prevent silence from turning into approval.
How Long Is This Evidence Good For?
Until something changes.
Set review triggers for a new contract or BAA, a plan change, a new integration, a material sub-processor update, revised retention terms, a new AI feature, a security incident, or a change in the type of PHI being handled. An annual vendor review is useful, but a workflow change can make last month's evidence incomplete.
Record the date or event that will trigger the next review. Assign an owner responsible for assembling contractual, assurance, product, and operational evidence into a single decision record.
What Should I Actually Write Down?
Enough context for the next reviewer to reconstruct your decision.
For each evidence source, record the title, owner, and location. Note the date you retrieved it and its effective or report period. Identify the legal entity, product, plan, feature, and region it covers. Write down the conclusion it supports, any conditions or limitations, and questions that remain open.
A spreadsheet works. A ticket works. A procurement record works. What matters is preserving the reasoning behind the decision before PHI enters the workflow.
Where to Go for More
Your legal, privacy, security, compliance, procurement, and operational teams should make the final call. The vendor evidence register makes their reasoning inspectable. Start with the data path, separate evidence types, record scope and dates, and reopen the review when the service or workflow changes.
