A DPA, or data processing agreement, is the contract GDPR requires between a controller and any processor handling personal data on its behalf. If a vendor touches personal data from your website — hosting, forms, analytics, CRM, marketing automation, a portal identity provider, a translation supplier working on contact lists — you generally need one with them. Whether a particular vendor is a processor, and what the agreement has to contain, is a legal determination for your counsel or data protection officer.
For an industrial manufacturer the list is usually longer than expected, because it follows the integrations rather than the marketing stack. Every connection built between the site and the ERP, PIM, CRM or distributor portal is a candidate, and so is every vendor a country subsidiary engaged independently. The practical starting point is a current inventory rather than a template contract.
Under GDPR the organisation deciding why and how personal data is processed is the controller; a party processing it on the controller’s instructions is a processor. The agreement records the subject matter, duration, nature and purpose of the processing, the categories of data and data subjects, and the processor’s obligations on security, sub-processors, assistance and deletion.
Some vendors act as controllers in their own right for part of what they do, which changes the instrument required. That classification belongs with your counsel.
Start from the data flow rather than the supplier list. Follow each form on the site to its destination, then follow each destination onwards: an RFQ form to the CRM, the CRM to marketing automation, the portal to its identity provider, the site to its host and backup location, the tags to their platforms.
Add whatever a country subsidiary engaged locally. Our website integrations page describes how those connections are documented during a build.
Datasheet and CAD download gates that email a link, chat widgets, webinar and trade fair registration platforms, distributor and installer portals using an external identity provider, e-signature tools used for account applications, and translation vendors handling customer lists alongside product copy.
Each was introduced for a reason and few were reviewed together. At the start, a vendor inventory recording who owns each relationship and where the data sits is worth more than the contracts themselves.
Beyond the required clauses, the terms worth reading closely are the sub-processor list and how changes to it are notified, security measures described in specifics rather than adjectives, breach notification timing, assistance with data subject requests, audit rights, the processing locations, and what happens to the data when the relationship ends.
Return or secure deletion at termination, with written confirmation, is the clause most often found missing during a later review.
A website’s personal data sits in more places than the production database: staging environments, backups, log files, error monitoring, and any export a team took for a campaign. An agreement covering the host should reflect the backup locations and retention as they are configured rather than as they were quoted.
Our managed hosting page sets out how those locations and retention periods are recorded.
We sign a processing agreement where we handle personal data on your behalf as part of an engagement, and we build to the handling requirements your data protection officer specifies. We can produce the data flow map, the tag and vendor inventory and the technical documentation a review needs.
The decision on which agreements are required, and on their terms, is for your legal team. See GDPR and consent for the technical side of that work.
A data processing agreement is the contract GDPR requires between a controller and a processor handling personal data on its behalf. You generally need one with any vendor touching personal data from your site: hosting, forms, analytics, CRM, marketing automation, a portal identity provider. Whether a specific vendor is a processor is a determination for your counsel or data protection officer.
For every vendor processing personal data on your behalf, which is a shorter list than the full supplier list. A tool that never receives personal data usually falls outside it, and some vendors act as controllers for part of what they do, which changes the instrument required. Build the list from the data flows and have counsel confirm it.
Follow each form on the site to its destination, then follow the destinations onwards: the RFQ form to the CRM, the CRM to marketing automation, the portal to its identity provider, the site to its host and backup location. Then add whatever a country subsidiary engaged locally, which is where most of the surprises appear.
The sub-processor list and how changes are notified, security measures described in specifics rather than adjectives, breach notification timing, assistance with data subject requests, audit rights, processing locations, and what happens at termination. Return or secure deletion with written confirmation is the clause most often found missing during a later review.
Yes, where we handle personal data on your behalf as part of an engagement, signing a processing agreement is a standard part of onboarding. It sets out how data is handled, secured, and returned or deleted when the work ends. Your legal team should review the terms against your own requirements before signing rather than accepting a template unchanged.
An agreement on its own does not settle that. Transfers outside the EEA rely on separate mechanisms, and the requirements differ by destination and data type. See does industrial B2B website data have to stay in the EU for how that question is approached, then confirm the position with your counsel.
Tell us which systems your site connects to and we will produce the flow map and vendor inventory your legal review needs.