United Kingdom
Jamaica
India
From fitness and health‑tracking devices to mental well‑being apps and remote monitoring services, healthcare organisations of all stripes solutions are using digital technology and data to deliver support in all kinds of new ways. But of course they collect and use vast amounts of sensitive personal information in order to do that, which places them squarely in the frame of data protection laws in every market they enter.
At the heart of data privacy compliance lies the question of responsibility. Who is responsible for all this data, and who is accountable for it when things go wrong? In order to add some real world nuance when answering this question, the EU GDPR – and most of the data protection regulations that echo it = draws a distinction between the data “controller” and the data “processor.”.
This may sound like legal jargon, but it’s a critical distinction that affects compliance obligations, risk exposure, and the practical realities of how services are delivered. Misunderstanding how the distinction applies to your organisation can have serious consequences, as misclassification of controller and processor roles creates accountability gaps, unlawful processing, and transparency failures, exposing organisations to regulatory investigations, heavy fines, reputational damage, and—most critically—the loss of trust when it comes to handling sensitive health data.
What this means is that any organisation, regardless of its size, needs to be clear into which category it falls in order to understand the impact this has on their data protection compliance. It is not uncommon for organisations and especially SMEs or fast-growing businesses that lack their own dedicated in-house data protection expert, to make the wrong choice and, as a result, go on to build their data governance efforts on the wrong set of foundations. To help clarify things, let’s unpack the terminology used. At its core, a “controller” is the entity that determines the purposes and means of processing personal data - the “why” and the “how” of the processing.[1] Controllers exercise decision making power over key elements of data use, and given this decisive influence bear the primary responsibility for compliance with data protection regulations – and demonstrating this compliance – by, doing things like, providing privacy notices, conducting appropriate assessments on how personal data is being used and notifying regulators and affected individuals in the event of a breach.
Just to make matters a little more complex, data protection law also recognises the concept of “joint controllers”. This situation arises when two or more organisations are working together and both making decisions about the purposes and means of processing of a particular set of personal data. Joint controllership is particularly common in contexts where collaboration is essential—such as healthcare research, partnerships or integrations between healthcare platforms. For instance, a developer of a blood pressure monitoring app, a provider of apps for medical professionals, and a hospital collaborating to study how blood pressure variations may predict disease would be regarded as joint controllers if all three organisations help design the app’s features and, once the research is complete, go on to use the results in their own activities.
Consider, for example, a counselling chatbot designed to provide mental health guidance. The company that develops this application determines the questions the chatbot asks and the responses it delivers. By shaping both the content and the manner of interaction, it exercises control over the processing of counselling data and, as such, is likely to be regarded as a controller. However, what happens if a second company organisation pays the first company to provide the chat app’s services to its own (the second company’s) employees? Now there’s a good case to make that the second company has become the data controller, while the first company is now a data “processor” – acting on instruction from the second company – even though its service – providing a mental health chat app – hasn’t changed at all.
A “processor” therefore is an entity that processes personal data on behalf of the controller and solely in accordance with the controller’s instructions, acting on the controller’s instructions. It handles data for someone else, and wouldn’t be handling that data if that someone else wasn’t asking (and, usually, paying for their services). Processors are generally responsible for implementing appropriate technical and organisational safeguards to ensure the data they handle remains protected, and they are not allowed to do anything with it outside of the tasks specified by the controller.
Think of cloud Software-as-a-Service providers, like Salesforce or SAP. Although they generally offer standardised online platforms with little scope for customisation and thus may appear to influence certain technical means of processing, they remain processors because they store data exclusively on behalf of customers and do not use it for their own purposes. Should they start to use that data for their own ends – like training AI or developing new commercial products – they would then have to become the controller in respect of that specific activity.
Most data protection regimes recognise this division of roles, even if the terminology differs across jurisdictions. Controllers engage third parties precisely to benefit from their specialist expertise such as their technical knowhow or services. It is therefore necessary for processors to enjoy a limited degree of discretion in how they deliver these services, which includes making certain decisions about how the processing is carried out. But,such discretion must not extend to determining the “essential means” of processing, which remains the sole responsibility of the controller.
The key thing to understand is that “controller” and “processor” are functional legal concepts that allocate responsibility based on actual roles, not on contractual labels. In other words, you cannot “contract your way out” of being a controller simply by being referred to as a “service provider” in a customer contract. Determining whether an entity is a controller or a processor depends on the factual circumstances of the processing—specifically, who retains decision‑making power over the purposes of using the data and the essential means of manipulating it.
In practice, each processing activity must be assessed individually, and health app providers often act as both controllers and processors depending on the circumstances in which these apps are used.
The path to data privacy compliance is complex and the stakes are even higher in the health sector, where the data involved is among the most sensitive and complex outsourcing arrangements and research partnerships are common. Multiple relationships across supply chains and partnerships make the controller/processor distinction harder to navigate, and as organisations expand globally, the regulatory landscape only grows more complex and challenging.
Ultimately, only an informed assessment of the actual circumstances of each processing activity can determine the correct allocation of controller/processor roles and ensure that an entity meets its obligations under data protection law. Getting this right often requires close collaboration with your data protection team or appropriately qualified external experts to ensure compliance and resilience. If you would welcome the opportunity to speak to one of our team of compliance experts to discuss your organisation, we would be delighted to hear from you. Contact us to find out how we can help.
[1] EDPB Guidelines 07/2020 on the concepts of controller and processor in the GDPR EDPB_guidelines_202007_controllerprocessor_final_en.pdf