DPA and Sub-Processor Management for Offshore Vendors (Article 28)

If an offshore vendor processes personal data on your behalf, UK and EU GDPR require a written data processing agreement (DPA) that meets Article 28, and that DPA must control how the vendor uses sub-processors. The DPA is the contract that turns "we take security seriously" into enforceable obligations: processing only on your instructions, confidentiality, security measures, sub-processor controls, help with data-subject rights, deletion or return at the end, and audit support. Sub-processor management is the part people most often get wrong, because an unmanaged sub-processor can quietly undermine every other commitment in the agreement.

This guide explains what Article 28 requires, the sections a strong DPA should cover (described, not pasted as a template), how sub-processor management works in practice, and how a fully-managed model reduces the chain you have to govern.

When do you need a DPA at all?

A DPA is required whenever a processor handles personal data on a controller's behalf. The roles drive everything:

• Controller: decides the purposes and means of processing. Usually your company.
• Processor: processes personal data on the controller's documented instructions. Usually the offshore vendor that employs the people doing the work.

Where you are the controller and the vendor is your processor, Article 28 makes a written contract mandatory, with specified terms. This is distinct from the international transfer mechanism: sending or giving access to personal data abroad also needs the UK IDTA or the EU SCCs and a transfer risk assessment. You need both the Article 28 DPA and a transfer tool. We cover the transfer side in our GDPR guide for hiring offshore developers and the formal cross-border assessment in our transfer impact assessment guide.

What Article 28 requires, in plain terms

Article 28 lists the obligations a processor contract must impose. In plain terms, the processor must:

• Process personal data only on the controller's documented instructions, including for transfers.
• Ensure people authorised to process the data are under a duty of confidentiality.
• Take appropriate technical and organisational security measures (the Article 32 standard).
• Respect the conditions for engaging sub-processors (authorisation and flow-down).
• Assist the controller in responding to data-subject rights requests.
• Assist with security, breach notification, impact assessments and consultation duties.
• Delete or return the data at the end of the engagement, and delete existing copies unless retention is required by law.
• Make available the information needed to demonstrate compliance and allow and contribute to audits.

A DPA is, in effect, the document that writes these obligations down and makes them binding. Anything weaker than this leaves you exposed as controller, because your accountability does not disappear just because a vendor is doing the processing.

The sections a strong DPA should cover

You should not paste a generic template and hope it fits; a DPA needs to reflect your actual processing. But it helps to know the structure a good offshore DPA generally contains, so you can check a vendor's draft against it. The typical building blocks:

• Definitions and roles. Who is controller and who is processor, with the GDPR terms defined.
• Subject matter and details of processing. Often an annex setting out the nature and purpose of processing, the types of personal data, the categories of data subjects, and the duration. This annex is doing real work, not boilerplate.
• Processor obligations. The Article 28 duties above, written as binding commitments.
• Security measures. A description (frequently a schedule) of the technical and organisational measures, mapped to Article 32.
• Sub-processor terms. Authorisation model, notice of changes, the right to object, and flow-down obligations (covered in detail below).
• International transfers. Which mechanism applies (IDTA or SCCs plus Addendum) and how transfers are handled, plus residency commitments where relevant.
• Data-subject rights assistance. How the processor helps you respond within time limits.
• Breach notification. Timescales and content of notifications to you.
• Audit and information rights. How you can verify compliance, including reliance on third-party certifications where appropriate.
• Deletion or return. What happens to data at the end, and evidence of deletion.
• Liability and indemnities. How responsibility is allocated between the parties.

Describing the structure is the safe way to use this: it gives you a checklist for reviewing a real DPA, while the actual drafting should be done or reviewed by a qualified adviser against your facts.

Sub-processor management: the part that bites

This is where offshore arrangements most often go wrong, so it deserves its own section. A sub-processor is anyone the vendor brings in to process the data on its behalf: cloud infrastructure, support tooling, an affiliated entity, a specialist subcontractor. Article 28 requires three things.

1. Authorisation. The processor needs your authorisation to use sub-processors. This is either specific (you approve each one) or general (you approve a list, and the processor must notify you of intended changes and give you a chance to object).

2. Flow-down. Each sub-processor must be bound by the same data-protection obligations as the processor, through a back-to-back contract. The protections cannot dilute as the chain lengthens.

3. Continuing liability. The original processor remains fully liable to you for its sub-processors' performance. A sub-processor's failure is the processor's responsibility towards you.

In practice, a well-run vendor maintains a current sub-processor list, flows the obligations down, and notifies you of changes with a right to object. The risk to watch for offshore is silent chaining: a vendor that quietly routes data through a sub-processor in another region (for backups, logging or support) can break a residency promise or create an unassessed transfer without anyone noticing. This is exactly why the sub-processor clauses, and the discipline to keep the list current, matter so much. Our data residency guide for offshore teams covers how an uncontrolled sub-processor can undermine where your data is supposed to live.

Sub-processor control	What good looks like	Why it matters
Authorisation model	Documented list, specific or general with notice	Stops unapproved parties touching data
Notice of changes	Advance notice with a right to object	Lets you assess before data moves
Flow-down terms	Same obligations imposed back-to-back	Protections do not dilute down the chain
Sub-processor list	Kept current and available to you	Visibility of the whole processing chain
Continuing liability	Vendor liable for its sub-processors	Single point of accountability to you

How a managed model simplifies the whole picture

A managed model does not remove your obligations as controller, but it shortens and simplifies the chain you have to govern, which is where most of the practical risk lives.

In a fully-managed model the provider employs the people doing the work directly. That matters for sub-processor management specifically: the individuals processing your data are the provider's employees, not a string of independent subcontractors, so confidentiality and security obligations flow down as employment terms rather than as another layer of sub-processor contracts you have to track. Fewer independent parties in the chain means fewer places for protections to dilute and fewer transfers to assess.

OSCABE structures offshore work as controller-to-processor under one UK contract: a DPA meeting Article 28, an appropriate transfer mechanism, a maintained sub-processor list with flow-down and notice, and ISO 9001:2015-certified processes, with a single accountable counterparty standing behind it all. Because OSCABE employs the professionals and vets each one through a five-stage process, the people inside the DPA are screened and bound directly, and you are not left stitching together obligations across many vendors. See our managed teams page, our how it works overview, and our legal page for the contractual framework.

A DPA and sub-processor checklist

• Confirm the roles: you as controller, vendor as processor.
• Require a DPA that covers every Article 28 obligation.
• Check the processing annex actually describes your data and purposes.
• Pin down the security-measures schedule against Article 32.
• Set the sub-processor authorisation model, with notice and a right to object.
• Require flow-down terms and a current, available sub-processor list.
• Add the transfer mechanism and any residency commitments.
• Fix breach-notification timescales and audit rights.
• Define deletion or return, with evidence, at the end.

Frequently asked questions

Is a DPA the same thing as the international transfer agreement?

No, they are separate. A DPA satisfies the Article 28 processor-contract requirement, while the IDTA or the EU SCCs (plus the UK Addendum) provides the lawful basis to transfer or give access to personal data abroad. For an offshore vendor you generally need both, alongside a transfer risk assessment, according to current UK and EU guidance.

Can a processor change its sub-processors whenever it likes?

Not under a properly drafted DPA. With a general authorisation, the processor must give you advance notice of intended additions or replacements and a chance to object; with specific authorisation it needs your approval each time. Either way the new sub-processor must be bound by the same obligations and the processor stays liable for it.

What should I check before signing an offshore vendor's DPA?

Confirm it covers all the Article 28 duties, that the processing annex matches your real data and purposes, that the security schedule is concrete, that the sub-processor terms include notice and flow-down with a current list, and that the transfer mechanism and breach timescales are specified. Then have a qualified adviser review it against your facts before signing.

How does a managed model reduce sub-processor risk?

Because the provider employs the people doing the work, the core processing happens inside one organisation rather than across many independent subcontractors, so there are fewer sub-processors to authorise, fewer flow-downs to track and fewer transfers to assess. You keep your controller obligations, but the chain you have to govern is shorter and sits behind a single accountable counterparty.

General information, not legal advice

This article gives general information about DPAs, GDPR Article 28 and sub-processor management for offshore vendors as at the date of publication. It is not legal advice and does not create a professional relationship, and the section descriptions above are not a template. DPA outcomes depend on your specific processing and facts; in most cases you should have a DPA drafted or reviewed by a qualified data protection adviser, and rely on current ICO and EU guidance, which can change over time.

Ready to engage an offshore vendor with the DPA done properly?

OSCABE provides dedicated, fully-managed teams from India and the Middle East under one UK contract, with a controller-to-processor DPA, Article 28 processor terms, managed sub-processors and an appropriate transfer mechanism built in. We carry the contractual plumbing so you can focus on delivery. Explore our managed teams, browse our engineers to start matching candidates, or contact us to review your DPA and sub-processor setup.