UK GDPR for Custom Software: A Practical Guide

Who is responsible for what

Your business is usually the controller: you decide why and how personal data is used, and you carry the main responsibility. Your developer, hosting company and any SaaS services that store the data are processors. UK GDPR Article 28 requires a written contract with each processor covering confidentiality, security, sub-processors, assistance with rights requests and deleting or returning data at the end. Check that this is in place for every supplier in the chain, including email services, AI APIs and backup providers.

The Data (Use and Access) Act 2025, which received Royal Assent on 19 June 2025, amended UK data protection law. The ICO says the data protection provisions are now in force, including a requirement for organisations to have a process for handling data protection complaints. Check the ICO's current guidance for how the changes affect you.

Privacy by design in practice

Article 25 requires data protection by design and by default. In a bespoke system that means:

• Data minimisation. Only collect fields you have a reason for. Do not ask for date of birth if you only need to know someone is over 18.
• Role-based access. Staff see only the records and fields their job needs.
• Audit logs. Record who viewed, changed, exported or deleted personal data.
• Retention rules. Automatically anonymise or delete records after a defined period.
• Sensible defaults. Marketing opt-ins unticked, profiles private unless chosen otherwise.
• Test data. Development and staging environments should use anonymised or synthetic data, not copies of live customer records.

Security the law expects

Article 32 requires security appropriate to the risk. For a typical business web app that includes HTTPS everywhere, encryption of data at rest for databases and backups, hashed passwords (bcrypt or Argon2), multi-factor authentication or single sign-on for staff, protection against common web attacks (the OWASP Top 10), patched servers and frameworks, tested backups and logging. If there is a personal data breach that risks people's rights and freedoms, you must usually report it to the ICO within 72 hours of becoming aware of it, so the system needs logs good enough to tell what happened.

Supporting people's rights

Build features for the rights people use most:

• Access. Find and export everything held about a person, across tables and file storage.
• Rectification. Let users or staff correct data, with a log.
• Erasure. Delete or anonymise a person while keeping records you must retain for legal reasons, such as invoices for HMRC.
• Objection to marketing. Suppression lists that stop all marketing immediately.

If the system makes significant automated decisions about people, or you are planning large-scale processing of sensitive data, carry out a data protection impact assessment (DPIA) first. AI features need particular care; see adding AI to business software.

A GDPR checklist for your development project

Use this list when scoping new software or reviewing an existing system:

1. List the personal data the system will hold, whose it is, and the lawful basis for each use.
2. Remove fields you do not need. Make optional fields genuinely optional.
3. Define roles and which data each role can see, edit and export.
4. Decide retention periods for each type of record, and build automatic deletion or anonymisation.
5. Record an audit trail for access to and changes of sensitive records.
6. Confirm where data will be hosted and backed up, and which suppliers (processors) can access it. Put Article 28 contracts in place.
7. Check any international transfers, including AI and email providers, and the safeguards that apply.
8. Plan how you will find, export, correct and delete a person's data on request.
9. Use anonymised or synthetic data in development and testing environments.
10. Agree security measures: encryption, MFA, patching, backups, monitoring, and a breach response plan.
11. Decide whether a DPIA is needed, and complete it before building if so.
12. Update your privacy notice to reflect what the system does.

Building these in from the first sprint is far cheaper than adding them after launch, when data is already spread across tables, logs and backups.

When to talk to dijitul

dijitul builds business software with role-based access, audit logs and GDPR-aware data handling from the start, and can review existing systems for gaps through a code audit. We are developers, not lawyers, so we work alongside your data protection lead or adviser. Start with a free chat and a fixed-price quote.

Related