Your Customer Questionnaire Answer Map

The 180-row questionnaire is due

A customer procurement team sent your CTO, VP Engineering, or Solo IT Director a spreadsheet with 180 rows. Last month’s customer sent 240. The request before that arrived as a PDF.

The wording changed. Most questions did not.

Map each incoming question to roughly 15 recurring topics. Keep one approved answer, dated artifact, owner, exception, and review date for each topic. The next portal then starts from your maintained record instead of an empty text box.

Build the three sheets first. A compliance platform can wait.

---

The three sheets behind your next response

Sheet	What it holds	Who maintains it
Question library	Every incoming customer question, mapped to a normalized topic	Whoever receives questionnaires
Control and evidence index	One row per topic: the control, the evidence artifact, its date, its owner	The person who owns the control
Customer response log	What you told each customer, when, with what evidence, and how many times that answer has been reused	Whoever sends the response

The reuse count is the field that proves this works. When an answer has been sent to eleven customers without amendment, you have a stable answer. When an answer keeps getting rewritten, you have a control problem hiding behind a wording problem.

---

Part 1: Map every incoming question to a maintained topic

Fifteen topics. Map every incoming question to one of them. Some questions map to two, which is fine, and a few map to none, which is your signal that a customer has a genuinely specific concern worth reading closely.

Code	Topic	What customers are actually asking	Evidence that answers it
AC	Access control	Who can reach production and customer data, and how is that list maintained	Access review record with dates, role definitions, joiner-mover-leaver procedure, current privileged account list with named humans
MFA	Multi-factor authentication	Can one stolen password get in	Identity provider enforcement policy export showing scope, plus the count of users and accounts in and out of scope
ENC	Encryption at rest and in transit	Is customer data readable if someone gets the disk or the wire	Configuration showing storage encryption enabled, TLS version and cipher policy, key management approach and who holds keys
LOG	Logging and monitoring	Would you know, and how fast	Log sources list, retention period, alert routing, who reviews alerts and when, an example of an alert that was acted on
VUL	Vulnerability management	Are known, published, already-fixed problems still open	Scan cadence and last scan date, remediation service levels by severity, current open findings with ages
SDLC	Secure development and code review	Can one engineer push to production alone	Branch protection settings, code review requirement, dependency scanning output, secrets scanning, change approval record
BAK	Backup and recovery	If this is destroyed, do we get our data back	Backup schedule, storage location, immutability or offline setting as configured, and a restore test record with a date and a duration
IR	Incident response	What happens at 2 a.m., and when do we hear about it	Incident response plan with a version date, contact tree, the last exercise record, notification commitments
SUB	Subprocessors	Who else touches our data	Current subprocessor list with purpose, data categories, and location, plus your notification process for adding one
RES	Data residency and deletion	Where does it live, and can we get it removed	Region configuration, retention schedule by data type, deletion procedure with expected timeframe, deletion confirmation format
PER	Personnel screening and training	Are your people a risk	Background check policy and scope, confidentiality agreements, security training completion with a denominator and a date
BCP	Business continuity	If your office burns down, do we lose service	Continuity plan, recovery objectives as designed, dependency list, last test date and outcome
PHY	Physical security	Where is the hardware	For cloud-hosted services this is usually inherited from your provider, so the honest answer names the provider and points at their attestation, plus your own office controls
PEN	Penetration testing	Has anyone competent tried to break it	Test report or summary letter, scope description, date, and the remediation status of findings
CERT	Certifications and attestations	Do you have a report we can file	Whatever you actually hold, with its scope and period, and a direct answer when you hold nothing

Preserve the customer’s wording and assign the answer owner

When a questionnaire arrives, do not answer it. Map it first.

Take each question, write its normalized code next to it, and count. A 180-row questionnaire usually collapses to somewhere between fifteen and forty distinct answers, with the rest being restatements, sub-parts, and yes-or-no confirmations of things you have already said. That collapse is the entire value of the exercise, and you get it in the first hour.

Then answer the distinct set. Then expand back out.

---

Part 2: Link each topic to its current evidence

One row per topic, and this is where the honesty lives.

Field	Definition
Topic code	From the library above
Control statement	What you actually do, in one or two sentences, written the way you would say it to an engineer
Control owner	A named person. Not a team. If nobody’s name fits, that is the finding
Evidence file	The specific artifact: a configuration export, a policy PDF with a version date, a report, a training completion record, a restore test log. Filename recorded here
Evidence date	When the artifact was produced. Evidence ages, and most of it is stale after a year
Exception	What the control does not cover, named specifically, with the reason
Approval	Who signed off that this answer may be sent to a customer, and when
Review date	When this row gets re-verified

Two of these fields carry most of the weight.

Evidence date is the field that keeps you honest across renewals. An answer that was true in March may not be true in November, and the customer who asks in November is entitled to the November answer. If your evidence date is more than twelve months old, treat the answer as unverified until someone re-checks it.

Exception is the field most organizations leave blank, and blank is almost always wrong. Nearly every control has a scope boundary. MFA is enforced except on two service accounts. Encryption covers the primary database and not the analytics replica. Logging retains 90 days and not 12 months. Writing the exception down is what turns a claim into a description, and a description is what a security reviewer can actually work with.

---

Part 3: Record what you sent, when, and to whom

Field	Definition
Customer question	The question as the customer wrote it, verbatim
Normalized topic	The code
Answer owner	Who produced the answer
Approved answer	The exact text sent
Evidence file	What was attached or offered
Evidence date	Date of that artifact at the time of sending
Exception	Any scope limit stated in the response
Approval	Who approved sending it, and when
Reuse count	How many times this exact answer has gone out

Keep the customer’s verbatim wording. It looks redundant next to the normalized topic and it is not, because six months later you will be trying to remember why you answered a particular way, and the wording is the reason.

Reuse count does three things. It tells you which answers are load-bearing and deserve the best evidence. It tells you when an answer has drifted, since a high-reuse answer that suddenly needs rewriting means the underlying control changed. And it gives you a number to show a customer who asks how mature your process is.

---

Part 4: Approved answer examples with evidence boundaries

Six answers, written the way they should go out. Two of them are honest negatives, because those are the ones people get wrong.

MFA: Put the enforcement scope and exclusions beside the customer’s question

MFA is enforced for all employee accounts on email, the identity provider, VPN, and administrative consoles for production infrastructure. Enforcement is set at the identity provider policy level and applies to 100% of the 47 human accounts as of [date].

Two exceptions exist and are documented: one service account used by [system] for automated data export, and one legacy account for [application] which does not support modern authentication. Both are restricted to a single source IP, have no interactive login, and are reviewed monthly. The legacy application is scheduled for replacement by [date].

Evidence available on request under NDA: identity provider enforcement policy export and account inventory showing in-scope and out-of-scope counts.

Why this works. It gives a number with a denominator, names the exceptions before anyone finds them, and states what compensates. A reviewer can price that. A bare “yes” invites the follow-up question that finds the service account anyway, and finding it themselves costs you more credibility than disclosing it.

Encryption: Name the data, configuration evidence, and key owner

Data at rest is encrypted using [provider] managed encryption on all production database volumes, object storage, and backups. Keys are managed by [provider] key management service, with key access limited to two named engineers and logged.

Data in transit is encrypted with TLS 1.2 or higher for all external connections. TLS 1.0 and 1.1 are disabled at the load balancer. Internal service-to-service traffic within the production VPC is encrypted in transit as of [date].

Evidence: encryption configuration export dated [date], TLS configuration scan result dated [date].

Why this works. It separates at rest from in transit, names who holds keys, and gives a date for the internal traffic change rather than implying it was always true.

Logging: Record sources, retention, reviewer, and a dated alert result

We collect authentication logs, administrative action logs, infrastructure logs, and application error logs into [system], with 90-day hot retention and 12-month archive retention.

Alerts are configured for [list the specific triggers]. Alerts route to a shared channel monitored during business hours and to on-call paging for the [severity] tier outside business hours. We do not operate a 24-hour staffed security operations center. Response outside business hours is by on-call engineer with an acknowledgment target of [N] minutes for paging alerts.

Evidence: log source inventory, retention configuration, alert rule export, and the on-call rotation schedule.

Why this works. It answers “24/7 monitoring” precisely instead of yes or no. Continuous collection and continuous human attention are different things, and stating which one you have is more defensible than a checkbox that a reviewer will interpret generously and a contract will interpret strictly.

Penetration testing: Give the precise no, decision owner, and planned date

We have not commissioned an independent third-party penetration test. Here is what we do instead, and what we are planning.

Current practice: automated dependency and container scanning on every build with [tool], authenticated application vulnerability scanning [cadence] against the staging environment, external attack surface scanning [cadence], and mandatory peer review with branch protection on all production code changes. Open findings are tracked with remediation targets of [N] days for critical and [N] days for high severity. Current open counts as of [date]: [numbers].

Planned: a scoped third-party application penetration test in [timeframe]. We are happy to discuss scope requirements that would satisfy your review, and to share the resulting report under NDA when complete.

Evidence available now: scan configuration and current findings report dated [date], branch protection settings export.

Why this works. It refuses to imply a test happened. It replaces the missing artifact with the evidence that does exist, quantified. And it offers a date, which converts a gap into a plan a reviewer can accept conditionally. Many enterprise reviewers will accept this. The ones who will not would also have rejected a vague yes, and later.

SOC 2 Type II: State the current report status and available evidence

We do not currently hold a SOC 2 Type II report.

The controls a SOC 2 examination would cover are documented in our security control index, which we can share under NDA. It covers access control, change management, encryption, logging and monitoring, vulnerability management, backup and recovery, incident response, subprocessor management, and personnel security, with a named owner and current evidence for each.

If a SOC 2 report is a requirement for this engagement rather than a preference, tell us now and we will discuss timing and scope. If your review can be satisfied by control documentation and evidence, we can begin that review this week.

Why this works. It is direct, it substitutes the underlying substance for the missing artifact, and it asks the one question that determines whether the deal is blocked: is this a requirement or a preference. A surprising number of questionnaires ask for a SOC 2 report as a default field and accept documented controls when asked.

Worth stating plainly, since a great deal of marketing suggests otherwise. SOC 2 is an examination framework defined by the AICPA around controls relevant to security, availability, processing integrity, confidentiality, or privacy. It is one possible evidence artifact. It is not a legal requirement and no federal rule imposes it. Whether your customers demand it is a commercial question about your specific market, and neutral data on how often enterprise buyers require it was not found, so treat any prevalence claim you hear, including a vendor’s, as unproven.

Subprocessors: List every third party with customer-data access

Current subprocessors as of [date]:

Subprocessor	Purpose	Data categories	Region	Contract
[Cloud provider]	Infrastructure hosting	All customer data	[region]	DPA in place
[Email provider]	Transactional email	Names, email addresses	[region]	DPA in place
[Error monitoring]	Application error tracking	Error payloads, may include user identifiers	[region]	DPA in place
[Support platform]	Customer support	Support ticket contents, names, email addresses	[region]	DPA in place

We notify customers at least [N] days before adding a subprocessor that processes customer data, at [location or method]. Our own outsourced IT provider holds administrative access to corporate systems and does not have access to production customer data.

Why this works. It is specific, it includes the error monitoring tool that most vendors forget, and it addresses the outsourced IT relationship that enterprise reviewers increasingly ask about. Third-party involvement appeared in 30% of breaches in Verizon’s 2025 dataset, which covered 22,052 incidents and 12,195 confirmed breaches. That is a contributed-case dataset rather than a population sample, so treat it as directional. Your reviewer has probably read it either way.

---

Part 5: Write the precise no and its owner

The rule is short and it holds across every topic.

A precise no beats an unverified yes, every time, and it usually costs less than people expect.

A no gets you a follow-up question. A wrong yes gets you a contractual commitment you cannot meet, discovered during an incident, in front of the customer who is already having a bad day.

The structure of a good no has four parts:

1. The direct statement. “We do not do X.” Say it first, in plain words, without hedging language in front of it.
2. What you do instead. The adjacent controls that address the same underlying risk, stated with specifics and numbers.
3. The plan, with a date. Or an explicit statement that you have no plan and why. An undated intention reads as a no with extra steps, and reviewers read it that way.
4. The offer. What you can share now, under what terms.

Three specific patterns to avoid:

• Answering the question you wish they asked. “Do you conduct penetration testing?” answered with a description of your vulnerability scanner is a no dressed as a yes. Reviewers notice, and the noticing is worse than the no.
• Describing a product instead of a control. “We use [security product]” does not answer “is MFA enforced for all administrative accounts.” A product that is licensed but not enforced is not a control.
• Answering for a control you inherited without saying so. If your physical security answer is entirely your cloud provider’s, say that. It is a perfectly good answer, and claiming it as your own gets embarrassing when they ask which data center.

---

Part 6: Review commitments before they enter the client contract

Here is the failure mode that this document exists to prevent.

A deal is close. A questionnaire arrives. Somebody in the room decides that a marginal yes is close enough to true, or that the plan counts as the practice, or that the exception is too small to mention. The questionnaire goes back clean. The deal closes.

Then the questionnaire answers get referenced in the agreement, or in a security exhibit, or in a set of representations. Now they are commitments. Your 24-hour breach notification answer, which sounded reasonable in a spreadsheet, is a contractual obligation with a clock on it. Your “we conduct annual penetration testing” is something you now have to do annually, or be in breach of. Your “all data is encrypted at rest” now covers a backup target that is not.

Three rules that prevent this.

Rule one: read every questionnaire as a draft contract. Because it frequently becomes one. Before you send, ask which answers you would be comfortable defending in a deposition, and rewrite the ones you would not.

Rule two: whoever owns the control approves the answer. Sales cannot approve a security answer. The person whose name is in the control owner field signs off. This costs a day and saves a year.

Rule three: check the commitment language separately. Notification timeframes, testing cadences, audit rights, and service levels that appear in a questionnaire have a way of appearing in the contract. Have whoever reviews contracts read the questionnaire response before it goes out. Note also that notification obligations may already be set by law for some data types. Under HIPAA, individual notice must occur without unreasonable delay and no later than 60 calendar days after discovery, with HHS timing that differs by breach size. Whether that applies to you is a legal determination.

A contractual commitment that is shorter than your operational capability is a self-inflicted incident. Pick the number you can hit at 3 a.m. on a holiday weekend.

---

Part 7: Count requests and reuse before you buy a platform

Compliance automation platforms are real products that do real work. They are also frequently sold to organizations that have not yet written down a single control, and buying one at that stage means paying a subscription to be asked the same questions you were avoiding.

Sort your gaps first.

Group A: costs nothing but attention. Writing the control statements. Naming owners. Collecting the evidence files you already have into one folder with dates. Recording exceptions. Building the question library from the three questionnaires already in your inbox. This is most of the work and it produces most of the value.

Group B: costs configuration or time. Enabling logging you already pay for. Setting branch protection. Running a restore test. Closing the MFA exceptions. Writing the incident response plan.

Group C: costs money. A penetration test. A SOC 2 examination. A compliance automation platform. A managed detection service.

Do A and B first. Then apply one test to any Group C proposal: ask which specific customer questions the product answers that your evidence index does not, and ask to see that mapping. If a compliance platform’s value is that it collects evidence automatically, ask how much of your evidence it can actually collect from your specific stack, by name. The answer is often less than the demonstration implies.

If a vendor’s first response to your questionnaire gaps is a platform proposal, ask which of your gaps are in Group A, and why those were not the recommendation.

---

Review the map before every customer deadline

Trigger	Action
New questionnaire arrives	Map to topics before answering. Log any question that maps to nothing
Answer sent	Increment reuse count. Record evidence date as of send
Evidence older than 12 months	Mark the row unverified until re-checked. Do not send stale evidence with a current date
Control changes	Update the index row, then find every high-reuse answer that referenced it
Exception closed	Update the answer and tell any customer whose active agreement referenced it
Quarterly	Review the top five reuse-count answers. Those carry the most contractual exposure

You know the map is working when a questionnaire takes an afternoon and the only new work is the handful of questions that mapped to nothing.

---

Keep the approved answer version with every response

This document is general guidance on structuring and answering customer security questionnaires. It is not legal advice and it does not interpret your contracts. Whether a questionnaire response becomes a contractual representation, and what follows from that, depends on your agreements and your jurisdiction. Have counsel review any response that carries a notification timeframe, an audit right, or a testing commitment.

Every regulatory and statistical claim above is sourced inline to a named authority through SBK’s source register. Where prevalence data does not exist, this document says so rather than supplying a number.

SBK Consulting is a family-run, vendor-neutral IT advisory firm serving the New York, Connecticut, and New Jersey metro area. Founded 2010. Zero vendor partnerships, zero reselling, zero commissions or referral fees. 125+ years combined experience, 100% US-based. We do evidence-map reviews for one active customer request if you want a second set of eyes before you send. If you never call us and this document gets your questionnaire answered accurately, it did its job.

(718) 407-4169