Your Software Provider Says Patient Data Is Secure. What Questions Have You Never Asked?

For years, the reassurance has sounded more or less the same.

Patient data is secure. The platform is compliant. Information is encrypted. Security standards are met. The software is trusted by thousands of healthcare organisations.

For most dental practice owners, those statements are reassuring for a simple reason: they appear to answer the question that matters most.

Is patient information safe?

But what if that is not the only question worth asking? What if it is not even the most important one?

Because when you follow the trail behind some of the largest healthcare supplier incidents, regulatory investigations and cybersecurity failures of recent years, a curious pattern begins to emerge.

The organisations involved were not necessarily using obscure software. They were often using respected suppliers. Established suppliers. Trusted suppliers. Sometimes market-leading suppliers.

Yet things still went wrong. Not always because security failed. But because security turned out to be only one part of a much larger story.

The Assumption Hidden Inside Reassurance

Spend enough time speaking with healthcare organisations and a familiar assumption appears repeatedly.

We chose a reputable supplier. The supplier says the information is secure. Therefore the issue has largely been dealt with.

At first glance, that logic seems entirely reasonable. After all, healthcare providers cannot build every system themselves. They rely on specialist suppliers. Those suppliers invest heavily in infrastructure, security and expertise. That is exactly what they are supposed to do.

Yet an uncomfortable question sits beneath the surface.

When a software provider says patient information is secure, what exactly are they proving?

The answer is surprisingly narrow.

They are largely demonstrating that they have implemented measures designed to protect information. Important measures. Necessary measures. Often impressive measures.

But that is not the same as demonstrating that everyone involved fully understands how information moves, who remains responsible, what third parties are involved, how changes are assessed or how accountability operates when something unexpected happens.

A secure platform may answer where data is stored. It does not always answer who understands it.

One of the most revealing aspects of major supplier incidents is not that they happened. It is what they exposed.

Take the widely reported cyber incident involving Advanced, a major healthcare software provider whose systems were used across parts of the healthcare sector.

The story was often framed as a cybersecurity event. And it was.

But look beyond the headlines and another question emerges.

How many organisations fully understood their dependency on the supplier before the incident occurred? How many had mapped the operational consequences? How many could explain exactly which services, workflows and responsibilities were connected to that supplier?

The incident revealed something that cybersecurity professionals have understood for years.

Organisations do not merely buy software. They inherit dependencies.

The same lesson appeared repeatedly in discussions surrounding the Capita incident.

The issue was not simply whether Capita had experienced a cyber event. The issue was the sheer number of organisations that suddenly found themselves affected by problems originating elsewhere.

A supplier's incident became somebody else's operational problem.

That distinction matters. Because responsibility may be shared. Consequences rarely are.

There is a sentence that rarely appears in contracts but often emerges in reality.

Patients do not care which supplier failed.

They care who they trusted.

Imagine explaining to a patient that a problem originated within a third-party provider. The explanation may be entirely accurate.

The patient may still see the practice as responsible. Not because the practice caused the issue. Because the practice was the organisation they entrusted with their information.

This creates a gap that many governance discussions fail to address.

Responsibility in a contractual sense may be distributed.

Trust is not.

Trust tends to remain exactly where it began.

With the practice.

Ask a practice owner which software platform they use and they can usually answer immediately.

Ask how many organisations sit behind that platform and the conversation often changes.

Cloud providers, infrastructure providers, support providers, communication services, analytics services, storage environments, sub-processors and third-party integrations.

Modern software ecosystems are often remarkably complex.

Again, this is not evidence of poor practice. It is simply the reality of modern technology.

The challenge is that many organisations stop their investigation at the first supplier.

The software provider becomes the answer.

When in reality it may be the beginning of the question.

The UK’s cybersecurity guidance increasingly reflects this concern.

Supply-chain security has become a major focus not because suppliers are inherently risky, but because organisations often underestimate how dependent they have become on systems they do not directly control.

The more complex the ecosystem becomes, the easier it is to lose sight of who is responsible for what.

Perhaps the most interesting discovery emerges when you compare security conversations with governance conversations.

Security discussions tend to focus on protection.

Governance discussions focus on understanding.

Those are not the same thing.

A practice may know that information is encrypted.

But does it know who reviews supplier changes? Does it know how new functionality is assessed? Does it know how responsibilities are divided? Does it know what would happen if a critical supplier became unavailable tomorrow? Does it know how decisions about data handling are made?

Security answers one question.

Governance answers many others.

The problem is that organisations often assume the first answer automatically provides the second.

The AI Problem Before It Becomes an AI Problem

This distinction becomes particularly interesting when software providers introduce new functionality.

Increasingly, that functionality includes AI-assisted capabilities.

Search tools. Administrative support. Workflow enhancements. Documentation assistance. Intelligent recommendations.

Many of these features arrive through routine updates.

No procurement exercise. No strategic review. No major announcement.

Just another feature release.

And yet every new capability raises governance questions.

Who reviewed it? Who approved it? Who understood it? Who assessed its impact? Who would explain it if questions arose later?

One of the more revealing observations from the Information Commissioner's Office is that accountability cannot be delegated simply because technology is involved.

The technology may belong to somebody else.

Responsibility for understanding its use often does not.

AI does not remove responsibility.

It changes who may be expected to explain it.

Perhaps the most important lesson from supplier incidents, regulatory investigations and governance failures is that organisations rarely suffer because they ignored obvious risks.

More often, they suffer because they stopped asking questions too early.

The supplier was trusted. The platform was reputable. The assurances sounded reasonable. The contract was signed.

The investigation ended there.

Yet governance failures often emerge in the space between trust and understanding.

Not because trust was misplaced.

Because understanding never caught up.

A trusted supplier can still sit inside an unclear process. A secure platform can still support weak governance. A compliant system can still leave important questions unanswered.

The Question Beneath the Security Question

The most valuable question may not be whether your software provider is secure.

It may be whether you understand everything surrounding that security.

Could you explain the governance chain from beginning to end? Could you identify who remains responsible at each stage? Could you explain how supplier changes are reviewed? Could you explain how new functionality is assessed? Could you explain how accountability operates when something unexpected happens?

Most organisations spend considerable time evaluating suppliers.

Far fewer spend the same amount of time evaluating their own assumptions about those suppliers.

That may be the most significant governance gap of all.

Because trust is important.

But trust without understanding is often little more than confidence built on assumption.

And when you look closely at many of the incidents that have shaped recent discussions around healthcare data, supply chains and accountability, that is the thread that appears again and again.

The technology was trusted. The supplier was trusted. The assurances were trusted.

What was never fully examined was everything surrounding them.

And that may be the question practice owners should be asking next.

Most practices don't have a clear picture of where AI already touches their staff tools, supplier platforms or client data, and that's rarely anyone's fault. The Free AI Snapshot Review is a short, practical first step to see where the gaps might be, with no pressure and no obligation.