.webp)
Choosing your practice management system is one of the biggest decisions you'll make when setting up a clinic. You're deciding who holds your patients' clinical records, prescriptions, mental health notes and financial data.
It's natural to compare features, pricing and ease of use first. But there's another question that's just as important: can you trust the system with patient information?
For many clinicians, that's where things start to feel daunting. Security can sound technical, full of jargon that most of us have never needed to understand.
You don't need to become an information security expert. You simply need to know which questions to ask, what good answers sound like and when something should make you pause. That's exactly what I’m here to help with.
Question one: Who’s responsible if something goes wrong?
When everything is working normally, it's easy to assume your software is looking after itself. But every healthcare system carries some level of risk, whether that's an unexpected outage, a software bug or information appearing where it shouldn't.
That's why every reputable supplier should have someone whose job is to think about clinical safety every day. They should be able to explain how risks are identified, assessed and acted on as the product evolves.
What to ask: "Who in your organisation is responsible for clinical safety? What are their qualifications? Can you walk me through how you identify and manage clinical risks in the product?"
✅ Green flag: There’s a named individual who can provide a clear explanation of their role and give evidence that shows clinical safety is an ongoing process, rather than something that lives in a policy document.
🚩 Red flag: There’s no named individual, and safety queries directed to a generic support inbox or a well-designed webpage about clinical safety with nobody accountable behind it.
Question two: How seriously do they take security?
One of the easiest ways to judge a software provider is by the independent security certifications they've achieved. These show an external organisation has reviewed how the company protects data, manages risk and operates securely.
You don't need to remember every name and acronym, but there are a few that are worth looking out for:
Cyber Essentials Plus is the UK government's backed cyber security standard. It shows that a company has had its security controls independently tested. Think of it as a strong baseline for any healthcare software provider.
ISO 27001 is the internationally recognised standard for information security. It looks beyond the software itself, assessing how the organisation manages security across its people, processes and technology.
NHS Data Security and Protection Toolkit (DSPT) is the NHS's own security and data protection framework for organisations handling health information. While not every private practice software provider completes it, those that do are demonstrating a commitment to meeting NHS-level standards.
PCI DSS applies if the system handles patient payments. It confirms that card details are processed and stored securely, helping to protect both your practice and your patients.
What to ask: "Which certifications do you currently hold? Can you share the certificates? Do you complete the NHS DSPT?"
✅ Green flag: Current certifications such as ISO 27001, Cyber Essentials Plus and, where appropriate, the NHS Data Security and Protection Toolkit. They should be happy to share evidence (ISO27001 holders should be able to produce their certificate).
🚩 Red flag: Lots of talk about "best practice" but no recognised certifications to support it. If they talk about their suppliers certifications – for example ‘AWS being ISO 27001’ – that does not apply.
Question three: Has anyone tried to break into their system?
No software is completely immune from cyber attacks. What sets a supplier apart is whether they actively looks for weaknesses before someone else does.
The best way to do that is through an independent penetration test, where specialist security experts are paid to try and find vulnerabilities in the system. Think of it like hiring a locksmith to test every lock and window before you move into a building.
Any EHR handling patient data should have a penetration test completed by a CREST or CHECK accredited firm within the last 12 months. A reputable vendor will share the executive summary under a confidentiality agreement.
What to ask: "When was your most recent independent penetration test? Which firm did it? Can I see the executive summary?"
✅ Green flag: There’s a named CREST-accredited firm, a test within the last 12 months, and a willingness to share findings and what was fixed.
🚩 Red flag: A vague statement like, "We follow secure development practices" or "our developers are security-trained." Those things may be true, but they're not a penetration test.
Question four: What does the system actually run on?
This question might sound a bit technical, but you don't need to understand cloud architecture to get the information you need. You just need to know whether your provider has invested in the kind of infrastructure you'd expect for software that's storing sensitive patient information.
Enterprise-grade systems are typically built on platforms such as Amazon Web Services (AWS), Microsoft Azure or Google Cloud. These are the same ones used by banks, hospitals and government organisations, because they're designed with security and resilience in mind.
Fast development can come with trade-offs
It’s never been easier to build software quickly using newer development platforms and AI-powered tools. That's helped drive innovation, but speed shouldn't come at the expense of security. Security researchers have found serious problems with these in healthcare settings: one study of over 1,400 apps built this way found more than 2,000 critical vulnerabilities and over 400 sets of exposed login credentials in live systems with real users.
You need the confidence that the foundations of your practice are as secure as everything you'll build on top of them.
What to ask: "What cloud infrastructure does your system run on? Has your database security configuration been independently audited?"
✅ Green flag: They can confidently tell you which enterprise cloud platform they use and explain how it's secured, including evidence of independent security reviews.
🚩 Red flag: They avoid the question, quickly steer the conversation back to features, or can't clearly explain what their system is built on. If they mention a platform you've never heard of, spend five minutes researching it before making a decision.
.webp)
Question five: Can they prove their reliability?
Systems occasionally have issues, that's true of almost any technology. What’s more important is how often they happen and how quickly they're resolved. A provider that's transparent about occasional incidents is far more reassuring than one that claims nothing ever goes wrong.
You can check this by looking for a public status page. This shows whether the system is running normally, records previous incidents and details what exactly happened. It's a simple way to see how a provider performs over time rather than relying on a promise in a sales meeting.
If you're running a larger practice, it's also worth asking about their Service Level Agreement (SLA). This sets out the level of uptime they guarantee (99.5% or above is a reasonable minimum), along with how quickly they'll recover if something goes wrong and how much data could potentially be lost. These are the commitments that matter when your clinic is relying on the system every day.
What to ask: "Do you have a public status page? What uptime do you contractually guarantee?"
✅ Green flag: A publicly available status page with incident history and, for larger practices, a written SLA guaranteeing at least 99.5% uptime.
🚩 Red flag: They tell you the system is reliable but can't show any evidence, or the contract offers little protection if the system is unavailable.
Question six: Where is your patient data stored, and who can access it?
Under UK GDPR and the Data Protection Act 2018, you need to know where patient data is held and whether it ever leaves the UK or EU. So it's perfectly reasonable to ask exactly where that information lives and who might have access to it.
Most modern EHRs rely on several specialist providers behind the scenes for hosting, databases, email delivery or monitoring. That's completely normal. The important thing is that your supplier is open about who those providers are and where your data is stored.
If the system includes AI features, it's also worth asking what happens to any information you enter. Does another company process that data? Is it ever used to train AI models? These are questions every healthcare provider should feel comfortable asking.
What to ask: "Where is patient data stored? Can you share your sub-processor list? If you use AI features, is patient data ever used to train your models?"
✅ Green flag: Patient data is stored in the UK or EU, there's a clear list of sub-processors and the provider can confirm its AI features don’t train on patient data.
🚩 Red flag: Vague answers about where data is stored, no sub-processor list or uncertainty about how AI handles patient data.
Question seven: If something goes wrong, who's responsible?
When it comes to contracts, many practices understandably focus on features and pricing, then sign on the dotted line without looking too closely at the legal terms. That's often where you'll find limits on the provider's responsibility if something goes wrong.
Most providers will cap their liability, and if a breach results in a fine, you will carry much of that burden, regardless of where the fault lay. Under UK GDPR, the ICO can fine the data controller – which is you, the practice, not the software provider - up to £17.5 million or 4% of annual turnover for serious breaches. So make sure you read the liability clause thoroughly before you sign anything.
It's also worth checking whether the supplier has cyber insurance. While insurance doesn't prevent incidents, it shows they've taken their own risks seriously enough to protect themselves and their customers.
If you’re a larger organisation, don't be afraid to negotiate. You're trusting a supplier with large volumes of patient data, so it's reasonable to ask whether their standard terms are appropriate for your practice.
What to ask: "What's your liability cap? Is it negotiable? Do you hold cyber insurance?"
✅ Green flag: They explain their liability cap clearly, are willing to discuss the contract where appropriate and confirm they have cyber insurance.
🚩 Red flag: Liability is capped at a very low level, there's no willingness to discuss the terms or they don't have cyber insurance.
Question eight: Are they a company you can trust for the long term?
Choosing an EHR isn't like choosing a new piece of office equipment. Clinical records often need to be retained for many years, so knowing the company behind your software will be around for the long term is key.
Spend a few minutes looking into the business itself. A quick look at Companies House will give you a good indication. How long have they been operating? Who are the directors? Are accounts filed? Do they have an established customer base?
Ask for references from practices similar to yours. A conversation with existing customers can tell you a lot about the stability of the business you're choosing.
What to ask: "How long have you been operating? How many practices use your system? Can I speak to one of your customers?"
✅ Green flag: Several years of trading, an established customer base and genuine customer references.
🚩 Red flag: They avoid giving numbers, can't provide references or appear to have very little operating history.
Question nine: What happens if you decide to leave?
Nobody signs up to an EHR expecting to move elsewhere, but it's still worth knowing what would happen if you did.
Your patient records belong to your practice. A good provider should make it clear how you'll get your data back, how long you'll have to export it and what format it will be provided in.
It's also sensible to understand what would happen if the supplier itself stopped trading. If a provider folds with no exit plan in place, recovering years of patient records can be difficult and expensive. Asking now avoids unpleasant surprises later.
What to ask: "How would we export our data if we left? What format would the data be in? What happens if your company stops trading?"
✅ Green flag: A clearly documented export process, data returned in a usable format and an explicit plan covering insolvency.
🚩 Red flag: Unclear answers, no defined export process or data that's difficult to move elsewhere.
Question ten: What happens if there's a security incident?
Even the most secure organisations occasionally experience security incidents. The difference is whether they're prepared for them.
A responsible provider should have a documented incident response plan that's regularly tested, along with a clear process for notifying customers if something affects their data. They should also make it easy for security researchers to report vulnerabilities so issues can be fixed before they become bigger problems.
You're not looking for perfection – you just need evidence that security is taken seriously and that there are well-rehearsed processes in place.
What to ask: "What happens if you experience a security incident? How quickly would you notify us? Do you have a responsible disclosure policy?"
✅ Green flag: A tested incident response process and a prompt customer notification.
🚩 Red flag: Vague assurances that they'd "notify you promptly" without explaining how or when.
Question eleven: Can you easily find their security information?
One final question often tells you a lot about a company's attitude to security.
Many providers now have a dedicated trust centre or security portal where they publish certifications, security documentation, audit reports and information about how they protect customer data. That means you can review much of what you need before you've even spoken to their sales team.
Transparency builds confidence. If you have to chase basic security information, it's worth asking yourself why.
What to ask: "Do you have a trust centre or security portal where I can review your security information?"
✅ Green flag: A publicly available trust centre with up-to-date certifications, documentation and security contacts.
🚩 Red flag: Security information isn't readily available, or you're repeatedly told someone will send it to you later.
Remember, you’re not just choosing software, you’re choosing a long-term partner to help protect your patients’ information. If a provider can’t answer these questions clearly or constantly steer the conversation to features instead of security, that’s valuable information in itself.
Your patients are placing their trust in you. It's perfectly reasonable to expect the same level of transparency from the company looking after their data. Ask the difficult questions; the right provider will be happy to answer them.
The ultimate security checklist
Print this out and run through it before signing any EHR contract.
- Named clinical safety lead and explanation of their risk management process
- Cyber Essentials Plus certificate
- ISO 27001 certificate
- NHS DSPT completion evidence
- PCI DSS compliance confirmation if the system handles payments
- Penetration test executive summary from a CREST or CHECK firm within 12 months
- Public status page with historical uptime data
- SLA with defined uptime guarantee plus RTO and RPO commitments for larger practices
- Full sub-processor list with UK or EU data residency confirmed
- Cyber insurance confirmation
- Contract liability clause reviewed
- Companies House registration and trading history checked
- Customer references
- Data export and insolvency terms in the contract
- Incident response and breach notification process
- Responsible disclosure policy
- Publicly accessible trust centre
.webp)
Fay Sears is Head of Information Security at Semble. In her role, Fay leads Semble's AI security and AI governance strategy: architecture, risk assessment, red teaming and secure AI adoption for regulated health technology. She works across security leadership, AI security, AI governance and technology operations, helping engineering teams and executives adopt new technologies safely without losing momentum.
