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

• Be able to prove you’re doing the right thing

I had originally written this document as a guide for CTOs as they must consider data protection as part and parcel of the technology infrastructure. Any technology used at a company should not be defined without considering things like UK GDPR and even though you may not want to attain ISO 27001, its standards are worth following. Having said this, this guide will provide the basics so that any company executive can follow to improve how they handle, store and protect data they use day-in day-out.

The four big influences on everything we do are:

• UK GDPR and the Data Protection Act 2018 – our legal backbone

• ISO 27001 – the gold standard for information security management

• NIST frameworks – thorough, practical, and widely respected

• Privacy by Design and by Default – the mindset that privacy should be baked in from the start, not bolted on at the end

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, we ask four straightforward questions. Answer these honestly and everything else falls into place.

Question	What we’re really asking
What?	What data do we actually have and how sensitive is it?
Where?	Where does it live and where does it travel?
Why?	Why are we allowed to have it in the first place?
How?	How are we keeping it safe?

If every team can answer these four questions for their own data, the organisation as a whole stays compliant and secure.

2.1. What - What data do we have?

This is where everything starts. You can’t protect something if you don’t know it exists. We need to understand:

• The types of information (names, addresses, health records, payment details, browsing habits, etc.)

• How sensitive each piece is

• Roughly how much we have

• Who “owns” it day-to-day

  
  

Regulators (especially the ICO) expect us to have this picture. It’s also the only way we can answer customer questions or spot something that shouldn’t be there at all.

You cannot protect what you do not know you have — and regulators will assume ignorance is negligence.

Framework alignment

• GDPR: Requires full knowledge of what is processed (Art. 5, Art. 30, Art. 35).

• ISO 27001: Treats data as assets requiring classification & controls (A.5–A.8).

• NIST: Demands asset and data categorisation to determine protection (ID.AM, RA-3).

• PbD: Begins with defining what data is collected and minimising it.
  

2.2. Where - Where is data stored and transmitted?

Data rarely sits still. It moves between laptops, cloud services, backup drives, suppliers, and sometimes across borders. Mapping the journey tells us:

• Which systems and companies touch the data

• Where the risky hand-offs happen

• Whether anything is going outside the UK or EEA (and whether we have the right paperwork for that)

Knowing where data resides allows you to enforce appropriate encryption, access control, network security, and vendor oversight.

Framework alignment

• GDPR: Strict requirements around transfers, processors, and data flows.

• ISO 27001: Maps “where” to physical, logical, supplier, and operational controls.

• NIST: Asset location, boundary controls, logging, and monitoring are core.

• PbD: Requires clarity on flows, architecture, and lifecycle protection.

  
  

2.3. Why - What is the lawful basis or business need?

This is the question most teams forget and the one regulators love to ask. For every piece of data we must be able to say:

• What specific purpose it serves

• Which lawful basis (or special-category condition) lets us use it

• Whether we could achieve the same goal with less or no personal data

• When we will delete it

If we can’t give a clear, current answer, the right thing to do is stop collecting it or delete it. Unnecessary data is pure risk with no reward.

Framework alignment

• GDPR: Purpose limitation is central (Art. 5, Art. 6, Art. 13).

• ISO 27001: Links purpose to business requirements, retention, and compliance.

• NIST: Requires documented justification for data collection and use.

• PbD: Enforces minimisation and purpose specification.

2.4. How - How is the data protected?

Once we’re confident about What, Where, and Why, the How becomes much easier to get right. Typical safeguards include:

• Encryption

• Strong access controls and multi-factor authentication

• Logging and monitoring so we spot anything unusual

• Regular testing and patching

• Clear incident-response plans

• Good contracts with any third parties who touch our data

• Training so everyone knows their part

This is the part that ISO 27001 and NIST describe in detail – and it’s the part the ICO will look at if something goes wrong.

Framework alignment

• NIST: Almost the entire framework is HOW to secure data (AC, SC, SI, IR, etc.).

• ISO 27001: Annex A controls define HOW to protect data.

• GDPR: Art. 24, 25, 32 require Technical & Organisational Measures (TOMs).

• PbD: HOW privacy and security are embedded by design and by default.

3. What about the GDPR?

We have mentioned the GDPR but how does what we've outlined align with it?. If we start at the core principles of the GDPR

• Lawfulness, fairness, and transparency: Personal data must be processed legally and fairly, and individuals must be kept informed about how their data is used.

• Purpose limitation: Data can only be collected for specific, explicit, and legitimate purposes.

• Data minimization: Only collect data that is adequate, relevant, and necessary for the purpose.

• Accuracy: Data must be kept accurate and up-to-date.

• Storage limitation: Data should only be kept for as long as is necessary.

• Integrity and confidentiality: Data must be stored securely and protected from loss or unauthorized access.

• Accountability: Organisations are responsible for demonstrating compliance with these principles. 

It is obvious that none of these core principles can start to be met without the core understanding of What, Where and Why. In addition to the principles within the GDPR, there are a set of rights that belong to the data subjects.

• The right to be informed about how their data is being used.

• The right of access.

• The right to rectification (correction).

• The right to erasure (to be forgotten).

• The right to restrict processing.

• The right to data portability.

• The right to object.

• The right not to be subject to solely automated decision-making. 

How these rights can be actioned is incredibly important. Article 5(2), the accountability principle, states:

“The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1.”

This means, if a data subject requests access, erasure, rectification, restriction, objection, etc, you must be able to prove what you did and when. A regulator will interpret not being able to show evidence as an indicator that the action was not taken and that you have not satisfied GDPR requirements.

In practice, fines for poor rights-handling usually range from £4.4k–£17.5m depending on the size of the organisation and severity.

4. Building a framework

The four questions give us the theory; now we need a handful of practical tools that everyone in the organisation can actually use day-to-day.

The sections below set out the core building blocks (classification, access rules, backups, the Data Inventory, and DPIAs) that together form a complete, low-friction data-protection framework most teams find straightforward and even helpful rather than bureaucratic.

4.1 Data Classification

All frameworks start with determining a core set of classification that define the data that is being stored. We use a simple six-level scheme that everyone can understand quickly:

Level	What it means in practice	Typical examples
Public	Safe to share with the world	Website, brochures, price lists
Internal	Okay inside the company, not outside	Org charts, internal wiki
Confidential	Would cause harm if leaked	Contracts, strategy documents
Personal Data	Relates to an identifiable person	Customer records, employee files
Special-Category Data	Extra-sensitive (health, political opinions, biometrics, etc.)	Medical notes, trade-union membership
Restricted	The absolute crown jewels	Source code, master encryption keys

On top of these levels we add “compartment tags” (HR-Only, Finance-Only, Legal-Privilege, etc.) so that even within the same sensitivity level, only the right people have access.

4.2 Data Security

Ultimate responsibility sits with the board, but day-to-day access is delegated sensibly:

• You can only give access to someone if you have it yourself

• Access must always match a genuine business need

• Compartment tags are respected automatically by our systems wherever possible. For example, HR data should only accessible to the HR team.

4.3 Backups

Backups are different. They often contain everything in one place, are rarely looked at, and are a favourite target for attackers. We therefore:

• Classify each backup according to the most sensitive data inside it

• Keep separate backup sets where it makes sense (so HR data isn’t mixed with marketing data)

• Use immutable secure storage for the most critical backups

• Delete data from backups when the retention period is up

One aspect of backups that is often missed and is a fundamental part of the GDPR. The right to erasure; this means that when a request comes in, all data associated with user must be removed. This may not be possible with some backups as they could be encrypted and immutable. Even then, it may be technologically feasible, but impractical to look into every backup (which may be daily), decrypt it, remove the data, re-encrypt. The ICO's guidance allows for this if you put the data 'beyond use' (e.g., via metadata flags) and explain it transparently in your response.

There are aspects of the GDPR that can account for this, but, you must be transparent to the data subjects that there are limitations. Specifically for backups, the ICO requires you to inform the individual about any limitations, ensuring they understand the implications for their privacy. This is normally handled by your response to the erasure request, it should be clear, concise, and in plain language, confirming what actions you've taken.

4.4 Data Inventory

This is the comprehensive list of all datasets we possess. Officially, it's referred to as the Record of Processing Activities (RoPA), but we simply call it the Data Inventory. The suggested fields below extend beyond those required by UK GDPR and the ICO; additionally, there are several practical fields that assist in maintaining an understanding of the data used by the organisation.

Field	Example / Notes
Unique Dataset ID	CUST-001, HR-EMP-003, MARKETING-LEADS-2024
Data owner (business)	Head of Customer Operations, HR Director
Data steward (technical)	CRM Administrator, HRIS Team
System(s) / application(s)	Salesforce, Workday, AWS S3 bucket “customer-uploads”
Primary storage location	UK, AWS eu-west-2; Frankfurt, Azure Germany; on-premise NAS in London DC
Backup location(s)	Veeam repository in Dublin; immutable S3 bucket in Ireland
Safeguards if storage is outside of UK	Contract + Data Addendum
Data collected	Name, Email, Address
Data subjects	Employees, customers, website visitors, children, job applicants
Sensitivity / classification	Confidential + Personal Data; Special-category (health)
Purpose	Communicating with employee; maintaining personnel records
Lawful basis	Necessary to perform employment contract
Sharing Status	Is the data shared with anyone?
Compartment tags / Security	HR-Only, Finance-Only, Legal-Privilege
Volume (approx. records)	100 employee records
Source of the data	Web forms, purchased list, in-store sign-up, recruited via agency
Automated decision-making / profiling?	Yes / No + details if Yes
DPIA required / completed?	Yes – DPIA v1.3 approved 2024-09-12
Last review date	2025-11-01
Next scheduled review	2026-11-01 or on change
Linked retention policy reference	RET-003 – Customer data: 7 years post-contract end

Practical implementation tips

• Keep it in a single master spreadsheet or a GRC tool that supports version control and access restrictions.

• Use one row per logical dataset or per processing activity. Do not try to list every database table.

• Link or embed the data-flow diagram for that dataset

• Review and re-certify with data owners at least annually or when any material change occurs (new vendor, new country, new category of data, etc.).

  
  

A complete, up-to-date data inventory turns data-protection compliance from a theoretical exercise into something you can demonstrate in minutes to the ICO, your auditors, or an angry customer.

4.5. Privacy Notice

A privacy policy is all about being transparent to the users and employees. The GDPR requires purpose-specific and audience-specific transparency, under Articles 13 and 14, privacy information must be:

• Clear

• Accessible

• Specific to the audience

• Specific to the purposes of processing

• Not overly generic

The ICO explicitly warns against “one-size-fits-all” privacy notices because different groups:

• Provide different types of data

• Have different risks

• Have different rights impacts

• Require different retention rules

• Face different consequences for misuse

• Have different lawful bases

The ICO provides a checklist on what to provide in a privacy notice. Looking back to our Data Inventory we can determine the following information

• Purpose

• Lawful Basis

• Location

• Retention Period

• Safeguards if storage is outside of UK

• Source of the data

• Automated decision-making

• Sharing Status

  
  

that is applicable to each Data Subject. This would form the backbone of the document by providing the following sections from the checklist.

• The purposes of the processing.

• The lawful basis for the processing.

• The legitimate interests for the processing.

• The categories of personal data obtained.

• The recipients or categories of recipients of the personal data.

• The details of transfers of the personal data to any third countries or international organisations (if applicable).

• The retention periods for the personal data.

• The source of the personal data (if the personal data is not obtained from the individual it relates to).

• The details of the existence of automated decision-making, including profiling (if applicable).

4.6. Data Protection Impact Assessments (DPIAs)

When done properly, a DPIA, is the single most effective risk-management tool in the entire data-protection programme. From the ICO

A DPIA is a process designed to help you systematically analyse, identify and minimise the data protection risks of a project or plan. It is a key part of your accountability obligations under the UK GDPR, and when done properly helps you assess and demonstrate how you comply with all of your data protection obligations.

You must carry out a DPIA before you begin any processing that is “likely to result in a high risk” to individuals.

A small company that maintains employee information solely for payment and basic HR monitoring does not need a DPIA. However, it's easy to exceed standard HR processes. For instance, if an employee submits an access-to-work request, you're handling health-related information, which is sensitive data. This necessitates extra checks and protections, which a DPIA can assist with. It's always safer to be cautious; conducting a DPIA is never a mistake, but failing to conduct one when needed can result in hefty fines.

4.6.1 One Living “Master DPIA”

For an organisation it is important to maintain one overarching DPIA that describes the baseline state of the entire organisation. Corporate DPIAs can take time to create but they are invaluable in defining a company's stance on how it is protecting data and what it considers are the main risks to that data and the mitigations in place.

4.6.2 Mini DPIA

This is a simple yes/no screening checklist and it will indicate whether a more detailed DPIA is required for a project. It forces discipline and creates an audit trail for why a particular project required or did not require a DPIA. It still allows us to track accountability but doesn’t kill velocity.

4.6.3 Supplemental DPIA

A supplemental DPIA is created if it has been identified, via the Mini DPIA, that the project involved many changes and could impact the master DPIA. Once the supplement has been approved and the project is complete, the information in the DPIA should be formally merged in to the master DPIA and version-controlled.

There must be pre-agreed rules on who can sign off a DPIA. If the project results in a risks that have a low or medium residual then they can be signed off by the project owner or DPO. If the project has high residual risks (risks with no mitigations) then this would require CEO or board approvals.

Consider adding additional criteria that help ensure that the project has addressed key considerations that are important to the business. A common set of criteria are the 7 foundation principles of Privacy By Design.

There should be a post implementation review 6 months after a project has gone live. Many risks only become visible once the changes have gone live.

4.7. Data Subject Rights – Turning Rights into Routines

GDPR gives people strong control over their data, but from a technical point of view, the real work is making rights requests (like access or deletion) fast and frictionless. There is a 1 month deadline which can be extended (although you might need to contact the ICO to confirm this). However, best practice is to start as soon as the request has been received.

With any request it is important to read what is being requested as some requests can be overly broad and may result in false positives that will need to be reviewed, which takes additional time.

A typical process would be:

Step	Action	Owner	Timeline
1. Receive & Log	Route via a central email/ticket; verify ID without over-collecting.	DPO/Legal	Day 1
2. Locate Data	Query the Data Inventory for all "Where?" locations.	Tech Steward	Days 1–3
3a. Extract & Review	Pull pseudonymised copies; flag any exemptions (e.g., legal holds).	Data Owner	Days 3–5
3b. Rectification	Adjust data so that it is accurate.	Data Owner	Days 3–5
3c. Delete	Remove data associated with the subject	Data Owner	Days 3-5
4. Respond Securely	Send via encrypted portal; include a summary of what was found/deleted.	DPO	Day 30 max
5. Log & Learn	Update Inventory with the request; review for process improvements quarterly.	All	Ongoing

This process needs to be tested end-to-end at least once a year. If the amount of requests start to spike then there are options to automate.

Logging of these requests is vitally important as these changes must be applied to any data that is recovered from backup.

Not complying with these requests within the 1 month deadline can lead to significant fines.

4.8 Breach Response – Because Things Sometimes Go Wrong

The framework above is not meant to provide a basis for managing breaches and incidents; that requires its own discussion and framework. However, a data protection framework is invaluable in quickly understanding the impact of a breach and what type of data that has been put at risk. This information can be obtained from the Data Inventory. Following on from this, the corporate DPIA will hold information as to whether there was risks identified with this dataset and what mitigations were employed.

This is information that is vital when drafting an ICO report. It does not have to be perfect but it is best to be honest and transparent. The ICO will need to be informed within 72 hrs of being the organisation being made aware of the breach. Remember, 90% of ICO fines stem from a poor and slow response, not the breach itself.

4.9 Vendor Management – Your Data Doesn't Stop at the Firewall

Vender/Supply chain compromise is now considered the second most prevalent attack vector after phishing and human error. Every vendor touching data needs an Article 28 DPA (Data Processing Agreement) that mirrors the standards set out above.

A core part of any onboarding of a new vendor must consider the following.

Check	What to Ask/Do
Security Posture	SOC 2 report or ISO 27001 cert? Aligns with your framework?
Location & Transfers	Where's data stored? UK adequacy or safeguards (e.g., IDTA for non-UK)?
Rights & Breaches	How do they handle DSARs? 24-hour breach alert to you?
Audit Rights	Annual access for your team?
Exit Strategy	Data return/deletion on contract end?

The best way to handle vendors is to control and understand what data they have access to. This information can be maintained in the Vendor Inventory.

Field	Example / Notes
Vendor Name	IT Supplied
Vender Lead (business)	Head of Customer Operations, HR Director
Vendor Contact/DPO	joe@it-supplier.com
Data Inventory References	CUST-001, HR-EMP-003

If a notification of a breach is received, the data that might be impacted can easily be identified and standard breach procedures followed.

5. Data Stored outside of the UK

For a UK based company it is more than likely that your data will be stored in the UK or EU (for the most part, due to adequacy decisions, UK and EU data protection are considered to be adequate to each other). With the proliferation of 3rd party providers it is important to understand where they store their data. This information will be provided in their privacy policy. If they store the data outside of the UK then it is your responsibility to ensure that the data is protected.

Most US companies will provide a Data Processing Addendum to confirm that the data is protected and some will operate under the EU-US Data Privacy Framework (DPF). However, as UK is not longer in the EU there is a way in which UK organisation can benefit from the DPF.

5.1. What is the Data Privacy Framework (DPF)

The DPF is a legal framework that lets organisations in the EU transfer personal data to U.S. companies. U.S. companies can self-certify to the DPF without needing bespoke contracts or extra transfer safeguards.

5.2. Where does the UK stand

Having left the EU, the UK is not automatically covered by the EU-US DPF under the EU’s adequacy decision. Therefore, transfers from the UK to US can’t simply rely on the EU-US DPF unless an additional step is taken.

In 2023, The UK-US Data Bridge (or "UK Extensions to the DPF) was created. Under the UK GDPR the government adopted new adequacy regulations to allow a "data bridge" from the UK to the US via the DPF. However, this is only applicable to companies that have opted into the UK Data Bridge without needing extra safeguards.

However, some categories of data remain sensitive or restricted under DPF/UK-GDPR (e.g. certain special-category data, criminal-offence data) and additional caution or safeguards may still be required.

6. Summary

Data protection only feels complicated until you strip it back to four simple 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 one living Data Inventory, one living Master DPIA, a clear classification scheme, and a handful of common-sense playbooks (rights requests, breaches, vendors, backups), and you will be more compliant, more secure, and calmer than 95 % of organisations out there. All done without drowning in paperwork.

Everything else (GDPR articles, ISO controls, NIST catalogues) is just detail hanging off those four questions. So next time someone asks “Are we okay on data protection?” you can smile and say:

“Yes—because we know exactly What, Where, Why, and How… and we can prove it in minutes.”. That’s not just compliance. That’s confidence.

And that’s the point.

7. Final Thoughts

All companies must have some form of data protection governance when it comes to personal data. A quick check list

• Do you process any personal data about UK individuals (including names, emails, IP addresses, cookie IDs, employee data)

• Do UK users interact with your service(even if just by visiting your website)

• Do you hold UK customer or leads

• Do you have UK employees or contractors

• Do you store personal data using cloud providers (storing an employee list in Sharepoint)

• Do you use analytics tools for your website such as Google Analytic.

There is no small-business exemption, even for micro-companies or sole traders. Having said this, small companies have lighter record-keeping requirements and reduced DPIA obligations but there still needs to be some form of understanding about how data should be protected. What I have outlined here is a structure that works but more importantly keeps things simple and straightforward for small and larger companies.