NIS2, DORA, and the GDPR oblige your customers to vet each supplier and service provider, so their supply-chain duties keep arriving as your spreadsheet. The workable response sits on your side: one approved answer set, a recorded origin for every answer, and review aimed where confidence is low.
NIS2, DORA, and the GDPR oblige your customers to vet each supplier and service provider, so their supply-chain duties keep arriving as your spreadsheet. The workable response sits on your side: one approved answer set, a recorded origin for every answer, and review aimed where confidence is low.
Have you ever wondered why the security questionnaires never stop? You answer one thoroughly, and the next arrives anyway: a different customer, a different template, largely the same questions. The reason sits upstream of you. The questionnaire in your inbox exists because your customer's regulator asked first. Directive (EU) 2022/2555 (NIS2) Art. 21(3) requires Member States to ensure that in-scope entities "take into account the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures." If your customer is in NIS2 scope, you're the direct supplier that sentence points at. The chain is short: their regulator demands supplier-specific diligence, a list of questions is the cheapest way to document that diligence, and the list lands in your inbox as a spreadsheet. Multiply that by every customer carrying such a duty and the flow is permanent.
Let's read the three texts that generate the flow. NIS2 binds "essential and important entities" (through national transposition, since it's a directive) to take "appropriate and proportionate technical, operational and organisational measures" for the security of their network and information systems (Art. 21(1)). Art. 21(2) then makes a minimum list mandatory: the measures "shall include at least the following", and point (d) is "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers". The word "each" in Art. 21(3) does real work here. A duty phrased supplier by supplier is hard to discharge with one generic vendor policy, so it gets discharged vendor by vendor, question by question.
For customers in financial services the mechanism is sharper. Regulation (EU) 2022/2554 (DORA) Art. 28(1)(a) says financial entities that contract ICT services "shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations under this Regulation and applicable financial services law". Hiring you doesn't transfer their obligations, which is exactly why they need to see inside your operation. Art. 28(4) lists what must happen before a contract is signed, and point (d) is the sentence that generates the pre-sales questionnaire: financial entities shall "undertake all due diligence on prospective ICT third-party service providers and ensure throughout the selection and assessment processes that the ICT third-party service provider is suitable". Note "throughout": the questions recur after signature. Art. 28(5) adds a gate: "Financial entities may only enter into contractual arrangements with ICT third-party service providers that comply with appropriate information security standards." And under Art. 28(3) they report at least yearly to their competent authority on new ICT contractual arrangements, with the full register available to the authority upon request, so the diligence behind each entry has an audience.
The oldest version of the duty is Regulation (EU) 2016/679 (GDPR) Art. 28(1): a controller "shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject." If you process personal data on a customer's behalf, those "sufficient guarantees" have to be established somehow, and a question list is how controllers collect the demonstration.
None of these texts mentions a spreadsheet. They oblige your customers to assess you and leave the format of the assessment to them. That makes the inbound flow structural: it grows with your customer count and with their regulatory exposure, and it doesn't shrink when you answer well. Answering well is what keeps the contract, and next year's round, alive.
The sender controls the artifact. Their GRC tool's export, their columns, their section headers, their answer scale — yes/no/partial here, free text there. Replying in their format is part of what's being assessed: a vendor who sends back "see our security page" is failing the diligence exercise the customer needs to document. So format standardization isn't available to you as the receiver.
What is available is your side of the table. The question set converges even when the formats never do. Encryption at rest, access reviews, backup cadence, subprocessors, incident notification: by the tenth questionnaire you've answered nearly every question before. The hours don't go into knowing the answers. They go into re-finding what you wrote last quarter, re-litigating phrasing that someone already fought over once, and figuring out whether the answer in the old file was ever signed off by anyone senior enough to own it. Each new questionnaire starts from zero because the previous answers live in sent-mail attachments. The outbox is the institutional memory, and the outbox doesn't compound.
I read this asymmetry as non-negotiable: the sender picks the format, you own only the answers. So the leverage is reuse and provenance, and any process that ignores those two pays full price on every questionnaire.
Four properties fall out of the pain above. All of them are tool-agnostic, so let's define them precisely before we look at any software.
None of this requires particular software. A team can run it on a shared spreadsheet, a naming convention, and discipline. The properties are the takeaway; what follows is one implementation of them, disclosed with its boundaries.
Here's how we implemented the loop at devguard, in the inbound-questionnaires module: upload → parse → match → review → export. (Outbound assessments, the ones you send your own vendors, are a separate module, deliberately kept fully apart from this one.) Upload takes XLSX, CSV, or PDF; the app shows whether a file is still processing, ready for review, or failed, and a failed spreadsheet parse surfaces the detected columns so you can re-map question and answer columns by hand rather than hit a dead end. Each parsed question is matched against your answer library, and every answer carries a visible origin label: matched from your approved library, drafted by the AI, written by hand for this questionnaire, or not yet touched.
Those labels are the previous section's provenance model made concrete, and the axis split holds: the label records where the text came from; a separate reviewer mark records that a human signed off. Attention routing keys off match quality: a semantic match below a high-confidence threshold is flagged for attention, weaker text-similarity matches always are, and the review screen surfaces flagged answers first. Approving an answer, singly or in bulk, promotes it into the library. A corrected answer updates the canonical entry instead of forking it. The first fill can come from history: upload an already-answered questionnaire with the import option and its answers join the library, marked as hand-written and reviewed.
We refused to build two things, and both refusals have costs. First, there's no buyer portal. The module works only for signed-in members of your workspace, with no share link; the export produces a standard XLSX or CSV in a Section/Question/Answer/Status layout, with unapproved drafts excluded by default, and your customer opens it without an account or login. The cost: the module gives you nothing buyer-facing, and sending the file back stays your job. Second, there's no silent AI. The upload–parse–match–review–export loop runs fully without generation; when semantic matching is unavailable, matching falls back to plainer text comparison. AI drafting is a button you press, never a default: it fills only untouched answers, labels everything it writes as AI-drafted with a timestamp, and nothing it drafts counts as approved until a person signs it off. The cost: fewer pre-filled answers on day one, because the compounding comes from approvals rather than from the model.
The test for any answering process, bought or built, is the tenth questionnaire: it should start mostly answered, with review time going to the handful of questions your library has never seen. The four properties — approval that compounds, origin on every answer, attention routed by confidence, a reply as a plain file — are what make that happen; the tooling is secondary. And the table has two sides. The same diligence duties that fill your inbox make you the sender when you contract your own providers. For that seat, start with the close read of the Data Act's switching rights from the buyer's chair.
The module above is devguard's Security Questionnaires, part of devguard.ch/platform.
Angelo runs strategy and the relationships behind devguard. He spends his time with the teams who live with compliance day to day, and keeps what we build tied to what they actually need.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.