Use this for one questionnaire at a time. You get three files in a new folder, ./customer-security-questionnaire-answers/<customer-role-or-deal-id>/: a spreadsheet you can open in Excel with every question, a draft answer, the document it comes from, a confidence level and the owner who must confirm it (answers.csv); a list of answers that need a human decision, such as promises, sensitive details and contradictions (flags.md); and the new or corrected answers worth keeping for the next questionnaire (library-updates.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Questionnaire answers often become part of the contract, so a named person approves every one before it leaves.
Inputs to gather
Read the questionnaire in whatever form it arrived, the company's policies and procedures, its assurance reports or certificates, past answered questionnaires if the company keeps an answer library, the architecture overview, the subprocessor list and the standard contract and data processing terms. Ask the reader, in one message: the deadline, the size and sector of the customer, whether the answers will be attached to the contract, who approves the final answers, and which documents may be shared under a confidentiality agreement.
Step 1: parse and group
One row per question: the customer's reference and wording unchanged, the type (yes or no, free text, document request, file upload), and a topic (access, encryption, incident, privacy, people, development, continuity, suppliers). Group duplicates; long questionnaires ask the same thing three ways, and the answers must match.
Step 2: draft each answer from a source
Answer from the company's documents and records only, and cite the path or section and the date of the source for each answer. Flag sources older than the customer will accept (a penetration test from last year, a certificate near expiry, a report outside the current period). Give each a confidence level:
- Evidenced: a policy says it and a record or configuration shows it happens.
- Policy only: written down, but no record at hand; owner to confirm.
- No source: nothing found. Leave the answer blank and route it to an owner; never fill the gap with what companies usually do.
Write answers that are short, true and scoped: "Yes. Production access uses single sign-on with multi-factor authentication; see the access control policy, section on authentication." When the truth is partial, say so: "Yes for production systems; internal tools are being moved to single sign-on." Answer the question asked and do not volunteer architecture details the question did not request.
Step 3: flag commitments and sensitive answers
Some answers are promises. Any incident notice time goes to the incident response owner, who checks it against the contracts and against what detection to notification has actually achieved; promising 24 hours when the process has never beaten 72 turns the first incident into a contract breach. Flag every other answer that states a time, a frequency or a guarantee (incident notice within a number of hours, a penetration test every year, data never leaves a region, deletion within a number of days) and check it against what the company does today and what its contracts already say. Flag answers that would reveal internal hostnames, network ranges, tool versions or open weaknesses; propose a higher-level wording instead, using one standard redirect ("we do not share this detail; our assurance report covers it and is available under confidentiality") so refusals read the same in every questionnaire. Check answers on subprocessors, transfers and retention against the records of processing and the data processing terms the customer will sign; a mismatch between the two is the finding a customer's lawyer spots first. For questions about what a framework expects, run a framework lookup rather than guessing.
Step 4: check consistency with past answers
Compare with previous questionnaires and the public trust or security page. Different answers to the same question for two customers create contractual and credibility risk. List every difference in the flags list (flags.md) with both versions and ask which is true now.
Step 5: write the outputs
The answer spreadsheet (answers.csv): reference, question, draft answer, source, confidence, owner to confirm. The flags list: no-source items, commitments, sensitive answers and inconsistencies, grouped by owner. The library file (library-updates.md): new or corrected answers for the library owner to add once approved. Note in the flags list that requested documents go out only after the confidentiality agreement is signed, as watermarked copies released by the approver, who logs which version went to which customer.
If the output folder exists, ask before overwriting and offer a new subfolder instead.
What good looks like
- Every answer points to a source a colleague can open.
- Partial truths are stated as partial. A reviewer trusts a questionnaire with a few honest "partially" answers more than one with three hundred yeses.
- The common mistake is aspirational answers: what the company plans to do, written as what it does. The tell: answers with no source, and commitments that nobody in operations recognises.
- Commitments are checked against reality before signature, because the customer will hold the company to them.
- The approved answers improve the library, so the next questionnaire takes hours, not days.
Framework lookups
If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-customer-security-questionnaire-answers
Rules
- MUST cite a source for every drafted answer and leave unsourced answers blank for an owner.
- MUST flag every answer that commits the company to a time, frequency or guarantee.
- MUST write outputs only inside
./customer-security-questionnaire-answers/ and ask before overwriting.
- NEVER submit answers to the customer or upload them to a portal; a named person approves and sends.
- NEVER present a planned measure as one already in place.
- NEVER include secrets, credentials, internal hostnames or network ranges in an answer.