The Silent Liability: Misunderstanding Roles And Responsibilities In Data Processing Relationships

1. Introduction

Many businesses move quickly into partnerships and business arrangements that rely on the exchange or integration of personal data. They share data here, connect an Application Programming Interface (API) there, link systems, combine datasets, and roll out solutions that depend on continuous information flows to third-party organisations. In the middle of this pace, one essential question can be overlooked: What is the role and responsibility of the organisation in the data processing relationship?

What we mean here by a data processing relationship is any arrangement where two or more organisations handle or process personal data together, whether through integrated systems, outsourced services, collaborative projects or shared platforms. More specifically, these relationships take different forms, including controller–processor, processor–sub-processor, joint controller and joint processor arrangements.

There are three important issues that organisations must understand and address when dealing with these data processing relationships. The first is the type of relationship they are entering into. The second is their specific role within that relationship. The third is the legal and contractual duties that attach to that role. While these issues may appear straightforward, they sit at the centre of many compliance failures. We have seen cases where organisations treat a business partner as a processor when that partner is in fact a controller, or assume joint control when the facts show that each party operates independently. We have also seen situations where processors drift into making decisions that place them squarely in controller territory without realising the shift.

Understanding whether you are a controller, processor, sub-processor, joint controller, or joint processor is critical because your role determines the obligations you carry, the agreements you must have in place, the safeguards you must implement and the level of accountability you hold when processing activities fail. The Nigeria Data Protection Act (NDPA) and its General Application and Implementation Directive (GAID) provide the statutory basis for determining some of these roles and the obligations attached to each. They also offer some indicators that help organisations understand how their responsibilities change across different types of data-processing relationships.

In this piece, we explain the various data processing relationships that organisations enter into and how to spot one's role in these relationships. We also explain the duties that attach to each role within these relationships, the contractual requirements that are essential for governing them and the legal expectations imposed on each actor.

2. Understanding the various data processing relationships

Before an organisation can understand its obligations, it must first understand the type of data processing relationship it is part of and how its role within such a relationship can be determined. These issues are explained below:

a) Controller–Processor

The NDPA explicitly acknowledges the controller–processor relationship. It does this by setting out the duties that apply when a data controller engages a processor to support its data processing activities.

A controller–processor relationship arises where one organisation decides why personal data should be processed and another organisation carries out the processing on the controller's instructions. The controller defines the purpose, sets the boundaries and determines the essential elements of the processing. The processor performs operational or technical activities that support that purpose, but does not make independent decisions about the data. This relationship is defined by a clear separation between decision-making power and execution.

To spot this relationship in practice, the first step is to examine who initiates the processing activity. If one party decides that personal data should be collected, identifies the categories of data required, determines the individuals affected and specifies what the processing aims to achieve, that party is more likely functioning as the controller. It does not matter whether the controller processes the data directly or outsources the work. What matters is that it retains authority over why the data exists in the first place. The processor's role then flows naturally from this. A processor receives instructions, follows a prescribed workflow and performs clearly assigned tasks without altering the purpose or broad method of processing. The processor's decisions tend to be technical, minor or operational rather than strategic.

This relationship commonly arises in routine business outsourcing or the use of external service providers. An organisation may use a document management platform to store customer forms, a software vendor to run analytics on behalf of the business or a call centre provider to manage customer support requests using scripts and data supplied by the organisation. In all these cases, the organisation determines the purpose, the nature of the data and the expected outcomes. The provider simply enables that decision through specific functions such as hosting, storage, customer interaction, analytics or system performance.

A useful way to confirm if this relationship exists is to consider whether the service provider has any independent interest in the data. If the provider is not expected to use the data for its own benefit, change the purpose of processing, decide new forms of processing and not act outside documented instructions, it is acting as a processor. The substance of the conduct, rather than the contract label, determines the true role.

b) Processor–Sub-Processor

The NDPA similarly explicitly acknowledges the processor–sub-processor relationship. It does this by setting out the duties that apply when a processor engages another processor to support its data processing activities.

A processor–sub-processor relationship arises when a processor, already acting on the instructions of a controller, engages another organisation to perform part of the processing activity on its behalf. This creates a layered structure where the controller instructs the primary processor, and the primary processor instructs the sub-processor. The controller does not directly engage the sub-processor, but the processing still occurs for the controller's ultimate purpose. The defining feature is that the sub-processor acts under the authority of the primary processor, not the controller, and does not determine any part of the purpose or essential means.

To recognise this relationship in practice, the key question is whether an organisation that is already a processor needs another service provider to complete or support the processing activity it has been contracted to deliver. If the original processor lacks certain capabilities, requires additional infrastructure or needs specialised support services, it may turn to a sub-processor. In this arrangement, the primary processor remains responsible for ensuring that the sub-processor works within the controller's instructions and does not introduce new purposes or new forms of processing. The sub-processor, therefore, sits further down the operational chain, performing tasks that enable the processor to fulfil its obligations to the controller.

This relationship commonly arises in layered digital service delivery. For example, a payment processor may use a cloud-hosting provider for secure data storage, a cybersecurity vendor for threat detection or a communication service for sending transaction alerts. Here, the payment processor is already processing data on behalf of the controller, and it relies on additional providers to carry out specific technical steps. The controller does not directly interact with these providers, yet their activities directly affect the controller's processing. Another example is a customer support processor that uses an external transcription provider to generate voice-to-text outputs for analytics. In all these cases, the sub-processor does not decide why the data is used, cannot alter the scope of processing and operates strictly within the boundaries set by the primary processor.

A practical way to confirm this relationship is to assess whether the secondary provider is acting on the instructions of the primary processor rather than the controller. If the primary processor controls the workflow, issues the instructions and integrates the secondary provider's service into its own delivery to the controller, the secondary provider is a sub-processor. The hierarchy of control, not the job title, determines the classification.

c) Joint Controller

The NDPA recognises the joint controller relationship through its definition of "controller." It defines a "controller" as any person or entity who, alone or jointly with others, determines the purposes and means of processing personal data.

A joint controller relationship arises where two or more organisations jointly determine the purposes and means of processing personal data. In this relationship, the parties share decision-making authority. They each contribute to why the data is processed and how the various aspects of the processing should occur. What binds them together is a shared intention and a coordinated approach to the use of the data. Their choices are interdependent, and neither organisation can fully carry out the processing without the input or agreement of the other.

This relationship becomes apparent when the processing activity is collaborative from the outset. To identify joint controllership, the first question is whether the organisations make decisions together about the purpose of the processing. If they co-design the data flows, jointly decide what information is collected, jointly determine how the system works or jointly shape the user experience, they are likely acting as joint controllers. It does not matter whether one organisation performs more of the operational tasks. What matters is that both organisations influence the purpose and essential method of the processing. In many cases, the joint nature of the decisions is reflected in project governance structures, co-created platforms, shared databases or jointly managed digital tools.

This relationship commonly arises in co-branded service delivery, collaborative platforms and partnerships where both parties depend on the same dataset for aligned objectives. For example, two organisations may jointly run a digital portal that collects personal data from users for a shared service. Each organisation relies on the collected data to achieve its own business goals, and each contributes to setting the rules that govern how the data is processed. Another example is a joint research initiative where the participating entities determine together which data is collected, how it will be analysed and how long it should be retained. In such cases, the decisions about why and how processing occurs are mutual rather than sequential.

A useful way to confirm the presence of joint controllership is to evaluate whether both organisations play a substantive role in determining the processing purpose. If both parties influence the essential means and neither can unilaterally alter the purpose or core activities without affecting the shared objective, they are joint controllers. The true classification depends on the extent of shared decision-making rather than the existence of a partnership or contract.

d) Joint Processor

Unlike what it does for the definition of "controller", in defining "processor", the NDPA does not explicitly acknowledge joint processor relationships. The law frames a processor as a person or entity that processes personal data on behalf of a controller or another processor, without referring to situations where two processors work together.

In practice, this data processing relationship arises where two or more processors work together to perform processing activities on behalf of the same controller. None of the processors determine the purpose or means of the processing, because these decisions remain with the controller. However, the processors coordinate their activities, rely on shared tools or infrastructure and perform interconnected tasks that support the controller's instructions. What defines this relationship is the level of integration between the processors' operational activities and the degree to which their work depends on coordinated execution.

To identify this relationship, the starting point is to examine whether the processors are carrying out related parts of the same processing operation using a combined or linked technical environment. If two service providers jointly operate a platform, deliver interdependent services or rely on shared systems to carry out their tasks, they may be acting as joint processors. The key is that both processors follow the controller's instructions but deliver their functions in a way that requires collaboration. Neither processor can fulfil the controller's requirements alone because their activities are functionally tied together. This interconnectedness distinguishes joint processors from separate processors who work independently on unrelated tasks for the same controller.

This relationship commonly arises where two vendors integrate their systems to deliver a unified service for a controller. For example, a customer service vendor may integrate its support tools with a transcription vendor that provides automated voice-to-text outputs, with both systems linked in a single workflow. Both vendors act on the controller's instructions but deliver their services through a coordinated process. Another example is where an analytics provider and a hosting provider operate in a shared technical environment created by the controller. Each provider performs its specific function, but their tasks rely on shared data structures, joint interfaces or connected operational processes.

A practical way to confirm joint processing is to consider whether the processors must coordinate to implement the controller's instructions. If their tasks depend on shared systems, coordinated data flows, combined outputs or mutual reliance on each other's tools, they are functioning as joint processors. The relationship is determined by the operational reality of integration, not by contract labels or commercial arrangements.

3. Understanding the duties that attach to the roles in the relationships

The duties that attach to different actors in data processing relationships have two main dimensions. The first dimension relates to obligations imposed directly by law on controllers, processors and any party acting on their behalf. These statutory duties determine how personal data must be handled, the safeguards that must be in place and the level of accountability expected from each actor.

The second dimension concerns the contractual obligations that govern these relationships. While some aspects of these contractual requirements are expressly mandated by the NDPA and the GAID, others arise from best practice and the need to allocate responsibilities in a way that reflects how the processing actually occurs. These two aspects, as they apply to the various data processing relationships, are explained below.

a) Controller–Processor

The NDPA expressly sets out statutory duties for controllers in controller–processor relationships. The controller must ensure that any processor it engages is capable of protecting personal data and supporting lawful processing. This includes verifying that the processor can comply with all applicable principles, support the controller in honouring data subject rights, maintain appropriate security and confidentiality measures, and provide the information necessary for demonstrating statutory compliance. The controller must also ensure that the processor does not bring in another processor without prior notification, and that the processor's activities remain within documented instructions.

While the NDPA focuses on the controller's oversight duties, the corresponding obligations of the processor flow from the same provision and from the general statutory duties imposed on processors. The processor must act only within the controller's documented instructions. It must maintain appropriate technical and organisational measures, assist the controller with rights requests, provide information needed to evidence compliance, support breach response and keep adequate internal records. Where the processor intends to appoint a sub-processor, it must notify the controller and ensure that the sub-processor can meet the same standards. If the processor is an individual or small operator engaged in high-risk processing, it must also demonstrate proper privacy training and registration in line with GAID.

On the contracting side, the NDPA requires a written data processing agreement for every controller–processor relationship, and the GAID specifies the elements that the agreement must contain. These include the identities and addresses of the parties, links to any principal contract or service agreement, the purpose, scope and lawful basis for the processing, the location of the processing, responsibilities of each party, technical and organisational measures, any DPIA outcomes, identified risks, evidence of NDPA compliance, confidentiality expectations, retention and deletion terms, specific restrictions, indemnity and insurance requirements, force majeure provisions and dispute resolution mechanisms. The agreement must also regulate sub-processing and ensure that relevant duties flow from the controller to the processor and then to any further processor engaged by the processor.

b) Processor–Sub-Processor

The NDPA similarly sets out the statutory duties of the processor in processor–sub-processor relationships. These duties aim to ensure that the same level of protection applies at every stage of the processing chain and that the controller's expectations are preserved, regardless of how many entities handle the data on the processor's behalf. A central principle is that the primary processor remains fully responsible for the actions and omissions of any sub-processor it appoints.

Legally, the processor must ensure that any sub-processor it engages can meet the obligations imposed on it by the controller. This includes confirming that the sub-processor can comply with applicable principles, support the fulfilment of data subject rights, implement adequate security and confidentiality safeguards and provide all information needed to demonstrate compliance. The primary processor must also notify the controller before engaging a sub-processor and must ensure that the appointment of the sub-processor does not expand the purpose or scope of the processing.

Like in the controller–processor relationship, the NDPA does not set out a dedicated list of duties for sub-processors in a separate provision. Nonetheless, the obligations that apply to processors generally also apply to sub-processors once they begin handling personal data on behalf of the primary processor. A sub-processor is expected to act strictly within the authority delegated by the primary processor, maintain appropriate technical and organisational measures and support the primary processor in responding to rights requests, breach management and compliance monitoring. Where a sub-processor operates as an individual engaged in high-risk processing, it must have proper privacy training and appropriate registration to demonstrate competence.

Contractually, the NDPA requires a written agreement between the processor and any sub-processor. This agreement should mirror the obligations contained in the controller–processor contract to ensure that duties flow consistently through the chain. The GAID's requirements for data processing agreements apply here as well, adapted to reflect the hierarchy. The agreement should identify the parties, link to any overarching service agreement, define the purpose and scope of the delegated processing, specify the location of processing, set out responsibilities, include the relevant technical and organisational measures, reflect any applicable DPIA outcomes, capture potential risks, confirm NDPA compliance, impose confidentiality duties, state retention and deletion expectations, outline any restrictions and include indemnity, insurance, force majeure and dispute resolution provisions. It should also make clear that the sub-processor is bound by the same constraints and safeguards that apply to the primary processor.

c) Joint Controller

While the NDPA does not set out the duties of actors in a joint controller relationship, the duties applicable to this relationship flow directly from the general statutory responsibilities imposed on controllers. Because both parties act as controllers, they each carry full responsibility for ensuring that the processing complies with the NDPA, even if they allocate tasks between themselves.

Legally, joint controllers must ensure that the processing meets all requirements of lawful basis, purpose limitation, data minimisation, transparency, security, rights fulfilment and accountability. Each joint controller remains responsible to data subjects and to the regulator, regardless of any internal arrangement. Both parties must therefore ensure that an adequate lawful basis exists, that privacy notices reflect the joint nature of the processing and that the technical and organisational measures put in place are sufficient for the shared activity. They must also coordinate how they will respond to data subject rights and manage any security incidents, and must be prepared to demonstrate compliance upon request. Where the processing triggers a DPIA, the joint controllers must coordinate the assessment and agree on responsibilities for implementing the resulting safeguards.

On the contracting side, while the NDPA does not prescribe a mandatory written agreement for joint controllers in the same way it does for controller–processor and processor–sub-processor relationships, a documented joint controller arrangement is essential. This agreement should clearly set out each party's responsibilities, including who provides privacy information, who handles rights requests, who manages incident response, who implements and monitors security measures, who conducts DPIAs and who maintains records of processing. It should also address governance expectations, cooperation duties, cost allocation, incident coordination, liability considerations and dispute resolution. The arrangement does not reduce the accountability of either joint controller, but it provides clarity and operational structure for managing compliance.

d) Joint Processor

The NDPA does not expressly define the duties of actors in a joint processor relationship, but the duties that attach to this relationship flow from the obligations imposed on all processors, with the added expectation that the processors must operate in a coordinated and consistent manner. Since the controller remains responsible for determining the purpose and essential means of the processing, joint processors must ensure that their activities strictly comply with the instructions issued by the controller and that their collaboration does not alter the scope or nature of the authorised processing.

Legally, each processor in a joint processor arrangement must maintain all duties imposed on processors under the NDPA, including implementing appropriate technical and organisational measures, protecting confidentiality, supporting the controller in fulfilling data subject rights and ensuring the security, integrity and lawful handling of personal data. They must also ensure that their coordinated activities do not lead to unauthorised decisions about purpose or essential means, as this would shift their role toward controllership. Joint processors must work together in a consistent manner to avoid gaps in security, contradictory operational practices or inconsistencies in rights handling. They must also be prepared to provide the controller with any information needed to demonstrate compliance and to support audits or oversight measures. If any joint processor intends to engage a sub-processor, it must notify the controller and ensure that obligations flow down appropriately.

On the contracting side, while the NDPA does not prescribe a mandatory written agreement specifically for joint processors, a documented joint processing arrangement is necessary to ensure coordinated compliance. This arrangement should identify the processors involved, outline the shared processing activities, clearly define each processor's responsibilities and set out how they will work together to implement the controller's instructions. Key contractual elements should include coordination on technical and organisational measures, alignment on security standards, procedures for responding to rights requests, mutual cooperation on incident management, information-sharing protocols, allocation of responsibilities for maintaining logs or records and mechanisms for resolving inconsistencies or disputes. The arrangement should also address confidentiality obligations, communication channels, liability expectations and escalation procedures for notifying the controller of incidents or operational issues.

4. Conclusion

Understanding data processing relationships is a practical requirement that determines who carries responsibility, who must take specific actions and who bears liability when things go wrong. Whether an organisation acts as a controller, joint controller, processor or sub-processor, its duties flow directly from the NDPA, the GAID and well-established data protection practice. Each role carries its own expectations, and these expectations only become more significant as organisations expand their digital operations, integrate third-party services and engage in increasingly complex data flows.

Accurate role identification, supported by the right contractual arrangements, is therefore central to compliant data governance. Organisations that take the time to define their role in each relationship, document responsibilities and monitor how processing is carried out are better positioned to meet regulatory requirements, respond to incidents and demonstrate accountability. Those that overlook these steps expose themselves to operational gaps, inconsistent practices and regulatory scrutiny.

Importantly, where any actor steps outside its assigned role, it risks assuming unintended legal responsibility. For example, a processor that begins to decide new purposes, reuse data for its own interests or alter the essential elements of the processing moves into the territory of a controller and becomes liable as one. This exposes the actor to full statutory obligations, regulatory enforcement and contractual consequences for acting beyond the authorised scope.

Similarly, a sub-processor that exceeds the authority delegated to it takes on responsibilities it was never meant to carry, including direct liability for unauthorised processing. Equally, joint controllers that start acting independently or unilaterally change aspects of the agreed processing may trigger liability for breaching the shared governance structure. In the same way, processors working jointly who introduce new methods or alter coordinated workflows may shift their role and become accountable for decisions they were not permitted to make.

Likewise, any organisation that fails in its oversight duties remains accountable for the misconduct of the parties it relies on. For example, if a controller does not monitor its processors, ignores warning signs or fails to verify capability, it may be held responsible for breaches that arise, regardless of intention or delegation. Similarly, if a processor fails to supervise its sub-processors, does not confirm their competence or allows them to expand the scope of processing unchecked, the processor remains fully answerable for the resulting non-compliance.

To keep track of the various data processing relationships that an organisation may be involved in and its specific role in each of these relationships, it may be useful to maintain a Data Sharing and Processing Register. This Register serves as a central record of every external party an organisation interacts with when personal data is shared or processed, regardless of whether the organisation is acting as a controller or as a processor. It should indicate whether each external party functions as a controller, joint controller, processor or sub-processor, and link that role to the specific service or activity being carried out.

It should also record the lawful basis or instruction governing the processing, the categories of personal data involved, the location of the processing, any cross-border implications and the existence of the required contractual documentation such as data processing agreements or data sharing arrangements. The Register can form part of the broader Record of Processing Activities, which provides a consolidated view of all processing operations an organisation undertakes.

For organisations that operate as processors, the Register should also note all sub-processors engaged and the scope of their delegated tasks. Maintaining a Data Sharing and Processing Register strengthens accountability, provides a complete map of data flows and offers clear evidence of compliance under the NDPA and GAID.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.