The Health System Security Review Your BAA Won't Pass

The short answer

A business associate agreement (BAA) is the contract HIPAA requires before you touch a health system’s patient data. Signing it is a legal promise. It’s also the easy part, and every serious health system knows it, because the BAA says what you’ll protect without saying how.

The security review is where they ask how. Before a pilot, a health system’s security team wants your architecture, in writing, with proof:

1. Keys. How encryption keys are managed, who and what can use them, and whether the hospital can hold its own.
2. Tenancy. How one customer’s patient data is kept from reaching another’s, and how you know.
3. Location and flow. Where patient data, backups and logs live, and a map of where data goes.
4. Fourth parties. Every subcontractor that touches the data, starting with your cloud and your AI model provider, and whether each one’s agreement covers what you actually use.
5. Identity. Single sign-on, multi-factor authentication, and who on your team can see patient data.
6. Logs. Who accessed which record, when, and whether the hospital can get those logs.
7. Testing. Your last penetration test, its scope, and how fast you patch.
8. Clocks. How fast you’ll report a suspected incident, and how fast you can restore.
9. AI. Whether you train on their data, which models see prompts, how long you keep them, and how you’ll warn them before a model changes.

None of this is exotic. It’s a short list of design decisions most startups made in their first month without writing them down. The founders who move fastest through a review wrote them down, attached the evidence, and sent the pack before the questionnaire arrived. The rest of this post walks through each answer with the health systems’ own wording, and the pre-flight further down drafts the pack for you.

What a BAA promises, and what it doesn’t

HIPAA’s rules for business associates say what the contract must contain: what you may do with protected health information, that you’ll use appropriate safeguards, that you’ll report breaches and security incidents, that your own subcontractors will sign the same terms, and that you’ll return or destroy the data at the end (45 CFR 164.504(e) and 164.314(a)). HHS publishes sample provisions that many templates start from.

Read that list again and notice what’s missing: keys, tenancy, logs, regions, models. The agreement commits you to “appropriate safeguards” and to the HIPAA Security Rule, and leaves the design of those safeguards to you. That’s by design. It also means a health system’s procurement team can’t tell from your signed BAA whether you’d survive a bad week, so a second team asks.

There’s a second gap, and it’s about time. HIPAA requires a business associate to notify the covered entity without unreasonable delay, and no later than 60 calendar days after discovering a breach (45 CFR 164.410). A health system running a hospital can’t wait 60 days to learn its scheduling vendor was compromised, so its own paper asks for days or hours. We’ll get to those clocks.

“Contracts aren’t controls.”

From the notes to episode 75 of The Security Podcast of Silicon Valley, with Jonathan Mortensen of Confident Security

Then there’s the regulation everyone keeps calling final. In January 2025, HHS proposed a broad update to the HIPAA Security Rule. It isn’t law. The federal regulatory agenda lists it as a long-term action, with final action projected for July 2027 (Reginfo.gov), and HHS’s own fact sheet says “the current Security Rule remains in effect” (HHS).

It matters anyway, because its checklist overlaps with much of what health system vendor reviews already ask. The proposal would require encryption of patient data at rest and in transit, multi-factor authentication, “a technology asset inventory and a network map that illustrates the movement of ePHI,” written procedures to restore certain systems “within 72 hours,” vulnerability scanning every six months and penetration testing every year. It would also have business associates notify covered entities “no later than 24 hours after activation” of a contingency plan, and verify their technical safeguards to their covered entities at least once a year, in a written analysis by a subject matter expert. Health systems can read the same proposal you did, and their risk teams don’t have to wait for a final rule to ask.

"I thought these haven't been approved/finalized yet?"

throw03172019, in the Hacker News thread on a "2026 HIPAA Security Rule Update" article, May 25, 2026. They hadn't.

We wrote about what that proposal means for a team that isn’t ready to hire a security lead in our Twin Cities Startup Week post. The short version: if you sell to health systems, your buyer is your compliance deadline, and your buyer moves faster than HHS.

"Universal encryption of PHI at rest is going to be INCREDIBLY painful."

iloveoof, in the same Hacker News thread. For a hospital running decades-old systems, maybe. For a cloud-native startup, it's a setting, and you should be able to show it.

Why health systems read past the paperwork

Because the vendors were the breach. Change Healthcare, a business associate that processes claims for much of the industry, notified HHS’s Office for Civil Rights that “approximately 192.7 million individuals have been impacted” by its 2024 ransomware attack (HHS). Conduent, which does mailroom, payment and back-office work for health plans, has reported at least 62,224,658 people affected by an intrusion that ran from October 2024 into January 2025 (HIPAA Journal). HIPAA Journal’s February 2026 report on 2025’s large breaches put 35.8% of them at business associates (HIPAA Journal).

The one that should get a digital health founder’s attention is smaller. Serviceaide, which HIPAA Journal describes as a business associate offering “agentic AI-powered agents for IT and workflow management,” left a Catholic Health Elasticsearch database reachable without authentication from September 19 to November 5, 2024. It held information on 483,126 patients (HIPAA Journal). No exotic attack, just a database without a login.

Then come the regulators, years later. In April, the Office for Civil Rights announced a $225,000 settlement with Consociate, a business associate that administers health plans, over a January 2021 ransomware attack, and the only finding it cited was the lack of an accurate and thorough risk analysis (HHS). OSF HealthCare signed a $552,250 settlement on July 1, 2026, for ransomware it discovered on April 23, 2021 (HHS). MMG Fusion, a dental marketing software company, paid $10,000 for a 2020 intrusion, including for failing to notify the covered entities whose data it held (HHS).

So a health system’s security team reads your BAA the way a bank reads a borrower’s promise to repay: necessary, and not the point. One HIPAA and SOC 2 operator put it from the vendor’s side of the table:

The contract is where security actually gets decided.

Jessie Hoch · Director of IT, Security and Compliance · October 8, 2026

Load the post from LinkedIn

"HIPAA compliance, HiTrust certification, BAAs, etc are table stakes"

chevman, on the Hacker News launch thread for a HIPAA compliance startup, February 2024. The rest of the comment says the real hurdle comes after: liability and indemnification terms in the contract.

The good news is that the questions are public. Health systems, universities and their industry council have published the exact wording.

The questions, in their own words

You don’t have to guess what the review will ask. These documents are a search away, and between them they cover almost everything you’ll see:

• McLaren Health Care’s Vendor Security Survey, a Michigan health system’s questionnaire with questions like “Is the application isolated on the host system(s), including a separate infrastructure?” (McLaren). It still asks about SSAE 16 reports, so expect old and new questions side by side.
• MD Anderson’s Rider 118, the cancer center’s information security terms, which ask for “dedicated customer servers” or an explanation of “a secure virtual or segmented configuration,” and a site visit for a security audit “within 24 hours notice” (MD Anderson).
• The University of California’s Appendix DS, the data security terms required “whenever a Supplier accesses, collects, processes, or maintains Institutional Information,” with a 2021 revision hosted by UCLA Health (UC Office of the President; Appendix DS).
• The Health Sector Coordinating Council’s model contract language, version 2, written for medical technology suppliers, with clauses for hosted and cloud solutions that apply to software vendors too (HSCC, November 2025).
• The Council’s third-party AI risk guide, published in April, which reads like the questionnaire an AI feature will face (HSCC, April 2026).
• HHS’s cybersecurity performance goals for healthcare, which put “Vendor/Supplier Cybersecurity Requirements” among the essential goals for healthcare organizations (HHS).

Here’s how their questions line up, one example each:

Theme	How they ask it	Who asks
Keys	”How are encryption keys managed and secured?”	Censinet’s list of common questions
Encryption	”How does your system secure data both in transit and at rest?”	McLaren
Tenancy	”Confirm data isolation and access controls”	HSCC AI guide
Location	”Does your organization store any data off-shore”	McLaren
Data flow	”a network map that illustrates the movement of ePHI”	Proposed HIPAA Security Rule
Subcontractors	”Cloud service provider relationships (especially for LLMs like OpenAI, Anthropic, etc.)”	HSCC AI guide
Logs	”What level of auditing does the system support?”	McLaren
Testing	”the date of the last comprehensive attack and penetration test”	McLaren
Incidents	”seventy-two (72) calendar hours after the initial suspicion”	University of California
AI training	”Vendor cannot use organizational data to train or improve models without explicit written consent”	HSCC AI guide
Exit	”documented confirmation of Customer Data wipe or destruction”	HSCC model contract language

The pre-flight below has 24 of them, with a draft answer for each. First, the two questions founders find hardest to answer well: keys and tenancy.

Keys: “How are encryption keys managed and secured?”

Almost every startup can say its data is encrypted at rest. That’s a checkbox in your cloud console, and reviewers know it. The key question is a different one. It asks whether you’ve thought about who can decrypt.

Here’s what a reviewer is listening for, in order:

1. What’s encrypted. Databases, object storage, backups, logs and analytics copies, not just the main database.
2. Where the keys live. In a cloud key management service such as AWS Key Management Service, Google Cloud KMS or Azure Key Vault, or a hardware security module, never in code or an environment file.
3. Who and what can use them. The services that need a key, and not your whole engineering team.
4. Whether every use is logged. Key management services can record each decrypt call, so you can show who used which key and when. AWS does it by default; in Google Cloud and Azure you turn that logging on.
5. How keys rotate. Automatic rotation is a setting in every major cloud.
6. Whether customers are separated. Per-customer keys, so one customer’s data can be made unreadable without touching anyone else’s.
7. Whether the hospital can hold its own key. The question you’re most likely to get from the biggest systems.

The pattern that answers the first six is called envelope encryption: your data is encrypted with data keys, and the data keys are encrypted with a key that never leaves the key management service (Google Cloud). Give each customer its own data keys, restrict key use to the services that need it, and you get a bonus at the end of the contract: destroy that customer’s keys and every copy encrypted under them is unreadable, backups included. That makes the destruction certificate in the exit questions a lot easier to sign.

Write your key model down in your cloud provider’s own words, because reviewers will ask about it in those words. One security chief learned that the hard way:

AI-drafted follow-up questions that nobody checked against the document they were drafted from.

Thomas Allen · Principal Consultant and Chief Information Security Officer · September 16, 2026

Load the post from LinkedIn

Then comes the seventh question. Some large health systems ask whether they can hold their own key, and they’ve seen it offered. OpenAI’s ChatGPT for Healthcare, launched in January and rolling out at institutions including Cedars-Sinai, HCA Healthcare and Memorial Sloan Kettering, offers “customer-managed encryption keys” alongside data residency, audit logs and SAML single sign-on (OpenAI). When the largest vendors ship a control, it becomes a question for everyone else.

Customer-managed keys are a real feature with a real cost, so offer them on purpose. The strongest version, where the key sits outside your cloud entirely, comes with Amazon’s own warning: “For most workloads, the additional operational burden and greater risks to availability and performance will exceed the perceived security benefits of external key stores.” And if that external key is lost, “ciphertext encrypted under the associated KMS key is unrecoverable” (AWS). For most startups, the right answer is per-customer keys in your own key management service today, customer-managed keys in the customer’s own cloud account for the enterprise tier when a deal needs them, and a written note on which you offer.

If you want to go deeper on keys, Riad Wahby of Cubist explained on episode 69 how startups can get secure key management without giving up speed. If keys are a feature request in your pipeline rather than a design question, building them into your product is part of our product security work.

Tenancy: “Is the application isolated?”

That’s McLaren’s wording: “Is the application isolated on the host system(s), including a separate infrastructure?” MD Anderson asks for “dedicated customer servers” or an explanation of how the vendor achieves isolation in “a secure virtual or segmented configuration.” The Council’s AI guide just says “Confirm data isolation and access controls.” Three phrasings, one question: if your code has a bug, can one hospital see another hospital’s patients?

Amazon’s 2020 whitepaper on tenant isolation, written for software companies, is blunt about the trap founders fall into. Logging people in isn’t isolation: “getting beyond the entry points of a login screen or an API does not mean you have achieved isolation.” And it’s honest about developers: “it’s unrealistic to expect that they will never unintentionally cross a tenant boundary” (AWS). The fix is to enforce the boundary below the application code, so a missing filter in one query can’t cross it.

There are three common ways to do that, and each has an honest answer for the review:

• A separate cloud account or project per customer. The strongest boundary and the easiest to explain, and the most expensive to run. Health systems that ask for “dedicated customer servers” love it.
• A separate database or schema per customer. A solid middle ground. The boundary is the database connection, so your answer explains how the application picks the right one and why it can’t pick the wrong one.
• Shared tables with a tenant identifier the database enforces. The cheapest, and the one that needs the most care. In Postgres, row-level security denies by default when a table has no policy, but “Superusers and roles with the BYPASSRLS attribute always bypass the row security system,” and table owners do too unless you turn on FORCE ROW LEVEL SECURITY (PostgreSQL). Connect as a role that owns nothing and bypasses nothing, and set the tenant at the start of every transaction, not once per pooled connection.

Row-level security that’s switched on but wrong is worse than none, because it looks done. A 2025 vulnerability record for apps generated by Lovable described “an insufficient database Row-Level Security policy” that let unauthenticated attackers read or write arbitrary tables; Lovable disputes it (NVD). The biggest platforms get this wrong too: Wiz’s ChaosDB research in 2021 found “complete unrestricted access to the accounts and databases of several thousand Microsoft Azure customers” (Wiz), and a 2025 flaw in Microsoft Entra ID tokens could, in its finder’s words, have allowed him “to compromise every Entra ID tenant in the world” before Microsoft fixed it (Dirk-jan Mollema).

So isolation is something you test, not something you assert. Add tests that log in as one customer and try to read and write another customer’s records, on every build, and fail the build if they succeed. Ask your penetration testers to try the same thing, and make sure the letter they write names cross-tenant access in the scope. Reviewers read scope closely, as we covered in what a buyer’s security team actually reads, and our penetration testing can put it in scope.

Separating each client's data so the agent cannot read across is a preventive control.

Ademola Isimeme Odewade · Founder and CEO, K-DEMS Consulting · October 12, 2026

Load the post from LinkedIn

Where patient data lives and moves

HIPAA doesn’t say patient data has to stay in the United States. Your customers’ contracts often do, and so does Texas.

Texas Senate Bill 1188 requires electronic health records to be “physically maintained in the United States or a territory of the United States,” and it explicitly covers records “stored by a third-party or subcontracted computing facility or an entity that provides cloud computing services.” It applies to storage “on or after January 1, 2026, regardless of the date on which the electronic health record was prepared” (Texas Legislature). The Health Sector Coordinating Council’s model contract language goes further: no “Customer Sensitive Information” may be “stored, processed, or maintained outside of the United States, United States territories, and Puerto Rico” by the vendor or its subcontractors “without the Customer’s prior written approval,” and backups belong “in physically protected, limited-access facilities within the United States” (HSCC).

Two details trip founders up. First, McLaren’s offshore question asks about people as well as servers: whether you “store any data off-shore,” and whether you have “employees working in off-shore components, or off-shore subcontractors or agents with access to servers or information systems” that handle its patient data. A contractor in another country with production access is part of the answer. Second, logs are data. The University of California’s appendix counts “application logs, metadata, and data derived from such data” as institutional information, so the log pipeline you send to a third-party service in another region is in scope too.

The proposed HIPAA update asks for “a technology asset inventory and a network map that illustrates the movement of ePHI.” Draw it before anyone asks. List every system that stores or processes patient data, including analytics, error tracking, support tools and AI providers, with its region and owner. Half the review’s questions get easier once that map exists, and you’ll usually find one tool nobody remembered.

Your AI vendors are their fourth parties

To a health system, you’re a third party. Your cloud provider and your AI model provider are fourth parties, and the Council’s April guide tells reviewers to ask about them by name: “Cloud service provider relationships (especially for LLMs like OpenAI, Anthropic, etc.)” (HSCC). The same guide lists the AI contract terms and checks you should expect:

• “Vendor cannot use organizational data to train or improve models without explicit written consent.”
• “Confirm data isolation and access controls.”
• “Advance notification requirements (e.g., 30 days for non-critical, 72 hours for security patches),” for updates, patches and feature changes.
• “Breach notification timelines specific to AI systems (e.g., 2 days for AI-related incidents).”
• “Timeline for data return (e.g., 30 days post-termination).”
• “Right to audit security controls.”

Your vendor security review was built for software. AI isn't just software.

Alison Duggins · Business Information Security Officer · October 7, 2026

Load the post from LinkedIn

Here’s the part that catches founders: your model provider’s BAA probably doesn’t cover everything you use. The agreements are scoped by product and feature, not by company:

• Anthropic provides a BAA “covering our HIPAA-ready services, such as use of our first-party API,” and it “excludes features such as Claude Console, Cowork in the cloud, or features currently in beta.” Its feature tables mark the Batch API, Code Execution and Web Fetch as not covered and not available to HIPAA-ready accounts, and say data you send to outside parties through external MCP servers isn’t covered. And “Covered Models require 30-day data retention and aren’t available with zero data retention (ZDR) enabled” unless Anthropic has expressly authorized it for your organization (Anthropic).
• OpenAI says “Most API services are covered, with a few exceptions,” that “we don’t offer a BAA for ChatGPT Business,” and that it reviews “each BAA request on a case-by-case basis” (OpenAI).
• Google Cloud tells customers not to use pre-release offerings with protected health information unless the offering’s terms say otherwise, and reminds them that HHS doesn’t offer a HIPAA certification (Google Cloud).
• Microsoft makes its BAA available through its Product Terms, and adds that “Microsoft doesn’t inspect, approve, or monitor your applications deployed on Azure” (Microsoft).
• Amazon Web Services requires a business associate addendum before you use eligible services with patient data (AWS), and says Amazon Bedrock deploys models in accounts its own service team owns and operates: “Model providers don’t have any access to those accounts” (AWS).

The practical fix is a one-page table you keep current: each AI feature in your product, the provider and model behind it, whether that exact feature is covered by the provider’s BAA, how long the provider keeps prompts and outputs, and the region it runs in. Check it whenever you adopt a new feature, because a beta tool you add in a hurry is often the one the agreement leaves out. Our AI and HIPAA work starts with exactly that table.

Health systems are building their own AI governance at the same time, and it flows downhill to vendors. Mass General Brigham requires every AI vendor to fill out a standard assessment form, Becker’s reported, and its chief health information officer, Rebecca Mishuris, said “Even being able to fill out that form is a non-negotiable” (Becker’s Hospital Review). The Joint Commission announced a Responsible Use of AI in Healthcare certification for hospitals and health systems in June, covering areas that include governance and data management (HealthSystemCIO). It certifies the health system, not your product, but a hospital working toward it will want evidence from the vendors whose AI it runs. HITRUST, for its part, now offers an AI Security Assessment that can be added to its e1, i1 or r2 assessments or pursued on its own (HITRUST), and our HITRUST certification work can include it.

The health sector's own 87-page guide to agent security does not mention sandboxes.

Matthew Beaverson · CTO advisory, healthcare technology · October 12, 2026

Load the post from LinkedIn

If you want the longer conversation about using AI without handing over your data, Jonathan Mortensen of Confident Security walks through confidential compute and attestation on episode 75, including how founders pass security reviews with it.

The clocks in their contract

HIPAA gives a business associate no more than 60 days to report a breach. Read a health system’s paper, and the guidance and proposed rule behind it, and you’ll find much shorter clocks that often start earlier than you’d expect:

Clock	What starts it	Where it comes from
24 hours	Activating your contingency plan	The proposed HIPAA Security Rule update (not final)
24 to 48 hours	A security incident, given as an example	The Health Sector Coordinating Council’s AI guide
72 hours	”the initial suspicion of a Security Incident and/or Breach”	University of California Appendix DS
72 hours	Restoring critical systems and data after a loss	The proposed HIPAA Security Rule update (not final)
3 business days	Learning that a product vulnerability is being exploited or is on CISA’s known-exploited list	The Council’s model contract language
5 days	Determining an actual breach of customer data	The Council’s model contract language
60 days	Discovering a breach	HIPAA’s outer limit for business associates

The trigger matters as much as the number. “Initial suspicion” starts the clock before your investigation finishes, so the honest answer to “how fast will you notify us?” includes who decides that something is suspected and how that person reaches the customer at 2 a.m. Our post on security exhibits traces where these clocks come from and which ones you can negotiate.

Recovery has a clock too. Backup and recovery is already a standard question, and the proposed rule’s 72-hour restore would put a number on it. The honest answer has a date in it: the last time you restored from backup, and how long it took. If you’ve never written that down, you’re not alone.

Nobody had ever written down a backup restore test.

Adrian S. · Fractional IT and security officer · October 8, 2026

Load the post from LinkedIn

Identity, logs and the rest of the list

The remaining questions are less surprising, and they still sink reviews when the answer is “we do that, it just isn’t written down.”

Single sign-on and provisioning. McLaren asks, “Does your application support integration with company’s Active Directory environment?” Larger systems often expect SAML single sign-on and SCIM provisioning, which ChatGPT for Healthcare advertises as “organization-wide user management through SAML SSO and SCIM.” If a health system can’t remove a departed nurse’s access from its own identity provider, that’s a finding.

Multi-factor authentication. The proposed rule would require it, and the Council’s AI guide asks for “Multi-factor authentication and access controls for AI systems.” Answer for your own staff as well as the product: every person who can reach production or patient data.

Who on your team can see patient data. The University of California’s appendix asks you to “Prevent the sharing of passwords or authentication secrets that provide access to Institutional Information,” and the Council’s contract language says “Supplier shall disclose to the Customer and end-user all accounts on Products.” Keep a short list of named people with production access, grant it per task, and keep the record of your last access review.

Logs. McLaren asks, “What level of auditing does the system support?” MD Anderson asks you to “record who, what, and when access to such servers and records occurs,” and the Council’s language says “Supplier shall collect, retain, and provide to the Customer logs from systems, Services, applications.” A sample log line with every field filled in answers all three.

Testing. McLaren wants “the date of the last comprehensive attack and penetration test in your environment,” and MD Anderson asks for the “results of a third-party external Information Security assessment conducted within the past 2 years.” Our evidence scorecard has a Healthcare setting that shows what a health system expects to see, and the Council’s contract language asks for patches “within 30 days of the patch release.”

Insurance, audits and the exit. McLaren asks whether you carry cyber liability insurance and at what limits. The University of California may “request and perform a security audit using a qualified third party,” and MD Anderson wants room for a site visit “within 24 hours notice.” At the end, the University of California wants its data returned and then disposed of “Within thirty (30) calendar days of the termination,” with a written certification that you did it.

None of these is hard on its own. Together they’re a few days of writing things down, which is why it pays to do it once, before the first review, instead of under deadline for every customer.

Run the pre-flight

Here are 24 of the questions above, grouped the way reviewers group them. Answer honestly: “yes, and we can show it” only if you could attach the evidence today. The questions marked as often a deal-breaker are the ones that tend to end a review when the answer is no. Open any question for a draft answer in plain language and the evidence to attach. It all stays in your browser.

Interactive · 5 minutes · Runs in your browser

The pre-flight: 24 questions before the health system asks

Pick your cloud and say whether AI touches patient data. The draft answers fill in your key service, logs and regions, and the AI questions drop out if they don't apply.

Company or product Cloud Amazon Web ServicesGoogle CloudMicrosoft AzureOther AI on patient data? YesNo

1. How are encryption keys managed and secured?
2. How does your system secure data both in transit and at rest?
3. Can we hold our own encryption key?
4. Is the application isolated on the host system(s), including a separate infrastructure?
5. How do you keep one customer's data from reaching another?
6. Was cross-tenant access in your last penetration test's scope?
7. Does your organization store any data off-shore, or have employees, subcontractors or agents off-shore with access to our data?
8. Can you show a network map that illustrates the movement of patient data?
9. Which subcontractors touch our data, and do you have a business associate agreement with each?
10. Do you use our data to train or improve models?
11. Which model providers see prompts with patient data, and does their business associate agreement cover every feature you use?
12. How long do you and your providers keep prompts, outputs and logs?
13. How will you tell us before the model or AI vendor behind a feature changes?
14. Does your application support single sign-on with our identity provider, and automated provisioning?
15. Do you require multi-factor authentication for everyone who can reach patient data?
16. Who on your team can access our patient data, and how is that access approved and reviewed?
17. What level of auditing does the system support?
18. Can you provide our logs on request?
19. Please provide the date of the last comprehensive attack and penetration test in your environment.
20. How fast do you patch, and will you tell us when a vulnerability in your product is being exploited?
21. How fast will you notify us of a suspected security incident?
22. Can you restore critical systems within 72 hours, and when did you last test it?
23. How will you return or destroy our data when the contract ends, and will you certify it?
24. What independent reports can you share, and will you support an audit?

Start over

…ready, with evidence you can attach

…true, but nothing to show yet

…not yet

…likely deal-breakers to fix first

Download the answer pack (.md) Download the tracker (.csv)

Everything here runs in your browser and is saved only in this browser. The draft answers are starting points: replace each bracket, attach the evidence, and send only what's true today. The deal-breaker flags reflect the published requirements quoted in this post, not any one health system's policy.

Have a person review my answers →

We get your email, the counts above, which deal-breaker questions you answered not yet, your cloud and whether AI touches patient data. Never your company name or your answers. A person who has been through these reviews replies with what they'd fix first. No sequence.

Prefer a spreadsheet? The same 24 questions, with draft answers, evidence and who asks, are in a CSV you can download and share with your team.

Send the answer pack before they ask

The answer pack the pre-flight downloads is a document you can attach to your BAA redlines: every question, your answer, and the evidence behind it. Sending it first changes the review. Instead of a long questionnaire and a deadline, the security team starts from your architecture and asks follow-ups. That’s a shorter conversation, and a friendlier one.

It also protects you from your own answers. A questionnaire answer can become a contractual promise: MD Anderson’s rider, for one, has the vendor warrant that the information in it is “current, complete, and accurate” (MD Anderson). A pack you wrote calmly, once, is more accurate than the same answers typed under deadline into five different portals. We wrote about what happens when the paper and the practice drift apart in The Security Exhibit Your Startup Signed Last Quarter.

"there has become a race to longer and longer questionnaires."

McCaffery, in the Hacker News thread "Our Dumb Security Questionnaire," January 2021. Nearly six years later, the race is still on.

If a health system’s security team is already asking and the deal has a date, our sales support team answers the questionnaire with you and joins the security call.

Ten working days to a review-ready architecture

Most of this is writing down what you already do, and fixing the two or three things you find along the way. Two weeks is enough if one person owns it.

1. Days 1 and 2: draw the map. The data flow diagram and asset inventory, and a list of every subcontractor that touches patient data with its agreement and the services it covers.
2. Days 3 and 4: keys and encryption. Confirm encryption at rest and in transit everywhere, backups and logs included. Move to per-customer data keys if you can, turn on rotation, and write your key model in your cloud provider’s terms.
3. Days 5 and 6: tenancy. Write down which isolation model you run, check that no application role bypasses it, and add cross-tenant tests to your build. Put cross-tenant access in your next penetration test’s scope.
4. Day 7: identity and logs. Single sign-on and SCIM for customers, multi-factor authentication for everyone on your team, a named list of who can reach patient data, and one sample audit log line.
5. Day 8: clocks. Write the incident plan with a notice step timed to the shortest clock in your contracts, and run a short tabletop. Restore a backup, time it, and write down the date.
6. Day 9: AI. Build the covered-features table for every model provider, set retention, and put the no-training commitment and the model-change notice in writing.
7. Day 10: send it. Assemble the answer pack, attach the evidence, and send it with your BAA, before the questionnaire arrives.

If you’d rather do this with people who have done it before, our HIPAA compliance program builds exactly this pack, and our AI and HIPAA work covers the model-provider side. For the view from inside government health IT, listen to Jose Arrieta, the former chief information officer and interim chief data officer of HHS, on episode 40. And if you’re still deciding between SOC 2, HITRUST and the rest, Jon and I walked through the whole alphabet on episode 37.

The BAA gets you into the room. The answer pack gets you the pilot.