If your SaaS imports personal data, list its sources. The 2026 GDPR transparency check asks your customers.

Say you sell a sourcing tool to recruitment agencies in Brandenburg. This year the state's data protection authority sent those agencies a questionnaire about how they inform people about their personal data, and for data an agency did not collect from the person, GDPR Article 14 makes it tell each candidate what kinds of data it holds and where they came from 2. Thousands of the agency's candidate profiles came in through your tool. If you cannot tell the agency what your tool pulled in, from where, and who else received it, the agency's answer to its regulator reads "imported through our sourcing vendor", and your product is now named in a regulator's file.

That questionnaire is part of a check that 25 European data protection authorities started in March 2026, coordinated by the European Data Protection Board (EDPB), the body where those authorities work together 1. The authorities are now comparing the answers, and the combined results are expected at the start of 2027, so customers who were asked may still be fixing their notices. Of the fourteen authorities that had said how they take part by 7 October 2026, none named software companies as a target. I read all fourteen statements, and my conclusion is that a software company meets this check through a customer's email, if its product brings in data about people that the customer did not collect from those people.

Why would a regulator's questions reach a software vendor?

Because the questions are about data the customer often cannot describe without you.

A recruitment agency that finds a candidate through a CV database, a referral or a public profile must tell that candidate which categories of data it holds and where they came from. It has one month at the latest, and less if it contacts the candidate or sends the CV to an employer first 2. The Slovenian authority picked employment agencies that pass candidate data to many employers, which is the case where that deadline is shortest. A marketing team that buys contact details, or uses a tool that adds job titles and phone numbers to its list, owes the same notice to every person on it.

To answer, the agency has to know what its sourcing tool pulls in, from where, and which other companies receive it. Often only the vendor that built the tool knows. That the questionnaire will travel to vendors this way is my reading; no authority has said so.

A vendor can also be asked directly in two cases. If it builds its own database of people, compiling profiles or contact data for its own purposes and selling access to them, it is a controller of that data and owes the Article 14 notice to every person in the database itself 2. And Slovakia, which picked healthcare providers, says it may also question their processors.

Which organisations are being checked?

Ten of the fourteen authorities that have published a statement say who they are checking:

Italy's sectors "include" the public sector, insurance and financial services, health and research, utilities and marketing, so its list is open-ended. The other fifteen participants have not said whom they contact.

Software is not named as a sector anywhere. A software company could still be in one of the samples defined only by country or size (Lower Saxony, Malta, Spain and Luxembourg), or in Italy's marketing sector if it sells marketing data itself. Answers can lead further: the EDPB says authorities may follow up after gathering facts 1, Italy announced "targeted follow-up", and some authorities take part through formal investigations, which can end in orders or fines.

What will the answers be measured against?

Three requirements decide whether a customer's answer holds up, and each depends on facts a vendor holds or on how a vendor writes:

• Complete. Every item GDPR lists for the notice, including who receives the data, how long it is kept and, for data obtained from someone else, its source 2.
• On time. For data obtained from someone else, the notice is due one month after obtaining the data at the latest, and earlier if the data is used to contact the person (at first contact) or passed to another company (at first disclosure) 2 3.
• No hedging. The EDPB-endorsed transparency guidelines say words such as "may", "might", "some", "often" and "possible" should be avoided, and an organisation that uses them should be able to show why it could not avoid them 3. Ulf counted how often generated privacy policies use them in what to check in a generated privacy policy.

The questionnaire itself has not been published, so these three come from the law and the guidelines.

What should you have ready?

If your product brings in data about people that your customers did not collect from those people, write these answers down before a customer asks. Most of them already exist in documents you keep:

• Data categories. Every kind of personal data your product imports about those people. Start from your data model or your import field mappings.
• Sources. Where each kind comes from. Start from your integrations list.
• Recipients. Every other company the data reaches. Start from your published sub-processor list, with the country each is in.
• Retention. What your product deletes, when, and what it keeps. Start from the deletion clause in your DPA.
• Plain wording. Write the answers without "may" or "some", because your customer will copy them into its notice.

If you build your own database of people, also check whether you have ever told the people in it that you hold their data and where you got it. If you have not, that is your own Article 14 gap.

Lawcel, the product we make, reads your pull requests and tickets and flags the changes that alter what your privacy policy or DPA has to say. The changes that make your privacy policy out of date are the same ones that make this list out of date.