Do we need a Business Associate Agreement with our scheduling software?

It depends on your regulatory status. A Business Associate Agreement is a HIPAA construct: it is required when your organization is a HIPAA covered entity and a vendor creates, receives, maintains, or transmits protected health information on your behalf. Many pregnancy help organizations are not covered entities because they do not bill health insurance electronically, so a BAA may not be legally triggered. That does not remove the need for a written agreement. Even outside HIPAA, you should have a contract that defines how the vendor protects, uses, and returns your client data. Establish covered-entity status first, then apply the right instrument.

What is vendor risk in healthcare?

Vendor risk is the exposure that comes from third-party tools that store or process your data. In healthcare and adjacent nonprofits, most sensitive client information lives inside scheduling, client-management or EHR, donor CRM, and text-messaging systems you do not control. If a vendor is breached, misconfigured, or quietly changes how it uses your data, your clients are exposed even though the failure happened outside your walls. Managing vendor risk means knowing every tool that touches client data, how each protects it, and what your agreement with each one actually says.

How do we vet a client-management system for privacy?

Before signing, ask where the data physically lives and who can access it, whether encryption and multi-factor authentication are standard, what the vendor's breach history and sub-processors are, and how client information is exported if you leave. Ask directly whether any AI feature uses your client data for model training, and get the answer in writing. Request the vendor's security documentation and, where you are a covered entity or protected health information is handled on your behalf, a Business Associate Agreement. Treat the sales page as a starting point, not evidence.

Vendor-Risk Checklist for Scheduling & Client-Management Systems

Why vendor risk is where the data actually is

A decade ago, protecting client information mostly meant locking a file cabinet and securing one shared drive. That mental model has quietly stopped matching reality. Today a pregnancy help organization’s most sensitive records — names, contact details, pregnancy status, appointment histories, follow-up conversations — are spread across software the organization does not own and cannot see inside. The scheduling tool holds who is coming and when. The client-management or EHR system holds the intake and service history. The donor CRM often holds contact details and notes. The text-messaging platform holds follow-up threads that can be as revealing as any chart.

Each of those is a vendor. Each one is a place your data can leak, be misconfigured, or be used in ways you never agreed to — and when that happens, the exposure lands on the women who trusted you, regardless of whose server failed. That is the heart of the matter: you can run a careful office and still carry real risk, because the risk moved into systems you rent rather than own. Vendor oversight is not administrative hygiene layered on top of the real work. In a software-run clinic, it is the real work of protecting client data.

Whether formal rules such as HIPAA apply to your organization is a separate, fact-specific question — and for many pregnancy help organizations the answer is that they are not covered entities. We walk through that determination in does HIPAA apply to your pregnancy help organization? The checklist here holds regardless of that answer, because attackers, insurers, and the people you serve do not wait on a regulatory finding.

The checklist

Work through these in order. For each item we describe what good looks like, so the goal is concrete rather than aspirational.

A complete vendor inventory. List every tool that stores or processes client or health information — scheduling, client-management or EHR, donor CRM, texting and email, forms, file storage, and anything a volunteer signed up for on their own.

What good looks like: one living document naming each vendor, what data it holds, who owns the relationship internally, and the renewal date. If a tool is not on the list, it is not being governed.
Where the data physically lives and who can access it. For each vendor, know what data leaves your building, where it is stored, and which people — yours and the vendor’s — can reach it.

What good looks like: you can answer “where is our client data right now?” for every system without guessing, and access is limited to the people who genuinely need it.
A written agreement for each vendor. Every tool that touches client data should be covered by a contract that defines how the vendor protects, uses, and returns your data. Where your organization is a HIPAA covered entity, or a vendor handles protected health information on your behalf, that agreement must include a Business Associate Agreement — a HIPAA instrument, not a universal one. Many pregnancy help organizations are not covered entities, so a BAA may not be legally triggered; a clear written agreement still is. See does HIPAA apply? to settle which instrument you need.

What good looks like: no vendor holds client data on a handshake, and where a BAA applies it is signed and on file.
Vendor security posture. Ask each vendor how it protects your data: multi-factor authentication, encryption in transit and at rest, breach history, and which sub-processors it hands your data to downstream.

What good looks like: you have documentation, not marketing copy, and you know the vendor’s sub-processors rather than being surprised by them.
Staff and volunteer access controls within each tool. Inside every system, control who can see and do what. Volunteers rarely need the same access as a director, and departed people need access removed promptly.

What good looks like: access is role-based, reviewed on a schedule, and revoked the day someone leaves — not months later.
Data export and orderly offboarding on exit. Before you depend on a vendor, know how you would get your data out and how the vendor deletes it if you leave.

What good looks like: you can export your records in a usable format on demand, and the agreement says what happens to your data when the relationship ends.
AI features inside vendors. Many tools have added AI features that may process — or train on — the data you put in. Ask directly whether client information is fed to model training, and get the answer in writing.

What good looks like: you know, per vendor, whether client data trains a model, and you have turned off or contractually excluded any use you did not intend.
A review cadence. Vendors change — new owners, new sub-processors, new AI features, new terms. A one-time inventory decays.

What good looks like: the inventory and agreements are reviewed on a standing schedule, so oversight is continuous rather than a scramble during survey week.

How to evaluate a new vendor before signing

The cheapest time to manage vendor risk is before the contract exists. When a new scheduling or client-management system is on the table, run a short due-diligence sequence:

Confirm what data it will hold — and whether it truly needs client or health information to do its job.
Ask where the data lives and who can access it, including sub-processors, before you enter anything sensitive.
Request security documentation — MFA, encryption, breach history — rather than accepting the sales page as evidence.
Ask the AI question in writing: is our client data used for model training, and can that be excluded?
Settle the agreement, including a Business Associate Agreement where you are a covered entity or protected health information is handled on your behalf.
Confirm the exit — how you export your data and how the vendor deletes it — before you are dependent, not after.

Running this sequence early costs a short conversation. Skipping it costs a migration, or a breach, later. For the wider view of how these controls fit together, our security risk assessment checklist places vendor oversight alongside the rest of a proportionate program, and the questions in the cybersecurity questions every board should ask help leadership keep the conversation going.

The honest limit

An inventory and a stack of signed agreements are the floor, not the ceiling. They tell you what you have and what was promised. They do not tell you whether a vendor’s security actually works, whether a sub-processor changed last quarter, or whether an AI feature was switched on by default in the last update. A vendor’s sales page will not volunteer those things.

That is where periodic independent review earns its place. Reviewing your vendors and their evidence on a schedule — rather than trusting the marketing — is what catches the gap between what was promised and what is true. Clinical Risk Monitor exists to run that standing function for organizations that cannot staff it full-time: industry-standard tooling supports the scanning and evidence, an AI analysis layer accelerates the mapping, and a named compliance expert reviews the evidence and signs the deliverables. The AI drafts; it never signs. We are not a certification body, and we do not certify compliance with any law. We help you run a verified privacy and security program — including the vendors where your client data actually lives — that your board, insurer, and accreditor can examine.

Questions organizations ask next

This article is educational and does not create an attorney-client relationship. Covered-entity status and the applicability of Business Associate Agreements depend on your facts; consult qualified counsel for legal determinations.