Most of the GDPR questions we get on discovery calls come down to one of two things: a procurement manager who has been told to check the compliance boxes before the contract can be signed, and a founder or operations lead who genuinely wants to understand what the rules mean in practice before handing over access to their data.
Both are reasonable. This article is for both. It covers what the regulation actually requires when you use a third-party data service, what a proper data processing agreement looks like, and the questions that reveal whether a vendor understands what they are agreeing to.
The processor relationship
Under the GDPR, if you collect personal data and hand it to a third party to process on your behalf, that third party is a “data processor” and you are the “data controller.” The regulation requires you to have a written contract, a Data Processing Agreement, or DPA, with any processor who handles personal data for you. Article 28 of the GDPR sets out what that contract must include.
This matters for dashboard services because many operational dashboards pull from systems that contain personal data. A sales pipeline dashboard that includes deal contact names, a logistics dashboard that includes driver IDs, an HR utilisation board that includes individual consultant names, all of these involve personal data in the legal sense. If your dashboard service reads those fields, a DPA is required.
Not all dashboards involve personal data. An inventory dashboard that shows stock levels, lead times, and supplier costs contains no personal data at all. An operations board showing throughput, on-time delivery rates, and margin by route does not need a DPA for most of its tiles. The relevant question to ask your vendor is specific: which fields from your systems will you read, and do any of them contain personal data as defined by the GDPR?
The five clauses to check in any DPA
A well-drafted DPA typically runs five to twelve pages. Here are the five clauses that matter most for a dashboard service engagement.
1. Purpose limitation.The DPA should state exactly what the processor is allowed to do with your data, and prohibit anything else. For a dashboard build, the permitted purpose is: read the specified fields, compute and cache the specified metrics, display them to the authorised users. That is all. A DPA that permits “use for service improvement,” “benchmarking,” or “product development” is granting broader rights than a dashboard build requires. Ask for the vague language to be removed or clarified.
2. Sub-processor list and notification.Article 28 requires the processor to obtain your authorisation before engaging sub-processors, the companies they in turn use to run the service. The DPA should include a list of current sub-processors and a mechanism for notifying you before adding new ones. “We will post changes on our website” is weaker than “we will email you 30 days before adding a sub-processor.” The difference matters if a new sub-processor is domiciled in a third country and triggers transfer obligations you have not assessed.
3. Data subject rights assistance.The GDPR gives individuals rights over their personal data, access, erasure, correction, portability. You as the controller are responsible for responding to those requests. If the data involved is held in a third-party system, you need the processor’s cooperation to respond. The DPA should commit the processor to assisting you with data subject rights requests within a defined timeframe. Thirty days is typical. “Best efforts” without a timeframe is not an enforceable commitment.
4. Breach notification. If the processor suffers a security incident involving your data, you need to know promptly, you have a 72-hour window to notify your supervisory authority. The DPA should require the processor to notify you without undue delay after becoming aware of a breach. The practical floor is 24 to 48 hours; anything longer makes your own notification window very tight. Check whether the notification obligation applies to suspected incidents, not just confirmed ones.
5. Deletion and return on termination.When the contract ends, the processor should delete your data and confirm in writing that they have done so, within a defined period. “Upon termination” without a specific deadline is vague. Thirty days with written confirmation is the standard we use. If the processor also provides you with an export of your data before deleting it, note the format and the scope of what is exported, you should not discover limitations in the export for the first time when you need it.
Data residency and third-country transfers
Data residency is not a GDPR requirement. The GDPR does not require personal data to stay inside the EU, it requires that transfers outside the EU happen under one of the approved legal mechanisms. The most common for software vendors are Standard Contractual Clauses, which are template contract terms approved by the European Commission, and adequacy decisions, which declare certain countries to have equivalent data protection standards.
The practical issue is that the adequacy framework has been unstable. The EU-US Privacy Shield was invalidated in 2020 (Schrems II). The replacement framework, the EU-US Data Privacy Framework, has been in effect since 2023 but is already subject to legal challenge. Companies in regulated industries, financial services, healthcare, critical infrastructure, are often required by their own internal policies or sector regulators to use EU-based processing regardless of what the GDPR minimum permits. If your organisation has a data residency policy, read it before evaluating vendors. It may be stricter than the legal baseline.
If you want to avoid transfer complexity entirely, the simplest approach is to choose processors who process exclusively within the EU on infrastructure owned by EU-domiciled entities. This eliminates the need to assess adequacy decisions, validate SCCs, or monitor for framework changes. It is not always available at the price points of hyperscaler-built products. It is available from vendors who have made the deliberate choice to build on European infrastructure.
The questions that reveal whether a vendor knows what they are doing
A vendor who genuinely understands their GDPR obligations can answer these questions specifically, not with boilerplate. If the answers are vague, that is information.
Which personal data fields from our systems will you read? The answer should be specific. “Only the fields required to build the dashboard” is not specific. “Deal owner name and contact first name from HubSpot,” or “none, the fields we pull are all aggregates”, that is specific.
Where is your infrastructure located, and who is the infrastructure provider?The answer should name a country and a company. “EU-based cloud” is not an answer. “Hetzner, Nuremberg, Germany” is.
Who are your current sub-processors?A short list with company names and countries is the right answer. “Our standard third-party providers” is not.
What is your breach notification timeline?If the response is “as required by law” without a specific number of hours, push for a number. Seventy-two hours is the legal window for you to notify the supervisory authority. Your vendor needs to notify you in time for that window to be viable.
Can we see a copy of your standard DPA before signing? Any vendor with proper documentation can produce this within a business day. If it takes a week and three email chains, that tells you something about how they handle compliance in general.
If you would like to go through your procurement questionnaire before the discovery call, send it to us beforehand. We will answer it in writing and you can review it with your legal or compliance team before we speak. Book a call here.
