The Security Questions You Should Ask Any Healthcare SaaS Vendor Before Signing

Every SaaS vendor selling into healthcare will tell you they are "HIPAA compliant." Most of them mean they have a BAA template ready and have checked a few boxes. Some of them mean they have done the actual work. The difference will determine whether your organization inherits a compliance posture or a compliance liability.

Here is what to ask any vendor that will touch PHI, what the answers should look like, and where most vendors fall short.

SOC 2 Type I vs. Type II: Know What You Are Looking At

The first question most procurement teams ask is "Do you have SOC 2?" That is the wrong question. The right question is: "Do you have a current SOC 2 Type II report, and can we review the auditor's opinion and any noted exceptions?"

A Type I report confirms that controls existed and were appropriately designed at a single point in time. A snapshot. A Type II report evaluates whether those controls operated effectively over a sustained period — typically six to twelve months. Type I is a starting point. Type II is evidence that the vendor actually runs their security program, not just that they designed one for audit day.

Any vendor handling PHI at scale should have a current Type II. If they only have Type I, ask when Type II will be completed. If they cannot answer clearly, they are earlier in their security maturity than their sales team is suggesting.

When reviewing the report, check the Trust Services Criteria covered — at minimum Security, but for healthcare workloads involving patient call data, Availability and Confidentiality are equally critical. Check the exceptions section. A vendor with clearly documented exceptions and remediation plans is often more trustworthy than one with a suspiciously clean report scoped narrowly enough to avoid findings.

What "HIPAA Compliant" Actually Means

There is no HIPAA certification. No government body stamps a software company "HIPAA compliant." The phrase is a self-attestation that a vendor's safeguards align with the Security Rule and Privacy Rule. What you should ask instead:

"Walk me through your HIPAA Security Rule implementation." You want specifics: access controls, audit logging, transmission security, integrity controls. Generic answers like "we follow HIPAA requirements" are a red flag.
"When was your last HIPAA risk assessment, and who conducted it?" The Security Rule requires regular risk assessments. A vendor who has not completed one in the last 12 months, or who conducted it entirely in-house without independent validation, is cutting corners.
"Have you experienced a reportable breach in the last three years?" Check the HHS Breach Portal independently — breaches affecting 500 or more individuals are public record. If a vendor says no but appears on the Wall of Shame, you have a credibility problem that extends beyond security.

BAA Requirements: Beyond the Template

Every vendor in healthcare knows they need a BAA. The question is not whether they will sign one — it is what it actually says. Review these provisions:

Breach notification timelines. HIPAA requires business associates to notify covered entities "without unreasonable delay" and no later than 60 days after discovery. Some vendor BAAs set the clock at 30 days. Others leave it vague. Push for specific, contractual timelines that give your organization enough runway to meet its own notification obligations.
Subcontractor flow-down. The BAA should require that any subprocessor with access to PHI is bound by equivalent obligations. If it is silent on this, your PHI could be handled by a third party with no contractual privacy obligations to anyone.
Return or destruction of PHI at termination. "We will delete it" is insufficient. You need a defined process, a timeline, and a certification of destruction.

Data Residency

Ask where your data will be stored, processed, and backed up. You want confirmation that PHI remains within the United States — including backups, DR environments, and analytics processing.

A vendor running on AWS, Azure, or GCP should tell you the specific regions where your data resides. If they cannot, or if their architecture allows processing outside the U.S. without customer control, that is a gap. With state-level healthcare data privacy laws expanding, residency requirements are tightening. Ask for documentation, not assurances.

Encryption Standards

Two questions. Both non-negotiable.

At rest: PHI on disk, in databases, and in backups should be encrypted using AES-256 or equivalent. Ask whether encryption is at the application layer, the storage layer, or both. Storage-layer encryption alone — such as AWS S3 default encryption — protects against physical theft but not against unauthorized access at the API level. Application-layer encryption closes that gap.

In transit: All transmission should use TLS 1.2 or higher. Ask whether the vendor enforces 1.2 as a minimum or merely supports it while still allowing TLS 1.0 fallback. Also ask about internal service-to-service communication — some vendors encrypt external traffic but transmit data unencrypted between microservices within a VPC.

Incident Response

A vendor's incident response plan tells you more about their security maturity than their marketing page. Ask for it, and evaluate:

Detection capabilities. How does the vendor detect incidents? What is their mean time to detection?
Response timelines. What are their internal SLAs for classification, containment, and customer notification? Mature vendors will have tiered timelines based on severity.
Post-incident review. Do they conduct root cause analyses? Will they share findings with affected customers?
Tabletop exercises. Ask when they last ran an incident response drill. A plan that has never been tested is a document, not a capability.

Subprocessor Management

Most SaaS vendors rely on subprocessors — cloud hosting providers, logging platforms, analytics tools. Each one that touches PHI extends your risk surface.

Ask for a current subprocessor list. Then ask how they vet new subprocessors, whether customers are notified before a new subprocessor is added, and whether you have the contractual right to object. The strongest agreements include a notification clause giving customers a defined window — typically 30 days — to review and object before a new subprocessor is granted access to customer data.

Putting It Into Practice

This is not exhaustive. Depending on your risk profile, you may also need to evaluate penetration testing cadence, background check policies, and disaster recovery RTOs. But the categories above represent minimum viable diligence for any healthcare organization evaluating a new healthcare vendor that will handle PHI.

At SurfacerIQ, we built our security architecture around these expectations because we handle one of the most sensitive data flows in healthcare — patient call recordings and the compliance signals extracted from them. Every vendor in this space should answer these questions without hesitation. The ones who cannot are telling you something about how they will handle your data after the contract is signed.

Run this checklist against every vendor on your shortlist. Compare the answers side by side. The gaps will tell you more than the demos.