GDPR and business software: a practical guide to protecting personal data

Customer records, membership databases, staff accounts and online enquiry forms all involve information about people. When software handles that information, data protection needs to be considered throughout its design, development and use.

Good software can make those responsibilities easier to manage. It can limit access, reduce unnecessary data collection, support retention policies and help an organisation respond when someone asks about their information.

This guide explains the main considerations for UK organisations planning a new application or improving an existing system.

Which data protection rules apply?

For organisations in Wales and elsewhere in the UK, the main framework is the UK GDPR, alongside the Data Protection Act 2018. The Privacy and Electronic Communications Regulations, commonly called PECR, contain additional rules affecting matters such as cookies and electronic marketing.

The Data (Use and Access) Act 2025 has amended these laws. It has not replaced the UK GDPR. Its changes include provisions affecting lawful bases, automated decisions and certain uses of cookies.

Organisations operating internationally may also need to consider the EU GDPR or other countries’ requirements. Which rules apply depends on the organisation’s activities and circumstances. ICO overview of the changes

What counts as personal data?

Personal data is information relating to an identified or identifiable living person. A name is an obvious example, but someone may also be identifiable through a combination of information.

Within business software, this could include:

• Customer contact details and correspondence.
• Membership records and subscription histories.
• Employee records and individual user accounts.
• Application activity linked to a particular person.
• IP addresses, location information and other online identifiers where they relate to an identifiable individual.

Removing names does not necessarily make a dataset anonymous. If people can still reasonably be identified, the information may remain personal data.

Some information requires additional protection. Health information, trade union membership and certain biometric information are examples of special category data. Criminal offence information has separate additional rules. These distinctions matter when deciding what a system should collect and how it should protect it. ICO definitions and guidance

Who is responsible for the information?

The controller decides why personal information is used and the essential means of using it. A processor handles information on the controller’s behalf.

For example, an organisation running a membership service will usually be the controller of its membership records. A supplier hosting or supporting the application may act as a processor for that work.

The position depends on the actual activities. A developer does not become a processor simply by writing software, particularly if they never access personal data.

Where a processor is involved, an appropriate written agreement must address matters including instructions, confidentiality, security, subcontractors, assistance with individual rights and what happens to the data when the service ends. Outsourcing an application does not remove the controller’s responsibilities. ICO guidance on processor contracts

Consent is not always required

An organisation needs an appropriate lawful basis for each purpose for which it uses personal information.

The UK GDPR now provides seven bases: consent, contract, legal obligation, vital interests, public task, recognised legitimate interest and legitimate interests. Each has its own requirements.

For example, processing necessary to fulfil a contract with an individual may rely on the contract basis. Keeping particular records may be necessary to meet a legal obligation. Other activities may require a legitimate interests assessment or freely given consent.

Consent should offer a meaningful choice. Where it is used, the organisation needs to record it and make withdrawal straightforward.

From a software perspective, this means understanding why each piece of information is needed before deciding which fields, permissions and preferences to build. A compulsory consent checkbox should not be added automatically to every form. ICO guidance on lawful bases

The seven principles in practice

The data protection principles provide a useful foundation for software requirements:

1. Lawfulness, fairness and transparency: use information legitimately and explain its use clearly.
2. Purpose limitation: define the purposes and assess proposed further uses.
3. Data minimisation: collect only what is necessary.
4. Accuracy: support corrections and appropriate updates.
5. Storage limitation: establish how long information is needed.
6. Integrity and confidentiality: protect information against inappropriate access, loss and damage.
7. Accountability: document decisions and demonstrate compliance.

A practical question follows from each principle. Why is this field mandatory? Who should see this record? When should it be reviewed or deleted? How will the organisation explain the decisions it made? UK Government guidance

Build data protection into the application

Data protection by design and default means considering privacy from the beginning and throughout the system’s life.

For a membership application, for example, different staff may need different access. Someone administering subscriptions might need payment status without needing access to sensitive case notes.

Depending on the system, useful design choices could include:

• Restricting access according to staff responsibilities.
• Making optional information genuinely optional.
• Limiting what appears in search results and exports.
• Avoiding unnecessary personal information in diagnostic logs.
• Providing controlled correction, deletion and retention processes.
• Using fictional or appropriately anonymised data for development and demonstrations.

Projects likely to create a high risk to individuals require a Data Protection Impact Assessment, or DPIA. This should inform the design before processing begins. ICO guidance on accountability and design

Security includes keeping information available

Security measures should reflect the nature of the information, how the system is used and the potential consequences of an incident.

Encryption can provide valuable protection, but it depends on appropriate implementation and secure management of the keys. Encrypting a backup is of limited benefit if the organisation subsequently loses the means to restore it.

Backups, recovery arrangements and controlled access therefore need to be considered together. Recovery should be tested, and backup retention should be consistent with the organisation’s approach to keeping and deleting personal information. ICO guidance on encryption and backups

Plan for people exercising their rights

People have rights concerning their personal information. Depending on the circumstances, these include access, correction, erasure, restriction, objection and portability.

Software should help authorised staff locate and review the relevant information. That may require looking across records, uploaded documents, correspondence and connected systems.

A subject access request generally needs a response without undue delay and within one month, subject to the applicable rules on identity checks, clarification and extensions. ICO guidance on responding to access requests

These rights have conditions and exemptions. Erasure is not an unconditional entitlement to remove every record: information may still be needed, for example, to comply with a legal obligation or deal with legal claims. ICO guidance on erasure

Data portability is a distinct right with its own scope. A routine database export should not automatically be treated as satisfying every information request. ICO guidance on portability

Cookies and third-party services need consideration

Websites can interact with analytics tools, advertising services, embedded media and other external providers. These connections should be understood when assessing privacy obligations.

PECR regulates storing information on, or accessing information from, someone’s device. Consent is normally needed unless an applicable exception is satisfied. Current rules include exceptions for certain statistical and functionality purposes, with conditions; this does not mean that all analytics tools are exempt.

A cookie banner must match the site’s actual behaviour. Its presence alone does not establish compliance, and advertising technologies should not be assumed to qualify for an exception. ICO guidance on cookies and similar technologies

Prepare for incidents

A personal data breach can involve accidental disclosure, deletion, loss or unauthorised access. An email sent to the wrong recipient can be a breach, just as a compromised application can.

Organisations should have a process for containing incidents, assessing the risk and recording their decisions.

Where notification to the ICO is required, it must be made without undue delay and, where feasible, within 72 hours of becoming aware of the breach. Affected individuals must also be informed where the breach is likely to create a high risk to their rights and freedoms. Not every breach requires notification, but all personal data breaches need to be documented. ICO guidance on personal data breaches

Questions to ask before commissioning software

Before development begins, it helps to establish:

• What personal information will the application use, and why?
• Does it involve sensitive information or children’s information?
• Who needs access, and what should each person be able to do?
• Which suppliers and connected services will handle the information?
• How will records be corrected, retrieved, retained and deleted?
• Who will maintain the application and respond to incidents?

Clear answers make it easier to agree sensible requirements and avoid expensive changes later.

How AIM Development can help

I can help translate your organisation’s data protection requirements into practical software features, whether you are commissioning a new application or improving an established system.

That can involve reviewing data flows, refining permissions, improving record management and building tools that support your staff’s day-to-day responsibilities.

The organisation’s policies, contracts and working practices remain essential. Software needs to support those arrangements, and continue to do so as the business changes.

Discuss your project

This article provides general information about data protection and software design. Requirements depend on the processing involved. For current regulatory guidance, consult the Information Commissioner’s Office.