HIPAA Compliance
General Compliance, HIPAA

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:

  1. The source title, owner, and location.
  2. The date it was retrieved and, when applicable, its effective period or report period.
  3. The legal entity, product, plan, feature, and region it covers.
  4. The conclusion the source supports.
  5. Conditions and limitations stated in the source.
  6. Questions that remain open and the person responsible for resolving them.
  7. 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."

U.S. Department of Health and Human Services. "Business Associate Contracts."

U.S. Department of Health and Human Services. "Guidance on Risk Analysis."

National Institute of Standards and Technology. "SP 800-66 Rev. 2: Implementing the HIPAA Security Rule."

Copyright © 2026 American Institute of Healthcare Compliance All Rights Reserved

Share 0
Post 0
Share 0
Read More
HIPAA Compliance
HIPAA

Strong BAAs Build a Chain of Trust

Business Associate Agreements & Covered Entity Compliance 

Written by Joanne Byron, LPN, BS, CCA, CIFHA, CHA, COCAS, CORCM, CHCO, HPOC, OHCC, CMDP, ICDCT-CM/PCS 

Building a chain of trust between healthcare providers (Covered Entities) and Business Associates (BAs) is a regulatory requirement under HIPAA designed to ensure that Protected Health Information (PHI) remains secure throughout its entire lifecycle, even when handled by third parties.

This chain of trust ensures that privacy and security obligations flow down to every subcontractor that creates, receives, maintains, or transmits PHI. This can produce increased confidence with your organization’s ability to earn and maintain patient trust.


Is Your Organization a Covered Entity, Business Associate or Both?

According to the Office of Civil Rights (OCR), the HIPAA enforcement agency, a Covered Entity (CE) is one of the following:

A Health Care Provider

A Health Plan

A Health care Clearinghouse

This includes providers such as:

  • Doctors
  • Clinics
  • Psychologists
  • Dentists
  • Chiropractors
  • Nursing Homes
  • Pharmacies

...but only if they transmit any information in an electronic form in connection with a transaction for which HHS has adopted a standard.

This includes:

  • Health insurance companies
  • HMOs
  • Company health plans
  • Government programs that pay for health care, such as Medicare, Medicaid, and the military and veterans health care programs.

This includes entities that process nonstandard health information they receive from another entity into a standard (i.e., standard electronic format or data content), or vice versa.

It may not always be straightforward. If you are not sure if your organization is a covered entity – the Centers for Medicare & Medicaid Services (CMS) provides a an educational website and also a Covered Entity Decision Tool (58-pagePDF).

A HIPAA covered entity (CE) acts as a business associate (BA) when it performs functions or services involving protected health information (PHI) on behalf of another covered entity. This activity-specific role requires a Business Associate Agreement (BAA) for that specific work, even while the organization acts as a CE for its own operations.

The key distinction is that the "business associate" status applies to the service being performed (e.g., providing administrative services) rather than the entity's status as a healthcare provider or payer.

Key Scenarios and Requirements:

  • Services for Another CE: If a hospital (CE) handles billing or provides administrative services involving PHI for an unaffiliated clinic (another CE), the hospital acts as a BA.
  • Subcontractor Relationships: If a BA hires a covered entity to perform work involving PHI, that hired CE is acting as a BA to that BA.
  • Data Sharing: While sharing for "treatment" between CEs doesn't need a BAA, sharing for services to one another (e.g., managing a personal health record or PHR) does. Common examples include patient portals, health apps, and online trackers, which can contain medical history, diagnoses, and medication logs. According to OCR, it is an electronic application used by individuals to maintain and manage their own health information, rather than records solely controlled by a doctor or insurer (EHR).

          PHRs are often, but not always, covered by HIPAA regulations. Key details include:

  • Control: Unlike Electronic Health Records (EHRs) managed by providers, PHRs are managed by the individual or their caregiver.
  • Types: They can be tethered (linked to a provider) or standalone (independent).
  • HIPAA Coverage: If a PHR is provided by a HIPAA-covered entity (like a health plan or doctor), it is covered under the HIPAA Privacy Rule.
  • Alternative Protection: If a PHR is offered by a company not covered by HIPAA, it is governed by the FTC’s Health Breach Notification Rule.
  • Compliance: When acting as a BA, the entity must adhere to HIPAA Security Rule and Privacy Rule requirements for the PHI it handles for that specific relationship.

A covered entity functions as a business associate in the following type of situations:

  • Centralized Administrative Services: A hospital (CE) provides billing, claims processing, or data analytics services for an independent physician group or affiliated clinic.
    • A hospital acting as a central billing clearinghouse for independent physician groups.
  • Specialized Clinical Services: An independent laboratory (CE) that typically treats patients directly acts as a BA if it analyzes data for a health plan's quality improvement program.
    • A large health system providing laboratory services.
  • Data Processing Support: A health insurance company (CE) assists another health plan with data processing or administrative tasks.
    • Managed Service Providers or IT support that requires access to another entity’s patient records.
  • Patient Safety Organizations (PSOs): PSOs are specifically treated as business associates when they receive and analyze patient safety event reports from other providers. Key Covered Entity Requirements regarding use of PSOs:
    • Risk Analysis & Mitigation: CEs must perform risk assessments to identify threats to ePHI, including data shared with PSOs, and implement appropriate security measures.
    • Staff Training & Governance: Implement comprehensive training on identifying PSWP and handling it according to both HIPAA and safety rules.
    • Breach Reporting: Any unauthorized disclosure of PSWP is treated as a breach, requiring prompt response and reporting to the Office for Civil Rights (OCR)

Compliance Obligations for the Dual Role

When acting as a business associate, the covered entity is required to:

  • Sign a BAA: It must execute a formal agreement with the other covered entity before PHI is shared.
  • Adhere to BA Duties: It must follow the specific privacy and security requirements outlined for business associates, including reporting breaches and following "minimum necessary" standards.
  • Segregate Data: Large organizations often use internal "self-BAAs" or separate departments to ensure PHI from their BA activities is not improperly mingled with their own patient data.

For more detailed regulatory definitions, you can refer to the HHS Summary of the HIPAA Privacy Rule.

When a BAA is NOT Required Between Covered Entities

Not all exchanges of PHI between covered entities trigger a business associate relationship. A Business Associate Agreement (BAA) is generally not required for:

  • Treatment Purposes: When two independent providers disclose or exchange PHI for treatment purposes, such as a doctor referring a patient to a specialist or treating a shared patient.
  • Standard Payment Activities: When a provider submits a claim to a health plan and the plan pays it; both are acting on their own behalf as covered entities.
  • Organized Health Care Arrangements (OHCA): When entities participate in a joint arrangement, such as a group health plan and its insurer, to perform joint health care activities.
  • Conduit Exception: Organizations that only transport PHI and do not access or store it, such as the U.S. Postal Service, internet service providers (ISPs), or private couriers.
  • Incidental Access: Personnel who might see or hear PHI by chance while providing services, such as janitors, maintenance workers, or electricians, where the access is not the purpose of the work.
  • De-identified Data: Sharing data that does not contain identifiers, as long as it cannot be re-identified.

Not sure if a BAA is required?

Do you need help determining if a specific service your organization provides requires a Business Associate Agreement? Consult with a HIPAA-experienced attorney or consultant instead of “guessing” or consulting with an unqualified professional.

Act Now to be HIPAA Compliant

The HIPAA Final Rule is expected to be published in May 2026, with a 60-day effective date followed by a 180-day grace period for compliance. Covered entities should begin updating their policies now to meet these more stringent requirements.

Establishing a strong chain of trust under HIPAA requires vendor contracts to be updated, compliant and translate legal requirements into operational controls. A robust BAA ensures that all parties involved in creating, storing, and transmitting ePHI (overed entities, business associates, and subcontractors), are bound by the same rigorous privacy and security standards, mitigating risk in an era where nearly half of all HIPAA breaches involve third-party vendors.

A legally binding Business Associate Agreement (BAA) is the foundational document of the chain of trust.

A robust BAA ensures that all parties—covered entities, business associates, and subcontractors—are bound by the same rigorous privacy and security standards, mitigating risk in an era where nearly half of all HIPAA breaches involve third-party vendors.

  • Mandatory Clauses: The BAA must explicitly outline permitted uses/disclosures, require the implementation of safeguards (administrative, physical, and technical), and mandate prompt breach reporting.
  • Defined Scope and Data Flows: Explicitly mapping where Protected Health Information (PHI) is created, stored, or transmitted to ensure the "minimum necessary" standard is applied.
  • Subcontractor Flow-Down Obligations: A crucial component requiring the business associate to bind any subcontractors to the same level of security and privacy protections.
  • Stringent Breach Notification Procedures: Defining clear timelines (e.g., within 60 days, or faster, such as 24-hour notice for emergency plans) for reporting incidents to the covered entity.
  • Security Safeguards Requirement: Mandating administrative, physical, and technical safeguards, including encryption in transit/at rest, multi-factor authentication (MFA), and regular risk assessments.
  • Termination and Destruction Protocol: Ensuring that upon contract termination, PHI is either returned or securely destroyed, with no further retention.
  • Audit and Compliance Rights: Granting the covered entity the right to audit the vendor's security controls and requiring access to records for HHS investigations
  • Pre-engagement Requirement: The BAA must be signed before any PHI is shared.

Do Your Due Diligence - Trust is built on verification, not just contracts. Conduct comprehensive risk assessments to evaluate a vendor's security posture, policies, and procedures before partnering.

  • Verify the vendor’s compliance.
  • Review the vendor's documented risk analyses, audit trails, and, if applicable, third-party certifications.

Best Practices for Maintaining the Chain of Trust –

  • Regular Updates: Reviewing and updating BAAs whenever services, technologies (e.g., cloud, AI), or regulations change, such as preparing for upcoming 2025 HIPAA revisions.
  • Vendor Due Diligence: Assessing a business associate's security posture before signing a BAA, rather than relying solely on the contract for security.
  • Employee Training: Ensuring the business associate trains its staff on the specific requirements of the BAA.
  • Assigning Liability: Clearly defining which party covers financial penalties, legal fees, or remediation costs in the event of a breach.

Consult with a HIPAA legal expert to assist your organization as you update your BAAs to be compliant to the New Final Rule. By tightening your BAAs and relationships with vendors, you will move from a compliance posture to an active, operationalized partnership that protects patient data, reputation and builds patient trust.

About the Author

Joanne Byron, BS, LPN, CCA, CHA, CHCO, CHBS, CHCM, CIFHA, CMDP, COCAS, CORCM, OHCC, ICDCT-CM/PCS is an educator with  Officer of the American Institute of Healthcare Compliance, a Licensing/Certification non-profit partner with CMS. She shares her experience of over 40 years as a nurse, consultant, auditor, and investigator in the healthcare field.

References

Copyright © 2026 American Institute of Healthcare Compliance All Rights Reserved

Share 0
Post 0
Share 0
Read More