Enterprise security evidence map

The 180-row questionnaire is due

A customer’s procurement team sends your CTO or IT lead a 180-row spreadsheet. Last month’s customer sent 240, and the one before sent a PDF. The wording changes, but most questions do not.

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

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

The three sheets

Sheet	What it holds	Who keeps it
Question library	Every customer question, mapped to a topic	Whoever receives questionnaires
Control and evidence index	One row per topic, with the control, evidence, date and owner	Each control’s owner
Customer response log	What you told each customer, when, with what evidence, and how often each answer was reused	Whoever sends the reply

The reuse count proves the system works. An answer sent to eleven customers unchanged is stable. An answer rewritten every time is a control problem disguised as a wording problem.

Part 1: Fifteen topics

Map every question to one of these. Some map to two, which is fine. A question that maps to none signals a customer’s specific concern worth reading closely.

Code	Topic	What customers really ask	Evidence that answers it
AC	Access control	Who reaches production and customer data, and how the list is kept	Dated access reviews, role definitions, the joiner, mover and leaver procedure, and named admin accounts
MFA	MFA	Whether one stolen password gets in	The identity provider’s policy export, with users and accounts in and out of scope
ENC	Encryption	Whether stolen disks or traffic are readable	Storage encryption settings, the TLS version and cipher policy, and who holds the keys
LOG	Logging and monitoring	Whether you would know, and how fast	Log sources, retention, alert routing, who reviews alerts, and one alert acted on
VUL	Vulnerability management	Whether known, fixed problems stay open	Scan schedule and last date, fix targets by severity, and open findings with their ages
SDLC	Secure development	Whether one engineer can push to production alone	Branch protection, code review rules, dependency and secrets scanning, and change approvals
BAK	Backup and recovery	Whether you get the data back	Schedule, location, immutability as configured, and a dated, timed restore test
IR	Incident response	What happens at 2 a.m., and when the customer hears	A dated plan, the call tree, the last exercise and notification commitments
SUB	Subprocessors	Who else touches the data	The list with purpose, data and location, and how you announce additions
RES	Residency and deletion	Where data lives, and whether it can be removed	Region settings, retention by data type, the deletion procedure and its confirmation
PER	Personnel	Whether your people are a risk	Background check policy, confidentiality agreements, and dated training completion with a denominator
BCP	Business continuity	Whether a disaster at your office stops the service	The plan, recovery objectives, dependencies, and the last test and result
PHY	Physical security	Where the hardware is	For cloud services, usually your provider’s attestation, plus your own office controls
PEN	Penetration testing	Whether a competent tester tried to break it	The report or summary letter, scope, date and fix status
CERT	Certifications	Whether you have a report to file	What you actually hold, with scope and period, or a direct statement that you hold none

Map before you answer

When a questionnaire arrives, map it before answering anything. Write each question’s code beside it and count.

A 180-row questionnaire usually collapses to fifteen to forty distinct answers. The rest are restatements, sub-parts and confirmations. That collapse is the whole value, and it comes in the first hour.

Answer the distinct set, then expand back out.

Part 2: The control and evidence index

One row per topic. This is where honesty lives.

Field	What goes in it
Topic code	From the library
Control statement	What you actually do, in one or two sentences you would say to an engineer
Control owner	A named person, not a team. If no name fits, that is the finding
Evidence file	The artefact, such as a settings export, dated policy, report, training record or restore log, with its filename
Evidence date	When the artefact was made. Most evidence goes stale within a year
Exception	What the control does not cover, named, with the reason
Approval	Who approved sending this answer, and when
Review date	When the row is checked again

Two fields carry most of the weight.

Evidence date keeps you honest. An answer true in March may be false in November, and the November customer deserves the November answer. Treat evidence over twelve months old as unverified until rechecked.

Exception is the field most organisations leave blank, and blank is almost always wrong. Nearly every control has a boundary.

MFA may skip two service accounts, or encryption may miss the analytics replica. Logs may keep 90 days, not 12 months. Writing the exception turns a claim into a description a reviewer can work with.

Part 3: The response log

Field	What goes in it
Customer question	The customer’s exact words
Topic	The code
Answer owner	Who wrote the answer
Approved answer	The exact text sent
Evidence file	What was attached or offered
Evidence date	The artefact’s date when sent
Exception	Any limit stated in the reply
Approval	Who approved sending it, and when
Reuse count	How often this exact answer has gone out

Keep the customer’s exact words. Six months later, you will want to know why you answered as you did, and the wording is why.

The reuse count does three jobs.

It shows which answers carry the most weight and need the best evidence. A sudden rewrite of a high-reuse answer means the control changed. And it gives you a number when a customer asks how mature your process is.

Part 4: Six example answers

These are written as they should go out. Two are honest negatives, since those are the ones people get wrong.

MFA, with scope and exceptions

MFA is enforced for all staff on email, the identity provider, VPN and production admin consoles. It is set in the identity provider’s policy and covers all 47 human accounts as of [date].

Two documented exceptions exist. One service account exports data for [system], and one legacy account serves [application], which lacks modern authentication.

Both are limited to one source IP, cannot log in interactively and are reviewed monthly. The legacy application will be replaced by [date].

Under NDA, we can share the policy export and an account inventory with in-scope and out-of-scope counts.

It gives a number with a denominator, names the exceptions first and says what compensates. A bare “yes” invites the follow-up that finds the service account anyway, which costs more credibility than disclosing it.

Encryption, with data, settings and key owners

Data at rest is encrypted with [provider]-managed encryption on all production databases, object storage and backups. Keys sit in [provider]‘s key management service, and only two named engineers can use them, with every use logged.

Data in transit uses TLS 1.2 or higher for all outside connections. TLS 1.0 and 1.1 are disabled at the load balancer. Traffic between internal services in the production VPC has been encrypted since [date].

We can share a dated encryption settings export and a dated TLS scan.

It separates rest from transit and names who holds keys. It dates the internal change instead of implying it was always true.

Logging, with sources, retention and reviewers

We collect authentication, admin action, infrastructure and application error logs in [system]. They are kept 90 days in fast storage and 12 months in archive.

Alerts fire for [specific triggers]. They go to a channel watched in business hours, and to on-call paging for [severity] at other times.

We run no staffed 24-hour security operations centre. Out of hours, an on-call engineer aims to acknowledge pages within [N] minutes.

We can share the log source list, retention settings, alert rules and on-call rota.

It answers “24/7 monitoring” precisely. Collecting logs continuously differs from people watching continuously. A checkbox gets read generously by a reviewer and strictly by a contract.

Penetration testing, a precise no

We have not commissioned an independent penetration test. Here is what we do instead, and what we plan.

Every build gets dependency and container scanning with [tool]. Staging gets authenticated vulnerability scans [how often], and the external attack surface is scanned [how often]. All production changes need peer review under branch protection.

We fix critical findings within [N] days and high ones within [N] days. Open counts as of [date] are [numbers].

We plan a scoped third-party application test in [timeframe]. We will discuss the scope your review needs and share the report under NDA.

We can share scan settings, a dated findings report and the branch protection export now.

It never implies a test happened. It replaces the missing report with quantified evidence that exists, and the date turns a gap into a plan. Many reviewers accept this, and those who do not would also have rejected a vague yes, later.

SOC 2 Type II, current status

We do not hold a SOC 2 Type II report.

Our security control index documents the controls a SOC 2 examination would cover, and we can share it under NDA. It covers access, change, encryption, logging, vulnerabilities, backup, incidents, subprocessors and personnel. Each has an owner and current evidence.

If SOC 2 is required for this engagement, not just preferred, tell us now. We will discuss timing and scope. If documented controls and evidence will do, we can start this week.

It is direct and offers substance in place of the missing report. It asks the question that decides whether the deal is blocked. Many questionnaires ask for SOC 2 by default and accept documented controls when asked.

SOC 2 is an AICPA examination framework covering security, availability, processing integrity, confidentiality or privacy. It is one possible piece of evidence, not a legal requirement, and no federal rule imposes it.

Whether your customers demand it depends on your market. No neutral data on how often enterprise buyers require it was found, so treat any claim about that as unproven.

Subprocessors, every third party with data access

Our subprocessors as of [date] are listed below.

Subprocessor	Purpose	Data	Region	Contract
[Cloud provider]	Hosting	All customer data	[region]	DPA in place
[Email provider]	Transactional email	Names and email addresses	[region]	DPA in place
[Error monitoring]	Error tracking	Error data, which may include user identifiers	[region]	DPA in place
[Support platform]	Customer support	Ticket contents, names and email addresses	[region]	DPA in place

We give customers at least [N] days’ notice before adding a subprocessor of customer data, at [location or method]. Our outsourced IT provider has admin access to corporate systems but none to production customer data.

It is specific, includes the error tracker most vendors forget and covers the outsourced IT relationship reviewers now ask about. The 2025 Verizon Data Breach Investigations Report covered 22,052 incidents and 12,195 confirmed breaches. Third parties were involved in 30% of breaches, from contributed cases rather than a population sample.

Part 5: How to write a precise no

A precise no beats an unchecked yes. It usually costs less than people expect. A no brings a follow-up question. A wrong yes brings a commitment you cannot meet, found during an incident in front of an unhappy customer.

A good no has four parts.

1. A direct statement. “We do not do X,” said first and plainly.
2. What you do instead. The related controls that address the same risk, with specifics and numbers.
3. A plan with a date. Or a plain statement that there is no plan, and why. Reviewers read an undated intention as a no.
4. An offer. What you can share now, and on what terms.

Avoid three habits.

• Answering the question you wished they asked. Answering “do you run penetration tests?” with your vulnerability scanner is a no dressed as a yes. Reviewers notice, and that is worse than the no.
• Naming a product instead of a control. “We use [product]” does not answer whether MFA covers all admin accounts. A licensed but unenforced product is not a control.
• Claiming an inherited control as your own. If physical security is wholly your cloud provider’s, say so. It is a good answer, and claiming it gets awkward when they ask which data centre.

Part 6: Check commitments before contracts

This is the failure the map exists to prevent.

A deal is close when a questionnaire arrives.

Someone decides a marginal yes is close enough, or that a plan counts as practice. An exception seems too small to mention. The questionnaire goes back clean, and the deal closes.

Then the answers land in the agreement, a security exhibit or a set of representations, and become commitments.

A 24-hour breach notice that sounded reasonable becomes a contractual clock. “Annual penetration testing” must now happen every year. “All data is encrypted at rest” now covers a backup that is not.

Three rules prevent this.

1. Read every questionnaire as a draft contract, since it often becomes one. Ask which answers you could defend in a deposition, and rewrite the rest.
2. The control owner approves the answer. Sales cannot approve a security answer. The person named as owner signs off, which costs a day and saves a year.
3. Check commitment language separately. Notice times, test frequency, audit rights and service levels tend to reappear in the contract. Have your contract reviewer read the reply first.

The law may already set notice times for some data.

Under HIPAA, people must be told without unreasonable delay and within 60 days of discovery. The rules are 45 CFR 164.404 and 164.408. Timing for HHS depends on breach size, and whether it applies to you is a legal question.

A commitment shorter than what you can actually deliver is a self-inflicted incident. Choose a number you can meet at 3 a.m. on a holiday weekend.

Part 7: Count before you buy a platform

Compliance automation platforms do real work. They are also often sold to organisations with no written controls. Those buyers then pay to be asked the questions they were avoiding.

Sort your gaps first.

• Group A costs only attention. Write control statements, name owners and gather dated evidence into one folder. Record exceptions, and build the question library from the questionnaires already in your inbox. This is most of the work and most of the value.
• Group B costs configuration or time. Turn on logging you already pay for and set branch protection. Run a restore test, close MFA exceptions and write the incident plan.
• Group C costs money. A penetration test, a SOC 2 examination, a compliance platform or a managed detection service.

Finish A and B first. For any Group C proposal, ask which customer questions it answers that your index cannot.

Ask to see that mapping. If a platform’s value is collecting evidence automatically, ask how much it collects from your own tools, by name. It is often less than the demo implies.

If a vendor answers your gaps with a platform proposal, ask which gaps fall in Group A. Then ask why those were not its advice.

Keep the map current

Trigger	Action
A new questionnaire	Map it before answering, and log questions that map to nothing
An answer is sent	Add to the reuse count, and record the evidence date at sending
Evidence over 12 months old	Mark the row unverified until rechecked, and never send stale evidence with a fresh date
A control changes	Update its row, then find every high-reuse answer that cited it
An exception is closed	Update the answer, and tell customers whose agreements cited it
Each quarter	Review the five most-reused answers, which carry the most contractual exposure

The map works when a questionnaire takes an afternoon. The only new work is the few questions that mapped to nothing.

Keep the approved answer with every reply

This is general guidance on structuring and answering customer security questionnaires. It is not legal advice and does not interpret your contracts. Whether a reply becomes a contractual representation depends on your agreements and jurisdiction.

Have counsel review any reply with a notice time, an audit right or a testing commitment.

SBK reviews an evidence map for one live customer request before you send it. Call (718) 407-4169.