A customer wants to work with you, but first they have sent a spreadsheet full of security questions. You recognize some terms. Others sound like they were written for a company with a whole IT department.
Start by separating what you can prove, what you need to check, and what you have not implemented. You do not need to invent reassuring answers or write fifteen policies before you reply.
First, confirm what the customer is asking about
Ask which service, systems, and information the questionnaire covers. Will you hold customer files, access their systems, or only exchange ordinary business contact details? Is every question mandatory? What is the deadline, and how should you explain a control that does not apply?
A questionnaire for a hosted software provider may include questions that do not fit a business delivering design work. That is a reason to clarify scope, not automatically mark every difficult question “not applicable.”
Check whether the answers become part of a contract or require a signed statement. Have the appropriate business or legal reviewer examine commitments you do not understand before submitting them.
Make a working copy and assign an owner
Keep the original request. In your working copy, add columns for:
- The person responsible for checking the answer.
- Current status: confirmed, checking, gap, or not applicable with a reason.
- Supporting record and the date it was checked.
- The action needed if something is missing.
Let one coordinator collect responses. Your provider can verify technical settings, while the owner or manager confirms business processes and approves the final response.
Turn unfamiliar terms into plain questions
| Customer question | What to ask internally | Useful supporting record |
|---|---|---|
| Do you enforce multifactor authentication? | Which accounts require an extra sign-in check, and which do not? | A current settings or coverage report for the systems in scope |
| Do you perform access reviews? | Has someone checked whether each person still needs their permissions? | A dated review with decisions and completed removals |
| Do you test disaster recovery? | What have we actually restored, when, and did it work? | Test scope, timing, validation, and unresolved issues |
| Do you have an incident response plan? | Do we have an approved procedure with contacts and responsibilities? | The actual plan and, if performed, an exercise record |
An example answer is not evidence. A downloaded policy also does not demonstrate that the setting or process is in place.
Answer at the scope you can support
Suppose your provider confirms an extra sign-in check on email and administrator accounts, but one older application does not support it. “Yes, all systems” would be misleading.
An illustrative explanation could be: “Required for company email and administrator accounts. The legacy scheduling application does not support it; its access is restricted and replacement is under review.” Use that only if it accurately describes your business and the customer’s form allows that explanation.
If the form requires only Yes or No and reality is mixed, ask the customer how to record a partial answer. Do not let the format force an unsupported claim.
If you find a gap, make the next action specific
Record the affected service, business impact, owner, action, and target date. Discuss serious exposures with your provider promptly. Do not promise a deadline before the person doing the work confirms it is achievable.
Some gaps may require a change before the customer can proceed. Others may lead to a conversation about scope or alternative safeguards. The customer decides whether your response meets its purchasing requirements; the questionnaire is not itself a certification.
A message you can send your IT provider
A customer has requested a security review for our work on [service]. Please help verify the questions about sign-in protection, access permissions, updates, backups, and incident response for [systems]. For each answer, please identify the supporting record, any exclusions, and any setting or process that is not yet implemented. Please do not send passwords or secret recovery codes.
Share evidence carefully and save the final response
Use the customer’s approved secure channel. Share only the material needed, with authorization and redaction where appropriate. Detailed diagrams, employee information, vulnerability reports, and recovery details should not be casually emailed to an unverified recipient.
Keep the submitted version, approvals, supporting evidence, and follow-up actions in a restricted location. Reuse earlier answers as a starting point next time, then verify them against the new scope and current practice.
If your answer depends on recovery tests or worker access, read how to check whether your backups work and the employee IT offboarding checklist.
Your next step
Choose five questions you can verify today and send the rest to named owners. Progress begins with an accurate picture, not a spreadsheet filled with “Yes.”
General operational guidance, not legal advice or an assurance opinion. NIST’s Small Business Quick Start Guide provides a broader starting point for identifying risks and responsibilities. The workflow and sample wording here are practical suggestions, not NIST-issued questionnaire answers.