GDPR compliance for small business software: a practical guide

GDPR guidance for small businesses tends to arrive in two unhelpful forms: legal boilerplate nobody reads, or scaremongering about fines from consultants selling compliance packages.

The practical reality is more manageable. UK GDPR and the Data Protection Act 2018 are principles-based, and for a typical small business those principles translate into a fairly short list of things a system should do. This post is that list.

The five principles that affect software design

There are more than five principles in the legislation, but these are the ones that change how software is actually built.

1. Lawful basis: know why you hold it

Every piece of personal data you store needs a lawful basis. There are six, and for most small businesses it is one of three: consent (they agreed), contract (you need it to deliver what they bought), or legitimate interests (you have a genuine business reason that does not override their rights).

Consent is the most commonly misused. It must be freely given, specific, and as easy to withdraw as to give. A pre-ticked box is not consent. For a clinic storing treatment records, contract or legal obligation is usually the correct basis, not consent.

2. Data minimisation: collect less

You should collect only what you actually need for the stated purpose. This one is quietly liberating, because the cheapest way to protect data is not to hold it.

In practice: review every field on every form. Do you need a date of birth, or would an age bracket do? Do you need a full address, or a postcode? Every field you delete is one less thing to secure, migrate, and disclose in a breach.

3. Storage limitation: delete on schedule

Personal data should not be kept forever. You need a retention period for each category of data and a mechanism that actually enforces it.

This is the most commonly ignored requirement, because deleting data feels wrong to businesses. But "we keep everything indefinitely" is not a retention policy, and a system with no deletion mechanism cannot comply no matter what the policy document says.

4. Integrity and confidentiality: the security bit

The law requires "appropriate technical and organisational measures." It is deliberately non-prescriptive, but for a modern small-business system a reasonable baseline looks like this:

• Encryption in transit (HTTPS everywhere, no exceptions) and at rest for the database.
• Role-based access control, so people see only what their job requires.
• Individual accounts with strong authentication. No shared logins, ever.
• An audit log recording who accessed or changed sensitive records, and when.
• Automated, tested backups. An untested backup is a hope, not a backup.
• Prompt patching of dependencies, which is where most real-world breaches begin.

5. Accountability: be able to show it

You must be able to demonstrate compliance, not merely claim it. For a small business this means a record of what you hold and why, your retention periods, who you share it with, and any processors you use. It does not need to be elaborate. A well-maintained document is fine.

The rights your system must actually support

Individual rights are where compliance meets engineering, because each one implies a feature. If your system cannot do these things, you cannot meet the deadlines.

The one that catches people out is access. A subject access request means producing everything you hold about a person within a month. If their data is spread across a CRM, three spreadsheets, an email archive, and a WhatsApp group, that request becomes days of manual work, and you will probably miss something.

This is one of the underrated arguments for consolidating systems: it turns a week of panic into a button. It is also a good reason to reduce the sprawl described in five signs you've outgrown spreadsheets.

Breaches: the 72-hour rule

If a personal data breach is likely to result in a risk to people's rights and freedoms, you must report it to the ICO within 72 hours of becoming aware of it. If the risk is high, you must tell the affected individuals too.

Seventy-two hours is not long to work out what happened. That is precisely why audit logging matters: without it, you cannot answer the ICO's first question, which is what data was actually accessed.

Questions to ask any developer or vendor

Whether you are buying off-the-shelf or commissioning something custom, these questions separate serious suppliers from the rest.

1. 1Where is the data physically hosted? UK or EEA hosting keeps international transfer rules simple. If it is elsewhere, ask what transfer mechanism applies.
2. 2Who can access the production database, and is that access logged? "The developer has full access whenever they like" is a poor answer.
3. 3How do we export all data for one person? If there is no answer, DSARs will be manual forever.
4. 4How is data deleted, and what happens in backups? Deletion that leaves records in backups indefinitely is not deletion.
5. 5Who owns the data and the code? Get it in writing. You should be able to leave with everything.
6. 6What sub-processors are involved? Every third-party service touching personal data needs to be on your record.

A sensible order to do this in

If you are starting from nothing, do not try to do all of it at once.

1. 1List every place personal data currently lives. Include the spreadsheets and the shared inbox. This alone is usually revealing.
2. 2For each, write down why you hold it and how long you keep it.
3. 3Delete what you do not need. This is the fastest genuine risk reduction available to you.
4. 4Fix access control on what remains: individual accounts, least privilege.
5. 5Then, and only then, worry about the more advanced tooling.

Most small businesses are closer to compliant than they fear, and the gap is usually retention and access control rather than anything exotic.