Choosing practice-management software is also a decision about how your clinic will handle patient, staff and business information. Use this checklist to compare suppliers on evidence, clarify the controls your clinic will still own, and keep a clear record of the decision.

This is practical procurement guidance, not legal or information-security advice. Seek specialist support where the risks, contracts or proposed data uses require it.

Why this due diligence matters

A practice-management system can sit at the centre of appointment booking, clinical notes, communications, billing, reporting and staff administration. Before selecting one, a UK clinic should understand what information will enter the service, who will use it, and which other tools will connect to it. That makes privacy and security due diligence part of the selection decision, rather than a last-minute supplier questionnaire.

Under the UK GDPR, a clinic that determines why and how personal data is processed will commonly be acting as controller, while a software provider processing that data on the clinic’s behalf may act as processor. The ICO’s guidance explains why controller–processor contracts matter and what they should address. A signed contract is important, but it does not remove the need to judge whether the supplier, the proposed configuration and the clinic’s own working practices are suitable.

Cloud hosting is not a shortcut to a risk-free decision. NCSC guidance describes cloud security as a shared-responsibility model: the allocation of responsibilities depends on the service and deployment model. Your due diligence should therefore test both the provider’s evidence and the controls your clinic must operate after purchase.

Map your data, users and responsibilities

Start with a short, usable map of the proposed service. It does not need to be a technical architecture diagram, but it should be detailed enough to turn broad supplier assurances into specific questions.

Record the categories of information expected to pass through the system. This may include patient contact details, appointment history, notes or documents, payment-related information, staff records, referral details, communications and audit records. Note where data comes from, where it is sent, and whether imports, exports, portals, messaging tools, payment services, video platforms or analytics products are involved.

Then map the people and accounts involved. Include reception and clinical users, managers, temporary staff, external practitioners, IT support, and any patients who will use an online portal. Identify privileged roles such as account administrators, and establish who in the clinic can approve new users, change permissions, export records or disable access.

Finally, write down the proposed division of responsibility. The supplier may operate the service infrastructure and some security functions, while the clinic may remain responsible for choosing secure settings, managing user access, using supported devices and responding to local incidents. NCSC notes that responsibility varies by cloud service model and implementation. A simple responsibility table is often more useful than an assumption that “the provider handles security”.

Check the data processing contract

Where a provider processes personal data for the clinic, ask for the relevant contract terms early enough for them to influence the shortlist. The ICO’s controller–processor guidance is the appropriate reference point for understanding the contract requirements and the respective responsibilities involved.

Use the contract review to ask practical questions:

  • Is the supplier’s role and the clinic’s role described clearly for the proposed use?
  • Does the agreement explain the subject matter, duration, nature and purpose of processing, as well as the types of personal data and data subjects involved?
  • Is processing limited to documented instructions from the clinic, except where law requires otherwise?
  • What confidentiality commitments apply to people authorised to process the data?
  • What technical and organisational measures does the provider commit to, and where is the supporting detail recorded?
  • How will the supplier assist with data-subject requests, security incidents, impact assessments or regulator-facing obligations when assistance is needed?
  • Which sub-processors may be used, how will the clinic be notified of changes, and what objection or escalation route is available?
  • What happens to clinic data when the service ends: return, deletion, timing, format, exceptions and confirmation?
  • What audit, assurance or information rights are available, and are they workable for a small clinic?

Do not treat a standard data processing agreement as automatically sufficient. Compare its wording with the product actually being bought, including integrations, support access, data locations, retention options and subcontracted services. If the supplier will not explain a material term, or if a proposed arrangement conflicts with the clinic’s intended use, record the gap and escalate it before contract signature.

Assess security controls and shared responsibilities

Ground the shared-responsibility assessment in an authoritative cloud-security guidance range Ask suppliers for evidence that is relevant to the planned deployment, not just a feature list. NCSC’s Cloud Security Principles cover areas including protection of data in transit, resilience, governance, operational security, secure user management, identity and authentication, secure administration, and customer audit information and alerting. They apply to cloud platforms and SaaS, while also recognising that customers need to configure services securely.

For a clinic software evaluation, turn those themes into focused questions. Establish how users authenticate, whether stronger authentication is available for administrators and remote access, and how roles and permissions are controlled. Ask how the supplier prevents inappropriate administrative access, how support access is authorised and recorded, and what audit information the clinic can review or export.

Discuss data protection in transit and the service’s resilience arrangements. Ask what service-status, backup, restoration and incident communications the supplier provides; how the clinic can obtain its data if an outage occurs; and what the clinic must do to maintain continuity at its end. Avoid assuming that a cloud provider’s underlying controls answer every application, account-management or configuration question.

Ask how security-relevant events are logged and how the clinic will learn about them. Useful evidence may include clear explanations of user and administrative audit trails, retention of those records, alerting options, incident reporting routes and the information the supplier can provide during investigation. The NCSC principles identify audit information and alerting as a cloud-security consideration, but the right level of evidence depends on the clinic’s own risk, workflow and capabilities.

Make the shared-responsibility boundary explicit. For SaaS, the supplier may take on a substantial share of service operation, but the clinic may still need to manage accounts, permissions, local devices, secure use, configuration and internal procedures. Capture each control as “supplier-owned”, “clinic-owned” or “shared”, name an owner, and check that the owner has the access, time and knowledge to carry it out.

Recognise limitations and red flags

Pause when an answer is vague, cannot be tied to the proposed service, or leaves a responsibility without an owner. A certificate, a cloud-hosting statement or a polished security webpage can be useful context, but none by itself proves that the clinic’s data flows, account setup and contractual needs have been addressed.

Common escalation points include an unexplained sub-processor chain; unclear support or administrator access; no credible account of user-management controls; limited audit information; uncertainty about data return or deletion; and an inability to explain how incidents will be communicated. A supplier may have a reasonable answer, but the answer should be recorded and assessed against the clinic’s requirements rather than accepted verbally.

Also consider operational fit. If the clinic cannot apply the available access controls, monitor the relevant alerts, maintain approved users or follow the supplier’s incident process, that is a risk in the proposed implementation even if the product has strong features. NCSC guidance makes clear that secure cloud use depends on both provider capabilities and customer configuration.

For material gaps, decide whether to obtain more evidence, negotiate terms, change the intended configuration, add compensating controls, seek specialist advice or reject the option. Record the rationale and any residual risk so that the decision can be revisited at implementation and renewal.

Run a practical due diligence process

AI-generated generic editorial illustration — not a retailer product photo and does not depict the reviewed product or service. Give clinic teams a quick, practical sequence for supplier due diligence.

Give clinic teams a quick, practical sequence for supplier due diligence Use a repeatable process so the comparison is fair and the eventual decision can be explained.

  1. Set the scope. Create the data, integration, user and workflow map before asking suppliers for evidence.
  2. Issue the same core questions. Request contract terms, security explanations, shared-responsibility information, sub-processor details, access-control options, audit information and incident arrangements for each shortlisted product.
  3. Assign reviewers. Give operations, clinical leadership, privacy and IT responsibilities that match their knowledge. One person should coordinate the evidence record and chase unanswered questions.
  4. Assess the evidence against the intended setup. Distinguish what the supplier operates from what the clinic will configure and manage. Do not score a control as complete until the proposed owner is known.
  5. Escalate gaps. Log unclear answers, contract exceptions and unresolved implementation dependencies. Decide whether each gap is acceptable, needs a condition before purchase, or requires specialist review.
  6. Retain the decision record. Keep the supplier responses, contract version, configuration assumptions, approvals, residual risks and reasons for the final choice.
  7. Recheck before go-live. Confirm that named clinic owners have applied the agreed access, administration and operational controls. Revisit the record when major integrations, users or service terms change.

This approach supports a proportionate decision without promising that every risk can be eliminated. The aim is to make responsibilities visible, gather evidence that can be tested, and avoid discovering a critical dependency after the clinic is committed.

Frequently Asked Questions

Is a cloud-hosted practice management system automatically secure?

No. NCSC guidance describes security in the cloud as shared responsibility, with the balance depending on the service model and implementation. A clinic should examine supplier controls and the controls it will still need to configure and operate, including user access and secure use.

Ask who they are, what processing they perform, how changes are notified, what terms apply to them, and how the clinic can raise concerns. The ICO’s guidance on controller–processor arrangements is the right starting point for assessing the contractual relationship; obtain specialist advice if the proposed arrangement is unclear or high risk.

Who is responsible for user access controls in a cloud practice management system?

It depends on the service and contract. The provider may supply authentication, role-management and audit capabilities, while the clinic may be responsible for approving users, assigning suitable permissions, removing access and using the controls securely. Document the division for the chosen configuration.

Seek advice when the contract, data flows, risk level, supplier evidence or proposed configuration cannot be assessed confidently by the clinic team. Examples include unresolved processing terms, significant integrations, uncertain incident arrangements, sensitive operational dependencies or a risk that cannot be assigned to a capable owner.

Sources

Editorial information: About our editorial team · Read our editorial policy · Read our affiliate disclosure.