How to Answer an EU Enterprise Security Questionnaire: AI SaaS Vendor Guide (2026 edition)

Key Takeaways

• A security questionnaire is really two questions in disguise: can you actually protect the buyer's data, and can they prove to their own bosses they picked a safe supplier? GDPR Article 28 makes them ask. Your job is to make it easy to say yes.
• More "yes" answers don't win the deal. An honest answer, scoped to the exact product they're buying and backed by proof you can point to, beats a wall of confident-sounding claims every time.
• Two small details trip up most vendors: a data breach means telling your customer fast ("without undue delay" under GDPR Article 33(2)), which is not the same as their own 72-hour clock with regulators. And never wave away an AI feature as "low risk". Say what it does and what role you play under the EU AI Act.
• Be specific about where you stand: is a control live today, half-built, planned, or simply not relevant? A promise on a roadmap is not a control you have. And make sure your questionnaire, contract, privacy notice and sub-processor list all tell the same story.

Intro

An EU enterprise security questionnaire is a buyer’s assessment of whether a supplier can protect data, maintain service availability and meet regulatory and contractual expectations. Depending on the buyer and sector, it may also be described as a vendor security assessment, supplier due-diligence questionnaire or GDPR processor assessment.

For an AI SaaS vendor, the form usually combines information-security, privacy, business-continuity and AI-governance questions. The strongest response is not the one with the most “yes” answers. It is accurate, scoped to the service being purchased and supported by current evidence.

Why EU buyers send vendor questionnaires

Under GDPR Article 28, a controller using a processor must select a provider offering sufficient guarantees for appropriate technical and organisational measures. The European Data Protection Board has said controllers should be able to verify those guarantees and maintain information about processors and sub-processors. Buyers may also apply supply-chain requirements under sector-specific rules, internal policies, NIS2-related risk programmes or, for financial-sector customers, DORA ICT third-party risk requirements.

A questionnaire is therefore testing:

1. whether the SaaS service has appropriate controls; and
2. whether the buyer can document a reasonable procurement decision.

A certification can help, but it does not answer every question about a specific product, data flow or contract. ENISA guidance similarly treats certifications and provider-assessment reports as only part of supplier assurance, alongside lifecycle monitoring, SLA review, incident review and periodic reassessment.

What buyers ask and what each question is really testing

These are representative examples. Answer the exact wording in the buyer’s form.

Example buyer question	What the buyer is testing	What a useful answer contains
“Will you process personal data on our behalf, and in what GDPR role?”	Whether the processing and contractual roles are understood.	Data categories, data subjects, purposes, processing operations, vendor role and any separate controller activities.
“Where is customer data stored, accessed and backed up?”	Data residency, remote access and international-transfer exposure.	Production and backup regions, support-access locations, transfer mechanism and configuration options.
“List all sub-processors that may access or process customer data.”	Supply-chain visibility and change control.	Legal entity, service and processing function, processing and access locations, data categories involved, applicable transfer mechanism, authorisation or change-notification procedure, and relevant onward-transfer safeguards.
“Is data encrypted in transit and at rest? How are keys managed?”	Whether encryption covers relevant systems and key access is controlled.	Control description, scope, key-management responsibility, rotation and exceptions.
“Do you enforce MFA and least-privilege access for privileged users?”	Protection against account compromise and excessive internal access.	Systems covered, identity provider, privileged-access process, access reviews and break-glass controls.
“Describe your secure development and vulnerability-management process.”	Whether weaknesses are prevented, found and remediated.	Code review, dependency scanning, testing, severity method, remediation targets and recent independent testing.
“What notification timelines apply to security incidents and personal-data breaches?”	Detection, escalation and ability to meet a contractual deadline.	Separate incident and breach timelines, notification triggers, processor-to-controller notification without undue delay, supportable contractual deadlines, phased updates and escalation contacts.
“What are your recovery time objectives and recovery point objectives?”	Whether continuity claims are measurable and tested.	RTO, RPO, backup frequency, restore testing, dependencies and latest exercise date.
“Is customer data used to train or improve AI models?”	Secondary use, confidentiality, role allocation and transparency.	A clear yes/no by data type, opt-in or opt-out rules, retention and third-party model-provider access.
“What is your role under the EU AI Act, and how have you classified the AI system?”	Whether the vendor understands its AI Act role and the regulatory status of the service.	The vendor’s role, intended and excluded uses, high-risk classification basis, and any applicable transparency or GPAI obligations.
“What evaluation, performance monitoring, known limitations and human-oversight measures apply to the AI system?”	Whether the buyer can assess operational and AI-related risk.	Intended purpose, supported and unsupported uses, evaluation methods and metrics, known limitations, monitoring arrangements, human oversight where applicable, and escalation routes.

Two distinctions often prevent incorrect answers. Under GDPR Article 33(2), a processor must notify the controller without undue delay after becoming aware of a personal-data breach. The controller’s separate supervisory-authority deadline is, where feasible, 72 hours after awareness, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. For AI systems, avoid describing the system simply as “low risk.” State the vendor’s AI Act role, define the intended purpose and specific conditions of use, and explain whether the system falls within Article 6 and the relevant high-risk categories. Record any assumptions or excluded use cases on which the classification depends.

How to write defensible answers

Scope every answer

State which product, deployment model and environment the answer covers. “MFA is enabled” is incomplete if it applies to employees but not customer administrators, or to production but not support tooling.

Separate fact, commitment and roadmap

Use clear status labels:

• Implemented: operating now, with evidence.
• Partially implemented: limited scope or a compensating control exists.
• Planned: approved work with an owner and realistic date.
• Not applicable: explain why it does not apply.

A roadmap item is not a current control.

Point to evidence

Where attachments are allowed, reference the document and section. Replace “we follow industry best practices” with a control description, owner, review cadence and evidence date.

Avoid unsupported absolutes

Claims such as “fully GDPR compliant,” “no data leaves the EU” or “all incidents are reported within 24 hours” create risk if broader than the actual process. Qualify answers and route contractual commitments through legal review.

Keep documents consistent

The questionnaire, DPA, privacy notice, sub-processor list, security overview and sales materials should describe the same service. Buyers follow up when locations, retention periods, model providers or incident deadlines conflict.

Document checklist for an AI SaaS vendor

Prepare a reusable due-diligence folder containing:

• service and security architecture overview;
• technical and organisational measures;
• data-flow map and GDPR role statement;
• DPA with processing details;
• current sub-processor list, locations and functions;
• international-transfer mechanism, such as an adequacy basis or SCCs where applicable;
• access-control, encryption, logging and vulnerability-management summaries;
• incident-response and personal-data-breach process;
• business-continuity and disaster-recovery plan with tested RTO/RPO;
• retention, deletion and customer-offboarding procedure;
• secure development lifecycle and recent penetration-test summary;
• AI intended-purpose, training-data-use and model-provider statements;
• AI evaluation, limitations and human-oversight documentation; and
• relevant certifications or assurance reports, including scope and validity period.

The European Commission publishes separate SCC resources for controller-processor terms in the EU/EEA and international transfers; confirm which instrument is relevant before referring to “the SCCs.”

Do not send highly sensitive materials automatically. Offer a summary first and use an NDA, controlled portal or supervised review for full penetration-test reports, detailed diagrams or confidential audit evidence.

A practical response timeline

For a substantial questionnaire where baseline documents exist, use this planning model rather than treating it as a market benchmark:

Day 0: confirm deadline, product scope, buyer entity and intended use.
Days 1–2: triage questions and assign security, privacy, engineering, product/AI and legal owners.
Days 2–4: collect evidence and identify contradictions or missing controls.
Days 4–6: draft answers and record assumptions, exceptions and open items.
Days 6–7: conduct technical, privacy and contractual review.
Day 8: submit a clean version, evidence index and named follow-up contact.

Add time where the buyer requests contract changes, a transfer assessment, a new control, detailed AI documentation or access to confidential reports. A rushed same-day response can create more delay if claims are inconsistent or unsupported.

Frequently asked questions

Do SaaS vendors need ISO/IEC 27001 certification or a SOC 2 Type II report to pass?

Not always. Some buyers require ISO/IEC 27001 certification, a current SOC 2 Type II report, or another specified form of independent assurance as a hard gate. Others accept documented controls, independent testing and a remediation plan. Confirm whether it is a hard gate or evidence of a broader control objective.

What should we answer when a requested control is missing?

Answer “no” or “partially implemented,” describe the risk, identify any compensating control and give a remediation date only when the work is approved. Concealing a gap is usually more damaging than documenting it.

Is a GDPR vendor assessment the same as a security questionnaire?

No. They overlap, but GDPR due diligence focuses on processing roles, instructions, sub-processors, data-subject support, retention, breaches and international transfers. Security questionnaires also cover access control, development, vulnerability management, resilience and operational security.

Final review before submission

Confirm that every answer is scoped to the purchased service, accurate as of a stated date, evidence-based, consistent with the DPA and public documents, reviewed by the responsible owner, and clear about gaps or future work.

When the review has progressed into contract redlines, liability positions or an AI addendum, consider the TrustReady.eu enterprise deal defense solution as a related due-diligence and buyer-response support option.