Data processor

A processor handles personal data on behalf of a controller. The controller sets the purpose and essential boundaries; the processor provides a service and follows the controller’s instructions. Processing can include storing, organising, analysing, transmitting, deleting or otherwise handling the information.

A supplier is not automatically a processor merely because it receives data. Banks, professional advisers, regulators or delivery partners may use information for purposes they determine independently. They may be separate controllers for those activities. Role-mapping must be done service by service.

Typical processor services include cloud hosting, outsourced payroll, bulk email delivery, managed IT support, document destruction and customer-support platforms. A processor may use a subprocessor to deliver part of the service. That chain matters because the information may be stored or accessed in additional locations.

Employees acting within their employer’s authority are generally part of the controller or processor organisation rather than separate processors. The focus is the legal person providing the external service.

Controllers and processors can have different direct legal duties, but both affect real-world risk. A controller cannot outsource responsibility for choosing a suitable provider. A processor should be able to show that it follows instructions, protects the data, supports the controller and reports incidents promptly enough for the controller to meet legal deadlines.

A charity sends employee information to an external payroll company. The charity decides why salaries are processed, whose details are included and how long records are needed. The payroll company calculates pay under the charity’s instructions and is likely a processor for that activity. If it uses the employee records to market unrelated financial products, that new use cannot be justified merely as payroll processing.

Instructions and independent decisions

Processors can make practical technical decisions—such as choosing routine security tools—without necessarily becoming controllers. The distinction becomes important when the supplier decides a new purpose of its own, combines the entrusted data into its own product, or uses it beyond the agreed service. At that point it may be acting as a controller for the additional use.

A written agreement should describe the service, permitted processing, confidentiality, security, incident handling, deletion or return, audit support and any subprocessor conditions required in the relevant jurisdiction. A contract is not enough by itself: the controller should also conduct proportionate due diligence and monitor the service.

Maintain a supplier and subprocessor register. Record the services, data categories, locations, instructions, security evidence, incident contacts, transfer implications and deletion arrangements. Review the relationship when the service or supplier’s own data uses change.

Related terms: controller; subprocessor; processing; data-processing agreement; cross-border transfer; security measures