I recently completed a cybersecurity and HIPAA Compliance assessment of an AI vendor for a healthcare provider.
Several other providers were already using the product.
The vendoI recently completed a cybersecurity and HIPAA Compliance assessment of an AI vendor for a healthcare provider.
Several other providers were already using the product.
The vendor was also being promoted through industry relationships.
They had a SOC 2 report.
They had a BAA.
They had compliance documentation.
There were plenty of reasons for a healthcare executive to believe this company had already been properly vetted.
Then I started reviewing the evidence.
By the time I finished, I had assigned the vendor an overall high-risk rating.
During our meeting, the clinic CEO told me they were glad they hadn't given the vendor access to patient information yet.
That reaction is what I want health tech companies to understand.
Because the findings are only part of the story.
The more important lesson is how a healthcare buyer's confidence changes when the evidence doesn't support the vendor's claims.
Why Healthcare Leaders Trust Vendors Their Peers Use
Healthcare executives make purchasing decisions in an ecosystem where they depend on other organizations' experiences.
They attend conferences.
They participate in industry groups.
They exchange recommendations with other healthcare providers.
And today, they're looking to adopt AI to improve operational efficiency.
When a vendor comes recommended by peers that carries weight.
I understand why.
A CEO has limited time and competing priorities.
Their clinical teams need support.
Their operations teams are looking for ways to reduce administrative work.
And everyone is looking at what AI could do for their organization.
So when another provider has already adopted a product, it's reasonable to assume some level of diligence took place.
That assumption creates confidence before the vendor has demonstrated anything directly to you.
During our discussion, one of the executives described how common this is.
Providers see another organization using a vendor and assume the vendor must be fine.
But that leaves an important question unanswered.
What did the other organization actually review?
You may never know.
And so the risk begins.
The Vendor Had a SOC 2 Report.
The first area I discussed with the CEO was the vendor's SOC 2 report.
The vendor had completed a Type 1 examination.
For someone unfamiliar with SOC 2, that can sound reassuring.
It's an independent examination performed by a CPA firm.
It carries credibility.
But you have to understand what the report covers.
A SOC 2 Type 1 evaluates the design of controls at a specific point in time.
A Type 2 evaluates whether those controls operated effectively over a defined period.
The CEO summarized the distinction during our conversation.
Type 1 is a snapshot.
Type 2 shows a pattern.
That's a useful way to understand it.
For a vendor handling PHI, I want to see evidence that controls are functioning consistently.
And as I continued reviewing the materials, more concerns were unveiled.
The Sub-processors Raised More Questions
The vendor's product relied on multiple third-party providers.
That's common in health tech.
Cloud services, APIs, AI models, communication platforms, and other applications often work together to deliver a single product.
But this vendor disclosed approximately 10 sub-processors involved in handling PHI.
This felt like the approach was "as long as we have a BAA we're good," rather than "we need to limit exposure."
I wanted to understand how much PHI was being shared, which vendors were receiving it, and what safeguards were in place.
The descriptions of the PHI being shared were vague.
A patient name and appointment reminder create a different exposure than a clinical record containing diagnoses, medications, and treatment information.
The amount, sensitivity, and retention of PHI matter.
How long does each vendor hold the information?
Can it be deleted?
Is the information de-identified where appropriate?
What happens when the relationship ends?
The challenge becomes greater as more vendors are introduced.
Each relationship creates another dependency that needs to be managed.
For a healthcare buyer, the expectation is that someone has already thought through these questions.
The documentation I reviewed left too much uncertainty.
The Documents Were A False Sense of Security
As I continued the assessment, a pattern developed.
The vendor said vulnerability scanning was being performed.
I didn't receive the supporting reports.
They indicated threat monitoring was enabled.
The materials provided limited evidence.
Their incident response plan was templated, had been updated just weeks before the contract, and showed no prior updates since 2024.
Disaster recovery capabilities were described as brief paragraph in Word.
Evidence of privileged access controls was provided for certain systems, but it didn't address the broader environment.
The risk assessment evidence was also limited.
I couldn't determine what risks had been identified, how they were evaluated, or what was being done about them.
The risk assessment also hadn't been completed since 2024.
One of the more concerning details involved logging.
The vendor indicated that logging had only recently been enabled.
That creates a problem when an incident needs to be investigated.
You need a historical record of activity.
Who accessed the system?
What actions occurred?
What information was involved?
When did the activity begin?
Without adequate logging, answering those questions becomes difficult.
This becomes especially important for AI systems capable of performing multiple actions in a short period.
By this point, the individual findings were starting to build a bigger picture.
The organization appeared to be moving quickly.
But their HIPAA Compliance efforts appeared not to be moving with it.
The CEO Was Evaluating the Vendor's Judgment
Something important happened during the meeting.
As I explained the findings, the CEO began connecting the technical weaknesses to how the vendor had presented itself throughout the relationship.
They described the vendor as appearing unprepared and moving faster than its internal capabilities could support.
Then they made an observation that I thought was gold.
If they were running that company, they would have wanted someone to identify those weaknesses before a customer found them.
I agree.
A mature compliance program is expected to identify risk.
That is why we perform risk assessments.
That's why we conduct penetration testing.
That's why we review vendors.
That's why we test incident response.
We want to understand where the weaknesses are before they create a serious problem.
During an earlier review, this vendor had provided a HIPAA assessment that reported no findings.
That raised another question for me.
I've reviewed enough security programs to know that an assessment with zero findings deserves closer examination.
The CEO recognized this too.
What concerned the CEO was whether the vendor understood its own risks and was actively managing them.
That tells you something important about how healthcare buyers evaluate vendors.
They want confidence in the people responsible for protecting their organization.
Their judgment.
Their processes.
Their ability to recognize problems.
Their willingness to address them.
Those qualities become visible in the evidence they provide.
AI Made the Questions More Important
The vendor was also offering AI-supported workflows involving patient outreach, scheduling, and other administrative activities.
Some of those functions could involve autonomous actions.
That required another level of evaluation.
I wanted to understand how the AI was authorized to perform actions.
What could it access?
Which activities required approval?
How were actions monitored?
Could an incorrect action be reversed?
What happened if the AI started behaving unexpectedly?
How would the provider stop it?
The CEO had already pushed back on a proposed level of access to the organization's EHR.
An AI system interacting with patient information or clinical workflows requires clearly defined boundaries.
The speed of these systems makes that especially important.
An automated workflow can perform many actions before a person recognizes that something is wrong.
Without sufficient logging, monitoring, authorization controls, and human oversight, investigating or stopping those actions becomes more difficult.
Why Growth-Stage Health Tech Companies End Up Here
I've worked with health tech companies at different stages.
One pattern I see is how quickly market acceptance can outpace compliance.
The company starts with a product that solves a real problem.
It attracts customers.
Sales gains momentum.
Engineering focuses on building features and supporting integrations.
Someone introduces a GRC platform.
Policies get created.
Controls are mapped.
Assessments are completed.
The organization begins building the documentation expected by healthcare buyers.
Those tools can be useful.
But somebody still needs to understand how the controls apply to the company's environment.
A sub-processor inventory needs to reflect where PHI travels.
A risk assessment needs to be reviewed regularly and when the ecosystem changes.
A penetration test needs an appropriate scope.
An incident response plan needs to reflect how the company would respond.
A completed questionnaire needs the right supporting evidence.
That requires experience and consistent follow-through.
When the company is focused on growth, it's easy for compliance to fall behind.
The consequences often surface during a buyer's security review.
The Moment the Buyer Reconsidered the Risk
Toward the end of our meeting, the CEO said they were glad the vendor hadn't been given access to patient information.
This captures the importance of the review.
The organization had been considering the product.
Other providers were using it.
There was industry support behind its adoption.
But a deeper review raised concerns that leadership had not fully understood before.
The CEO now had a clearer picture of the potential exposure.
And the health center could evaluate that information before deciding how to proceed.
That's how the process should work!
What Health Tech Vendors Should Take From This
If you're selling into healthcare, pay attention to what happened in this review.
The vendor had market credibility.
They had existing healthcare customers.
But when someone examined the supporting evidence, the buyer's confidence changed.
Every unanswered question created uncertainty.
As the findings accumulated, the CEO began questioning the vendor overall.
That is a difficult position for a health tech company trying to win business.
For growth-stage health tech companies, that is why HIPAA Compliance needs experienced ownership.
Someone has to understand the risks, maintain the controls, evaluate the evidence, and prepare the organization for that level of scrutiny.
Your existing healthcare customers may help establish credibility.
Your next buyer will make their own decision.
And the evidence you provide will influence it.
—Larryr was also being promoted through industry relationships.
They had a SOC 2 report.
They had a BAA.
They had compliance documentation.
There were plenty of reasons for a healthcare executive to believe this company had already been properly vetted.
Then I started reviewing the evidence.
By the time I finished, I had assigned the vendor an overall high-risk rating.
During our meeting, the clinic CEO told me they were glad they hadn't given the vendor access to patient information yet.
That reaction is what I want health tech companies to understand.
Because the findings are only part of the story.
The more important lesson is how a healthcare buyer's confidence changes when the evidence doesn't support the vendor's claims.
Why Healthcare Leaders Trust Vendors Their Peers Use
Healthcare executives make purchasing decisions in an ecosystem where they depend on other organizations' experiences.
They attend conferences.
They participate in industry groups.
They exchange recommendations with other healthcare providers.
And today, they're looking to adopt AI to improve operational efficiency.
When a vendor comes recommended by peers that carries weight.
I understand why.
A CEO has limited time and competing priorities.
Their clinical teams need support.
Their operations teams are looking for ways to reduce administrative work.
And everyone is looking at what AI could do for their organization.
So when another provider has already adopted a product, it's reasonable to assume some level of diligence took place.
That assumption creates confidence before the vendor has demonstrated anything directly to you.
During our discussion, one of the executives described how common this is.
Providers see another organization using a vendor and assume the vendor must be fine.
But that leaves an important question unanswered.
What did the other organization actually review?
You may never know.
And so the risk begins.
The Vendor Had a SOC 2 Report.
The first area I discussed with the CEO was the vendor's SOC 2 report.
The vendor had completed a Type 1 examination.
For someone unfamiliar with SOC 2, that can sound reassuring.
It's an independent examination performed by a CPA firm.
It carries credibility.
But you have to understand what the report covers.
A SOC 2 Type 1 evaluates the design of controls at a specific point in time.
A Type 2 evaluates whether those controls operated effectively over a defined period.
The CEO summarized the distinction during our conversation.
Type 1 is a snapshot.
Type 2 shows a pattern.
That's a useful way to understand it.
For a vendor handling PHI, I want to see evidence that controls are functioning consistently.
And as I continued reviewing the materials, more was unvield.
The Sub-processor List Raised More Questions
The vendor's product relied on multiple third-party providers.
That's common in health tech.
Cloud services, APIs, AI models, communication platforms, and other applications often work together to deliver a single product.
But this vendor disclosed approximately 10 sub-processors involved in handling PHI.
This felt like "as long as we have a BAA we're good," rather than "we need to limit exposure."
I wanted to understand how much PHI was being shared, which vendors were receiving it, and what safeguards were in place.
The descriptions of the PHI being shared were vague.
A patient name and appointment reminder create a different exposure than a clinical record containing diagnoses, medications, and treatment information.
The amount, sensitivity, and retention of PHI matters.
How long does each vendor hold the information?
Can it be deleted?
Is the information de-identified where appropriate?
What happens when the relationship ends?
The challenge becomes greater as more vendors are introduced.
Each relationship creates another dependency that needs to be managed.
For a healthcare buyer, the expectation is that someone has already thought through these questions.
The documentation I reviewed left too much uncertainty.
The Documents Looked Complete Until We Examined the Evidence
As I continued the assessment, a pattern developed.
The vendor said vulnerability scanning was being performed.
I didn't receive the supporting reports.
They indicated threat monitoring was enabled.
The materials provided limited evidence.
Their incident response plan was templated, updated weeks before this contract, nothing since 2024.
Disaster recovery capabilities was a brief paragraph in Word.
Privileged access controls was provided for certain systems, but didn't sufficiently address the broader environment.
The risk assessment evidence was also limited.
I couldn't determine what risks had been identified, how they were evaluated, or what was being done about them.
This also hadn't been completed prior to 2024.
One of the more concerning details involved logging.
The vendor indicated that logging had only recently been enabled.
That creates a problem when an incident needs to be investigated.
You need a historical record of activity.
Who accessed the system?
What actions occurred?
What information was involved?
When did the activity begin?
Without adequate logging, answering those questions becomes difficult.
This becomes especially important for AI systems capable of performing multiple actions in a short period.
By this point, the individual findings were starting to build a bigger picture.
The organization appeared to be moving quickly.
But their HIPAA Compliance program had not moved with it.
The CEO Was Evaluating the Vendor's Judgment
Something important happened during the meeting.
As I explained the findings, the CEO began connecting the technical weaknesses to how the vendor had presented itself throughout the relationship.
They described the vendor as appearing unprepared and moving faster than its internal capabilities could support.
Then they also made an observation that I thought was gold.
"If she were running that company, she would have wanted someone to identify these weaknesses before a customer found them."
I agree.
A mature compliance program is expected to identify risk.
That is why we perform risk assessments.
That's why we conduct penetration testing.
That's why we review vendors.
That's why we test incident response.
We want to understand where the weaknesses are before they create a serious problem.
During an earlier review, this vendor had provided a HIPAA assessment that reported no findings.
That raised another question for me.
I've reviewed enough security programs to know that an assessment with zero findings deserves closer examination.
The CEO recognized this too.
What concerned her was whether the vendor understood its own risks and was actively managing them.
That is an important to know how healthcare buyers evaluate vendors.
They want confidence in the people responsible for protecting their organization.
Their judgment.
Their processes.
Their ability to recognize problems.
Their willingness to address them.
Those qualities become visible in the evidence they provide.
AI Made the Questions More Important
The vendor was also offering AI-supported workflows involving patient outreach, scheduling, and other administrative activities.
Some of those functions could involve autonomous actions.
That required another level of evaluation.
I wanted to understand how the AI was authorized to perform actions.
What could it access?
Which activities required approval?
How were actions monitored?
Could an incorrect action be reversed?
What happened if the AI started behaving unexpectedly?
How would the provider stop it?
The CEO had already pushed back on a proposed level of access to the organization's EHR.
An AI system interacting with patient information or clinical workflows requires clearly defined boundaries.
The speed of these systems makes that especially important.
An automated workflow can perform many actions before a person recognizes that something is wrong.
Without sufficient logging, monitoring, authorization controls, and human oversight, investigating or stopping those actions becomes more difficult.
Why Growth-Stage Health Tech Companies End Up Here
I've worked with health tech companies at different stages.
One pattern I see is how quickly market acceptance can outpace compliance.
The company starts with a product that solves a real problem.
It attracts customers.
Sales gain momentum.
Engineering focuses on building features and supporting integrations.
Someone introduces a GRC platform.
Policies get created.
Controls are mapped.
Assessments are completed.
The organization begins building the documentation expected by healthcare buyers.
Those tools can be useful.
But somebody still needs to understand how the controls apply to the company's environment.
A sub-processor inventory needs to reflect where PHI travels.
A risk assessment needs to evaluated annually...at least.
A penetration test needs an appropriate scope.
An incident response plan needs to reflect how the company would respond.
A completed questionnaire needs the right supporting evidence.
That requires experience and consistent follow-through.
When the company is focused on growth, it's easy for compliance to fall behind.
The consequences often surface during a buyer's security review.
The Moment the Buyer Reconsidered the Risk
Toward the end of our meeting, the CEO said they were glad the vendor hadn't been given access to patient information.
This captures the importance of the review.
The organization had been considering the product.
Other providers were using it.
There was industry support behind its adoption.
But a deeper review raised concerns that leadership had not fully understood before.
The CEO now had a clearer picture of the potential exposure.
And the health center could evaluate that information before deciding how to proceed.
That's how the process should work!
What Health Tech Vendors Should Take From This
If you're selling into healthcare, pay attention to what happened in this review.
The vendor had market credibility.
They had existing healthcare customers.
But when someone examined the supporting evidence, the buyer's confidence changed.
Every unanswered question created uncertainty.
As the findings accumulated, the CEO began questioning the vendor overall.
That is a difficult position for a health tech company trying to win business.
For growth-stage health tech companies, that is why HIPAA Compliance needs experienced ownership.
Someone has to understand the risks, maintain the controls, evaluate the evidence, and prepare the organization for that level of scrutiny.
Your existing healthcare customers may help establish credibility.
Your next buyer will make their own decision.
And the evidence you provide will influence it.
—Larry
