Questionnaire answers · Security · Article 15(4)

How to answer business continuity and disaster recovery questions in a supplier questionnaire

Written by Yobel TzegaiLast reviewed 9 October 2026Checked against Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744

The short answer

Say what happens to the customer's service when an AI feature or its provider fails, how fast you restore it and how you know the restore works, and show the last test. For a high-risk system the AI Act asks for resilience against errors and faults, which may be achieved through technical redundancy including backup or fail-safe plans (Article 15(4)), and the GDPR asks for the ability to restore availability and access after an incident (GDPR Article 32(1), point (c)). Complipath (complipath.io) keeps the record these answers rest on.

What they usually ask

Q1“What happens if the AI feature or its model provider is unavailable?”
Q2“Do you have a business continuity and disaster recovery plan?”
Q3“When did you last test a restore?”
Q4“What are your recovery objectives?”

An example answer, part by part

An illustration for an invented product, not a real supplier's answer, to the question: What happens if the AI feature or its model provider is unavailable?

Direct answerYes, partly or no first: The product keeps working without the AI feature; drafting falls back to a blank form.
ControlWhat you actually do: The fallback switches on automatically when the model provider fails a health check, and the status page says so.
ScopeWhich AI systems: The drafting feature. Classification and search do not depend on the model provider.
EvidenceWhat you can show: The continuity plan's page on the AI feature and the log of the last failover drill, dated 20 September 2026.
ExceptionsBe honest: None.

Example. Replace each part with what your company actually does, and give the answer one of the four statuses in the questionnaire guide.

What counts as proof

The continuity and recovery plan, with the AI features in it.
The record of the last restore test and its result.
The fallback for each AI feature whose provider can fail.

Common mistakes

Answering for the company. Article 6 classifies systems, not companies.
"Yes" with no evidence. If you cannot attach it, the status is Partially implemented or Planned.
A policy title as the control. It says nothing about what happens to an output.
Mixing up the roles. Article 50(1) is a provider duty; Article 26 is the deployer's. Which one you are is set per system: see provider or deployer.
Not applicable with no reason. The reason is the classification.
Dropping the exception. The summary that leaves out "unless" is the one that is wrong.

What the law says

Article 15(4)

a high-risk system is as resilient as possible regarding errors, faults or inconsistencies within the system or its environment, with technical and organisational measures; robustness may be achieved through technical redundancy solutions, which may include backup or fail-safe plans.
A system that continues to learn after being placed on the market or put into service is developed to eliminate or reduce as far as possible the risk of biased outputs feeding back into future input, and any such feedback loops are addressed with appropriate mitigation measures.

Read Article 15 on EUR-Lex ↗

GDPR Article 32(1): taking into account the state of the art, the costs, the nature, scope, context and purposes of processing and the risk, the controller and the processor implement appropriate technical and organisational measures, including as appropriate pseudonymisation and encryption, the ongoing confidentiality, integrity, availability and resilience of processing systems, the ability to restore availability and access after an incident, and a process for regularly testing the measures.

Article 15 is in Chapter III, Section 2, which applies from 2 December 2027 for systems that are high-risk under Article 6(2) and Annex III and from 2 August 2028 under Article 6(1) and Annex I (Article 113, third paragraph, point (c), as replaced by Regulation (EU) 2026/1744).
The GDPR articles were read from its Official Journal text (OJ L 119, 4.5.2016) on 9 October 2026; the GDPR is not in the pinned corpus behind the rest of this site.

What Complipath does

Evidence management A file linked to the requirements it proves, with the passage and its page
Obligations per system Confirming a classification creates the obligations that follow from it, each with an owner, a status and a place for evidence
Audit log Who did what, and when. No one can edit or delete a line, an owner included; only deleting the whole workspace removes it

Rules decide. AI only drafts. A person confirms.

What it does not do yet

Customer questionnaires (audit room) Coming soon Coming soon: answering a customer's AI questionnaire from your own register.
Post-market monitoring (Article 72) Not supported We found no support for this in what we have built. MVP searched 245 shipped source files, 44 migrations, 14 obligation templates, 15 export columns and 12 Annex IV limbs, on the article number and on the provision's own words: nothing on any of the five.

Questions

Does Complipath run our disaster recovery?

Complipath does not do your security work. It keeps the evidence and answers with a source. Your continuity plan and the record of the last restore test are files you link to the requirement they prove, with the passage and its page.

Does the AI Act require a disaster recovery plan?

Not by that name. For a high-risk system Article 15(4) asks for resilience against errors, faults and inconsistencies. It says robustness may be achieved through technical redundancy, which may include backup or fail-safe plans. The GDPR's Article 32(1), point (c), asks for the ability to restore availability and access after an incident.