Before PHI Enters a SaaS Workflow

Building a Vendor Evidence Register

Written by Coco Yang

Introduction

A clinic can approve a scheduling platform and still miss the place where patient information leaves the approved path. An intake form may pass data to the scheduler, which sends a notification through an email service, creates a record in a customer relationship management system, and copies details into an analytics tool. The vendor review may have covered the scheduling platform. The actual workflow contains four or five services.

That is why a product name and a "HIPAA compliant" statement are not enough to document a SaaS decision. The review needs to identify the exact service, plan, configuration, integrations, users, and data flow. It also needs a record of what each source supports, what it does not support, and what still requires an answer from the vendor.

A vendor evidence register provides that record. It is not a certification score and should not replace legal, privacy, security, procurement, or clinical review. It is a practical way to keep the evidence behind a decision visible before protected health information (PHI) enters a software workflow.

Start With the Workflow, Not the Vendor Name

The first question is not simply, "Does this vendor support HIPAA?" A more useful starting question is, "What will this organization do with this exact service?"

Write down the product edition and paid plan, the features that will be enabled, the people who will have access, and the systems that will send or receive data. Include support tools, exports, backups, browser extensions, mobile applications, application programming interfaces, automation services, and optional artificial intelligence features. Then identify where PHI is expected to be created, received, maintained, or transmitted.

This boundary matters. A vendor may make a business associate agreement (BAA) available only for certain products, plans, customers, or configurations. An integration may be provided by another company. A feature may use a separate sub-processor or different retention setting. HHS guidance on cloud computing advises covered entities and business associates to understand the cloud environment they are using so they can conduct their own risk analysis and enter into appropriate agreements.

A simple workflow sentence helps anchor the review. For example: "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 the team cannot write that sentence with confidence, it is too early to approve the workflow.

Keep Different Kinds of Evidence Separate

Vendor material often arrives as a mixed folder of contracts, reports, help-center pages, questionnaires, and sales statements. These sources do not answer the same questions.

A BAA is contractual evidence. HHS explains that a business associate contract establishes permitted and required uses and disclosures, requires safeguards, addresses incident reporting, applies restrictions to relevant subcontractors, and covers return or destruction of PHI at termination when feasible. The review still needs to confirm that the agreement applies to the exact legal entity and service being purchased.

A SOC 2 report is security-assurance evidence. It can help a reviewer understand the systems, controls, time period, exceptions, and subservice organizations described in the report. It does not establish that the vendor will sign a BAA, that the intended product is included in the BAA, or that the customer's configuration is appropriate.

Product documentation explains how features work. It may describe access controls, audit logs, retention settings, encryption, data regions, or deletion behavior. Marketing language is a weaker source. It can point the team toward a question, but it should not be treated as proof that a contract, report, or technical control covers the planned workflow.

Keeping these evidence types separate prevents one familiar logo or badge from doing more work than it should.

What to Record

The register does not need to be elaborate. A spreadsheet, ticket, or procurement record can work if it preserves enough context for another reviewer to reconstruct the decision. For each item, record:

The source title, owner, and location.
The date it was retrieved and, when applicable, its effective period or report period.
The legal entity, product, plan, feature, and region it covers.
The conclusion the source supports.
Conditions and limitations stated in the source.
Questions that remain open and the person responsible for resolving them.
The date or event that will trigger another review.

Short conclusions are more useful than broad labels. "Vendor says HIPAA compliant" is difficult to act on. "BAA offered for the Enterprise plan; analytics add-on not named; vendor confirmation pending" tells the next reviewer what is known and where the uncertainty sits.

The same discipline should be used for security evidence. Instead of recording "SOC 2 available," note the report type, review period, system description, relevant exceptions, complementary customer controls, and whether important subservice organizations are included or carved out.

Check the Operational Questions

Contracts and assurance reports are only part of the review. The intended use also depends on routine operational details.

Ask which sub-processors may create, receive, maintain, or transmit PHI. Confirm how administrators and support personnel obtain access, whether that access is logged, and how emergency support is handled. Review default retention, backup retention, deletion timing, export behavior, account termination, and the process for returning or destroying data.

Incident language deserves the same attention. Identify where the vendor describes security incidents and breach notification, who receives notice, and whether the timing and cooperation terms match the organization's requirements. Customer-side safeguards should also be explicit: identity management, multifactor authentication, role design, device controls, logging, staff training, approved integrations, and procedures for offboarding users.

A signed BAA does not configure the product. HHS risk-analysis guidance makes clear that regulated organizations must identify potential risks and vulnerabilities to all electronic PHI they create, receive, maintain, or transmit. The vendor's evidence informs that work; it does not perform the organization's risk analysis for it.

Use Evidence States Instead of a Single Verdict

A binary field labeled "compliant" hides too much. Evidence is often conditional, incomplete, inconsistent, or old. A small set of evidence states makes the record more honest:

Supported: the source directly supports the conclusion for the identified scope.
Conditional: the conclusion depends on a plan, configuration, contract, location, or customer action.
Missing: the needed source has not been obtained.
Conflicting: two sources disagree or describe different scopes.
Stale: the source no longer reflects the current product, contract, report period, or workflow.

These are evidence states, not compliance determinations. They help the organization route questions to the right owner and avoid treating silence as approval.

Review Again When Something Changes

An annual vendor review is useful, but a change in the workflow can make last month's evidence incomplete. Set event-based review triggers for a new contract or BAA, a plan change, a new integration, a material sub-processor update, revised retention terms, a new artificial intelligence feature, a security incident, or a change in the type of PHI being handled.

The register should also have an owner. Procurement may hold contracts, security may review assurance reports, privacy or compliance may assess uses and disclosures, and the operational team may know the actual configuration. Someone must be responsible for assembling those pieces and recording the final conditions of use.

Conclusion

A SaaS review is easier to defend when another person can see exactly what was reviewed, when it was reviewed, and which workflow the decision covered. Begin with the data path. Separate contractual, assurance, product, and marketing evidence. Record scope and dates. Preserve unresolved questions. Reopen the review when the service or workflow changes.

The purpose of a vendor evidence register is not to produce a universal badge. It is to make the reasoning behind a decision inspectable before PHI enters the workflow. Final decisions should remain with the organization's qualified legal, privacy, security, compliance, procurement, and operational professionals.

About the Author

Coco Yang is the Founder of ComplySaaS, an educational SaaS vendor compliance research project that organizes public HIPAA, BAA, PHI, and SOC 2 signals, source dates, workflow conditions, and verification questions. Her work is limited to documented vendor-research practice; she is not presenting herself as an attorney, auditor, healthcare provider, or compliance certifier. Company website: https://www.complysaas.com/

References

U.S. Department of Health and Human Services. "Guidance on HIPAA & Cloud Computing."