| 1. Intake | The questionnaire arrives — as a PDF, an Excel/Google Sheet, or entries in a customer's TPRM portal (Vanta, OneTrust, ServiceNow, a proprietary portal) — and gets logged against the customer relationship. | Parsing structured formats (spreadsheets, portal exports) into a consistent internal record; detecting duplicate or near-duplicate questions across formats. | Confirming the correct customer, contract scope, and deadline; deciding whether the questionnaire covers a new service or an existing one under a different name. | Questionnaires get lost in email, answered against the wrong scope, or missed deadlines trigger unnecessary escalation. |
| 2. Requirement interpretation | Each question is parsed for what is actually being asked — not just its literal wording. | Suggesting the likely underlying control category a question maps to (e.g., recognizing that "how is data protected in transit" maps to encryption-in-transit). | Resolving ambiguous, compound, or jurisdiction-specific wording; deciding what a vaguely worded question is really trying to establish. This is where misinterpretation risk is highest in the entire pipeline. | An answer that technically responds to the literal words but misses the customer's actual concern — the single most common source of follow-up questions and stalled reviews. |
| 3. Evidence retrieval | The interpreted requirement is matched against your existing library of approved documents, facts, and prior answers. | Searching a structured evidence library and surfacing likely matches, including matches worded differently than the source document. | Confirming a retrieved document is the current version and actually covers the specific system, region, or service the question is about. | An answer cites evidence that has expired, been superseded, or doesn't cover the scope actually asked about. |
| 4. Answer drafting | A first-pass written answer is produced from the retrieved evidence. | Producing a fluent, on-topic draft quickly from approved source material — this is where AI drafting adds the most visible speed. | Deciding whether the draft accurately represents current practice, not just plausible-sounding text. A fluent draft is not the same as a correct one. | An answer reads well but overstates, understates, or misdescribes an actual control — a problem a customer may not catch until an incident. |
| 5. Gap detection | The system checks whether a question has no matching approved evidence at all. | Flagging the absence of a match reliably and consistently, including partial or low-confidence matches. | Deciding whether a genuine gap should be closed before submission, disclosed with a compensating explanation, or escalated as a blocker. | A question with no real evidence behind it gets answered anyway, because a draft was generated — the most dangerous failure mode in the whole pipeline. |
| 6. SME routing | Gapped, ambiguous, or high-stakes items are sent to the right internal owner — security engineering, legal, privacy, or leadership. | Identifying which category a gapped question likely falls into, based on prior routing history. | Judging urgency, choosing the actual right person for an unusual question, and following up when an SME doesn't respond in time. | Gaps sit unrouted until the deadline, or get routed to whoever is available rather than whoever actually knows the answer. |
| 7. Review | A human reads the draft against the original question and the underlying evidence, not just against fluency. | Surfacing the source excerpt and confidence score next to the draft so review is faster and more targeted. | The review itself — confirming the draft matches both what was asked and what's actually true today. | A draft that sounds right gets approved without anyone checking it against the actual question or the evidence it cites. |
| 8. Approval | A distinct, accountable sign-off — separate from review — especially for answers involving legal commitments, security posture claims, or anything a contract might later reference. | Tracking who approved what, when, keeping an audit trail of the approval itself. | The accountability decision itself cannot be automated: someone has to be willing to stand behind the answer. | No one is accountable for a specific claim if it turns out to be wrong later — a real problem in a contractual dispute or incident post-mortem. |
| 9. Submission | The approved, complete questionnaire is delivered back to the customer, in whatever format they requested. | Formatting and exporting approved answers into the customer's required structure. | Confirming the submission is complete and matches what was actually approved (not an earlier draft version). | The wrong version — an earlier draft, a partially completed set — gets sent by mistake. |
| 10. Follow-up | The customer asks clarifying questions or requests more evidence after initial review. | Retrieving the original source evidence and prior answer quickly to support a fast, consistent follow-up response. | Judging whether a follow-up is a simple clarification or actually reveals a gap or inconsistency that needs to go back through review. | Follow-ups get answered inconsistently with the original submission, undermining the reviewer's trust in the whole package. |
| 11. Reuse | The final, approved answer is fed back into the reusable evidence and answer library for the next questionnaire. | Storing the approved answer in a structured, searchable form so it surfaces automatically at stage 3 next time. | Deciding when a reused answer needs to be re-validated because underlying practice, systems, or providers have changed since it was last approved. | The library fills with stale answers that keep getting reused after the underlying practice has actually changed — the most common way "approved" evidence quietly becomes wrong evidence. |
