Introduction
The passage of Nigerian Data Protection Regulation 2019 (NDPR) and the proactive steps thus far taken by the National Information Technology Development Agency (NITDA) has awakened the consciousness of the organisations and individuals to be NDPR compliant. The concepts/designations of Data Controller (DC) and Data Processor (DP) takes centre stage in the NDPR. This is because it determines who takes responsibility for compliance and the related liability as well. There is always lack of clarity between the two concepts vis-a-vis their roles. Sometimes, an organisation or person may perform the role of a DC and DP, such as where it processes personal data (PD) on behalf of another organisation (as processor), but is a controller for PD of its employee. However, no company or person can be a DC and DP for the same activity.[1]
When an organisation contracts another to process PD on its behalf, confusion could arise as to who is whom, and the extent and limit of their respective responsibilities and liabilities. Therefore, it is imperative in such situations, to decipher who is the processor and controller of PD respectively, in order to distinguish between their specific responsibilities and liabilities.
Definitions: Data Controller and Processor determined
- Data Controller
“‘Data Controller’ means a person who either alone, jointly with other persons or in common with other persons or a statutory body determines the purposes for and the manner in which PD is processed or is to be processed”.[2] By this definition, it means a DC exercises control over personal data, and by extension, bears the ultimate responsibility of demonstrating compliance with the NDPR. There might be a scenario where more than one person or institution determines the means and purpose(s) of processing PD. In such scenarios, such persons or institutions will be jointly regarded as DC and they may be jointly or individually liable. However, where they process the same data but for different purposes, they will not be regarded as joint controllers (JC).[3]
It is important to note that except in situations where there is statutory designation, no person or organisation is by nature a controller or processor. The question of being a controller is a matter of fact, which must be derived from the circumstances/facts of each case. Thus, the appropriate question to ask in each circumstance is: who determines means and purpose of data usage? A mere contractual formal designation of DC or DP may not be sufficient.[4] In the Swift Case,[5] Swift was formally considered a DP, but it de facto acted – to a certain extent – as a DC.
In that case, it was held that even though the designation of a party as DC or DP in a contract may reveal relevant information regarding the legal status of such party, the contractual designation is nonetheless not decisive in determining its actual status; which must be based on concrete circumstances. The case concerns the transfer to US authorities, with a view to fight terrorism financing, of banking data collected by Swift pursuant to financial transactions on behalf of banks and financial institutions.
Also Read: Examinations: Data Subjects’ Rights Under the Nigerian Data Protection Regulations 2019
Therefore, DCs are the chief decision makers on how PD should be collected, stored, transferred and deleted. A person who assumes control and decides the means and purpose of the usage of the data will at all material times be regarded as DC. Professional service providers are usually regarded as DC. This is because they work under certain professional obligations that compels them to take responsibility for the PD they process.[6]Nevertheless, regard should be hard to facts of each case.
- Data Processor
According to Article 1.3(ix) NDPR “‘Data Administrator’ means a person or an organisation that processes data”. NDPR did not define the term ‘Data Processor’ (DP) or expressly provide that it connotes the same meaning as Data Administrator (DA). However, under Articles 2.4(b) and 4.1(3) NDPR and Paragraph (Para) 3.1 of Implementation Framework 2020 DP was used interchangeably with DAs. Consequently, it is submitted that both bear the same meaning. Any person that follows another’s instruction in processing PD data is a DP. Therefore, where the purpose upon which PD was processed was instructed by a client and one did nothing except making some technical instructions on how the PD will be processed, such a person is most likely a DP.[7]
As explained by the ICO: “A bank hires an IT services firm to store archived data on its behalf – having ensured that the IT firm has given sufficient guarantees about the security of its systems and processes. The bank will still control how and why the data is used and determine its retention period. In reality the IT services firm will use a great deal of its own technical expertise and professional judgment to decide how best to store the data in a safe and accessible way. However, despite this freedom to take technical decisions, the IT firm is still not a data controller in respect of the bank’s data – it is a processor. This is because the bank retains exclusive control over the purpose for which the data is processed, if not exclusively over the manner in which the processing takes place.”[8]
There are two criteria for becoming a DP: separate entity in relation to the DC and processing PD on behalf of the DC.[9] Therefore, an entity cannot be a DC and DP of PD on the same processing activity. If the DC decides to process data itself (i.e., act as DP), using its own resources within its organisation, for example through its own staff, this is not a processor situation.[10] It is possible to be a DP and DC of PD, but not on the same processing activity. However, in some cases, an entity could be a controller and a processor of the same PD – but only if an entity is processing for different purposes. This maybe the situation where a DP deviates or goes beyond the purpose or instruction given by the DC in the course of processing PD. In this situation the processor automatically becomes a controller for the processing outside the DC instruction: Swift Case (supra).
The processor must ensure the system and procedures distinguish PD processed in the capacity of DC or DP. If the data is same, the processor must ensure the system distinguish between these two capacities and allow different measures and processes to apply. Otherwise, the processor may be considered a joint controller, rather than a processor for the data processed on behalf of the client.[11]
In other jurisdictions such as the United Kingdom (UK),[12] a processor can contract a sub-processor (SP) to perform a specific or general processing of PD depending on the type of consent obtained from the DC. The NDPR did not specifically provide or define a SP, which makes it unclear whether or not a processor can contract SP. However, in an attempt to define a third-party in Article 1.3(xxvii), NDPR factored the possibility of a sub-processor. According to Article 1.3(xxvii), “a third party means any natural or legal person, public authority, establishment, or any other body other than the Data Subject, the Data Controller, the Data Administrator, and the persons who are engaged by the Data Controller or the Data Administrator to process Personal Data”.[13]
Therefore, it can be correctly argued that NDPR envisage a situation where a DP can appoint a SP in processing PD. Even against this backdrop, a DP can still appoint a SP under the NDPR based on the principle of freedom of contract, entitling parties to enter into any legal contract without restriction.[14] The NDPR did not prohibit SP. It is merely silent on it, and its silence cannot be construed to be a prohibition.Nevertheless, engaging SP may raise two important questions: Does the original processor become controller to SP? Can the original controller be held liable for the fault of SP?
- Does the original processor become a controller to SP?
NDPR is silent on this, but according to the ICO,[15] the fact that a processor subcontract some or all of the processing activities, does not make him a controller in his own right. The usual control of the processing remains with the original controller provided the controller’s consent was obtained. Article 28(3) UK GDPR 2020 enjoins processors to put in place a contract with the SP offering equivalent level of protection for PD as those between the processor and controller. This position can be adopted in Nigeria too.
- Can an original controller be held liable for the breach of SP?
NDPR did not offer any guidance in answering this question. However, by the relevant provisions of Article 28(4) and 82(5) UK GDPR 2020, where breach is occasioned by SP, the DC maybe be liable but may claim back compensation from the processor and the processor may claim back from the SP. This means that the DP is liable to the DC for the breach of the SP. This position may be adopted in Nigeria, but it is advised that a fresh agreement involving the three parties should be entered to avoid the incidence of privity of contract.
Importance of Distinguishing Between Data Controller and Data Processor
The EDPB’s guidance clarifies that the starting point for assessing the status of an entity within a data transaction will be based on the factual circumstances of the transaction, irrespective of how the parties are named or labelled. Purpose is considered the key indicator.
As has been stated in this piece DC and DP plays different roles and have differing responsibilities in processing PD. Drawing a line between them is important for determining who bears a particular responsibility and liability. For instance, the DC is responsible for ensuring that data subjects’ rights are at all material times properly respected by complying with the principles of data processing, consent and other compliances.
DPs on the other hand ensures that certain information are made available to DC to enable them comply with NDPR such as notifying data breaches and helping the DC comply with the Data Protection Impact Assesment. The DP must ensure strict compliance with the terms of the agreement as it relates to processing of PD. The extent and limits of instructions of the Controller must be expressly contained in the contract, and complied with by the DP.
Also Read: Actions: Beyond the Nigerian Data Protection Regulations (NDPR) 2019
In the event that the DP goes beyond the instructions given by the DC in the contract, the DP will be deemed a DC and regarded to have infringed NDPR, which may make him subject to sanctions. But where the DP complies with the instructions of the DC, the responsibility and potential liability for breaching the NDPR will be on the DC. In order to understand which duties apply to which parties, recourse must be made to the activities of the parties vis-as vis the definitions of DC and DP.
It is important to note that the DC shoulders the highest level of compliance responsibility with NDPR at all material times. Even though the DP is expected to comply as much as provided by the NDPR, DC bears ‘the sheep –shepherd responsibility’, because he still has the responsibility to ensure that the DP compliances with the NDPR.
Conclusion
The issue of data privacy and its compliance are becoming a very serious matters, with economic and reputational consequences in Nigeria.[16] In determining whether a party is a DC or DP regarding data privacy compliance responsibilities, recourse must be made to the actual activities of the party, and not just the formal designation in the contract. Also, institutions or individuals should be aware that a DC may bear ultimate responsibilities in data processing, and must thus take steps to procure a DP that has the technical capacity to undertake the processing.
