Security questionnaires and RFPs

The problem

Every enterprise deal arrives with a spreadsheet: 300 questions about your encryption, your retention policy, your sub-processors, your uptime, your incident process. You have answered all of them before, in slightly different words, in a different spreadsheet, for a different customer.

What it costs today:

• A week of an engineer's life per deal, and it is always the engineer you can least afford to lose for a week.
• Deals that slip. The questionnaire sits in someone's inbox for ten days because nobody has a clear run at it.
• Drift. Three people answer the same question three different ways across three deals, and one of those answers is now out of date.

What good looks like

A first draft of every answer, grounded in your actual documentation, with a citation — plus an explicit list of the questions nobody should let an AI answer alone. The engineer's week becomes an afternoon of review.

What you build

Data sources:  security policy, DPA, architecture docs, previous questionnaires
Skill:         "Questionnaire answering" — house style + what needs escalation

Task ("Acme security questionnaire")   attachment: questions.csv
      │
      ▼
 [Parse Questions]  Node.js → array of { id, section, question }
      │
      ▼
 [For Each question]
      │
      ├──▶ [Search Knowledgebase]     retrieve supporting passages
      │
      └──▶ [Draft Answer]  Smart Agent → structured output
                           { answer, confidence, sources, needsHuman }
      │
      ▼
 [Build Workbook]  → xlsx with answers + sources + review flags
      │
      ▼
 [Publish File]

Pieces used: Data sources, a Skill, a Task trigger, Each, Search in Knowledgebase, a Smart Agent, JSON to Excel, Publish File.

Implementation

1. Index what you already answered

The quality of this build is decided before you write a single step. Connect data sources for:

• the security policy and DPA
• architecture and infrastructure documentation
• previous completed questionnaires — the single highest-value source, because it contains answers already vetted by your own legal and security people

Nothing else in this build matters as much as that last one.

2. Write the house style as a Skill

Create a Skill rather than stuffing this into a prompt.

Description — this is what the agent uses to decide when to open it, so make it a trigger condition:

Use when answering a security questionnaire, vendor assessment or RFP item —
house answer style, evidence rules and what must be escalated to a human.

Instructions — the playbook you would hand a new hire:

Answer in the customer's own vocabulary, not ours. Two to four sentences.
State what we do, not what the industry does.

Never claim a certification, control or commitment that is not in the
retrieved sources. If the sources do not support an answer, say so and set
needsHuman.

Always escalate rather than answer: anything about liability, indemnity,
contractual commitments, penetration test results, or a control we are
in the middle of implementing.

A skill costs the agent only a one-line header until it opens it, so several can be enabled at once — the house style, plus a separate one for, say, healthcare-specific questionnaires.

3. Parse the questionnaire

Take the spreadsheet as a task attachment, and turn it into an array with an Execute Node.js step returning _context: { questions: [...] }.

Normalise here: strip numbering, keep the section heading with each question (a question means something different under "Encryption" than under "Sub-processors"), and drop the instruction rows that questionnaires are full of.

4. Retrieve, then answer

Inside an Each loop over questions:

Search in Knowledgebase — retrieve against {{loop.item.question}}, with the source-saving option on so the citations survive.

Smart Agent — with Skills set to the questionnaire skill, and this task prompt:

Section: {{loop.item.section}}
Question: {{loop.item.question}}

Supporting material:
{{kb.response}}

Draft our answer.

Structured output:

{
  "type": "object",
  "properties": {
    "answer":     { "type": "string" },
    "confidence": { "type": "string", "enum": ["high", "medium", "low"] },
    "sources":    { "type": "array", "items": { "type": "string" } },
    "needsHuman": { "type": "boolean" },
    "reason":     { "type": "string" }
  },
  "required": ["answer", "confidence", "needsHuman"]
}

needsHuman is the field that makes this build acceptable to a security team. It is not a confidence score dressed up — the skill defines specific categories that must always be escalated regardless of how confident the model feels.

5. Accumulate and ship

Create an array variable with Define Variable before the loop and grow it inside with Add Item to Array — remember that a step's own output holds only the last iteration.

After the loop, JSON to Excel produces the workbook with columns for the answer, confidence, sources and the review flag, and Publish File attaches it to the task.

Optionally add a Track Event inside the loop with confidence and needsHuman as dimensions, so you can see over time which sections of your documentation keep coming back weak.

What happens at run time

Sales files the questionnaire as a task. The run works through it question by question — the trace shows each retrieval and each drafted answer, so a reviewer can check why an answer says what it says.

The task finishes with a workbook where the escalated rows are already marked. The engineer reviews those first, spot-checks the high-confidence ones, and sends it back the same day.

What you get

• A complete first draft, grounded in your own documents rather than the model's memory of the industry.
• Citations per answer, so review is verification instead of rewriting.
• An explicit escalation list — the questions a human was always going to have to answer, separated from the 250 that were mechanical.
• A drift signal: the sections that repeatedly come back low-confidence are the documentation gaps you should fix once.

Extensions

Feed the answers back in. Once a questionnaire is signed off, add it as a data source. The build gets better with every deal, which is the whole point.

Let sales self-serve. Expose the flow through a Peer so an account executive can ask "how do we answer questions about data residency" in Slack and get the house answer without filing anything.

Split by section. For very large questionnaires, use a Classifier to route sections to different agents — one that knows infrastructure, one that knows privacy — each with its own skill.

Pitfalls

An agent with no retrieval will still answer. If the Search step is missing or returns nothing, the model produces a plausible industry-standard answer with nothing behind it. Check that kb.response actually has content before trusting a run.

Confidence is not a control. Do not let the flow decide what needs review on the model's self-reported confidence alone. Name the escalation categories explicitly in the skill.

One giant prompt instead of a loop. Pasting 300 questions into a single agent call produces uniformly mediocre answers and no citations. One question, one retrieval, one answer.

Stale sources. An indexed policy from eighteen months ago answers confidently and wrongly. Keep the sources synced.

Related

• Data sources and best practices
• Skills
• Contract review — the same document-grounded extraction, aimed at legal