Why Data Processing Agreements with suppliers matter

February 2025

Controller to processor contractual terms

Supply-chain data breaches have become all too common. If one of your suppliers (service providers) suffers a breach or other privacy violation, the data protection clauses in contractual terms could suddenly become very important.

GDPR (and it’s UK GDPR spin-off) sets out strict contractual requirements for when an organisation utilises the services of another organisation which will handle personal data on its behalf – including technology providers. These contractual terms are designed to protect all parties; the individuals whose data is processed, the (controller) organisation and their supplier (processor).

Establishing the relationship

First, it’s important to clearly establish what the relationship is between your organisation and the third party. Are both parties are acting as separate or joint controllers? Or is the supplier acting as your processor?

This is not always easy to determine. The lines can become blurred when a third party in some situations is acting as a processor, but at other times as a controller – either using the data for their own purposes, or for jointly shared purposes (i.e. joint controllers). Controller or processor; what are we? 

Who’s accountable?

Prior to the GDPR being implemented in 2018, accountability rested almost entirely with the controller, who was liable if things went wrong. Post GDPR, the controller and processor could both or solely be held accountable, and liable for compensating any damages, either material or non-material, suffered by individuals.

What obligations does each party have?

While the majority of data protection compliance obligations rest with controllers, processors also have their own accountabilities. These include, but are not limited to, being accountable for any sub-contractors (aka ‘sub processors’) they appoint which process the controller data, any international data transfers and keeping adequate records of their processing activities.

Processors are also required to assist the controller with their obligations. For example, in the event of a data breach, handling privacy rights requests and conducting Data Protection Impact Assessments.

What Controller-Processor contracts need to cover

The requirements an organisation needs to meet when utilising the services of processors are set out in Article 28, GDPR. This applies when suppliers are:

■ processing personal data on behalf of the organisation (e.g. processing the organisation’s employee records, customer data or another category of personal data;
■ acting solely under the instructions of your organisation; and
■ NOT using the personal data for their own business purposes.

Data protection legislation makes it very clear this arrangement must be covered by a binding agreement and there are specific provisions which must be included.

The specific data protection provisions are often set out separately to other provisions, in a Data Processing Agreement (DPA) or Addendum. Alternatively, they may be included within the main agreement. So if there’s no adequate data protection section in the main agreement, look for a DPA or Addendum! These should include the following aspects.

1. Technical and Organisational Measures (TOMs)

A processor needs to provide sufficient guarantees to implement appropriate technical and organisational measures to meet the requirements of GDPR and ensure the protection of individuals’ rights. Good practice would be to include a summary of key information security measures within the contractual terms.

It’s advisable as part of the due diligence process, prior to entering into a contract, to conduct data protection and information security assessments, where relevant, to gain suitable oversight and assurances from suppliers that personal data will be properly protected. In practice its unlikely to be feasible to carry out such due diligence on all suppliers, so you may wish to focus efforts on those which handle sensitive data or types of processing which involve higher levels of risk.

2. Appointment of sub-processors

A processor must not engage other processors (often referred to as ‘sub-processors’) to conduct processing of the controller’s personal data without the authorisation of the controller. The processor also needs to inform the controller of any intended material changes concerning additional/replacement sub processors. The controller must be given the opportunity to object to such changes.

A contract should therefore provide details of any sub-processors which will be used to handle the controller’s data. Updates should be provided when this list changes. In our experience, well-established suppliers will often just provide a link to view their sub-processors and may put the onus on the organisation their contracting with to check for updates. Something to watch out for.

Processors need to be aware they are accountable for the actions of their sub-processors. It is specifically stated that the same obligations as set out in the contract between the controller and processor shall be imposed on another (sub) processor by way of contract or other legal act.

Where a sub-processor fails to fulfil its data protection obligations, the processor up the chain may become accountable and liable to the controller for the performance of the sub-processor’s obligations. Processors are therefore responsible to conducting due diligence of any sub-processors they use.

This point really illustrates how important it is to clearly establish controller > processor > sub-processor supply chains and make sure the nature of the relationship between parties is clear in contractual terms.

3. Further contractual requirements

A contract (or other legal act) between a controller and processor must set out the following:

■ Types of personal data the processor will be processing on behalf of the controller (e.g. name, email address, telephone number, bank account number, date of birth – including any special category data)
■ Categories of data subject (e.g. employees, patients, customers, students, minors)
■ Nature and purpose of processing activities
■ Duration of processing (i.e. the term of the contract)

Terms must also include:

a) Rights and duties of each party, e.g. the processors commitment not to use the controller’s personal data for any other purpose than for providing the agreed service(s).

b) Instructions from the controller – The agreement should include details of what the processor is permitted to do with the personal data it is provided. In practice, this may often be set out by the supplier (processor) and often may be provided separately to the main agreement – particularly if there are multiple workstreams or project-based activities. But the controller should check and agree that these accurately represent their instructions, so the scope of data processing is clear.

c) International data transfers – If relevant, the agreement should include details and provisions for any transfer of personal data to a third country, whether this be to the processor itself or any sub-processors used. International Data Transfers Guide.

d) Duty of confidentiality – There must be a confidentiality clause which commits the processor to ensuring the people authorised to access the controller’s personal data have committed themselves to a duty of confidentiality or are under a statutory obligation of confidentiality.

e) Data subject’s rights – The processor must commit to assist the controller, where applicable, with the fulfilment of data subject’s rights, such as Subject Access Requests, the right to erasure, the right to object to processing, etc.

f) Assistance with controller’s compliance – the agreement should set out that, as and when required, the processor will assist the controller with:

■ Security of processing
■ Conducting Data Protection Impact Assessments (DPIA), should this be required
■ Prompt notification of any personal data breaches affecting controller data. Often the terms will stipulate the processor must inform the controller about any data breach affecting the controller’s personal data ‘without undue delay’ or will have a specific timeframe, for example, within 24/48 hours. This could become vital so that the controller can meet its reporting deadline of 72 hours.

g) Return or destruction of the data – the agreement should stipulate what happens to the controller’s personal data at the end of the contract term. The law states that, at the choice of the controller, all personal data must be returned or destroyed.

h) Audits and inspections – the agreement should set out that the processor agrees to make available all information necessary to demonstrate compliance with Article 28 and will allow for, and contribute towards audits, including inspections, by the controller or an authorised auditor.

What might be the consequences of getting contracts wrong?

It’s crucial contracts relating to data processing include all the appropriate terms to make sure that individuals are properly protected, and also to make sure the accountabilities and liabilities of each party are clearly agreed should a data breach or other violation of data protection law occur. As GDPR states:

‘Any person who has suffered material or non-material damage as a result of an infringement of this Regulation shall have the right to receive compensation from the controller or processor for the damage suffered.

Any controller involved in processing shall be liable for the damage caused by processing which infringes this Regulation. A processor shall be liable for the damage caused by processing only where it has not complied with obligations of this Regulation specifically directed to processors or where it has acted outside or contrary to lawful instructions of the controller.’ (Article 82)

What can we do when contractual terms are non-negotiable?

Size matters! Established suppliers such as big tech providers will often have their own standard Data Processing Agreements and offer little or no room for negotiation. It’s sometimes a case of ‘take it or leave it’. In this situation, organisations will need to take a balanced approach, weighing up the necessity of utilising the services with the contractual terms provided, and decide whether these are sufficient.
Conversely, big established controllers will often be in a position to dictate their terms to smaller suppliers.

However, it really is wise to check Data Processing Agreements, or data protection clauses within a main contract. It’s worth clicking on the link to check the sub-processors a supplier uses. All of this will inform your decisions. If you don’t check, you may be unaware of some underlying risks.

After a successful career in publishing Simon moved into data protection consultancy in 2015. Simon advises businesses of all sizes across a wide range of sectors. He held the role of Director of Information Governance at Royal Mail Group in the run up to GDPR enforcement. He regularly delivers data protection courses for clients and the Institute of Data & Marketing (IDM).

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

Training your people in data protection: where to begin?

February 2025

In most organisations, your people are your greatest asset. However, from a compliance perspective, without proper training, knowledge and understanding, employees might make mistakes with potentially serious consequences. They could miss key legal requirements – whether this be compliance with Health & Safety, Employment, Data Protection or any other relevant laws.

Organisations need to give people relevant training and guidance, but when it comes to data protection, establishing the most effective approach can be tricky.

Legal requirements

There’s a requirement under GDPR for organisations to ‘implement appropriate technical and organisational measures’. The ‘organisational measures’ part is where employee awareness and training comes in, but the law doesn’t say how organisations should do this. Alongside this, organisations are required to meet GDPR accountability requirements.

Regulatory expectations

The UK’s Information Commissioner’s Office’s Accountability Framework provides helpful pointers on what a ‘good’ data protection training and awareness programme would look like. To summarise, the following are key components:

■ Appropriate training in data protection and information security for all employees
■ Refresher training on a regular basis
■ Data protection and information security in induction programme for new starters
■ More specialist training for specific employees where relevant.
■ Ongoing exercises to keep raising awareness

One size doesn’t fit all

Each organisation needs to work out its own approach. Some organisations (and indeed some teams within organisations) will handle much more sensitive data than others. Some employees may have very limited contact with personal data in their roles. While some may need to know how to conduct a Data Protection Impact Assessment, others may need to understand the nuances of fulfilling Data Subject Access Requests. Some teams may need to understand more about supplier due diligence, controller to processor contracts and the rules for international data transfers, and so on.

How the core data protection principles and lawful bases are applied in practice will vary enormously for different business functions – from Marketing to Operations, from HR to a Contact Centre.

For example, marketers usually need to understand more about consent and legitimate interests, the right to opt-out, what the law says about profiling, and so on. They also need to be very familiar with marketing rules under different legislation, such as PECR.

Whereas HR teams need to understand how data protection laws apply to recruitment and the many different tasks which take place for employment purposes; such as appraisals and development, health, sickness and absence data, diversity, employee communications, payroll… and so on.

What does good training look like?

‘All’ staff training

Often, to cover baseline training for all employees, organisations will look to use an outsourced providers’ data protection training module(s). Alternatively, they may customise an external solution or develop their own training content internally.

In my experience, the quality of outsourced training modules can vary enormously, so it pays to do your homework and find an effective solution which suits your organisation well.

Just be mindful; outsourced generic online training which is not customised is unlikely to be enough on its own. For example, it won’t tell your people how to internally report a suspected data breach, or who to forward privacy rights requests to. It won’t cover your own internal standards or policies. Additional internal materials will be needed – be these policies, procedures, guides, factsheets, short videos and so on.

It’s worth repeating; the law doesn’t tell us how we embed necessary knowledge and understanding. If you have certain roles where people’s handling of personal data is very limited, you may decide making them sit through an online training module really isn’t necessary. You could choose different methods to instil simple, relevant and important ‘dos and don’ts’.

More specialist training

Training is likely to be most effective if it’s bespoke or tailored to the needs of specific functions or teams and provides useful examples, such as user-journeys or case studies. Aligned to the different data protection requirements people need to consider for their own role.

However, this could become time consuming and costly, so a balance needs to be struck between the benefits and time. It can help to think about where the biggest risks lie in your business, so you can focus your efforts on the key teams which have greater exposure to, and influence, over data risk.

Does training need to focus on the Sales & Marketing team, the HR team, customer-facing teams, development team, anyone else?

Data Subject Access Requests (DSARs) and other data rights are usually handled by nominated people, who are highly likely to need more specialist knowledge in how to handle them. But if your organisation has never had any privacy rights requests, this is unlikely to be a priority area.

Organisational culture

Ideally you’d want training to align with your organisation’s culture. Training doesn’t have to be provided in a specific format and there’s nothing to say you can’t be creative. Some organisations use gamification, bite-sized videos, ‘win a prize’ quizzes and so on. Try and include humour if you can; a joke just might make a key message hit home.

To sum up, making sure people have the right skills and knowledge for your business is one of the best ways to reduce the chance of data protection risks being overlooked. Prevention is usually better than cure!

As a data protection consultant since 2015, Philippa advises and supports a broad range of clients, and delivers data protection training. She also regularly writes GDPR guides to support data protection teams in their day-to-day work.

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

Data Breaches: Assessing the level of risk

February 2025

The alarm goes off inside your organisation; you’re certain, or have a reasonable degree of certainty, a personal data breach has occurred. You’ve either contained the breach, or are in the process of doing so. You’ve established all the facts or are still gathering them.

Great stuff. You’re starting to manage the risk. Alongside this, there are two pressing issues to address under GDPR (and UK GDPR):

1. Do you need to report the breach to a Data Protection Authority?
(e.g. the UK’s Information Commissioner’s Office – ICO).
Reporting is required within 72-hours of becoming aware of a breach, and must be done unless the breach is unlikely to represent a ‘risk’

2. Do you need to notify affected individuals?
This is required without undue delay if the breach represents a ‘high risk’.
Data Protection Authorities don’t need to hear about every incident where there’s minimal risk to individuals. In fact, the ICO made it clear after GDPR was implemented they saw a degree of over-reporting. There’s a balance to be struck; you don’t want to fail to report a data breach when you should have.

Each incident needs to be considered on a case-by-case basis, taking account of all relevant factors. No two incidents are likely to be the same (unless you failed to address something crucial the first time around!).

The key is balancing the severity of the potential impact on those affected with the likelihood of this occurring. For example, the impact could be quite severe, but highly unlikely to materialise, or conversely the impact could be relatively low, but highly likely.

What do data breach harms look like?

There could be a number of negative consequences for people affected, so you need to consider the harms and/or damage the breach might cause.

For example, it could result in any of the following: financial loss, identity theft, fraud, emotional distress, loss of confidentiality, discrimination, humiliation and reputational damage. Other harms could include material or physical damage, loss of control of personal data, social disadvantage or limitation of rights.

How to assess the potential harm from a data breach

In assessing the types of harm the breach may result in it can be useful to answer the following types of assessment questions:

■ Can individuals be identified easily?
■ Are people at increased risk of identity theft or fraud?
■ Could people suffer financially?
■ Could people’s reputation be damaged?
■ Is there a breach of confidentiality?
■ Are people at risks of physical harm?
■ Does the breach involve information relating to children or vulnerable adults?
■ Does the combination of data involved pose more of a risk?

The above is by no means an exhaustive list. The importance of certain questions will vary, depending on the nature of the incident, the personal data and individuals affected and indeed the nature of your organisation.

It’s good practice to use a risk matrix, with a scoring system of likelihood against severity, so you can evaluate the severity and likelihood of harm identified. This helps answer the key questions of a) should we report to a Data Protection Authority? and b) should we notify affected individuals? Not only does a scoring system provide internal reassurance a clear methodology is being used it’s also useful evidence of your assessment should it ever be required.

The European Commission Guidelines on Notification of a Personal Data Breach (in section IV) provide helpful pointers on how to assess risk and high risk.

If your breach involves special category data or financial details, the risks may be more obvious and the decision to report the breach may be more-clear cut.

Assessments may need to be fluid, including regular ‘check-ins’ with colleagues as your understanding of the situation evolves and answers to your questions become known.

While your response to a data breach needs to be swift and effective, often you won’t know all the facts and are unable fully evaluate the risk posed within 72-hours. The first report to a Data Protection Authority can be just an initial report. This can then be followed up with more information as it becomes available. In some cases the risk rating of a breach might be downgraded or upgraded.

The key to success is having a robust data incident procedure, to help your data incident response team manage what can be multiple moving parts as effectively as possible. A procedure which includes a clear method of assessing the risk. Like many ‘emergencies’ in life, from a punctured tyre to a cut finger, being well prepared will prove invaluable.

As a data protection consultant since 2015, Philippa advises and supports a broad range of clients, and delivers data protection training. She also regularly writes GDPR guides to support data protection teams in their day-to-day work.

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

AI: Risk and Regulation

February 2025

Artificial Intelligence is an epoch-defining opportunity. The biggest game-changer since the Internet. Governments, businesses and other organisations fear losing out, unless they embrace innovation and change. Yet the benefits of AI carry with them ethical challenges. There’s the risk of considerable harms to individuals, wider society and the environment. Organisations also have to navigate risks; reputational, commercial and regulatory.

To regulate, or not to regulate AI?

The AI regulatory landscape’s far from settled – in fact, it’s a new frontier. On the one hand, the first phase of the EU AI Act comes into effect – the world’s first comprehensive AI regulation. On the other, President Trump has ‘ripped up’ Joe Biden’s AI Executive Order of 2023. The new US administration wants to remove barriers it claims stifle innovation. All previous policies, directives, regulations and orders in relation to AI are under review. The focus is on making sure America is a global leader in AI technology.

In the UK, an EU-style regulation looks unlikely. For the time-being a ‘principles-based framework’ is supported for sector specific regulators to interpret and apply. Specific legislation for those developing the most powerful AI models looks the most likely direction of travel.

John Edwards, the UK Information Commissioner penned a letter to the Prime Minister (in response to a request from Government to key regulators, to set out how they’ll support economic growth) in which he says; “regulatory uncertainty risks being a barrier to businesses investing and adopting transformative technology”. The Commissioner says his office will “develop rules for those developing and using AI products, to make it easier to innovate and invest responsibly”. Interestingly, the Commissioner supports the idea of a statutory Code of Practice for AI, saying this would give regulatory certainty to businesses wanting to invest in AI in the UK.

AI regulation has supporters and critics in equal measure. The EU’s strict approach has led to fears Europe will languish behind the rest of the world. Others argue it’s crucial to enforce an ethical and responsible approach to AI – in the absence of regulation, the argument goes, AI could be more malevolent than benign.

The divisions were crystal clear at a high-level AI Summit in Paris on 11 February, as the US and UK refused to sign President Macron’s declaration calling for open and ethical AI.

The potential is there for the UK to find a sweet spot, positioning its approach between its cautious European neighbours on one side and the ‘Wild West’ on the other?

EU AI ACT – first phase now applicable

The AI Act was implemented in August 2024, and is coming into effect in stages. On 2nd February rules in relation to AI literacy requirements, definition of an AI system and a limited number of prohibited AI use cases, which the EU determines pose an unacceptable risk, came into effect.

Like GDPR, the AI Act has extra-territorial scope, meaning it applies to organisations based outside the EU, where they place AI products on the market or put them into service in the EU, and/or where outputs produced by AI applications are used by people within the EU. We’ve already seen how EU regulation has led to organisations like Meta and Google excluding the EU from use of its new AI products.

In brief the prohibited uses under the AI Act are:

■ Facial recognition – the use of AI systems which create or expand facial recognition databased through the untargeted scraping of images from the internet or CCTV footage. Social scoring – AI systems which evaluate and score people on their behaviour or characteristics, where this might lead to detrimental or unfavourable treatment in an unrelated context. Or where it could lead to detrimental or unfavourable treatment which is unjustified or disproportionate.

■ Predictive criminal risk assessments based on profiling.

■ Subliminal manipulation or other deceptive techniques which distort people’s behaviour and cause them to take decisions they wouldn’t have otherwise taken which are likely to cause significant harm.

■ Exploitation of vulnerabilities – such as someone’s age, disability or social/economic disadvantage.

■ Inferring emotions in the workplace or educational setting.

■ Biometric categorisation which infers special category data.

■ Real-time remote biometric identification for law enforcement purposes.

The European Commission has published guidelines alongside these prohibited practices coming into effect. Guidelines on Prohibited Practices & Guidelines on Definition of AI System

EU AI Act – what comes next?

The rules are complex and organisations which fall within the scope of the AI Act will need to comply with tiered requirements dependent on risk, which at a very top level involves;

■ For AI systems classified as high-risk there will be core requirements, such as mandatory Fundamental Rights Impact Assessments (FRIA), registration on a public EU database, data governance and transparency requirements, human oversight and more.
■ General-purpose AI (GPAI) systems, and the GPAI models they are based on, will be required to adhere to transparency requirements, including technical documentation, compliance with EU copyright law and detailed summaries about content used for training AI systems.
■ For Generative AI applications, people will have to be informed when they are interacting with AI, for example a Chatbot.

It’s worth bearing in mind an AI system could, for example, be both high-risk and GPAI.

Managing AI use

While compliance will be a key factor for many organisations, protecting the organisation’s reputation may be an even bigger concern. So, how do we ensure AI is used in an efficient, ethical and responsible way?

Organisations already utilising AI are likely to have embedded robust governance, enabling smart investment and innovation to take place within a clear framework to mitigate potential pitfalls. For others, here are some points to consider:

■ Senior leadership oversight
Establish your organisation’s approach to AI; your strategy and risk-appetite.

■ Key stakeholders
Identify key individuals and/or departments likely to play a role in governing how AI is developed, customised and/or used.

■ Roles and responsibilities
Determine who is responsible and accountable for each AI system.

■ Knowledge of AI use
Understand and record what AI systems are already in use across the business, and why.

■ Policies and procedures
Develop appropriate policies and procedures, or update existing policies so people understand internal standards and relevant regulatory requirements.

■ Training, awareness and AI literacy
Provide appropriate training, consider if this should be role specific. Remember, already in effect under the EU ACT is a requirement for providers and developers of AI systems to make sure their staff have sufficient levels of AI literacy)

■ Risk assessments
Develop a clear process for assessing and mitigating potentials AI risks. While a Data Protection Impact Assessment (DPIA) may be required, this is unlikely to be sufficient on its own.

■ Supplier management
Embed appropriate due diligence processes when looking to adopt (and indeed customise) third-party AI SAAS solutions.

AI security risks

Appropriate security measures are of critical importance. Vulnerabilities in AI models can be exploited, input data can be manipulated, malicious attacks can target training datasets, unauthorised parties may access sensitive, personal and/or confidential data. Data can be leaked via third party AI solutions. We also need to be mindful of how online criminals exploit AI to create ever more sophisticated and advance malware, for example, to automate phishing attacks. On this point, the UK Government has recently published a voluntary AI cyber security code of practice.

AI is here. It’s genuinely transformative and far-reaching; organisations unable or unwilling to embrace change – and properly manage the risks – will be left behind. To take the fullest advantage of AI’s possibilities, agile and effective governance is key.

As a data protection consultant since 2015, Philippa advises and supports a broad range of clients, and delivers data protection training. She also regularly writes GDPR guides to support data protection teams in their day-to-day work.

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

Data protection and employment records

February 2025

How to manage personal data relating to employees

Data protection compliance efforts are often focused on commercial or public-facing aspects of an organisation’s activities. Making sure core data protection principles and requirements are met when collecting and handling the data of customers, members, supporters, students, patients, and so on. However the personal data held relating to employees and job applicants doesn’t always get the same level of attention.

Handling employees’ personal information is an essential part of running a business, and organisations need to be aware and mindful of their obligations under the UK GDPR and Data Protection Act 2018. As well as, of course, obligations under employment law, health and safety law, and any other relevant legislation or sector specific standards.

A personal data breach could affect employee records. Employees can raise complaints about an organisation’s employment activities and employees (or former employees) can raise Data Subject Access Requests which can sometimes be complex to respond to. All of which can expose gaps in compliance with data protection laws. In some organisations employee records may represent the highest privacy risk.

Employee records are likely to include special category data and more sensitive information such as:

■ DE&I information (such as information relating to race, ethnicity, religion, gender, age, sexual orientation, etc)
■ disabilities and/or medical conditions
■ health and safety records
■ absence and sickness records
■ performance reviews and development plans
■ disciplinary and grievance records
■ occupational health referrals
■ financial information required for payroll

Alongside the core HR records, employees may be present on other records – such as CCTV, any tracking of computer / internet use, and so on. All of which need careful consideration from a data protection standpoint. Also see monitoring employees.

In my experience, while the security of employee records may often be taken into consideration, other core data protection principles might sometimes be overlooked, such as:

■ Lawfulness

It’s necessary to have a lawful basis for each processing activity. Many activities may be necessary to perform a legal obligation or covered under the contract of employment with the individual. However, the contract may not cover every activity an organisation has requiring the use of employee data. It should be clearly determined where legal obligation or the contract is appropriate for any given activity and confirm any activities where you may instead need to rely on other lawful bases, such as legitimate interests or consent.

■ Special category data

To handle medical information, trade union membership and diversity, equity and inclusion (DE&I) activities, and any other uses of special category data, it’s necessary to determine a lawful basis, plus a separate condition for processing under Article 9. Handling special category data

■ Data minimisation

The principle of data minimisation requires employers to take steps to minimise the amount of personal information about their employees to what is necessary for their activities and not hold additional personal information ‘just in case’ they might need it.

■ Data retention

Employee’s data should not be kept longer than necessary. There are statutory retention requirements for employment records in the UK (and many other jurisdictions), which set out how long they must be kept. But these laws may not cover all types of activities you may have for employment data. Once you set these retention periods, they need to be implemented in practice, i.e. regular reviews of the data you hold for specific purposes and securely destroy records you no longer need. These may be electronic records on IT systems or perhaps physical HR records languishing in boxes in a storeroom! You may wish to refer to our Data Retention Guidance

■ Transparency

Employees are entitled to know the ways in which their employer uses their personal data, the lawful bases, the retention periods and so on. The requirements for privacy notices must be applied to employees, just like external audiences. This necessary privacy information may be provided in an Employee Privacy Notice or via an Employee Handbook.

■ Risk assessments

Data Protection Impact Assessments are mandatory in certain circumstances. In other cases they might be helpful to conduct. Organisations mustn’t overlook DPIA requirements in relation to employee activities. For example, any monitoring of employees which might be considered intrusive or the use of biometric data for identification purposes.

Record keeping

Appropriate measures need to be in place to make sure employee records are being handled lawfully, fairly and transparently and in line with other core data protection principles. It’s difficult to do this without mapping employee data and maintaining clear records of the purposes you are using it for, the lawful bases, special category conditions and so on, i.e. your Record of Processing Activities (RoPA). The absence adequate records will make the creating a comprehensive privacy notice rather challenging.

Training

Whilst we’re on the topic of employees, let’s also give a mention to training. All employees handling personal data should receive appropriate information security and data protection training. It’s likely those in HR / People teams handling employee data on a daily basis will benefit from specialist training beyond the generic online training modules aimed at all staff.

To help you navigate data protection obligations the ICO has published new guidance on handling employee records, which provides more detail on what the law requires and regulatory expectations.

Finally, don’t forget data protection compliance efforts need to extend beyond employees to job applicants, contractors, volunteers and others who perform work-related duties for the organisation.

After a successful career in publishing Simon moved into data protection consultancy in 2015. Simon advises businesses of all sizes across a wide range of sectors. He held the role of Director of Information Governance at Royal Mail Group in the run up to GDPR enforcement. He regularly delivers data protection courses for clients and the Institute of Data & Marketing (IDM).

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

Data Subject Access Requests – what are people entitled to?

February 2025

I’m often asked what’s in scope when responding the Right of Access – aka Data Subject Access Requests (DSAR/SAR). What are organisations obliged to provide, and what can they legitimately exclude? I’ve taken a look at some questions which routinely come up. But first a quick summary of what the law says…

The Right of Access is a fundamental right under data protection legislation in the UK and EU. There are similar rights in other jurisdictions, but I’m focusing here on the right under UK GDPR and the Data Protection Act (DPA 2018).

The law gives people the right to receive and copy of their personal data, and other supplementary information from any organisation acting as a controller. Controller or processor – what are we?

Personal data is any information which could directly or indirectly identify the requestee. To give some examples, this could include images, voice and video recordings, demographic information, profiles, order history, marketing preferences, HR records, performance reviews, opinions expressed about the requestee, other personal identifiers … and the list goes on.

Now, on to the FAQs…

Q: Do we need to provide information the requestee already has, or is obvious to them?

The short answer is, yes. Based on UK case law, organisations can’t refuse to disclose information on the grounds personal data is already known to the individual. (Case: Lttihadieh v 5-11 Cheyne Gardens, 2017). However, it wouldn’t need to be included if the person has made it clear they don’t want this information. You can always ask them.

Q: Are they entitled to full documents?

It isn’t a right to documentation. Just because someone’s name appears in a report, spreadsheet, meeting notes or any other document doesn’t mean they’re entitled to the whole document, if the rest doesn’t relate to them. It may prove easier and relevant to provide full documents, but you would be justified in not doing so. You can extract the necessary information, or redact the irrelevant information. But remember what you provide must be meaningful and have context.

Q: Are they entitled to the full content of email correspondence?

Linked to the question above, people are only entitled to a copy of their personal data. So just because their email address or email signature appears in an email (or email chain) doesn’t make this their personal data. For example, routine business as usual emails, where the content is solely about business related matters will not be the individual’s personal data. It can be really helpful to explain this from the start.

Q: Are handwritten notes in scope?

Personal data which is not part (or intended to be part) of a structured filing system is not in scope. For example handwritten notes in a personal notepad where there’s no intention to formally file these notes would not need to be included. However, if for example, employees write notes in ‘day books’ which are intended to be kept as a record of conversations, these would be in scope.

Q: How much effort is required?

Organisations are expected to make all reasonable efforts to search, identify and retrieve all the personal data being requested. The ICO would expect systems to be well-designed and maintained so information can be efficiently located (including carrying out searches) and extracted. The right of access is not new. It was around long before GDPR came into force in 2018, so organisations would be expected to be well prepared to handle requests.

Q: Can we refuse to comply with a request?

Sometimes it may seem obvious the requestee has an ulterior motive for submitting a DSAR. In general, an individual’s motives shouldn’t affect their right to obtain a copy of their personal data, or the organisation’s duty to respond. Organisations can however refuse to comply with a request, either partially or fully, where they judge it to be manifestly unfounded or manifestly excessive.

A request might be considered manifestly unfounded if, for example, the individual…

■ has no real intention of exercising their right
■ offers to withdraw their request in return for some kind of benefit
■ explicitly states they want to cause disruption
■ makes unsubstantiated accusations or allegations
■ is targeting a specific employee due to a grudge
■ sends regular and targeted requests as part of a concerted campaign

A request might be considered manifestly excessive if it’s clearly or obviously unreasonable or would involve disproportionate effort. In assessing whether it would involve disproportionate effort, you should consider the following factors:

■ the nature of the requested information;
■ the context of the request, and the relationship between you and the individual;
■ whether a refusal to provide the information or even acknowledge if you hold it may cause substantive damage to the individual;
■ your available resources;
■ whether the request largely repeats previous requests and a reasonable interval hasn’t elapsed; or
■ whether it overlaps with other requests (although if it relates to a completely separate set of information it is unlikely to be excessive).

If you rely on either of these grounds, be sure to document your decision, the rationale behind it and explain this to the individual.

To give an example, quite a few years ago I worked on a request from a disgruntled former employee where, among everything else, they asked for all CCTV footage of them. The business operated CCTV which captured employees as they entered and exited the main office. We asked the individual if there were specific dates and times they were interested in. They responding just reiterating the request for all CCTV footage. I think understandably we judged this to be an manifestly excessive request, requiring disproportionate effort and that it would not cause any damage to the individual not to receive this.

Q: What can be excluded or redacted?

Once all the information relating to the individual has been retrieved, the data collated often includes information which doesn’t need to be disclosed. There may be justifiable grounds for excluding information or redacting documents, emails, video recordings and so on.

Information relating to others: the person making the request has a right to receive a copy of their personal data, they’re not entitled to personal data about other people. The DPA 2018 confirms you do not need to include certain information if it means disclosing information which identifies someone else, unless the other person has given their consent or it’s reasonable to disclose without the other person’s consent.

Confidential information: A duty of confidence may arise when another individual has genuinely shared ‘confidential’ information with the expectation it remains confidential. Confidentiality cannot be automatically assumed and needs to be assessed on a case-by-case basis. Other information which may also be considered confidential includes, but is not limited to; trade secrets, information made confidential under another law, internal costs or commercial rates, intellectual property and information covered as part of a non-disclosure agreement

Other exemptions: The DPA 2018 provides a number of further exemptions which may apply depending on the nature of your business and the context of the specific request. These don’t always apply in the same way. Sometimes you might be obliged to rely on an exemption (i.e. it would break another law), other times it will be a choice. Commonly used exemptions include; legal professional privilege, crime and taxation, management information, research and statistics, confidential references and journalism.

The ICO says exemptions should not be routinely relied upon or applied in a blanket fashion. And remember, you may be required to demonstrate how an exemption applies and your rationale for relying on it. The ICO has published guidance on exemptions and how they apply.

These are just some questions I get asked and I’m afraid to say there are plenty more. Responding to DSARs can be very time-consuming, with nuanced considerations and can feel a minefield if you don’t receive many requests or out of the blue receive your first one. Our DSAR Guide provides more information about how to prepare and fulfil requests. Also see the ICO’s detailed Right of Access Guidance.

As a data protection consultant since 2015, Philippa advises and supports a broad range of clients, and delivers data protection training. She also regularly writes GDPR guides to support data protection teams in their day-to-day work.

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

Why record keeping is the cornerstone of data protection

January 2025

Records of Processing Activities

No one ever wrote a thriller about record keeping. Denzel, Keanu, Keira and Brad are not required on set. But here’s why we should give it due attention.

Put simply, without adequate records it’s difficult to demonstrate compliance with data protection legislation (GDPR and UK GDPR). Records are core to meeting the accountability principle, i.e. being ready and able to demonstrate evidence of compliance.

Let’s step back for a moment. Each organisation needs to know what personal data they hold, where it’s located and what purposes it’s being used for. Only then can you be sure what you’re using it for is fair and lawful, and gain confidence you’re meeting other GDPR obligations.

To put it another way, how confident is your organisation in answering the following questions?

  • Do we know what personal data we hold, it’s sensitivity and all the systems it’s sitting on – including data shared with third parties?
  • Do we know all purposes for processing?
  • Have we determined an appropriate lawful basis for each purpose? And are we meeting the specific requirements for that basis?
  • When handling special category data, have we also identified a special category condition?
  • Have we confirmed how long we need to keep the data for each purpose?

All of the above feed into transparency requirements, and what we tell people in our privacy notices.

In my opinion, you can’t answer these questions with confidence unless you map your organisation’s use of personal data and maintain a central record. This may be in the form of a Records of Processing Activity (RoPA).

Okay, so the absence of data protection records might only come to light if your organisation is subject to regulatory scrutiny. But not putting this cornerstone in place could result in gaps and risks being overlooked – which could potentially materialise into a serious infringement.

In my view, a RoPA is a sensible and valuable asset for most organisations. I fully appreciate creating and maintaining a RoPA can feel like a Herculean task, especially if resources are overstretched. That’s why we often recommend taking a proportionate and achievable approach, focussing on special category data use and higher risk activities first. Then build on this foundation when you can.

RoPA requirements under GDPR & UK GDPR

The requirements apply to both controllers and processors and include keeping records covering:

  • the categories of personal data held
  • the purposes of processing
  • any data sharing
  • details of transfers to third countries, including a record of the transfer mechanism safeguards in place;
  • retention periods
  • the technical and organisational measures used to protect the data

and more…

Do you employ less than 250 people?

If so, record keeping requirements may be less stringent. But you’ll still be required to maintain a RoPA if:

  • your processing of personal data is not occasional
  • your processing is likely to result in risk to the rights and freedoms of individuals
  • you process special category data (e.g. health data, ethnicity, trade union membership, biometrics and more)
  • you process personal data relating to criminal convictions and offences.

You can read more about the requirements in ICO records of processing guidance.

Benefits of Record Keeping (RoPA)

Here are just some of the benefits you can get from your RoPA.

1. Understanding the breadth and sensitivity of your data processing.

2. Visibility of where data protection risks lie. This will help establish priorities and focus efforts to tackle key risks.

3. Confidence your activities are lawful and meet specific regulatory requirements.

4. Tackle over retention of data – it’s a common challenge. By establishing your purposes for processing personal data, you can determine how long you need to keep that data. Then you can take practical steps to delete any data you no longer need.

5. Transparency – An up-to-date RoPA feeds into your privacy notice, making sure the information you provide accurately reflects what you are really doing.

6. Data breaches – Your RoPA should be the ‘go to’ place if you suffer a data breach. It can help you to quickly identify what personal data may have been exposed and how sensitive the data is, which processors might be involved and so on. Helping you to make a rapid risk assessment (within 72 hours) and helping you make positive decisions to mitigate risks to protect individuals.

7. Supply chain – Keeping a record of your suppliers (‘processors’) is a key aspect of supplier management along with due diligence, contractual requirements and international data transfers.

8. Privacy rights – If you receive a Data Subject Access Request, your records can help to locate and access the specific data required to fulfil the request. If you receive an erasure request, you can quickly check your lawful basis for processing and see if the right applies, and efficiently locate what systems the data needs to be deleted from.

Tips to get started

Here are a few very quick tips on how to commence a RoPA project or breathe new life into an outdated spreadsheet you last looked at in 2018!

Who?

No DPO or data protection team can create and maintain these records their own – they need support from others. Enlist the support of your Senior Leadership Team, as you’ll need them to back you and drive this forward.

Confirm who is or should be is accountable for business activities which use personal data within all your key business functions – the data owners. For example, Human Resources (employment & recruitment activities), Sales & Marketing (customer/client activities), Procurement (suppliers), Finance, and so on. Data owners are usually best placed to tell you what data they hold and what it’s currently used for, so get them onside.

What?

Make sure you’re capturing all the right information. The detail of what needs to be recorded is slightly different if you act as a controller or processor (or indeed both). If you need to check take look at the ICO guidance on documentation.

When?

There’s always some new system, new activity and/or change of supplier, isn’t there? You should aim to update your records whenever you identify new processing or changes to existing processing – including identifying when you need carry out a Data Protection Impact Assessment or Legitimate Interests Assessment. Good stakeholder relations can really help with this.

In conclusion, record keeping might not win many Oscars, but it really is the cornerstone of data protection compliance. Adequate records, even if not massively detailed, can be really beneficial in so many ways, not just if the ICO (or another Data Protection Authority) comes calling.

After a successful career in publishing Simon moved into data protection consultancy in 2015. Simon advises businesses of all sizes across a wide range of sectors. He held the role of Director of Information Governance at Royal Mail Group in the run up to GDPR enforcement. He regularly delivers data protection courses for clients and the Institute of Data & Marketing (IDM).

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

Controller or processor? What are we?

January 2025

The importance of establishing if an organisation is acting as a processor or controller

On paper the definitions of controller and processor under GDPR (& UK GDPR) may seem straight-forward, but deciding whether you’re acting as a controller, joint-controller or processor can sometimes be a contentious area.  Many a debate has been had between DPOs and lawyers when trying to classify the relationship between different parties.

It’s not unusual for it to be automatically assumed all suppliers providing a service are acting as processors, but this isn’t always the case. Sometimes joint controllership, or separate distinct controllers, is more appropriate. Or perhaps a company is simply providing a service, and is not processing the client’s personal data (other than minimal contact details for a couple of employees).

It’s worth noting service providers (aka suppliers or vendors) will often act as both, acting as controller and processor for different processing tasks. For example, most will be a controller for at least their own employee records, and often for their own marketing activities too.

What GDPR says about controllers and processors

The GDPR tells us a controller means ‘the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data’.

A processor means ‘a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller’.

How to decide if we’re a controller or processor

There are some questions you can ask to help reach a conclusion:

■ Do we decide how and what personal data is collected?
■ Are we responsible for deciding the purposes for which the personal data is used?
■ Do we use personal data received from a client/partner for our own business purposes?
■ Do we decide the lawful basis for the processing tasks we are carrying out?
■ Are we responsible for making sure people are informed about the processing? (Is it our privacy notice people should see?)

If you’re answering ‘yes’, to some or all of these questions, it’s highly likely you’re a controller.

The ICO makes it clear it doesn’t matter if a contract describes you as a processor; “organisations that determine the purposes and means of processing will be controllers regardless of how they are described in any contract about processing services”.

A processor only processes a controllers’ personal data on their behalf and crucially doesn’t use this data for its own business purposes. While a processor may make its own day-to-day operational decisions, it should only process the data in line with the controller’s instructions, unless required to do otherwise by law.

Sometimes overlooked is the fact even if a handful of employees of a service provider only have access to a controller’s personal data it still means the service provider is ‘processing’ the data, and will be a processor.

Why it’s important to confirm your status

Controllers have a higher level of accountability. They are obliged to comply with all data protection principles, such as ensuring the lawfulness of processing, being transparent (e.g. privacy notices), fulfilling privacy rights requests and so on.

Processors do have a number of direct obligations, such as being required to implement appropriate  technical and organisation measures to protect personal data. A processor is also responsible for ensuring the compliance of any sub-processors it may use to fulfil their services to a controller. In fact processors are liable for the sub-processors.

The ICO issued a £3m fine to a software company in March 2025 for failing to implement sufficient measures, which you can read about here.

Data processing agreements

There’s a requirement to have an appropriate agreement in place between a controller and a processor.  Article 28 of EU / UK GDPR sets out specific requirements for what must be included in the contractual terms.

Such terms are often covered in a Data Processing Agreement/Addendum, but sometimes will be covered in a specific section on data protection within the main contract. (If there’s no DPA, no addendum and no section on data protection that’s a massive red flag!)

Often overlooked is the need to have clear documented instructions from the controller. It can be helpful to have these as an annex to the main contract (or master services agreement), so they can be updated if the processing changes. We’ve written more about the detail of what needs to be covered in contractual terms here. Another area which can get forgotten is sub-processors and international data transfers.

There are times where you’re looking to engage the services of a household name, a well-known and widely used processor. This sometimes leads to limited or no flexibility to negotiate contractual terms. In such cases, it pays to check the terms and, if necessary, take a risk-based view on whether you wish to proceed or not.

Before even looking at the terms, due diligence on prospective processors is a ‘must do’ for controllers, while taking an approach proportionate to the level of risk the outsourced processing poses. And for their part processors need to be prepared to prove their data protection and information security credentials.

As a data protection consultant since 2015, Philippa advises and supports a broad range of clients, and delivers data protection training. She also regularly writes GDPR guides to support data protection teams in their day-to-day work.

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

SIGN UP FOR OUR NEWSLETTER

Get DPN updates direct to your inbox. Insight, free resources, guides, events & services from DPN Associates (publishers of DPN). All our emails have an opt-out. For more information see our Privacy Statement.