GDPR compliant practice management software is software that lets you, the clinic, meet your own GDPR duties and can prove how: health data encrypted at rest and in backups, consent recorded with the wording the patient actually agreed to, an audit trail showing who opened which record, and a signed data processing agreement. No product is GDPR compliant on its own, because the regulation binds organisations rather than apps. So the useful test is not whether a vendor makes the claim. It is whether they can hand you the evidence within a few days.
This guide is for owners of small private clinics who feel the weight of patient data and have been putting off the software decision because of it. You may run a dental practice in Dublin, a physiotherapy clinic in Rotterdam, a dermatology practice in Lisbon or a nutrition consultancy that sees clients from several countries. What follows is the list of documents to request, the small tests to run in a demo, and the gaps worth watching. It is general information, not legal advice. Your data protection officer, regulator's guidance or a lawyer has the last word for your situation.
What a "GDPR compliant" badge can honestly mean
Treat the phrase as a marketing sentence until something stands behind it. Some vendors mean their hosting is in the EU. Others mean they added a consent checkbox. A few mean a serious programme of controls, audits and contracts. All three can use identical wording on their website.
The GDPR does provide for approved certification schemes under Article 42, but they are not widespread in this market, and having one does not transfer your responsibilities to anyone else. An ISO 27001 certificate is useful evidence about a vendor's security management, though it is not a GDPR verdict. Ask for its scope too: a certificate that covers an office but not the product's production environment tells you less than it appears to.
The roles are the part worth memorising. Your clinic decides why and how patient data is used, which makes you the controller. A vendor hosting that data on your instructions is normally a processor. Article 28 requires you to use only processors offering sufficient guarantees and to have a written contract with them. So when a vendor's security turns out to be thin, a regulator's first question goes to you: what did you check before signing?
Which rulebook are you actually under?
A surprising number of software conversations go wrong because nobody asked this first. Compliance doesn't travel in a neat package, and a product built around one regime says little about another.
EU and EEA clinics work under the GDPR plus national health law. National rules often decide how long clinical records must be kept, who may access them and whether extra safeguards apply, and they vary. UK clinics work under the UK GDPR and the Data Protection Act 2018, with the ICO as regulator and NHS-related requirements if they do NHS work. US practices handling protected health information face HIPAA, which relies on a Business Associate Agreement rather than a GDPR-style processing agreement. A vendor being strong on one says nothing certain about the other. Clinics outside these regions can still fall under the GDPR if they target patients in the EU, for example through a medical tourism programme marketed to German or Dutch patients.
Write down your jurisdiction, and every country whose patients you actively seek, before you compare products. Then ask each vendor the same direct question: which legal frameworks do your contract and your product explicitly support? Vague answers here tend to predict vague answers later.
The evidence pack: seven documents to request before any demo
Demos are built to impress, and you can't assess security by watching a tidy screen. Send a short written request first. A prepared vendor will have most of this in a folder, and the speed of the reply is itself a data point.
| Request | What a good answer contains | Warning sign |
|---|---|---|
| Data processing agreement | Draft you can read now, covering the Article 28 terms | "We send that after you subscribe" |
| Sub-processor list | Named companies, their purpose, their location, and how changes are notified | "Our trusted partners" |
| Hosting and transfer statement | Primary, backup and support-access locations listed separately, with the transfer mechanism if data leaves the EEA | "Cloud-based, so it's secure" |
| Security overview | Encryption, key handling, access control, patching, testing approach | A marketing brochure |
| Breach procedure | How fast you are told and what the notice includes | "It has never happened" |
| Exit terms | Export format, timeline, deletion including backups | Export available only "on request" with no terms |
| Independent evidence | Certificate or audit report, with its scope | A logo with no document behind it |
You don't need all seven to be perfect. A small vendor may have no certificate and still be honest and careful. What you are screening for is a company that knows what you're asking and answers it in writing.
Encryption questions that survive a technical answer
Article 32 of the GDPR names encryption as an example of an appropriate measure, without saying which kind, and that leaves room for hand-waving. The padlock in your browser only shows that data is protected while travelling. Patient records spend almost all their lives sitting still, in a database and in backup files, and that is where a breach hurts most.
File storage deserves its own question. X-rays, before-and-after photos and scanned consent forms are often kept outside the main database, and in an aesthetic or dental clinic they are the most sensitive material you hold. Ask whether the encryption statement covers them. Then try a small test in the demo: copy a photo's link, paste it into a private browser window and see whether it opens without signing in. If it does, you have found something worth a follow-up conversation.
Key management is where a good answer separates itself from a recited one. Encrypted data is only as safe as the keys that unlock it. Who at the vendor can use those keys, is that access logged, and are the keys kept apart from the data? You needn't judge the cryptography yourself. If a vendor can't explain this in plain language or treats the algorithm's name as a trade secret, pass the answer to someone technical. Algorithm names aren't secret. Keys are.
Logging in matters as well. Encryption does nothing for an account whose password sits on a sticky note at reception. Check that each user gets a personal login, that multi-factor authentication is available, particularly for access from outside the clinic, and that idle sessions close automatically on shared front-desk computers.
Consent records: treatment usually isn't the part that needs one
Many clinics over-rely on consent. They give patients one long form that covers treatment, data use, photos and promotional messages, and then file it. That approach creates two problems at once. Consent under the GDPR must be freely given, specific and as easy to withdraw as to give, so a bundled form is weak. And if consent is your legal basis for running the clinical record, what happens when a patient withdraws it?
Care delivered under professional secrecy often rests on Article 9(2)(h) rather than on consent, with national law filling in the detail. Consent tends to be the natural basis for things that are truly optional: using a photo on your website, sending promotional newsletters or joining an optional programme. Clinical consent to a procedure is a different concept again, belonging to medical law. Have your adviser map your activities once, on a single page. Software can't make these decisions for you. It can only record them well.
When you look at a system's consent feature, four questions show whether it's real:
- Are purposes separate? A single "GDPR accepted" tick isn't enough for photo use and marketing.
- Is the wording versioned? When your privacy notice changes, can you still show which text a patient accepted three years ago?
- Is the context stored? Date, channel and the staff member who recorded it.
- Does withdrawal do anything? Withdrawal should stop the related activity while keeping a record of when it happened.
Test the last one directly. Create a test patient, grant photo consent and refuse marketing consent. Go to the bulk messaging screen and check that the patient is excluded. Then withdraw the photo consent and see how the record looks. That takes about two minutes and tells you more than any feature list. E-marketing rules, such as the ePrivacy-based national laws and PECR in the UK, sit alongside the GDPR here, so treat appointment reminders and promotions as separate categories.
The audit trail drill: "Who opened Maria's record?"
Picture a patient who works in your town's only school. She tells you that a colleague knows something about her treatment, and she wants to know who at your clinic viewed her file. She may have a right to some of that information through an access request, and in any case you need to investigate. Can you answer within the hour?
This is what an audit trail is for, and it's different from the activity history many products show. An activity history says an appointment was created or a payment was taken. An audit trail should capture read access too, sit where ordinary users can't edit it and be searchable. Ask for these in the demo:
Have the vendor run two searches live: every user who opened a given patient's record in the past six months, and every record a given user opened last month. If they need to file a support ticket or export a raw log to answer, factor in how that would feel during an actual incident. Ask how long entries are kept as well. A log that is purged after a few weeks may not reach back to when the problem began. Logs contain personal data themselves, so who can read them should be a separate permission.
A log only deters and explains. Prevention comes from permissions, under the principle that each person sees what their role requires. A front desk usually needs names, phone numbers and appointment times but not clinical notes. An accountant needs payments but not diagnoses. A treatment name in a payment list can reveal a good deal on its own, so ask whether service names can be simplified for non-clinical roles.
Small-clinic habits that defeat good software
In a small practice, the weak points are rarely cryptographic. They come from the way busy people work, and it is worth checking how well a product helps you resist them.
The shared login. One account for the whole front desk is convenient, and it makes the audit trail meaningless. Ask whether adding a user for each person is practical under the vendor's plan structure, because a pricing model that punishes extra seats quietly encourages sharing. For small teams, this question deserves real attention when you compare quotes.
The monthly export. Someone downloads a patient list to work on in a spreadsheet. From that moment, the file has none of the protections in this article. Restrict export to one or two people and make sure every export is logged.
The messaging shortcut. Staff send a photo of a wound to a clinician's personal phone. Reminders mention a specific treatment. Using WhatsApp in a healthcare setting raises its own questions about the provider's role and international transfers, which is why you should take advice and keep reminder templates neutral: "Your appointment is tomorrow at 15:00" says everything the patient needs.
The trial with real data. This is the easiest mistake to make when you're evaluating software. Loading real patients into a free trial before any contract or DPA exists is exactly the situation you were trying to avoid. Use made-up records for the trial and move real data only once the paperwork is finished.
The forgotten old system. After a migration, old accounts stay active and old backups sit on a shelf. Decide in writing whether each is retained, archived or destroyed. The migration file itself deserves care too, so don't send it by plain email. More on basic backup discipline is in our guide to business data security and backups.
Records you must keep, data you must delete
Patients sometimes assume the right to erasure means everything vanishes on request. For clinical records it often doesn't, since Article 17 has exceptions where a legal retention duty applies, and many countries set minimum periods for medical documentation. Those periods differ by country and record type, so your local rules matter. What your software needs to support is the difference between three actions.
Suppress: take someone out of marketing and reminders immediately. Restrict: keep a record but limit who can see it, for instance once a retention period is all that justifies holding it. Delete: permanently remove data whose retention period has expired, and do it in a documented way that covers backups on a known schedule. Ask a vendor to show how each works. A system with only an "archive" button leaves your retention policy as a hope rather than a process.
Exit is the other half of this. Article 20 gives patients a portability right in some circumstances, and you need practical portability as a customer. Ask for a sample export before you sign. Are clinical notes, attachments and consent history all included, in a form another system could read? How long after you leave does your data remain, and when do backups age out? It's far easier to negotiate these points while the vendor still wants your business.
Where Welda CRM stands on this test
We'd rather you judge us with the same list. Welda CRM as GDPR compliant practice management software is a web-based system for appointment-led clinics and practices. Our product pages state that client and health records are stored encrypted, that KVKK and GDPR consent management is built in, that an audit log records who accessed what, and that permissions are role-based. Health records include allergy and contraindication warnings, with a before-and-after photo archive. All of that is designed to support your obligations. None of it completes them for you.
Here is what those pages don't specify, and what you should get in writing from us as you would from anyone: the encryption algorithm and key handling, hosting and backup locations, backup frequency, multi-factor login, audit log retention, post-contract deletion timelines, and the sub-processor list. WhatsApp reminders mean a phone number and message content pass through the messaging provider, so keep those templates neutral and consider this channel in your own assessment.
Where it may fit: private clinics and practices that want scheduling, patient records, packages, payments and reminders in one place, and are moving away from paper and spreadsheets toward personal logins, permissions and a recorded trail. Setup and data migration are included, and the interface comes in English, German and Turkish.
Where it won't fit: our pages describe KVKK and GDPR support, not HIPAA. They don't list insurance claim submission, e-prescribing, lab interfaces, direct imaging-device integration or certified EHR status. If any of those are requirements in your country or specialty, Welda CRM shouldn't be your core clinical system. If you must host on your own servers, that option isn't on our pages either. For a broader look at record-keeping, see patient records systems, and if you practise alone, the solo practice software guide covers what you can leave out. Our patient data security guide goes deeper on daily clinic habits.
A forty-five minute vendor test
Once the evidence pack is in, shortlist two vendors and run the same session with both. Use only test data. Have the person who will run the front desk in the room, because they will spot workflow problems you won't.
- Ten minutes on roles. Create a receptionist account. Log in as that person and try to open clinical notes, export the patient list and view the audit log. All three should be refused unless you allowed them.
- Ten minutes on consent. Run the separate-purpose test described above, including withdrawal and the bulk message exclusion.
- Ten minutes on the trail. Open a record as the receptionist, then search the audit log as the administrator and find that view. Check whether the entry can be edited.
- Five minutes on files. Upload a test image and try the private window link test.
- Ten minutes on the bad day. Ask them to walk through their response to a suspected breach on a Friday evening. Who calls you? When? What will you receive to complete your own notification under Article 33, which generally gives controllers 72 hours?
Score each answer as shown, promised or vague. Then compare offers on a like-for-like basis: subscription level, users, messaging volume, storage and any integration fees. Pricing for Welda CRM is set in a free conversation based on your branches, users, messaging volume and modules, so bring the same list to that call.
Frequently asked questions
Does using GDPR compliant software make my clinic compliant?
No. You remain the controller. Privacy notices, legal bases, staff training, retention rules, records of processing and, where required, a data protection impact assessment or data protection officer are your responsibility. Good software makes these tasks easier and leaves evidence behind.
Must my patient data be hosted in the EU?
The GDPR doesn't impose a blanket requirement, but transfers outside the EEA need a valid mechanism such as an adequacy decision or standard contractual clauses. Some national health rules are stricter. Ask for primary, backup and support-access locations separately and check them against your local requirements.
Do I need patient consent for everything in the system?
Usually not for delivering care, where another legal basis often applies under Article 9 together with national law. Marketing and optional uses such as photos are usually handled differently. Your adviser should confirm this for your country and activities.
Is a spreadsheet with a password acceptable for a very small practice?
A password is a barrier, but it gives you no record of who saw what, no individual permissions and no consent history, and it stops protecting anything once shared. It's hard to defend as a long-term home for health data, even if the practice is small.
Is a data processing agreement really necessary for a small clinic?
Yes. Article 28 doesn't exempt small controllers. If a vendor processes patient data on your behalf, you need that contract in place before real data goes in.
Can I try Welda CRM before deciding?
Yes. There's a 7-day free trial with all modules open, and we suggest starting with sample records. When the trial ends, the account becomes read-only and the data isn't deleted, so ask what happens to anything you've entered if you decide not to continue.
What should I do next?
Send the evidence request to your shortlisted vendors this week and put the replies in one table. If you'd like to put your list in front of us too, book a free call. We'll go through your questions on GDPR compliant practice management software and tell you plainly whether Welda CRM fits your clinic.