Answering an ICT supplier questionnaire: evidence that a reviewer can trace

Source → Verification → Decision → Evidence

A financial customer sends an ICT questionnaire. Sales wants a quick response. Security has policy documents, operations has service records and legal has the contract. Several questions look familiar, so someone copies an older answer. That answer may describe another service, an earlier configuration or an assurance that the company cannot currently demonstrate. The risk enters when a convenient draft becomes a customer commitment without an owner checking its basis.

Choose one service and one historical questionnaire for a bounded pilot. The deliverable is a reviewed answer packet with evidence, scope, unresolved issues and approval for the exact customer response. AI can help locate and summarise documents. It should not independently decide contractual acceptance, claim regulatory compliance or submit the questionnaire. The workflow in this guide is Brillnet's recommendation for operating control, with legal context supported by the sources below.

Identify the entity, service and customer relationship

Record which legal entity supplies the service, which service configuration the questionnaire concerns and which customer receives the answer. A group policy does not automatically prove that every subsidiary implements the same measure. A shared platform can also have different controls or dependencies for different offerings.

Ask the service owner to confirm the boundary. Include the relevant environment, delivery model and subcontractor chain at the level necessary for the questions. Keep commercial restrictions visible. A public security statement, a confidential report and an internal operational log have different disclosure permissions even when they concern the same control.

DORA applies to specified financial entities subject to its scope and exceptions. A financial entity using ICT services remains responsible for its obligations. An ICT supplier does not become a financial entity merely because it serves a bank. Customer contracts and the oversight framework for designated critical providers have their own context. Determine the role before describing a document as DORA evidence. [1]

Classify the question before retrieving an answer

Questions can ask for a policy, an implemented control, an operating result or a future commitment. These require different evidence. A policy says what the organisation intends or requires. A dated test record can show how a control operated in a particular case. A promise to implement a feature next quarter needs authority to make that commitment.

Label the question type in the packet. If the wording is ambiguous, draft a clarification rather than selecting the easiest interpretation. “Do you encrypt data?” may concern stored data, transmitted data, backups or specific key-management arrangements. A single “yes” can conceal several unresolved questions about the actual service.

Use the customer's exact question identifier. A stable identifier makes it possible to connect corrections and later follow-up requests to the original answer. Preserve the question text and version. A model-generated paraphrase should not replace the authoritative wording the customer will evaluate.

Match claims to evidence of the right strength

For each proposed answer, list the supporting source, date, service scope and owner. Record the precise statement that the source supports. Do not attach a long report and assume every sentence in the answer is covered. A reviewer needs a short path from a claim to the relevant evidence.

A recent vulnerability scan does not establish the absence of every vulnerability. A successful restore exercise for one system does not demonstrate the recovery capability of an unrelated service. A certificate can support its stated scope and validity, but it should not be expanded into a claim about entities or services outside that scope.

When the evidence is absent or stale, say so in the draft. The owner can obtain a current record, narrow the answer or explain the limitation to the customer. Inventing a control to avoid an empty field turns an information problem into a possible contractual problem.

The table is a recommended design. You can add these fields to an existing response system rather than maintaining another spreadsheet that drifts from the approved record.

Distinguish readiness from a demonstrated result

A configured control may be ready for use without having a current operating test. Record that distinction when the question asks for effectiveness. “Backup configured” and “restore verified on the stated date” answer different questions. If the organisation has no current verification, the packet should preserve that limitation.

An illustrative case is a supplier with a written recovery procedure and a restore exercise for a test environment. The draft must not claim that the production service met a specific recovery objective unless the evidence supports that statement. The service owner can explain the exercise boundary and the next planned verification, where disclosure is authorised.

Avoid a global compliance badge based on questionnaire completion. DORA Article 28 addresses ICT third-party risk management, including relevant assessment and information-register context; Article 30 addresses key contractual provisions. A completed answer packet is one part of the customer's evaluation, not proof that every applicable requirement has been met. [1]

Decide which response creates a commitment

A factual description of an existing control differs from accepting an additional customer requirement. Mark requested commitments for the authorised commercial or legal owner. An assistant should not accept an audit right, change a service level, promise a location of processing or agree to a notification term merely because the questionnaire expects a short answer.

Tie approval to the exact response and evidence package. If a reviewer approves a version and someone later adds a stronger assurance, the earlier approval does not cover the new wording. Keep the changed text visible and send it back to the appropriate owner before submission.

For services supporting a critical or important function, assess the additional requirements that apply to the actual relationship. The importance of the function is not determined simply by whether the service contains AI. Ask what depends on the service and use the relevant contractual and legal assessment. [1]

Control retrieval and disclosure separately

Internal access to evidence does not automatically authorise sharing it with a customer. The tool can draft a response from a restricted source while the owner decides what may leave the organisation. For some evidence, an approved summary or redacted extract is more appropriate than the complete underlying document.

Give the drafting integration read access to a curated service evidence set and write access to a draft location. Keep external submission outside the initial permissions. A supplier or customer attachment containing instructions to send files should not override those controls. Test that source content cannot widen the permitted recipients or retrieve another service's restricted evidence.

GDPR requirements still apply where staff names, contact data, logs or other personal information enter the packet. Determine purpose, legal basis, processor arrangements, access and security for that data flow. Commercial sensitivity and personal-data protection can overlap; neither is resolved by placing the packet in a general shared folder. [2]

Keep legal context attached to the right question

NIS2 can cover particular ICT activities and entities, with national implementation and other scope conditions affecting applicability. For financial entities, DORA's position as sector-specific Union law is relevant to the relationship between frameworks. A questionnaire should identify the activity and role rather than assuming every recipient or supplier follows one identical regime. [3]

The AI Act distinguishes uses and roles. A documentation assistant has a different intended purpose from creditworthiness assessment or certain insurance risk and pricing uses involving natural persons. Do not classify every financial chatbot as high risk solely by sector, and do not expand this pilot into those decisions without a separate assessment. [4]

Where the questionnaire requires a legal interpretation, assign it to the authorised reviewer. The assistant can organise the relevant source and question. It should not silently turn a broad legal summary into a binding assurance about the supplier's exact obligations.

Test known weak answers before expanding the system

Create a reference set from a previously reviewed questionnaire. Include an answer based on a stale policy, one relying on evidence from another service, one requiring clarification and one asking for a new commitment. The expected output should include unresolved statuses as well as supported answers.

Count unsupported claims, scope mismatches, wrong dates and disclosure mistakes separately. Measure how much rewriting the owners perform. An answer that sounds professional but requires complete factual reconstruction adds work. Compare the full review effort with the existing process, using questions of similar difficulty.

Include an unavailable evidence repository and an attempted cross-service read. The draft should remain unresolved when a necessary source cannot be checked. A network error should not produce a confident answer from an older cached document without clearly stating its status.

Preserve a response that can be reconstructed later

Keep the submitted answer version, approved evidence set, owners' decisions and submission outcome. Read back the customer portal's saved response when the channel permits it. A successful API call or uploaded file alone may not demonstrate that the customer received the intended final version. Record uncertain outcomes without automatically submitting again.

When a control changes, identify affected answers and customer relationships. Correcting an internal evidence record does not update an answer already sent externally. The responsible owner decides whether communication or contractual follow-up is needed. Keep that decision connected to the original question and commitment.

Pulsar GRC is being developed in early access to organise customer documents, requirements, controls, risks, actions and evidence. Confirm the available scope for the proposed response packet. CrewShift or Zmianowo is being developed for document-based training and tests with human approval; it can be considered for reviewed changes to the internal response procedure. Neither product replaces the entity's legal decision or guarantees compliance.

Bring one anonymised questionnaire, the service boundary and several accepted evidence records to an implementation discussion. The first deliverable should let a reviewer explain every customer-facing claim and identify every unresolved question. That is a measurable basis for deciding whether further automation is justified.

Review an answer that combines supported and unsupported claims

A fictional questionnaire asks whether a service has a tested recovery process. The evidence set contains a current written procedure and a dated test for another environment. The draft says that the production service meets the customer's requested recovery objective. That response combines documents that exist with a conclusion they do not demonstrate. The reviewer should examine the exact claim rather than accepting the presence of attachments as sufficient support.

Split the draft into its factual statements and requested commitments. The procedure can support a description of the documented method within its scope. The test can support the result for the environment actually tested. Neither automatically supports a production performance claim or acceptance of a new contractual target. Show the limitation and assign the unresolved statement to the authorised service owner.

The owner can obtain suitable evidence, narrow the answer or ask the customer to clarify the intended requirement. If the response mentions a future test, keep it within an approved commitment and its actual status. A planned test should not appear as an operating result. The assistant must not choose an attractive completion date merely because the customer form expects a short response.

Before approving the packet, check the permitted disclosure of each source. A report may contain another customer's information or internal details irrelevant to the question. The approved response can need a summary or an extract instead of the complete file. Retain the owner's decision about the exact content and recipient so staff can reconstruct what the approval covered.

After submission, preserve the response version and the saved customer-facing result where the channel supports readback. If the portal shows a different answer or the operation has an uncertain outcome, leave that state visible for follow-up. Do not repeatedly submit the packet merely to obtain a success message. A duplicate can create conflicting versions for the customer and additional review work.

Use the case in the pilot's reference set. Check whether the draft distinguishes evidence scope, planned activity and a new commitment. Measure the owner's effort to correct it and record the unresolved question until it has an approved outcome. These are Brillnet's operating recommendations. They do not establish that a response packet fulfils every DORA requirement or that one test demonstrates the resilience of the entire service.

Sources

The sources support the identified legal facts, guidance and public product scope. Workflows, fictional examples and evaluation measures are Brillnet's operating recommendations. Source review: 2026-10-04.

1. European Parliament and Council — DORA, particularly Articles 28 and 30: https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng
2. European Parliament and Council — GDPR: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02016R0679-20160504
3. European Parliament and Council — NIS2 Directive: https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng
4. European Commission — AI Act questions and answers: https://digital-strategy.ec.europa.eu/en/faqs/ai-act-questions-answers
5. Pulsar GRC — public product scope and early-access status: https://pulsar-grc.com/en/
6. CrewShift / Zmianowo — training, tests and the meaning of a completion record: https://crewshift-app.com/en