The 5 Questions Every Hospital Procurement Asks

Different hospitals use different questionnaires. Some send you SIG-lite. Some have their own 100-question security assessments. Some use third-party platforms like Venminder or OneTrust.

The formats vary. The underlying questions do not.

After reviewing hundreds of these questionnaires and helping dozens of vendors respond, I can tell you: procurement is trying to answer the same five questions every time. If you understand what they are really asking - and what a good answer sounds like - you can handle any questionnaire they throw at you.

Here is the breakdown.

Question 1. Are you actually a Business Associate?

How it shows up on questionnaires.

• "Will your solution access, store, or transmit PHI?"

• "Describe what patient data your system handles"

• "Are you a Business Associate under HIPAA?"

What they are really asking. Is PHI going to touch your systems in any way? This includes storage, processing, transmission, logs, backups, support access, analytics - any contact at all.

Why this matters. If you are a Business Associate, the hospital needs a BAA with you, and you are subject to HIPAA's requirements directly. If you are not, the procurement process is simpler. They want to know which track you are on.

What a good answer looks like. A clear, confident statement of your BA status with a simple explanation of what PHI you handle and why. Best case, include a data flow diagram showing exactly where PHI enters, moves, and rests in your system.

Where teams stumble. They underestimate what counts as PHI contact. "We do not store PHI" while their error logs capture patient identifiers. "We do not access PHI" while their support team can view it for troubleshooting. "It is de-identified" when it is actually just partially anonymized.

Know your data flows cold. If you are fuzzy here, everything downstream feels uncertain - because it is.

Question 2. Can you sign our BAA?

How it shows up on questionnaires.

• "Are you willing to sign our Business Associate Agreement?"

• "Do you have any required modifications to our standard BAA?"

• "Please describe your BAA process"

What they are really asking. Are you operationally ready to take on HIPAA obligations? Have you thought through what signing a BAA actually commits you to?

Why this matters. A BAA is not just legal paperwork. It is a contractual commitment that you will:

• Implement specific safeguards (administrative, physical, technical)

• Report security incidents and breaches within defined timeframes

• Allow audit rights (sometimes)

• Ensure your subcontractors are also bound by appropriate agreements

• Return or destroy PHI on termination

• Accept liability for compliance failures

If you cannot deliver on these commitments, signing the BAA creates liability, not compliance.

What a good answer looks like. "Yes, we can sign your standard BAA. We have the operational infrastructure to meet its requirements, including brief summary of key capabilities. If there are specific terms you would like to discuss, we are happy to review."

Where teams stumble. Two failure modes.

Signing blindly. Teams agree to whatever BAA the hospital sends without understanding the obligations. Then they cannot meet breach notification timelines, or they do not have the audit logs the BAA requires, or they have not flowed requirements down to their subcontractors.

Refusing to sign. Some teams, knowing they are not ready, try to negotiate away key provisions or refuse to sign altogether. This ends the deal.

The right approach is to understand what BAAs typically require, build the operational foundation to deliver, and negotiate only on genuinely problematic terms (unreasonable indemnification, overly aggressive audit rights, etc.).

Question 3. Where does PHI live and who can touch it?

How it shows up on questionnaires.

• "Where is PHI stored?"

• "What encryption standards do you use?"

• "Describe your access control mechanisms"

• "Who has access to PHI and under what circumstances?"

• "Where are your servers located?"

What they are really asking. Did you design your data handling intentionally, or did it just happen? Do you have control over PHI, or is it scattered across your infrastructure?

Why this matters. This is where technical controls meet organizational controls. Procurement wants to see that you know exactly where PHI is at all times, who can access it, and that access is limited to what is necessary.

What a good answer looks like. Clear, specific answers covering.

Data location: "PHI is stored in AWS US-East-1 region, using specific services. Data does not leave the US."

Encryption: "Encrypted at rest using AES-256, in transit using TLS 1.2+."

Access control: "Role-based access controls with least-privilege principles. Access requires individual credentials (no shared accounts), MFA, and manager approval. Access is reviewed quarterly and terminated within 24 hours of role change or departure."

Support access: "Support staff can access PHI only through our secure support portal, with all access logged. We use break-glass process for emergency access."

Where teams stumble.

Shared credentials. Still more common than you would think. "The team shares a production login" is an immediate red flag. No access reviews. Access accumulates over time. If you are not regularly reviewing who has access to what, you have lost control. Unclear data residency. For APAC teams especially, data location matters. US hospitals get nervous about PHI crossing borders. Know exactly where your data lives and be prepared to explain why.

Support access as an afterthought. Your support team often has more PHI access than anyone. If that access is not controlled and logged, procurement will notice.

Question 4. What happens when something goes wrong?

How it shows up on questionnaires.

• "Describe your incident response process"

• "What is your breach notification timeline?"

• "Do you maintain audit logs? For how long?"

• "Have you experienced any security incidents in the past 3 years?"

What they are really asking. When (not if) something goes wrong, will you be able to figure out what happened and tell us quickly? Or will you panic and make our lives harder?

Why this matters. Breaches happen. Systems get compromised. Employees make mistakes. Hospitals know this. What they need to know is that you have a plan. HIPAA requires notification of breaches to affected individuals and HHS within specific timeframes. Hospital BAAs often have stricter requirements, sometimes 24-48 hours for initial notice. If you cannot meet these timelines, you are not a viable partner.

What a good answer looks like.

• "We have a documented incident response plan that defines identification, containment, investigation, notification, and remediation phases."

• "Our Security Officer coordinates response with a defined escalation path to executive leadership."

• "We maintain audit logs for [time period] that enable forensic reconstruction of events."

• "Initial notification to affected business associates within 24 hours of confirmed breach, with full details within the timeframe specified in our BAA."

• "We test our incident response process annually through tabletop exercises."

Where teams stumble.

No written plan. "We would handle it" is not a plan. Procurement wants to see documentation. No clear ownership. Who is in charge during an incident? If the answer is "whoever is around," that is a problem.

Insufficient logging. If you cannot reconstruct what happened, you cannot fulfill notification requirements. You also cannot learn from incidents or prove containment. Never tested. A plan that has never been exercised is theoretical. Annual tabletop exercises show you take this seriously.

Question 5. What else is in your stack?

How it shows up on questionnaires.

• "List all subprocessors/subcontractors that handle PHI"

• "Do you use any third-party analytics in patient-facing applications?"

• "Describe how you assess vendor security"

What they are really asking. We are evaluating your risk. Your vendors are part of your risk. What have we inherited by working with you? Why this matters. Your subcontractor risks become the hospital's subcontractor risks. If your error-tracking service has a breach, patient data from their systems might be exposed. If your analytics provider is scraping data they should not, the hospital is liable.

What a good answer looks like.

• A clean list of every vendor that touches PHI: name, function, BAA status

• Description of your vendor assessment process (how you evaluate security before engaging, how you monitor ongoing)

• Confirmation that no non-HIPAA-eligible tools touch PHI

• Clear statement about analytics in patient-facing applications (ideally: none, or HIPAA-eligible only)

Where teams stumble.

Incomplete inventory. You need to know every tool that touches PHI. Not just the obvious ones - also error tracking, logging, analytics, customer support platforms, backup services. Tools that are not HIPAA-eligible. Many popular SaaS tools are not designed for healthcare data. Google Analytics in a patient portal is a common mistake. Using Zendesk or Intercom for support without checking HIPAA eligibility is another. No vendor management process. Procurement does not just want a list. They want to know you are actively managing vendor risk - assessing new vendors before you use them, monitoring existing vendors, responding when their security posture changes.

The pattern

Notice that these five questions span technical, administrative, and organizational domains. Only one (Question 3) is primarily about technical controls. The others are about documentation, process, planning, and organizational capability. This is why teams with strong engineering but weak compliance programs struggle. They can ace Question 3 and stumble on the other four. The teams that close deals can answer all five confidently, with documentation to back up every claim.

In the next post, I will dig into the specific policies you need to have in place before procurement calls.

The 30/70 split — Why technical controls are only 30% of what procurement evaluates, and what makes up the other 70%.

The policies you need — Not a compliance wishlist, but the specific policies procurement expects to see and what they should actually contain.

The training requirement — Yes, your engineers in Singapore need HIPAA training. Here's why, and here's how to do it.

The gap assessment — How to figure out where you actually stand before procurement figures it out for you.

The procurement pack — The specific documents you need ready so you can respond to questionnaires in days, not weeks.

ISO217001 ≠ HIPAA compliant — A strong foundation for your security posture but does not guarantee HIPAA compliant.You may also be interested in: