DPA Data Processing Agreement

Key Takeaways

• A data processing agreement is mandatory under the general data protection regulation (GDPR) since 25 May 2018 whenever a data controller outsources the processing of personal data to a data processor. This requirement applies equally to supply chain transparency tools like ImpactBuying, which handle supplier, worker, and audit information on behalf of client organisations.
• Every DPA must clearly define roles-who is the data controller, who is the data processor-and spell out the data processing activities in scope, the security measures and organizational measures in place, and the rules for international data transfers, including the use of EU standard contractual clauses following the June 2021 updates.
• A robust DPA protects data subjects rights, reduces regulatory exposure under GDPR as well as emerging ESG frameworks (CSRD, CSDDD, EUDR, LkSG), and is critical for retailers, brands, and traders relying on supplier data to map global supply chains. A DPA assures consumers that their personal information is protected by strict privacy standards, and it delineates liability and accountability to protect the data controller from penalties for the processor’s actions.
• In most customer relationships, ImpactBuying acts as a data processor for client data, providing transparency and sustainability analytics under the client’s documented instructions and the agreed governing law.
• The rest of this article walks you through essential DPA clauses, common pitfalls, and practical tips for organisations working with ESG and supply chain platforms.

Introduction: What Is a Data Processing Agreement and Why It Matters in 2026

A data processing agreement is a contract that governs how one party-the data processor-handles personal data on behalf of another party, the data controller. Think of it as the rulebook that ensures every piece of supplier information, every worker complaint record, and every auditor contact detail is handled according to clear, enforceable standards.

Since GDPR enforcement began in 2018, and with the adoption of the Corporate Sustainability Due Diligence Directive (CSDDD) in 2024, Germany’s LkSG already in force, and the EU Deforestation Regulation (EUDR) taking effect, DPAs have become foundational documents for any data-driven sustainability or traceability project. The primary purpose of a DPA is to outline the rights and obligations of both parties regarding personal data protection under GDPR, and a data processing agreement ensures GDPR compliance for data processing across every link in the supply chain.

For platforms like ImpactBuying-which collect and analyse supplier and product information across more than 250,000 mapped supply and product chains-a DPA is the key instrument governing client data, data protection, data transfer, and cooperation in case of incidents. Without it, there is no formal framework for what happens when things go wrong.

Retailers, brands, manufacturers, and traders operating across global supply chains deal with personal data every day: supplier contact details, factory audit reports, worker grievance logs. In 2025 alone, European supervisory authorities issued roughly €1.145 billion in GDPR fines, and missing DPAs accounted for approximately 18% of those penalties. Whether you have a direct business relationship with a single supplier or manage thousands of sourcing partners, getting your DPA right is no longer optional-it is a legal and commercial necessity.

Understanding the Core Roles in a Data Processing Agreement

Correctly defining roles is the legal backbone of every DPA, especially in complex supply chains where multiple actors process overlapping data sets. Data processing agreements must define roles of controller and processor with precision, because getting this wrong can trigger enforcement action or leave gaps in accountability.

A data controller is the entity that determines the purposes and means of data processing. In a typical supply chain scenario, a European retailer sourcing coffee beans from farms in Brazil decides why supplier data, worker information, and audit records are collected-for example, to comply with CSDDD human rights obligations or to verify deforestation-free sourcing under EUDR. The controller bears ultimate responsibility for ensuring that all applicable data protection laws are respected.

A data processor is the service provider that processes personal data strictly according to the controller’s documented instructions and the DPA. A data processor processes data on behalf of the controller and must not repurpose it for independent objectives. When ImpactBuying maps a client’s supply chain, stores supplier contact details, or generates ESG risk scores, it acts as the processor-executing tasks that the client has defined and authorised.

Data subjects in supply chain transparency projects are the natural persons whose information is stored and used. These can include:

• Employees at supplier companies
• Farm workers in producing countries
• Audit team members and consultants
• Contact persons at factories and trading houses
• Individuals filing grievance reports

In some projects, other organisations may also be involved. An NGO conducting on-the-ground verification, or a certification body issuing compliance labels, may act as independent controllers or even as joint controllers. The DPA should clarify exactly where processor responsibilities start and end, so there is no ambiguity when a data subject request arrives or a personal data breach occurs.

If you source cocoa from West Africa through three intermediary traders, each with its own workforce records, your DPA needs to map which party controls which data set-and who the processor is for each.

Mandatory Nature and Legal Basis of a DPA Under GDPR

The GDPR was enacted on April 27, 2016, and has required full compliance since 25 May 2018. Article 28(3) mandates a written (including electronic) data processing agreement whenever a controller engages a processor for data processing activities. Establishing a DPA is a legal requirement under GDPR, not a recommendation.

Both the data controller and data processor can be held liable if processing occurs without a compliant DPA. By mid-2026, supervisory authorities across 33 EU/EEA countries had recorded over 5,576 enforcement actions totalling more than €10.7 billion in GDPR and ePrivacy penalties. Implementing a DPA helps companies comply with GDPR and avoid significant fines-the average fine for SMEs in 2025 was approximately €16,200, while major players faced penalties in the hundreds of millions.

A DPA is also expected under other regional data protection frameworks. The UK GDPR (enforced by the UK Information Commissioner’s Office) maintains equivalent requirements post-Brexit. Brazil’s LGPD, the California Consumer Privacy Act (CCPA), and comparable laws in APAC jurisdictions use similar concepts, even if the exact terminology differs. Additionally, the data protection commission in various EU member states has been increasingly active in scrutinising supply chain data handling.

For ImpactBuying projects, a data protection agreement is concluded alongside the main service agreement. It prevails on data protection matters if there is any conflict with general commercial terms-ensuring that the rules around personal data processed in the platform always take precedence.

Key Components of a Robust Data Processing Agreement

Well-drafted DPAs are structured into clear clauses that map directly to GDPR requirements and operational reality. A DPA must contain specific elements as mandated by GDPR guidelines, covering every stage of the data lifecycle.

The main building blocks that any processing agreement should cover include:

• Subject matter and duration of processing
• Types of personal data and categories of data subjects
• Documented instructions from the controller
• Technical and organizational measures for data security
• Conditions for engaging sub processors
• Procedures for handling data subjects rights
• Rules for data transfers, including international data transfers
• Data breach notification and incident management
• Audit rights and documentation
• Deletion, return of data, and retention periods
• Governing law and jurisdiction

For supply chain transparency solutions-such as mapping more than 250,000 supply and product chains across continents-the DPA must also reflect cross-border data flows between the EU, UK, US, and producer countries in Latin America, Africa, and Asia. The following subsections walk through each core component with actionable guidance for sustainability and procurement teams.

Subject Matter, Scope, and Duration of Data Processing

This clause explains what processing services are provided and how they translate into specific data processing activities. A DPA should detail the subject, duration, nature, and purpose of data processing so that both parties have a shared understanding of what is in scope.

For an ImpactBuying engagement, typical services include supplier onboarding, risk scoring, traceability dashboards, and ESG reporting. Each of these involves distinct personal data undergoing processing-from supplier contact records to audit photographs-and the DPA must link each service to its data processing purpose. Purposes might include compliance with CSRD and CSDDD, monitoring human rights risks, or verifying deforestation-free sourcing under EUDR.

The duration of processing must match the term of the main services agreement. Beyond that, the DPA should specify how long records are retained after contract end-typically to satisfy statutory limitation periods or regulatory reporting obligations. If a retailer needs to keep audit records for five years under CSDDD, the DPA should reflect this.

The scope clause should also make clear that the processor will not use customer personal data for its own independent purposes, such as marketing or unrelated analytics, without a separate legal basis and agreement. This boundary is essential for maintaining trust and avoiding role confusion.

Types of Data and Categories of Data Subjects

The DPA should describe the typical data processed in supply chain transparency projects:

• Supplier contact data: names, email addresses, phone numbers, job titles of supplier employees
• Audit data: names and contact details of audit report signatories, inspection teams
• Worker data: grievance hotline reports, worker survey responses, health and safety incident records
• Traceability data: farm-level GPS coordinates linked to individual farmers or cooperatives

Categories of data subjects commonly include:

• Employees of the retailer or brand (the controller’s own staff)
• Supplier management and factory contacts
• Factory workers and farmers
• Transport operators and logistics personnel
• Consultants involved in ESG assessments

If any special categories of personal data are processed-such as health data from safety incidents, union membership, or data on criminal convictions related to labour violations-the DPA and main agreement must explicitly acknowledge this and require enhanced data security and legal basis checks under Article 9 GDPR.

Documented Instructions and Controller Responsibilities

The data controller defines its instructions through the DPA, implementation documents, and written change requests. Processors must follow documented instructions from controllers at all times and must not process such data beyond what is authorised.

Controllers must comply with data protection laws during processing, which includes determining the legal basis (e.g., legitimate interests, legal obligation under CSDDD or LkSG) and ensuring they inform data subjects through adequate privacy notices. A retailer instructing ImpactBuying to collect factory-level worker data for risk assessments must specify what data is collected, why, and how changes to that instruction are approved and recorded.

The DPA should require the processor to alert the controller if an instruction appears to violate data protection law and to document any such concerns. This safeguard protects both parties-giving the controller a chance to correct course and giving the processor a documented defence if a regulator later asks questions.

Technical and Organizational Measures for Data Protection

Processors must implement appropriate technical measures for data security, aligned with Article 32 GDPR. These measures should consider the risks involved, the state of the art, and the nature of customer personal data being handled. Data protection laws require confidentiality obligations for personnel accessing data, meaning every team member with access to supplier or worker records must be bound by strict confidentiality commitments.

For a platform like ImpactBuying, relevant organizational security measures and technical controls include:

• Encrypted data transfer (TLS 1.2+) and encryption at rest
• Role-based access control for ESG analysts and client teams
• Multi-factor authentication for all platform users
• Secure data processing facilities and data centres located within the European Economic Area
• Regular penetration testing and vulnerability assessments
• Staff training covering both human rights awareness and privacy obligations

ISO 27001 standards are recommended for data protection measures and serve as a strong baseline for demonstrating a processor’s security posture. Rather than hard-coding every control into the main DPA text, it is practical to annex a security schedule-such as ImpactBuying’s information security overview-so that updates can be notified without renegotiating the whole agreement.

Measures to prevent accidental or unlawful destruction, loss, or alteration of personal data should be explicitly documented, along with incident response playbooks aligned with ESG reporting cycles.

Subprocessors and Supply Chain of Services

Sub-processors are engaged by processors to assist in data processing-for example, cloud hosting providers in the EU, helpdesk services, or specialist data verification partners operating in producing countries.

Rules regarding the hiring of subprocessors must secure prior written consent from the data controller. The DPA should require either:

• Specific authorisation: a named list of approved sub processors
• General authorisation: with a clear notification and objection mechanism, typically giving 15–30 days’ notice before a new subprocessor is engaged

Sub-processors require prior authorization in data processing agreements, and sub-processors must comply with the same data protection obligations as the primary processor. The processor must flow down all contractual obligations to each subprocessor via a written contract and remains fully liable for their performance.

For transparency platforms like ImpactBuying, it is important to distinguish between tech infrastructure subprocessors (e.g., a hosting provider) and independent data sources or partners (e.g., a certification body) that may act as separate controllers rather than sub processors.

Data Subjects’ Rights and Processor Assistance

Processors must assist in fulfilling data subject rights requests under GDPR. These rights include access, rectification, erasure, restriction, data portability, and objection-as well as comparable rights under other jurisdictions’ data protection law.

Data subjects can request access to their personal data at any time. Processors must notify controllers of data subject requests promptly, and data subject requests must be handled without undue delay. If a factory worker asks what complaint data has been stored about them, the processor must identify, log, and forward such a request to the controller without adding unnecessary steps.

Controllers are responsible for responding to data subject requests-meaning the processor only responds in its own name when legally required by applicable law. Even then, the processor should, where permissible, promptly inform customer before taking action. Controllers using ImpactBuying should ensure their privacy notices explain how worker and supplier data are processed and provide contact details for rights requests, with the DPA reflecting this allocation of tasks. The processor must provide reasonable assistance to support the controller in meeting these obligations in a timely manner.

Data Breach Notification and Incident Management

Agreements on how to handle data breaches must be included in a DPA. Processors must notify companies of data breaches without undue delay-contractually, this often means within 24 hours of becoming aware of a personal data breach affecting client data.

Data breach notifications are required under GDPR and other laws, and the notification must include relevant information on:

• The nature of the breach
• Categories and approximate number of data subjects and records affected
• Likely consequences of the breach
• Measures taken or proposed to mitigate adverse effects

Data breach notifications must include breach details and consequences so that the controller can act quickly. Companies must document all relevant facts of a data breach for regulatory and internal accountability purposes. The controller is ultimately responsible for notifying the competent supervisory authority within 72 hours and, where required, affected data subjects must be notified of high-risk data breaches.

In high-risk contexts-such as large-scale worker surveys or deforestation risk mapping involving hundreds of suppliers-consider running joint incident simulations and post-incident reviews to test your response readiness.

The DPA should also address cooperation between the processor and other third parties (e.g., forensic investigators or a law enforcement authority) if needed during breach response.

Audit Rights, Documentation, and Transparency

The controller has the right to obtain information about the processor’s data processing activities-including security certificates, policy summaries, and penetration test overviews. Where necessary, the controller may conduct or commission such audit.

A practical approach is to allow remote audits first (questionnaires, document reviews, video calls) and reserve on-site audits for situations justified by risk, with reasonable notice and limits to protect confidentiality of other customers. Processors like ImpactBuying can leverage independent certifications (e.g., ISO 27001, SOC 2 if available) and third-party assessments to demonstrate compliance and reduce the need for frequent inspections.

The DPA should also require the processor to keep records of processing activities (ROPA) under Article 30(2) GDPR. These records can be shared with the controller or supervisory authority upon such a request, supporting the controller’s own obligation to demonstrate compliance with applicable data protection laws.

Deletion, Return of Data, and Retention Periods

Obligations for data deletion or return must be stated in a DPA after the contract ends. Data must be deleted within 10 business days after service cessation, unless longer retention is legally required for regulatory reporting or statutory limitation periods.

The controller should be able to request either:

• Full deletion of all client data from production systems, backups, and archives
• Structured export before deletion-for example, CSV or API extraction in formats that match reporting needs for CSRD or internal ESG dashboards

The processor should commit to delete or anonymise backup copies according to documented retention schedules and provide written confirmation of completion upon such request. Some aggregated, non-personal analytical insights may be retained by the processor, but only if they are fully de-identified and cannot be traced back to individual data subjects or specific clients. The extent permitted for such retention should be clearly documented.

International Data Transfer and EU Standard Contractual Clauses

Many supply chain and sustainability projects necessarily involve cross-border data transfer. When an EU-based company sources from producers in Brazil, Indonesia, or West Africa, personal data transferred between these jurisdictions must meet strict requirements.

Data transfers outside the EU require adequate protection measures. The GDPR regulates personal data transfers outside the EEA, and any such transfer must comply with GDPR Chapter V. The most common mechanism is standard contractual clauses-specifically the EU standard contractual clauses updated in June 2021. These SCCs provide a standardised, legally vetted framework. The data exporter (typically the EU-based controller or processor) and the data importer (the receiving party outside the EEA) enter into the appropriate SCC module:

• Module 2: controller-to-processor transfers
• Module 3: processor-to-processor transfers

Restricted data transfers to third countries that lack adequate protection from national data protection requirements demand additional safeguards. For each such transfer, a Transfer Impact Assessment (TIA) should evaluate the recipient country’s legal framework-particularly regarding government access to data.

ImpactBuying generally prefers EU-based hosting for client data, but DPAs must still address cases where support staff, verification partners, or cloud subprocessors outside the European Economic Area may access limited data for service delivery. For example, a Dutch retailer using an EU-hosted ImpactBuying instance might grant limited access to vetted staff in Kenya for on-the-ground supplier verification. In that case, the DPA specifies the transfer mechanism used for personal data transferred, the scope of access, and the security safeguards-ensuring each such transfer is documented and lawful. The transfer controller remains accountable for verifying that adequate protections are in place.

Data protection laws govern cross-border data transfers comprehensively, and a data protection impact assessment may be needed where high-risk processing is involved, such as large-scale profiling of supplier workforces.

Governing Law, Jurisdiction, and Relationship to ESG Regulations

The DPA should contain a clear governing law clause-for example, the laws of the Netherlands, Germany, or England and Wales-and a jurisdiction clause specifying which courts will resolve disputes that cannot be settled amicably. For ImpactBuying, a Netherlands-based company, Dutch law is the typical default.

However, governing law does not limit the territorial reach of data protection frameworks. GDPR may still apply to data subjects in the EU regardless of where the processor is located, and other local data protection act requirements may apply in producing countries where suppliers operate. The free movement of personal data within the EEA means that intra-EU transfers generally do not face additional restrictions, but transfers outside the EEA trigger the mechanisms discussed above.

DPAs increasingly intersect with sustainability and human rights regulations such as CSRD, CSDDD, EUDR, and LkSG. These frameworks require robust data collection and verification on issues like child labour, forced labour, and deforestation-all of which may involve personal data. ImpactBuying designs its DPAs and service descriptions to support clients’ compliance with these ESG regulations, while keeping the DPA focused on personal data and not turning it into a full ESG contract. The applicable law for data protection and the applicable law for ESG obligations may differ, and the DPA should clarify how conflicts between the two are resolved.

Common Pitfalls and Practical Tips When Negotiating a DPA

Many organisations treat DPAs as mere checkboxes, but small drafting flaws can create significant risks when you process customer personal data from hundreds of suppliers across continents.

Typical pitfalls include:

• Vague descriptions of data processing activities (“all supplier data”) without specifying which data types or data subjects are in scope
• Unclear roles-calling a party a “processor” when it actually makes independent decisions about purposes, making it a controller or joint controller
• Missing details on international data transfers or reliance on outdated pre-2021 SCCs
• Unrealistic security guarantees (“we encrypt everything”) without traceable commitments, periodic review, or supporting documentation
• Not aligning the DPA with actual product functionality or with the organisation’s privacy notice and ESG policies

Practical tips for ImpactBuying-style projects:

• Involve privacy, procurement, and sustainability teams early in DPA negotiations. Data processing is not just a legal issue-it has operational consequences for ESG reporting.
• Maintain a data flow inventory that maps exactly which personal data flow through the platform, where they go, and who has access. This makes DPA annexes accurate rather than aspirational.
• Align DPA annexes with ESG questionnaires and supplier onboarding workflows to ensure that what you collect, process, and report is consistent across documents.
• Review your DPA regularly-every 12 to 24 months-to keep pace with evolving case law, EDPB guidance, new SCCs, and changes in ESG regulations. Long-term supply chain programmes should build DPA reviews into their governance calendar.
• When evaluating service providers, ask for evidence of their data protection requirements: certifications, audit reports, subprocessor lists, and incident response records.

A DPA that doesn’t match the reality of how your platform works is worse than no DPA at all-it creates a false sense of compliance.

How ImpactBuying Typically Positions Itself Under a DPA

In most customer relationships, we act as a data processor (or subprocessor) for client data, processing it solely to provide supply chain mapping, traceability, and ESG analytics processing services described in the main agreement. We do not decide independently what personal data to collect or how to use it-that decision belongs to our clients.

Client organisations-retailers, brands, manufacturers, and traders-are usually the data controllers. They decide what personal data to upload, which suppliers to engage, and which due diligence obligations (e.g., under CSDDD or LkSG) they aim to meet. We implement technical and organizational measures such as secure EU-based hosting, rigorous access management within our processing systems, and staff training on human rights and privacy, all documented in a security annex to the DPA. We continuously work to ensure compliance with data protection requirements across our operations.

We maintain a published list of sub processors-including hosting providers and support partners-and inform customer organisations of any changes. Clients can exercise their right to object where justified by risk, and we provide sufficient notice to allow meaningful review.

Our approach is straightforward: we handle client data under strict contractual obligations, we do not repurpose it, and we cooperate fully if a supervisory authority or a data subject makes a request. When needed, we provide reasonable assistance for any data protection impact assessment or regulatory inquiry, so our clients can focus on building transparent, sustainable supply chains.

FAQ: Data Processing Agreements for Supply Chain Transparency

The following questions address common, practical issues that arise when setting up or reviewing DPAs for supply chain transparency and ESG projects. Answers are written in plain English for both legal and non-legal stakeholders.

Do I need a DPA if I only share business contact details of suppliers?

Yes. Business contact details like supplier employees’ names, emails, and phone numbers are still personal data under GDPR, because they relate to identifiable natural persons. A data processing agreement is required whenever such data are processed by a third-party platform such as ImpactBuying. Even if the perceived risk is low, regulators expect a formal DPA to document responsibilities, security measures, and data subjects’ rights.

How does a DPA interact with our human rights due diligence obligations?

The DPA itself does not create or replace human rights due diligence duties under laws like CSDDD or LkSG. Instead, it underpins the trustworthy data handling needed to demonstrate compliance with those laws. You should align your due diligence policies, supplier codes of conduct, and ESG questionnaires with the DPA’s data protection and data transfer provisions, so there are no conflicts or blind spots between your ESG obligations and your data protection commitments.

Can a platform provider ever be a data controller instead of a processor?

Yes. A platform provider may act as an independent controller for certain processing-such as product improvement analytics or aggregated benchmarking-if it determines its own purposes and means for that processing. In such cases, the parties should document this clearly in a separate section or addendum, and ensure that privacy notices and legal bases reflect the split between controller and processor roles. This prevents confusion when handling a data subject request or a regulatory inquiry.

What happens if our data protection laws change during the contract term?

Modern DPAs usually contain a clause allowing updates where necessary to comply with changes in applicable data protection laws, new EU standard contractual clauses, or guidance from supervisory authorities. Controllers and processors should agree on a practical update mechanism-for example, written notice and a defined review period-so they can adapt without renegotiating the entire commercial agreement. This keeps the DPA current as regulations evolve.

How detailed should the technical and organizational measures be in the DPA?

TOMs should be specific enough to demonstrate a robust security posture-covering encryption, access controls, logging, and training-but maintained in an annex or separate security document that can evolve over time. Ask processors like ImpactBuying for up-to-date security summaries, certifications (such as ISO 27001), and policy overviews to supplement the DPA. This keeps the main contract from becoming overly rigid while still giving you the relevant information needed to implement technical safeguards and verify that your data is protected.