Data Protection

1. Introduction

Data protection does not have to be scary or overwhelming. At its heart it is about treating people's information with the same care we would want for our own. The law, standards, and good practice all circle around the same common-sense ideas: know what you have, only keep what you truly need, look after it properly, and be able to prove you are doing the right thing.

This guide was originally written for CTOs, because data protection has to be considered as part of the technology infrastructure. Any technology used by a company should be defined with UK GDPR, ISO 27001-style controls, NIST thinking, and privacy by design in mind.

The four big influences on everything we do are:

• UK GDPR and the Data Protection Act 2018, which provide the legal backbone.
• ISO 27001, the practical standard for information security management.
• NIST frameworks, which are thorough, practical, and widely respected.
• Privacy by Design and by Default, where privacy is built in from the start.

All four say the same thing in different languages. This guide translates them into plain English and gives you a simple, repeatable way of working.

2. Summary of data protection

Instead of drowning in articles, controls, and acronyms, start with four straightforward questions. Answer these honestly and everything else becomes easier to reason about.

2.1 What data do we have?

You cannot protect something if you do not know it exists. Teams need to understand the types of information they hold, how sensitive each piece is, roughly how much exists, and who owns it day to day. Regulators expect this picture, and it is the only way to answer customer questions or spot information that should not be there at all.

Framework alignment is straightforward: GDPR requires full knowledge of what is processed, ISO 27001 treats data as assets requiring classification and controls, NIST starts with asset and data categorisation, and Privacy by Design begins by defining and minimising what is collected.

2.2 Where is data stored and transmitted?

Data moves between laptops, cloud services, backup drives, suppliers, and sometimes across borders. Mapping that journey shows which systems and companies touch the data, where the risky hand-offs happen, and whether anything is leaving the UK or EEA.

Knowing where data resides lets you enforce encryption, access control, network security, logging, monitoring, and vendor oversight in the right places. It also reveals transfer risks before they become contractual or regulatory problems.

2.3 Why do we have it?

For every piece of data, the organisation should be able to say what specific purpose it serves, which lawful basis permits its use, whether the same goal could be achieved with less personal data, and when it will be deleted. Unnecessary data is risk with no reward.

Purpose limitation, retention, minimisation, and business justification all sit here. If a team cannot explain why the data exists, it should stop collecting it or delete it.

2.4 How is it protected?

Once What, Where, and Why are clear, How becomes more practical. Typical safeguards include encryption, strong access control, multi-factor authentication, logging and monitoring, testing and patching, incident response plans, supplier contracts, and staff training.

This is where ISO 27001 and NIST become most operational. GDPR also expects appropriate technical and organisational measures, and Privacy by Design expects those measures to be embedded into systems by default.

3. What about GDPR?

GDPR principles such as lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity, confidentiality, and accountability cannot be met properly without understanding What, Where, and Why. The same applies to rights such as access, rectification, erasure, restriction, portability, objection, and protection from solely automated decision-making.

Accountability matters because the controller must be able to demonstrate compliance. If a data subject requests access, erasure, rectification, restriction, or objection, you must be able to prove what was done and when.

Poor rights handling can become expensive quickly, but the more practical issue is trust. If you cannot locate, correct, export, or delete data reliably, you do not really understand the system that holds it.

4. Building a framework

4.1 Data classification

Compartment tags such as HR-Only, Finance-Only, and Legal-Privilege can then restrict access further even within the same sensitivity level.

4.2 Data security

Ultimate responsibility sits with the board, but day-to-day access should be delegated sensibly. Access must match a genuine business need, and the systems should respect compartment tags wherever possible.

4.3 Backups

Backups need special attention because they often contain everything in one place, are rarely inspected, and are a favourite target for attackers. Classify each backup according to the most sensitive data inside it, separate backup sets where sensible, use immutable secure storage for critical backups, and be transparent about erasure limitations.

The right to erasure is often missed when backups are discussed. Encrypted and immutable backups may make deletion technically possible but operationally impractical. Where data is put beyond use rather than removed immediately, the limitation needs to be transparent in the response to the individual.

4.4 Data inventory

The data inventory, or Record of Processing Activities, should be a living register of the datasets and processing activities the organisation relies on.

Keep the inventory in a single controlled place, use one row per logical dataset or processing activity, link the data-flow diagram, and review it at least annually or whenever there is a material change.

4.5 Privacy notice

Privacy notices should be clear, accessible, specific to the audience, specific to the purposes of processing, and not overly generic. Different groups provide different data, face different risks, have different rights impacts, and rely on different lawful bases.

The data inventory gives you the backbone of the privacy notice: purpose, lawful basis, location, retention period, transfer safeguards, source of data, automated decision-making, and sharing status.

4.6 Data Protection Impact Assessments

A DPIA is the strongest risk-management tool in the programme when it is used properly. It should be completed before processing that is likely to result in high risk, and it should be treated as part of accountability rather than paperwork.

A practical model uses one living master DPIA for the organisation, a mini DPIA checklist to screen new work, and supplemental DPIAs for material changes. Once the change is complete, the supplement should be merged back into the master DPIA and version controlled.

Sign-off rules should be clear. Low or medium residual risks can usually be accepted by the project owner or DPO. High residual risks need CEO or board approval, and a post-implementation review should happen once the system has been live long enough for hidden risks to surface.

4.7 Data subject rights

This process should be tested end to end at least once a year. Logging is vital because changes may need to be applied again if data is recovered from backup.

4.8 Breach response

Breach and incident management needs its own framework, but the data protection framework gives you a fast way to understand what data is at risk. The data inventory identifies the impacted dataset, and the DPIA shows known risks and mitigations.

This information is vital when drafting an ICO report. The ICO needs to be informed within 72 hours of the organisation becoming aware of a reportable breach, and it is usually better to be honest and transparent than to wait for perfect information.

4.9 Vendor management

Your data does not stop at the firewall. Every vendor touching personal data needs appropriate contractual controls, security due diligence, transfer checks, rights handling, breach notification expectations, audit rights, and an exit strategy.

A vendor inventory should record the vendor name, business owner, vendor contact or DPO, linked data inventory references, and the data they can access.

5. Data stored outside the UK

UK companies must understand where third-party providers store personal data. If data is stored outside the UK, the organisation remains responsible for ensuring appropriate protections are in place. US providers may rely on Data Processing Addenda, the EU-US Data Privacy Framework, or the UK Extension where applicable, but sensitive and restricted categories still require additional caution.

5.1 What is the Data Privacy Framework?

The Data Privacy Framework allows organisations in the EU to transfer personal data to US companies that self-certify to the framework, without needing bespoke contracts or extra transfer safeguards.

5.2 Where does the UK stand?

The UK is not automatically covered by the EU-US framework. The UK-US Data Bridge, created in 2023, allows a data bridge from the UK to the US through the framework where the recipient has opted into the UK extension. Some categories of data still need extra caution.

6. Summary

Data protection only feels complicated until you strip it back to four questions: What do we have? Where is it? Why are we allowed to have it? How are we keeping it safe? Answer those honestly and keep the answers in a living data inventory, master DPIA, classification scheme, and common-sense playbooks.

7. Final thoughts

• Do you process any personal data about UK individuals, including names, emails, IP addresses, cookie IDs, employee data, customer data, or lead data?
• Do UK users interact with your service, even if they only visit your website?
• Do you hold UK customers or leads?
• Do you have UK employees or contractors?
• Do you store personal data using cloud providers, including tools such as SharePoint?
• Do you use website analytics tools such as Google Analytics?

There is no small-business exemption, even for micro-companies or sole traders. Smaller organisations may have lighter record-keeping duties, but they still need a practical understanding of how data should be protected.