In a previous article, we looked at Data Retention: Why It Matters and How to Stay Compliant and why organisations should not keep personal data longer than necessary.
Retention policies help organisations manage this risk and avoid holding data indefinitely.
However, before deciding how long data should be retained, there is an important question to answer first.
Is it actually your data to keep?
In a number of recent discussions with organisations, it has become clear that many people are unsure about the difference between a data controller and a data processor.
When that distinction is unclear, organisations can end up holding personal data long after a customer relationship has ended simply because they believe they must keep it for a vague idea of "data retention" rather than a specific legal or contractual requirement.
In many cases, that assumption is incorrect.
Consider a software platform used by a healthcare provider to manage patient information. The healthcare provider later moves to a different system, but the previous provider still holds copies of the patient data. When asked why the data is still there, the explanation is that it is being retained for "compliance reasons". However, the contract does not require this, and the provider has no independent reason to keep the data.
Situations like this usually come down to misunderstanding the roles of data controller and data processor.
What is a data controller?
Under the UK GDPR, a data controller is the organisation that decides why and how personal data is processed.
In practice this means the controller decides things such as:
- why personal data is collected
- what data is needed
- how it will be used
- who it will be shared with
- how long it should be kept
The Information Commissioner's Office (ICO) describes the controller as the organisation that determines the purpose and means of processing personal data in its guidance on controllers and processors.
Because the controller makes these decisions, they carry the main responsibility for complying with data protection law.
Typical examples include employers that manage employee information, or organisations holding a database of customer information.
What is a data processor?
A data processor processes personal data on behalf of a controller.
Processors can provide services such as software platforms, cloud hosting, payroll services or IT infrastructure.
In these situations the processor does not decide why the data is collected. Instead they process the data according to the instructions of the controller.
The ICO also explains in its guidance on controllers and processors that processors must only process personal data in line with the controller's documented instructions.
A simple way to think about it
One way to understand the difference is to think about a storage facility. Imagine you rent a storage unit because you need somewhere secure to keep your belongings.
The storage company provides the building. They manage the locks, alarms and access control.
But the contents of the unit still belong to you. You decide what goes in the unit and how long it stays there.
If you stop renting the unit, the storage company does not get to keep your belongings simply because they were storing them. Their role was to look after them while you needed the service.
Many software platforms are in a similar position. They store personal data on behalf of their customers, but that does not mean the data becomes theirs to keep.
Security and risk decisions sit primarily with the controller
The storage example also helps explain another point that often causes confusion. If you were choosing a storage facility, you would want to know how secure it was before putting your belongings there. You might check things such as locks, alarms, CCTV or flood protection. That decision would be your responsibility because the items in the unit belong to you.
The same principle applies to personal data.
The organisation that decides to collect the data is responsible for assessing the risks involved in processing it. In some situations this includes carrying out a Data Protection Impact Assessment (DPIA). The ICO explains in its DPIA guidance that DPIAs help organisations identify and minimise data protection risks when processing personal data.
Because the controller decides why the data is processed, it is normally the controller that carries out the DPIA. Processors can help by providing information about their systems and security controls, and many providers will also carry out their own internal risk or privacy assessments, but responsibility for the DPIA itself usually sits with the controller.
This is why asking a SaaS provider to provide a DPIA is often a misguided request. What organisations usually need is information that allows them to complete their own assessment.
Why this matters for data retention
Retention policies usually sit with the controller because they decide how long the data is needed. Processors should not normally decide retention periods themselves. Their role is to process and store the data according to the instructions set out in their agreement with the controller. In many service agreements this includes provisions about what happens to the data when the service ends. This might include returning the data to the customer, securely deleting it, or confirming that it has been removed from the system.
If a processor continues holding personal data without instruction or legal reason, there may be no clear or appropriate lawful basis for doing so.
When a provider is both controller and processor
In practice, many software companies are both controllers and processors at the same time. A SaaS provider may act as a controller for some types of data and a processor for others. The role depends on the specific processing activity, not on what the organisation calls itself.
| Data | Role |
|---|---|
| Customer billing information | Controller |
| Marketing contact details | Controller |
| Customer data stored within the platform | Processor |
Before setting retention periods
Retention policies remain an important part of data protection. They help organisations avoid keeping information longer than necessary and reduce the amount of data held over time.
However, before deciding how long data should be retained, it is important to confirm who is responsible for that data. If you are acting as a processor, your responsibility may simply be to store the data securely while the service is active and then return or delete it when the contract ends.
Only once your role is clear should you move on to defining retention periods. We explored that in more detail in our earlier article on data retention.
Before asking how long you should keep data, make sure it is actually your data to keep.
