GDPR-Compliant Software for UK Businesses: What It Actually Requires (Beyond the Cookie Banner)

Quick answer

UK GDPR compliance is mostly not a software feature — it is how your business uses software: knowing what personal data you hold, why you may hold it, how long you keep it, and being able to find, export and delete it when a customer asks. But software choices make those duties easy or impossible. Whether you are buying off-the-shelf tools or commissioning a custom build, the same short checklist applies: data mapping, retention that actually deletes, access-request capability, sensible security (roles, encryption, audit trails), and processor contracts with every vendor touching your data. None of it requires a compliance department; all of it requires deciding before the system is full of customers.

The duties your software must support

Buying off-the-shelf: the questions that matter

Reputable SaaS handles the infrastructure layer (encryption, hosting, uptime), but four questions separate genuinely helpful vendors: Where is the data stored (UK/EU or adequacy-covered — post-Brexit transfer rules matter)? Is there a data processing agreement (a GDPR requirement for every processor — reputable vendors publish one; its absence is disqualifying)? Can you export everything in usable formats — for access requests and for leaving? Do retention and deletion actually work — can you purge on schedule, or does “delete” just hide? The same diligence applies to the informal tools where data leaks sideways: the spreadsheet copies, the WhatsApp job photos with names attached — shadow data is unmanaged data, and it is the audit’s first finding (one more argument in the case against spreadsheet systems).

Building custom: compliance by design (it is cheaper that way)

Data protection by design is a legal principle, but it is also just cheaper: retention jobs, role-based access, audit logging, per-person export and clean deletion cost little specified in a build’s requirements and multiples retrofitted later. The custom-build checklist we specify by default on software projects: collect only fields with a purpose (every “nice to have” field is future liability), a soft-delete-then-purge pipeline, admin tooling for access requests, environment-separated test data (real customer data in dev systems is a classic finding), and audit trails on personal-data reads. If the system integrates with others, the data-sharing map is part of the design — every integration is a data flow with a lawful basis, not just an endpoint. Ageing systems deserve the same lens: unsupported platforms holding customer data are a compliance exposure as much as a technical one, covered in legacy modernisation.

The proportionate version for a small business

1. One-page data map: what personal data, in which systems, why, kept how long. Two hours, and it drives everything else (the ICO’s small-business resources template this well).
2. Registration: most UK businesses processing personal data owe the ICO a small annual data protection fee — commonly missed, easily fixed.
3. Retention rules set in the tools you already use — CRM auto-archiving, mailbox policies, a diarised annual purge.
4. An access-request drill: once, for a test person, before a real request arrives with the clock running.
5. Processor list with DPAs — every SaaS tool touching customer data, with its agreement noted.

That is a day of work, most of it once. GDPR enforcement against SMEs is rare and reserved for the careless — but the same day of work is also what stops a stolen laptop or a mis-sent export becoming a crisis, which is the practical point of the whole regime.

A retention schedule you can actually write this afternoon

“Retention with teeth” is the duty most often nodded at and least often implemented, because people imagine it requires legal advice. It requires a table. Most UK small businesses can produce a defensible one in an hour by starting from the obligations that already govern them, then defaulting everything else to the shortest period they can live with.

Write it, date it, and set one recurring calendar entry to run the purge. The document matters as much as the deletion: an SME that can produce a retention schedule and show it was followed is in an entirely different position from one that cannot, even if some data survived longer than intended.

What compliance costs a small business, itemised

• ICO data protection fee: most organisations processing personal data owe an annual fee, in the region of £52 for the smallest tier and rising for larger organisations, with a small discount for direct debit. Check the current figures on the ICO’s site — the tiers are reviewed periodically and the fee is trivially cheap compared with being chased for not paying it.
• Privacy notice and internal policy drafting: £0 using ICO templates and an hour of honesty, or £300–£900 if you want a solicitor’s version because commercial clients ask for one.
• Cookie consent tooling: £0–£15 a month. Note that this is the layer everyone buys and the layer that matters least; a perfect banner on a site that emails a 2018 list is compliance theatre.
• An access-request handled manually: 3–8 hours of somebody’s time the first time, mostly spent finding data in mailboxes and spreadsheets. That is the true cost of poor data mapping, and it recurs.
• Building the export and delete tooling into a system: commonly £500–£2,500 specified up front, and several times that retrofitted into a live system with real customers in it.
• External DPO or advisory retainer: £150–£600 a month. Genuinely unnecessary for most small businesses; relevant if you process health data, children’s data or large volumes of special-category information.

For context on the downside, UK GDPR penalties top out at £17.5 million or 4% of global turnover, while breaches of the electronic marketing rules are capped separately at £500,000 — and it is the marketing rules, not the grand data-protection principles, that catch small businesses most often, because sending unsolicited email to a bought list is a discrete, provable act.

The subject access request drill, step by step

Run this once against a fictional customer before a real request ever arrives, because the clock — one calendar month — starts when the request is received, not when someone recognises it as a request.

1. Log it. A request can arrive by phone, email, social media message or a comment to a member of staff. Anyone who takes it must know to record the date. Train the person who answers the phone, not just the office manager.
2. Verify identity proportionately. Enough to be sure, not so much that you are collecting new data to satisfy a request about existing data.
3. Search every location on your data map. The CRM, the accounts package, the shared drive, the job-photos folder, the mailbox archives, the WhatsApp threads, the paper file in the van. If a location is not on your map, this is when you discover it.
4. Redact third parties. Other people’s names and details in the same records generally come out; this is the fiddly part and the reason a real request takes hours.
5. Supply in a usable format, with an explanation of what the data is and why you hold it.
6. Record what you did. The file note is your evidence of compliance if the requester complains to the ICO.

Businesses that hold customer data in one properly structured system finish this in under an hour; those running on mailboxes and spreadsheets spend a day and still cannot be sure they found everything, which is one of the underrated arguments for consolidating contacts into a single system in the first place — the honest comparison of when that is worth it is in whether your small business needs a CRM.

The two areas SMEs consistently forget

Employee and contractor data. Every business focuses on customers and forgets that staff records — recruitment notes, sickness absence, disciplinary files, tracker data from vans, right-to-work copies — are personal data with the same rights attached, including access requests. Employee SARs are, in practice, far more likely to arrive than customer ones, and they usually arrive during a dispute, which is the worst possible time to discover that your appraisal notes are in a personal mailbox.

Your website is a processing system. Contact form submissions go somewhere, sit somewhere, and are backed up somewhere. An unpatched site holding two years of enquiry data is both a security exposure and a compliance one, and “we didn’t know the plugin stored them” is the standard post-incident sentence. The proportionate answer is the basic hardening described in WordPress security for small businesses, plus a decision about who is actually responsible for updates, backups and access control — which for most owners is worth contracting out as ongoing website management and hosting rather than leaving as an unowned task.

Sharing data with customers: the portal question

A pattern worth naming, because it turns a compliance duty into a service improvement. Businesses that email documents containing personal data — quotes, certificates, reports, invoices, photographs of someone’s home — are creating uncontrolled copies in unknown mailboxes, with no retention, no revocation and no audit trail. Every mis-typed address is a potential notifiable breach, and mis-sent email is one of the most commonly reported incident types in the UK precisely because it is so easy to do.

Putting the same documents behind an authenticated area solves several duties at once: access is logged, documents can be withdrawn, retention can be automated, and the customer stops asking you to resend things. It also happens to be a better experience than an inbox search. Whether that justifies building anything depends on volume and sensitivity — the SaaS-versus-custom trade-off and the realistic price of each is worked through in client portals for small businesses. For a firm sending a dozen documents a month, a shared drive with proper permissions is proportionate; for one sending hundreds containing health, financial or safeguarding information, it is not.

Sources & Further Reading

• Advice for Small Organisations — ICO
• UK GDPR Guidance — ICO
• Data Protection Overview — GOV.UK