Category: Controller & Processor Roles
Third-Party Processor
Also known as: Third-Party Payment Processor, TPPP
Simply put
A third-party processor is an outside service that helps a business accept and handle payments, such as card and online transactions, without the business needing its own individual merchant account. It sits between the customer, the business, and the banking system to move payments through. In this payments context, the term refers to a commercial payment-handling role rather than a data protection role.
Formal definition
A third-party payment processor (TPPP) is a merchant service provider that aggregates and processes payment transactions on behalf of businesses, originating transactions for consumers or businesses and facilitating card and online payments without requiring the business to hold an individual merchant account. Typical offerings include point-of-sale (POS) systems, card readers, and mobile payment acceptance tools. Note: the evidence provided describes 'third-party processor' exclusively in the payments/merchant-services sense; it does not address the GDPR concept of a 'processor' under Article 28, and readers should not conflate this commercial payments role with the data protection role of a processor acting on behalf of a controller.
Why it matters
The term "third-party processor" carries a significant risk of confusion in privacy and compliance work because it names a commercial payments role that sounds nearly identical to the data protection concept of a "processor." In the payments context described here, a third-party payment processor is a merchant service provider that helps a business accept card and online payments without holding its own individual merchant account. This is a financial-services and merchant-services function, not a defined role under the GDPR, and treating the two as interchangeable can lead to material errors in contracts, records, and risk assessments.
For teams building compliance programs, precision here matters practically. A payment processor may, depending on the facts, also act as a processor or as an independent or joint controller for data protection purposes, but that characterisation must be assessed separately against the applicable data protection framework and is not established simply by the commercial "third-party processor" label. The evidence provided describes this term exclusively in the payments and merchant-services sense; it does not address the GDPR concept of a processor or any related contractual instrument. Readers should therefore confirm the data protection role of any payment provider on its own facts rather than inferring it from the payments terminology.
Who it's relevant to
Compliance and data protection officers
Those maintaining records and vendor inventories need to avoid conflating the commercial 'third-party processor' payments role with the data protection role of a processor. The commercial label does not, by itself, establish a party's data protection classification; that should be assessed separately against the applicable framework on the specific facts.
Businesses accepting card and online payments
Merchants and retailers use third-party payment processors to accept card and online transactions without holding an individual merchant account, typically relying on POS systems, card readers, and mobile payment tools. They should treat the data protection characterisation of any such provider as a distinct question requiring its own assessment.
Procurement and contract teams
Teams negotiating with payment providers should recognise that the payments 'third-party processor' terminology in this evidence does not describe or govern data protection obligations. Any data protection contractual requirements should be identified and addressed separately, based on how the provider actually handles personal data.
Inside Third-Party Processor
Processor role (Article 4)
A third-party processor is a natural or legal person, public authority, agency, or other body that processes personal data on behalf of a controller. The processor acts on the controller's documented instructions rather than determining the purposes and means of processing itself; where it does determine purposes and means, it would generally be treated as a controller instead.
Data Processing Agreement (Article 28)
Engaging a processor requires a contract or other legal act binding the processor to the controller. Under Article 28 this instrument typically sets out the subject matter, duration, nature and purpose of processing, the type of personal data and categories of data subjects, and the obligations and rights of the controller.
Documented instructions
A processor generally processes personal data only on the controller's documented instructions, including as regards transfers, unless required to do otherwise by EU or member state law. This is a defining feature distinguishing a processor from a controller.
Security and confidentiality obligations
The processor is typically required to implement appropriate technical and organisational measures and to ensure that persons authorised to process the data are bound by confidentiality. The precise measures are subject to a risk-based assessment rather than a fixed checklist.
Sub-processing (further processors)
A processor generally may not engage another processor (a sub-processor) without prior specific or general written authorisation of the controller, and must flow down equivalent data protection obligations to any sub-processor it appoints.
Assistance and cooperation duties
The processor typically assists the controller in meeting obligations such as responding to data subject rights requests and, where relevant, supporting security, breach notification, and impact assessment processes, and makes available information needed to demonstrate compliance.
Return or deletion and audit
At the end of the provision of services the processor typically returns or deletes the personal data as directed by the controller, and generally submits to audits or inspections in accordance with the terms agreed. Specific arrangements are set by the contract and can vary.
Common questions
Answers to the questions practitioners most commonly ask about Third-Party Processor.
Is a third-party processor the same as a controller, since both handle personal data?
No. A processor processes personal data on behalf of, and on the documented instructions of, the controller, whereas the controller determines the purposes and means of the processing. A third-party processor generally does not decide why or how personal data is processed for its own purposes. If a processor begins determining purposes and means, it may be treated as a controller (or joint controller) for that processing and take on the corresponding obligations. The distinction turns on the actual decision-making in practice, not merely on how the parties label themselves in a contract.
Does engaging a third-party processor transfer the controller's compliance responsibility to that processor?
No. Engaging a processor does not discharge the controller of its own accountability. Under the GDPR the controller remains responsible for ensuring the processing complies with its obligations, and Article 28 requires that a processor be engaged only where it provides sufficient guarantees to implement appropriate technical and organisational measures. The processor has its own direct statutory obligations as well, but this is generally additional to, rather than a substitute for, the controller's responsibilities. Allocation of liability between the parties should be assessed on the facts and the governing contract.
What must the written contract with a third-party processor contain?
Article 28 requires a written contract (or other legal act) binding the processor to the controller. It typically sets out the subject matter, duration, nature and purpose of the processing, the type of personal data and categories of data subjects, and the obligations and rights of the controller. It generally must include stipulations that the processor acts only on documented instructions, ensures persons authorised to process are under confidentiality obligations, implements appropriate security measures, respects conditions for engaging sub-processors, assists the controller with data subject rights and with security and breach obligations, deletes or returns data at the end of the service, and makes available information to demonstrate compliance and allow audits. You should verify the precise required terms against the current text of Article 28.
Can a third-party processor engage its own sub-processors?
Generally a processor may engage another processor (a sub-processor) only with the controller's prior authorisation, which may be specific or general. Where general authorisation is given, the processor typically must inform the controller of intended changes to add or replace sub-processors so the controller has the opportunity to object. The same data protection obligations imposed on the processor should be imposed on the sub-processor, usually by contract, and the initial processor generally remains liable to the controller for a sub-processor's failure to meet its obligations. The exact mechanics should be reflected in the processing agreement.
How should a controller assess whether a prospective processor offers sufficient guarantees before engaging it?
Article 28 requires that a controller use only processors providing sufficient guarantees to implement appropriate technical and organisational measures so that processing meets GDPR requirements and protects data subjects' rights. In practice this typically involves due diligence on the processor's security measures, governance, staff confidentiality arrangements, sub-processor practices, breach handling, and ability to assist with data subject rights. Adherence to an approved code of conduct or certification may be used as an element to help demonstrate sufficient guarantees, though such mechanisms are subject to availability and ongoing developments. The depth of assessment is generally risk-based and should be documented.
What extra considerations apply when a third-party processor is located outside the EU or processes data abroad?
Where using a processor involves a transfer of personal data to a third country, a valid transfer mechanism is generally required in addition to the Article 28 contract, since the processing agreement itself does not by default legitimise the transfer. Transfer tools such as an adequacy decision, standard contractual clauses, or other recognised mechanisms may be relevant depending on the circumstances, and supplementary measures may need to be assessed. Because adequacy decisions, transfer tools, and related guidance evolve over time, the position should be verified against the current framework rather than treated as fixed.
Common misconceptions
A processor and a controller are broadly interchangeable, and either label can be applied for convenience.
The roles are distinct. A controller determines the purposes and means of processing, while a processor acts on the controller's instructions. The classification follows the factual reality of who decides purposes and means, not the label chosen in a contract; a party that goes beyond instructions and determines purposes and means may be treated as a controller with corresponding obligations.
A Data Processing Agreement under Article 28 is the same thing as, or substitutes for, a Data Protection Impact Assessment.
These are different instruments. An Article 28 agreement governs the controller-to-processor relationship, whereas a Data Protection Impact Assessment under Article 35 is an assessment of risks to individuals for certain higher-risk processing. Having one does not discharge the obligation, where applicable, to conduct the other.
A processor can freely appoint sub-processors as it sees fit.
A processor generally requires prior authorisation from the controller before engaging a sub-processor and must impose equivalent data protection obligations on that sub-processor. The permitted approach depends on what the controller has authorised and on the terms of the processing agreement.
Best practices
Confirm the factual role of each party before drafting: assess who determines the purposes and means of processing to determine whether an entity is genuinely acting as a processor rather than a controller or joint controller.
Put in place a written processing agreement that addresses the elements set out in Article 28, including subject matter, duration, nature and purpose, types of data and categories of data subjects, and the parties' respective obligations.
Specify documented instructions clearly and record any changes, so that the scope of authorised processing (including any transfers) is unambiguous and auditable.
Establish sub-processor controls, including a defined authorisation mechanism and a requirement that equivalent obligations flow down to any appointed sub-processor.
Define practical arrangements for assisting with data subject requests, security, breach handling, and audits, and set clear terms for return or deletion of data at the end of the engagement.
Where processing may involve transfers outside the relevant jurisdiction or special category data, verify the applicable transfer mechanism and any additional Article 9 condition separately, and review these against the current official text and guidance as they can evolve.