Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →How to answer buyer security questionnaires in hours instead of weeks, what an answer library actually contains, and when to refuse the spreadsheet.
A security questionnaire program has four parts: an answer library keyed by question meaning rather than by question wording, an evidence set that is already collected and already classified for release, a single named owner for every response, and a turnaround target the sales team can quote. Built once, a mid-sized questionnaire drops from two weeks of engineering interruption to two to four hours of one person's time. The volume itself is reducible: a published trust centre and a current SOC 2 report between them remove a large share of the questions before anyone asks them.
Security questionnaires are a sales function that reports into security. They arrive attached to revenue, they are usually blocking, and the person who has to answer them is almost always the person with the least slack in the company. The purpose of a program is not to make the questionnaires go away. It is to make the marginal cost of answering one approach zero, so that a deal is never slowed by the fact that a buyer asked a reasonable question.
Without a program, each questionnaire is a fresh project. Someone reads two hundred rows, works out which ones they can answer, forwards fifteen to engineering, chases them for a week, gets three answers, guesses at the rest, and sends it back nine business days later with a handful of answers that are subtly wrong. The cost is not just the delay. It is that the wrong answers are now on file at the customer, and a future auditor or a future incident can be measured against them.
With a program, the same questionnaire is a lookup task. Most questions map to answers you already wrote and had reviewed. The remainder are genuinely new and get answered properly, then added to the library so they are never new again. The library is a compounding asset: the tenth questionnaire costs a fraction of the first, and the fortieth costs almost nothing.
The other thing a program buys is consistency. Two answers to the same question given six months apart by two different people, to two different customers, is a live liability. A buyer who compares your questionnaire response to your SOC 2 report, or to your trust page, or to the answer you gave their sister company, and finds a contradiction, has just turned a routine review into a diligence problem.
Almost everything you receive is one of three things, and each one needs a different response.
A bespoke spreadsheet, written by the buyer's security team, usually somewhere between forty and three hundred rows. These are the most work per question because the wording is unique, so an answer library keyed to exact question text is useless against them. They also contain the most badly scoped questions, because they were assembled by copying from previous questionnaires and no one has ever pruned them.
A standardized questionnaire, most commonly the Cloud Security Alliance CAIQ or a Shared Assessments SIG in one of its sizes. These are longer but far cheaper to answer, because the questions are stable across every buyer who uses them. Answering a full standardized questionnaire once and keeping it current is the single highest-leverage thing a small vendor can do, because you can hand the completed file over in response to a request rather than filling in the buyer's form.
A portal, where the buyer uses a third party risk platform and you are invited to complete a questionnaire inside it. Portals are the most annoying operationally because you cannot bulk-paste, the session times out, and the evidence upload limits are arbitrary. They are also the easiest to underestimate: a two hundred question portal is a half-day of clicking even when you know every answer.
A fourth thing arrives that is not a questionnaire at all: an email asking for your SOC 2 report, your penetration test summary and your policies. Treat it as the best possible outcome and answer it immediately, under NDA, because it costs you nothing and it is a buyer who has decided to trust documents rather than a spreadsheet.
One named person owns each response end to end. Not a team, not a shared inbox, and not the account executive. The owner is accountable for the answer being accurate, for the deadline, and for escalating when a question cannot be answered honestly in the affirmative.
In a company under fifty people this is usually whoever runs security or compliance, with a fallback named for when they are away. In a company past a hundred it is often a solutions engineer or a technical account role, with the security owner as reviewer. The pattern that fails is distributing the questionnaire across five subject matter experts and hoping it converges, because nobody then owns the coherence of the whole document, and coherence is what a reviewer is actually assessing.
Sales owns the commercial context and the deadline, and must supply both at intake: which customer, which deal, what stage, what the customer said they need, and by when. A questionnaire that arrives with no deadline gets treated as having no deadline. A questionnaire that arrives with "ASAP" gets treated the same way, because ASAP is not a date.
Engineering and IT own the facts they alone hold. The correct way to use them is to send three specific questions with a two-day deadline, not to forward a spreadsheet. Every question you send to an engineer should be one they can answer from knowledge in under two minutes, or one that requires them to check a specific setting. If a question needs an engineer to think for an hour, it is not a questionnaire question, it is a gap.
The core insight is that questions repeat but wording does not. "Do you enforce multi-factor authentication for administrative access to production systems?" and "Is MFA required for privileged users?" and "Describe your authentication controls for production infrastructure" are the same question in three costumes. A library keyed on exact text answers none of the variants. A library keyed on topic answers all three.
Structure the library as topics, roughly forty to eighty of them for a typical SaaS business, each holding a short answer, a long answer, the evidence that supports it, and a confidence and review date. Topics that cover most of what arrives: authentication and MFA, access provisioning and deprovisioning, access review, privileged access, encryption at rest, encryption in transit, key management, network segmentation, endpoint management, vulnerability management, patch SLAs, penetration testing, logging and monitoring, alerting and on-call, incident response, breach notification commitments, backup and restore, business continuity and disaster recovery, change management, secure development, dependency and supply chain management, code review, secrets management, data classification, data retention and deletion, data residency, subprocessors, subcontractor management, personnel screening, security awareness training, policy set and approval, risk assessment, asset inventory, physical security, remote work, insurance, and audit and certification status.
Every entry carries two answers because questionnaires ask in two registers. The short answer is one or two sentences that fits in a spreadsheet cell and stands alone. The long answer is a paragraph for the questions that say "describe your approach to". Writing only the long one means somebody paraphrases it into the cell each time and the paraphrase drifts. Writing only the short one means the descriptive questions get one-line answers that read as evasive.
Each entry also names the evidence that backs it and the person who owns the underlying control. That second field is what makes the library maintainable. When the control changes, the owner is the person who knows, and the library entry is the thing that has to change with it.
Add a review date and treat the library as perishable. An answer written eighteen months ago describing a monitoring stack you replaced last spring is worse than no answer, because it is specific, confident and false. A yearly review of every entry, or a review triggered whenever the underlying control changes, is enough. Entries that survive two reviews unchanged can go to a longer cycle.
The reviewer at the other end is looking for three failure signals: vagueness, overclaiming, and inconsistency with your other documents. Good answers are specific, bounded and boring.
Name the mechanism, not the intention. "Access to production is granted through our identity provider using group membership, requires MFA, and is reviewed quarterly by the system owner" tells the reviewer something. "We maintain appropriate access controls in line with industry best practice" tells them you are hiding. The second answer produces a follow-up question, and follow-up questions are where the real cost of a questionnaire lives.
Bound the claim. If MFA is enforced everywhere except one legacy admin console, the answer says so, and says what compensates. Reviewers are far more comfortable with a bounded exception than with a blanket yes that turns out to be untrue. They are used to exceptions. They are not used to vendors who admit them, and it buys you disproportionate credibility on every other answer.
Never claim a certification you do not hold, and never let a questionnaire answer say more than your evidence supports. This is not a matter of caution. A questionnaire response is a representation made in the course of a commercial transaction, it is retained by the buyer indefinitely, and it will be produced if there is ever an incident or a dispute. The same overclaim on a public page is worse, because it is a misrepresentation to every buyer at once and it is the first thing an auditor searches for.
Answer the question that was asked. A common trap is answering an adjacent question you have a good story for. If asked whether you carry cyber insurance and you do not, the answer is no, optionally with the reason and the plan, not a paragraph about your security program. Reviewers score evasion harder than absence.
Be careful with "yes" on questions containing more than one clause. "Do you encrypt data at rest and in transit using industry standard algorithms and manage keys in a dedicated key management service?" is three questions. If any part is no, the whole answer is not yes.
Questionnaires increasingly ask for attachments, and the difference between a fast review and a slow one is usually whether the evidence pack was ready. Decide once, in advance, what is releasable and under what conditions, and record that decision so nobody has to make it under deal pressure.
Three tiers work well. Public: anything already on your trust page, your subprocessor list, your security contact and disclosure policy, high level architecture, data residency statements. Under NDA: the SOC 2 report or ISO certificate with scope statement, penetration test executive summary, policy documents, your business continuity plan summary, insurance certificate. Never: raw scan output, full penetration test findings with unremediated issues, internal risk register, audit findings, incident records, employee data, and anything that names another customer.
The penetration test question deserves specific handling because it comes up in almost every enterprise review. Share an executive summary that describes scope, methodology, the date, the severity distribution of findings and the remediation status. Do not share the full technical report with open findings in it; you are handing someone a list of ways into your product, and no buyer needs it to complete their review. A buyer who insists on the full report is either inexperienced or has a genuine regulatory reason, and the second one is a conversation, not a policy exception. There is more on this in what to do when a customer wants proof of a penetration test.
Screenshots as questionnaire evidence are weak and should be avoided where a system generated export is available. A configuration screenshot with no visible date, no visible system identity and no visible scope is an assertion with a picture attached. This is the same standard an auditor applies, and buyers are increasingly applying it too.
Keep the evidence pack assembled and dated, in one place, with an owner and a refresh cycle. The pack is stale the moment the SOC 2 period ends, the penetration test passes twelve months, or the insurance certificate expires. Stale evidence sent to a buyer is an own goal, because the buyer notices the date before they read the content.
Give the process one front door. A shared address or a form that sales uses, capturing the customer name, the deal stage, the file itself, the customer's stated deadline, and whether an NDA is in place. The NDA question matters because half the useful evidence cannot move without one, and discovering that on day four costs you the week.
Triage on receipt, within a day. Count the questions, identify the format, spot the ones that need engineering, and check whether any question would have to be answered no. That last check is the important one, because a blocking no is a commercial conversation that has to start immediately rather than land in the customer's inbox at the end of the week.
Commit to a turnaround the sales team can quote. Five business days for anything up to a couple of hundred questions is defensible and achievable with a working library. Ten business days for a large standardized questionnaire or a portal with heavy evidence requirements. Publishing the commitment internally is what stops the process being negotiated per deal, and it lets sales set expectations with the buyer at the point the questionnaire is first mentioned rather than after it arrives.
Track three numbers: how many questionnaires arrive per month, how long each takes in elapsed days and in hours of effort, and what proportion of questions the library answered without new work. The third one is the health metric. If it is not climbing over time, the library is not being fed after each response, which is the single most common reason these programs stall.
Feed the library at the end of every response, not at the start of the next. Twenty minutes of writing new topics into the library while the reasoning is fresh is what makes the next one cheaper. Skipping it is how a company answers forty questionnaires and still has no library.
Two standard formats dominate. The CAIQ, the Cloud Security Alliance's Consensus Assessments Initiative Questionnaire, is aligned to their Cloud Controls Matrix and organized into domains covering the usual ground plus cloud-specific areas like virtualisation and interoperability. It is mostly yes or no with a notes column, which makes it fast to complete once and easy to keep current. A completed CAIQ can be submitted to the CSA's public registry, which some buyers check directly.
The SIG, from Shared Assessments, comes in sizes. The lighter version is a manageable few hundred questions covering the main risk domains and is what most buyers actually send. The full version is very large and is normally reserved for financial services and other regulated buyers assessing a critical supplier. SIG is more common in finance, insurance and healthcare procurement; CAIQ is more common with cloud and technology buyers.
The strategic move is to complete one standardized questionnaire properly and keep it current, then offer it proactively. When a buyer sends their bespoke spreadsheet, reply with the completed standard questionnaire plus your report and evidence pack, and ask whether that covers their requirement. A meaningful proportion of buyers will accept it, because their security team would rather read a familiar format than parse your prose. The ones who decline have a real requirement and you fill in their form, having lost nothing.
Do not complete both a CAIQ and a full SIG speculatively. Pick the one your buyer segment uses. If your customers are banks and insurers, do the SIG. If they are technology companies and cloud platforms, do the CAIQ. Doing both means maintaining two documents that will eventually disagree with each other, and a disagreement between two documents you published is a worse position than not having the second one.
Pushing back is legitimate and is done constantly by vendors larger than you. The trick is to push back on proportionality and on process, never on the buyer's right to ask.
Push back when the questionnaire is disproportionate to the engagement. A three hundred question review with a physical site visit for a twelve thousand dollar annual subscription to a tool that holds no customer data is a reasonable thing to question. Offer the alternative rather than refusing: your report under NDA, your completed standard questionnaire, and an offer to answer any specific residual questions on a call.
Push back when a question does not apply to your architecture. A pure SaaS product should not be answering questions about the buyer's data centre cage locks. Mark them not applicable with a one line reason rather than leaving them blank, because a blank reads as avoidance and a reasoned not-applicable reads as competence.
Push back when the questionnaire demands something you cannot give without harming other customers or yourself. Full penetration test reports with live findings, direct network access for a buyer's scanning team, a right to audit your own suppliers, unrestricted right to audit you on demand. Counter with what you can give: the executive summary, evidence of remediation, your supplier reports under NDA, a right to audit that is limited in frequency and requires notice.
Push back on timing when the questionnaire arrives at contract signature after nine months of sales process. That is a process failure on both sides and it is worth naming, because it repeats. The fix is to ask about the security review at qualification and get the questionnaire in flight early.
Do not push back by answering vaguely, and do not push back by delaying. Both read as evasion. If you are going to decline something, decline it explicitly in the response with a reason, and offer the alternative in the same sentence.
Every growing company answers some questions no, and reviewers know it. What separates a survivable no from a deal-killing one is whether it comes with context and a plan.
The pattern that works: state the position, state what compensates for it, state what is planned and by when if anything is. "We do not currently hold a SOC 2 report. Readiness work is under way with an observation window planned to open in January and a report expected in the second quarter. In the meantime we can share our policy set, our most recent penetration test summary and our completed CAIQ under NDA." That answer is credible, verifiable and gives the reviewer something to write in their own risk record.
The pattern that fails: a bare no, or worse, a yes that describes an intention. "Yes, we perform quarterly access reviews" when you have performed one, ever, is the answer that ends badly, because the buyer may ask for the last four and your own auditor will certainly ask for them later.
If a no is genuinely blocking the deal, that is information rather than a defeat. It tells you which control to build next, with a specific customer and a specific revenue number attached to it. That is a far better prioritisation input than a generic framework checklist, and it is the argument that actually gets budget approved.
Nothing leaves without a second read. The reviewer is checking four things and it takes fifteen minutes.
First, does any answer claim something the evidence does not support. Second, does any answer contradict your SOC 2 system description, your trust page, your policies, or a response you sent another customer. Third, has anything confidential leaked in: another customer's name, an internal hostname, an unremediated finding, a screenshot with someone's personal data in the corner. Fourth, are the blanks intentional, because an unanswered question in a returned questionnaire will come straight back as a follow-up.
The consistency check is the one that earns its keep. Your questionnaire answers, your public trust page and your audit report are three descriptions of the same system, written by different people at different times for different audiences. They drift. A buyer who reads all three and finds them aligned stops looking. A buyer who finds a contradiction starts.
Keep every sent response, dated, with the version of the answers used. When the same buyer sends a new questionnaire at renewal, the old response is the starting point, and any answer that has changed is a change you should be able to explain.
A published trust page will not eliminate questionnaires, and anyone who tells you otherwise is selling one. What it does is remove the easy questions from the ones you receive, deflect a share of reviews entirely at the smaller end of the market, and shift the conversation from "prove you are secure" to "here is our position, tell us what else you need".
The sections that do the deflection work are: your compliance position stated honestly, a subprocessor list with purposes and locations, where data is stored by region, your security contact and vulnerability disclosure route, a list of your approved policy titles, and a clear way to request the real documents under NDA. Those six things answer a surprising proportion of a standard review before it starts.
The hard rule is that the page can only say what you can evidence. A framework with no report or certificate on file reads as readiness in progress, never as certified. Publishing a claim you cannot back is a misrepresentation to every buyer who reads it, and it is the first thing an auditor finds when they search for you. The companion guide, what to publish on a trust centre, covers where that line sits in detail.
The measurable effect shows up in two places: the proportion of inbound requests that are "send us your report" rather than "complete our spreadsheet", and the number of questions per questionnaire that were already answered on the page. If neither number moves after six months, the page is not saying enough, or it is not linked from the places buyers actually look, which are your footer, your security page and your sales collateral.
The library that never gets fed. Forty questionnaires answered, no library, because nobody spends the twenty minutes at the end. Every response starts from zero forever.
The library keyed on question text. Looks like a library, functions as a search engine that never matches, because no two buyers word a question the same way.
The forwarded spreadsheet. Sending two hundred rows to three engineers and waiting. It never comes back complete, and the parts that do come back are inconsistent with each other.
The optimistic answer. Someone answers yes because the control is planned, or because it is true for one environment out of three. This is the failure that has consequences later rather than now, which is exactly why it happens.
The stale evidence pack. The report period ended eight months ago, the penetration test is fourteen months old, and the buyer checks the dates first.
The unowned response. Sales assumes security has it, security assumes sales is driving, and the questionnaire sits for eleven days.
The contradiction across documents. The questionnaire says quarterly, the policy says monthly, the trust page says continuously, and the buyer read all three.
The security review that starts at signature. Nine months of sales process and then a three week security review nobody planned for. The fix is at qualification, not at the end.
| Format | Typical size | Who sends it, and what it costs to answer |
|---|---|---|
| Buyer bespoke spreadsheet | 40 to 300 rows | Most common from mid-market and enterprise security teams. Highest cost per question because the wording is unique. A topic-keyed library still answers most of it. |
| CAIQ | Several hundred items | Cloud and technology buyers. Aligned to the CSA Cloud Controls Matrix, mostly yes or no with notes. Complete it once, keep it current, offer it proactively. |
| SIG Lite | A few hundred questions | Financial services, insurance and healthcare procurement. The version most buyers actually send. Reusable across every buyer who uses the standard. |
| SIG full | Very large | Regulated buyers assessing a critical supplier. Expect days, not hours, on the first pass. Reasonable to ask whether the lighter version will do. |
| Third party risk portal | 100 to 400 questions | Buyers using a managed vendor risk platform. No bulk paste, session timeouts, awkward evidence limits. Budget a half day even when you know every answer. |
| Document request only | One email | The best outcome. Report, policies and penetration test summary under NDA. Answer same day; it costs almost nothing and it ends the review. |
| Privacy or DPIA questionnaire | 20 to 80 questions | Privacy teams, often separate from security. Covers lawful basis, retention, subprocessors, transfers and data subject requests. Needs a different answer set. |
| AI or model use questionnaire | 15 to 50 questions | Increasingly common and increasingly separate. Training data, retention, hosting region, human review, and whether customer data reaches a model provider. |
| Insurance application | 30 to 60 questions | Underwriters at bind and renewal. Answers are warranties, not marketing. Treat accuracy here more strictly than anywhere else. |
With a working answer library, a mid-sized questionnaire of one to two hundred questions should take one person two to four hours of actual effort, returned inside five business days. Without a library the same document routinely consumes two weeks of elapsed time and several people. The elapsed time and the effort are worth tracking separately, because they have different causes: long elapsed time usually means the response is unowned or blocked on engineering, while high effort usually means the library is thin.
Build the content first regardless. Tools that suggest answers from a repository are only as good as the repository, and the expensive part of this work is writing accurate answers and keeping them current, not searching them. A structured document or a shared sheet with forty to eighty topics, each with a short answer, a long answer, supporting evidence and a review date, will carry a company a long way. Buy a tool when the volume is high enough that lookup time is genuinely the bottleneck, which for most companies is well past twenty questionnaires a quarter.
Say no, then say what compensates for it and what is planned. A bounded no with context is a normal thing for a reviewer to record and score. A yes that describes an intention rather than a practice is a representation you will be measured against later, by that customer during an incident and by your own auditor when they ask for the last four quarters of a review you have run once. If a specific no is blocking a specific deal, that is useful prioritisation information rather than a failure, and it is usually the most persuasive budget argument available to you.
You can decline the format, and you should sometimes. What works is offering a substitute rather than refusing outright: your SOC 2 report or ISO certificate under NDA, your completed standardized questionnaire, your penetration test executive summary, and an offer to answer specific residual questions on a call. Many buyers accept that, because their reviewer would rather read a familiar document than parse a new one. Refusing without offering an alternative reads as evasion and puts the deal at risk for no benefit.
No. Share an executive summary covering scope, methodology, test dates, the severity distribution of findings and the remediation status, plus evidence that the significant findings were fixed and retested. The full report is a map of how to attack your product, and handing it out multiplies the number of parties holding that map. A buyer with a genuine regulatory need for more detail is a conversation to have individually, usually resolved by a supervised read or a redacted version rather than a copy they keep.
It reduces them substantially but does not end them. A current Type II report will satisfy some buyers entirely, will shorten many questionnaires because reviewers skip the sections the report covers, and will change the tone of the rest. Buyers in regulated sectors, and any buyer with a mature third party risk function, will still send a questionnaire because their own regulator or policy requires them to complete one regardless of what you hold. The report changes the questionnaire from an investigation into a confirmation.
They are two standardized questionnaire formats maintained by different bodies for different audiences. The CAIQ comes from the Cloud Security Alliance and is aligned to their Cloud Controls Matrix, is mostly yes or no with a notes column, and is more common with cloud and technology buyers. The SIG comes from Shared Assessments, is available in a lighter and a full version, and is more common in financial services, insurance and healthcare procurement. Complete whichever one your buyer segment actually uses. Maintaining both means eventually publishing two documents that disagree.
One named person, usually whoever runs security or compliance, with a named backup for absences. Sales owns intake and the commercial context: which customer, which deal, what stage, and a real deadline. Engineering answers specific questions on a short deadline rather than receiving a forwarded spreadsheet. The arrangement that reliably fails is splitting the document across several experts with nobody accountable for the whole, because coherence across the answers is exactly what the reviewer is assessing.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We build the answer library and the evidence pack against your real environment, so the next questionnaire is a lookup instead of a project.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.