Plenty of companies sign an outsourcing contract believing that, with the signature, they also handed off responsibility for the personal data the provider will process. They didn't. Under Colombia's data protection law (Ley 1581 of 2012, the same controller/processor logic behind regimes like the GDPR), outsourcing a process that touches personal data doesn't transfer responsibility: it splits roles. And getting your own role wrong is where most of the legal risk in the operation hides.
One disclaimer first: this is a general framing to understand how the roles work, not legal advice. Every contract should be reviewed with each party's legal team.
Two roles, not one
The law defines two figures worth keeping apart. The controller (responsable del tratamiento) decides why and how the data is processed: the purpose, what is collected, how long it is kept. The processor (encargado del tratamiento) processes that data on the controller's behalf and under its instructions, without deciding the purpose on its own.
In a typical outsourcing arrangement the client is usually the controller —it owns the relationship with the data subject and defines why that data exists— and the BPO provider is usually the processor, handling the data to deliver the contracted service. But there's a point that gets missed: the role isn't defined by the label in the contract, it's defined by who decides. If the provider starts deciding purposes on its own, it acts as a controller even if the paperwork says otherwise.
Why the distinction changes the risk
The difference isn't semantic. Before the data subject and before the authority, the party that answers for the processing at bottom is the controller: it's the one that must hold the authorization, disclose the purpose and attend to claims. The processor answers for its own part —for security failures, for breaching confidentiality or for stepping outside the instructions it received— but it doesn't absorb the controller's responsibility just by signing.
This carries an uncomfortable practical consequence: a client can't "outsource the problem" of data protection. It can delegate operations, but it remains the first to answer to the data subject. Understanding that changes how the contract is negotiated and what gets demanded of the provider.
A processing handover is not a transfer to another controller
Here another common mistake slips in. When the controller hands data to a processor to handle on its behalf, that is a transmission (transmisión): the data moves, but the purpose and control stay with the controller. When the data passes to a different controller that will decide its own purposes, that is a transfer (transferencia), and the rules are different.
The distinction matters because a transmission to a processor, backed by a contract that sets the scope, doesn't by itself require asking the data subject for authorization again for that operation; a transfer to another controller triggers a different analysis. Misclassifying the movement of data is a quiet source of non-compliance.
What the contract should say
When the provider acts as a processor, the relationship is documented with a processing agreement that shouldn't stay in generalities. At a minimum it should set: the scope and the purposes for which the processor may handle the data; the express instruction that it only processes as directed by the controller and not for its own purposes; the security and confidentiality duties; what happens with subcontractors if the processor relies on third parties; how and how quickly a security incident is notified; and what happens to the data when the service ends —returning or deleting it, not keeping it "just in case". These clauses belong to the same discipline you use to define an SLA you can actually meet: if they aren't written, they don't exist on the day you need to enforce them.
The duties that don't get outsourced
Even with a solid contract, some obligations stay on the controller's side and can't be pushed onto the provider. The controller still has to hold the data subject's authorization, disclose why the data is used, maintain its data-processing policy, and be the guarantor that channels exist to handle inquiries and claims. It can lean on the processor to operate those channels, but the obligation that they work is its own.
On the processor's side, the duties are concrete: apply reasonable security measures, keep confidentiality even after the relationship ends, process the data only per instructions, not use it for its own purposes, and help the controller when an inquiry or a claim arrives. Neither party clears itself alone: the model works when each one knows what falls to it.
The mistakes that repeat
The first is labeling the provider a "processor" in the contract and believing that shields the client. The label doesn't erase the controller's responsibility; it only orders the relationship between the parties.
The second is the opposite: a provider that, in practice, starts deciding purposes —reusing data for something the client never asked for— and becomes a de facto controller, with the obligations that implies, without having planned for it.
The third shows up when data crosses borders. If the processing means the information leaves the country, you have to look at where it goes and under what conditions, because an international transfer has its own analysis. In nearshore or multi-country operations this stops being a detail.
All three mistakes share the same root: not having mapped what data enters the process, where it comes from and what it's for before signing. That map is part of what should be ready well before day one, alongside the rest of what's worth documenting before outsourcing a process.
How smartBPO works it
In the processes where we handle our clients' data we act as a processor: we process the information on the controller's behalf and per its instructions, not for our own purposes. That rests on a processing agreement that sets the scope, the security and confidentiality duties, and what happens to the data when the service ends. We don't promise that a contract removes the risk —it doesn't—; what we propose is that the roles be clear from the start, because a model where each party knows whether it's controller or processor is far easier to run and to defend than one you discover on the day of the claim.