Answer a GDPR questionnaire before it binds you

A buyer's GDPR questionnaire reads like a security form, but its answers feed the contract that governs how you process the buyer's personal data. Under the EU's General Data Protection Regulation (GDPR), a buyer acting as controller may use only a processor that provides sufficient assurances of appropriate technical and organisational measures, and the questionnaire is how it checks yours. Answer each recurring question from one owned, dated evidence set, mapped to the contract term it will become, and ensure every promise you sign has proof behind it.

Where a GDPR questionnaire breaks between your teams

Most GDPR supplier questionnaires look familiar, so it is easy to route them like any other security questionnaire. They break when answers drafted from separate inputs by security, legal and the data protection officer (DPO) turn into contract terms with no current evidence behind them.

Say a buyer renewing your hosted payroll service sends its data protection questionnaire as a spreadsheet. You split it three ways. Security answers the measures questions by citing the group's ISO 27001 certificate. Legal answers the breach-notice question with wording taken from another buyer's agreement. The DPO describes processing locations from the privacy notice, and the subprocessor tab copies the list sent at the last renewal.

Each answer reads well on its own. Together they commit you to a certificate scope, a notice period, a set of locations and a list of subprocessors that nobody has checked against the service as it runs today. Once the buyer's legal team carries those answers into the contract, the gap is yours, and as bid manager you answer for what the response promised.

Under the European Data Protection Board's Opinion 22/2024 on processors, contract clauses alone cannot show that the assurances behind them are actually in place.

Sort each question by the contract term it feeds

Before anyone drafts, tag each question with the term of the data processing agreement it will feed, because that term decides who approves the answer. The data processing agreement (DPA) is the binding contract Article 28 of the GDPR requires between the buyer and you as processor. It sets out the subject-matter, duration, nature and purpose of the processing, the types of personal data, and the buyer's rights and obligations. The questions a GDPR supplier questionnaire keeps asking map onto its terms.

An answer that commits you to act - notifying, deleting, authorising, opening your systems to audit - goes to legal before it goes to the buyer. Each one is a promise the buyer can write into the agreement.

Questions that ask more than the service needs

Answer for the service in the bid, and say plainly where a question reaches beyond what it processes. Under the EDPB's opinion, how far a buyer verifies depends on the technical and organisational measures involved, which follow from the risk of the processing. A scoped answer therefore fits what the buyer has to check. If a question asks about data the service never receives, state that it does not process that data, describe what it does process and offer the evidence that covers it. Ticking "yes" to keep the form clean is riskier, because that yes can become a term.

Describe the data and where it is processed

Describe the personal data and every processing location as the service actually runs, because the DPA binds you to process only on the buyer's documented instructions, including transfers to a third country. An answer that lists fewer locations than you use sets instructions the service already breaks.

In the payroll example, the privacy notice named the hosting region but not where support staff open records or where backups sit. Build the answer from the service instead, listing the categories of personal data and of people it covers, the systems that hold it, and each place it is stored or accessed from. Where any of that sits in a third country, say so and point to the transfer terms the buyer will instruct, rather than leaving the buyer to find it later.

The same description feeds the buyer's data protection impact assessment, its own assessment of what the processing risks for the people whose data it is. The GDPR requires the processor to assist the buyer with that assessment, among other obligations. So give detail the buyer can work from, not a summary of your privacy notice.

Answer security questions within the certificate's scope

A certificate or report answers only for what it covers. Check that the service in the bid sits inside it before you cite it, and answer any gap in writing.

What an ISO 27001 certificate covers

Certification to ISO/IEC 27001 requires an organisation to define the scope of its information security management system, as the National Standards Authority of Ireland sets out. Read the scope statement before citing the certificate, and check that it covers the service, the systems and the teams that handle the buyer's data. In the payroll example, a group certificate scoped to hosting operations answers the infrastructure questions and leaves the application's access controls to a written answer.

What a SOC 2 report covers

A SOC 2 examination can address security, availability, processing integrity, confidentiality and privacy, according to the AICPA, and the report states which are in scope. Check those areas and the system the report describes. A security-only report does not address privacy criteria, so the privacy questions still need their own answers.

Call neither a GDPR certification. Cite each for what it covers, then write the answers it leaves open so they hold up under the buyer's review.

Name every subprocessor and keep the list current

Under the GDPR, a processor may not engage another processor without the buyer's prior specific or general written authorisation. Every subprocessor you list is one you are asking the buyer to authorise, so the list has to be complete when you send it.

The EDPB's opinion goes further. It expects the processor to provide, without being asked, the name, address and contact person of every subprocessor, with a description of the processing each carries out, and to keep that information up to date at all times. That makes the list a maintained piece of evidence rather than a tab you copy forward.

Give it one owner and have them update it whenever a provider is added, changes what it processes or moves where it processes. In the payroll example, the copied tab missed a support provider added since the last renewal, and you remain liable for that provider's performance. Publishing the list once can save repeat answers, provided its owner keeps it current, which is the trade-off behind whether a published trust centre can stand in for a questionnaire.

Promise the breach notice the contract fixes

The GDPR requires a processor to notify the buyer without undue delay after becoming aware of a personal data breach, and it sets no number of hours. Any hour figure in the questionnaire comes from the buyer's DPA, or from the one it wants you to sign.

That changes how you answer. Describe the process you actually run, naming how an incident is detected, who decides whether personal data is affected, who notifies the buyer and through which channel. A buyer can judge that against its own needs. A bare "yes" to a stated window tells it nothing about how you would meet it, and it commits you to a period your incident process may not be built for.

In the payroll example, legal's borrowed wording promised another buyer's window. If a questionnaire asks you to commit to hours your standard DPA does not set, answer with the commitment you have and flag the request to legal as a contract point.

Keep one evidence set current across buyers

The buyer's duty to use processors with sufficient assurances is continuous, and under the EDPB's opinion it should verify them again at appropriate intervals. That is why the same questions come back at renewal and periodic review, and why the evidence behind them has to stay current between rounds.

Answer every GDPR questionnaire from one evidence set kept for each service. It holds the data and location description, the ISO 27001 certificate and SOC 2 report with their scope, the subprocessor list, the breach-notice procedure, the deletion and return procedure, and your standard DPA. Give each item an owner, a review date and the DPA term it feeds, so a change to one shows which answers it touches.

Reuse then means taking the facts from the set and adapting only the wording to each buyer's format, whether a spreadsheet, a portal form or a Word document. Reusing answers across formats works only while the item behind them is in date. An answer copied from the last buyer's file carries its age with it.

How SEQUESTO runs a GDPR questionnaire

In SEQUESTO's agentic operating system (aOS), the payroll questionnaire stays in the buyer's own spreadsheet. Agent Force, the specialist agents in aOS, parses it into a question list, and James, who orchestrates the work, drafts each answer from the Knowledge Hub. Every evidence item there keeps its owner, review cycle and expiry date, and expired material, including an expired subprocessor list, is flagged before it reaches a draft.

Security, legal and the DPO now draw on one set of sources rather than three. Each answer cites the policy document and clause it comes from, with the source snippet beside it, and the SOC 2 report can be attached to the answers it supports. Where the Knowledge Hub holds nothing that fits, a low confidence score shows the gap before anyone fills it with a promise.

Each question can carry its own reviewer and approver, so the breach-notice, subprocessor and deletion answers go to legal while the measures answers go to security. The team sees what James drafted and accepts, adjusts or rejects it. The bid manager signs off before export, which keeps the spreadsheet's original structure for a person on the team to submit.

When a policy is updated, the system flags every answer drawn from it for review, and each answer retains the policy version it came from. Every action is logged with actor, timestamp and item, so at the buyer's next review the team can show which evidence stood behind each answer and who approved it.

Checklist for every GDPR questionnaire

Run these tests before the bid manager signs off.

• Every question is tagged with the DPA term it feeds and the person who approves it.
• Questions beyond the service are answered for what the service processes, with the reason stated.
• The data categories and processing locations match the service as it runs, including support and backup access.
• Any transfer to a third country points to the buyer's transfer terms.
• Every certificate or report cited covers the service in the bid, and each gap has a written answer.
• The subprocessor list gives each one's name, address, contact person and processing, and its owner has confirmed it is current.
• The breach-notice answer matches the DPA you will sign and names who notifies the buyer.
• Every evidence item has an owner and a review date that has not passed.
• Legal has approved every answer that commits you to act.