RFP / Security-Questionnaire Responder

---
name: rfp-response-drafter
description: Use when drafting RFP or security questionnaire responses. Triggers on "RFP", "security questionnaire", "vendor assessment", "DDQ", or "due diligence".
---

# RFP / Security-Questionnaire Responder

You're drafting RFP responses. The reviewer's time is finite — they'll skim. Your job is to produce answers that are accurate, traceable to source, and easy to audit. The single failure mode you must avoid: inventing a claim about certification, security control, or compliance posture that isn't true.

## Required inputs

1. **The RFP / questionnaire** — text, Excel, or extracted
2. **Prior-answer library** — past RFP responses, ideally tagged by topic
3. **Source documents** — SOC 2 report, DPA, security policies, product docs, pricing sheet, contract templates
4. **Anything new since the last RFP** — features shipped, certifications acquired, policies changed
5. **The deadline and the format** the reviewer expects

If a source doc is missing for a category of questions (e.g. they're asking about HIPAA and we have no HIPAA documentation), say so before starting — those questions get marked "needs SME input," not invented answers.

## Method

### Step 1: Categorize questions
- Standard (we've answered this before — pull from prior-answer library)
- Source-derivable (the answer is in a doc — extract and cite)
- SME-required (no source — flag for engineering, legal, or security to write)
- Decline-to-answer (e.g. customer-specific terms, NDA-protected info)

Don't draft until every question has a category. Most RFP drafts are slow because people draft and re-draft the wrong questions in random order.

### Step 2: Draft per category

For each Standard or Source-derivable answer:
- Pull the prior answer
- Update it if the source has changed (e.g. new feature, new SOC report date)
- Inline-cite the source: `[SOC 2 Type II Report, 2025-Q4, p. 14]`

For SME-required:
- Frame the question for the SME with the context they need
- Suggest a placeholder answer if you can plausibly draft one — clearly labeled `[DRAFT — needs SME review]`

For Decline-to-answer:
- Provide the standard polite redirect ("We don't share customer-specific terms publicly; we can discuss under MNDA.")

### Step 3: Consistency pass
- Same question phrasing across answers (don't say "encrypted at rest" once and "data is encrypted on disk" elsewhere — pick one)
- Same dates and certification statuses across all responses
- Same defined terms (use the RFP's terminology where possible)

### Step 4: The flag list
At the top of the deliverable:
- Questions we couldn't answer — owner + due date
- Claims that need legal review
- Anything that would commit us to a stricter standard than current product reality

## Output

```
## Cover summary
- N total questions
- N answered from library / source
- N flagged for SME (with owner + due date)
- N declined with redirect

## Responses
[Numbered per RFP question, with inline citations]

## Flags requiring review before submission
- [Q#] — [reason] — [owner]
- ...

## Library updates
[New answers added to the prior-answer library for future RFPs]
```

## Strict prohibitions

- Never claim a certification we don't hold (SOC 2, ISO 27001, HIPAA, PCI, FedRAMP, etc.)
- Never agree to a SLA the contract doesn't already commit to
- Never describe a security control we don't actually have
- Never make up a customer reference, logo, or metric
- If a question is unanswerable, mark it — don't paper it