300 questions standing between you and the deal
The spreadsheet arrived from their security team. Some answers are easy. Some are aspirational. And a few tell you something true about your infrastructure that you would rather not have found out during a sales cycle.
The questions that stop teams
Nobody gets stuck on the easy sections. They get stuck where the question assumes infrastructure that was never built.
Your largest prospect sent a vendor security assessment, and the sections on identity, logging, encryption and change management cannot be answered honestly today.
-
“Our biggest prospect sent a 300-question security questionnaire and we can't answer half of it.”
The deal is now paced by a security reviewer you have never met, and every "we plan to" answer invites a follow-up.
-
“We just realized a former contractor still has admin access.”
The access review question is answerable, and the answer is one you do not want to write down.
-
Nobody can say who can reach production, or how that is revoked.
Access management sections take the longest to fill in and carry the most follow-up questions.
-
Cloud credentials exist as long-lived keys in more than one place.
Key management and secrets questions turn into a remediation plan attached to the contract.
-
The answer to log retention is a guess.
Monitoring and incident response answers cannot be evidenced, and reviewers escalate rather than accept them.
What an unanswerable questionnaire costs
A security review is not a form. It is a procurement gate with a person behind it who is paid to be unsatisfied.
- The deal timeline
- Every round of follow-up questions adds a week, and enterprise reviewers batch their rounds. Three rounds is a quarter.
- Conditions in the contract
- Weak answers become remediation commitments with dates in the agreement, and you now have a deadline set by someone else's security team.
- Repetition
- The next enterprise prospect sends a different spreadsheet asking the same things. Without real controls, you rewrite the same intentions every time.
- Credibility
- Reviewers compare your answers against what they see in an architecture call. An answer you cannot demonstrate is worse than a gap you acknowledge.
What we do about it
We build the infrastructure that makes the answers factual, and give you the configuration to point at when a reviewer asks how you know.
-
Identity with one place to grant and revoke
Single sign-on with enforced multi-factor authentication, defined permission sets per role, production read-only except for named leads, time-limited sessions and reporting on access that has not been used.
-
No long-lived cloud credentials to disclose
A guardrail policy denies the creation of users and access keys outright, and pipelines authenticate with short-lived federated credentials instead.
-
Logging, encryption and segmentation as deployed facts
Organization-wide audit logging into a separate account, customer-managed encryption keys with rotation, enforced modern transport security, network flow logs and isolated production traffic.
-
Detection and change control you can describe
Threat detection, configuration monitoring, web application firewall rules, alarms on sensitive actions and a reviewed pull request behind every infrastructure change.
The outcome: Every identity, logging, encryption, monitoring and change-management question has a factual answer, and behind each answer is a configuration file you can show. The review stops being a negotiation about intentions.
What that is, in the portfolio
-
BuiltForProd Baseline
A multi-account cloud foundation in OpenTofu and Terragrunt, customized for your organization, deployed into your accounts by our engineers, then handed over with the repositories and the documentation.
-
BuiltForProd Assessment
A fixed-fee assessment of what you run today against the eight properties of the BuiltForProd Standard, with a prioritized gap list at the end.
What you get
-
Answers backed by configuration
For each control area, a deployed mechanism and the code that defines it, so an answer can be evidenced in the same sentence it is given.
-
An access model that survives scrutiny
Named permission sets, no standing administrator access to production, and offboarding that removes access everywhere at once.
-
Evidence sources for the follow-up call
Configuration history, security findings, access analysis and the pull request history of every change, ready before the reviewer asks.
-
Architecture material for the review call
Architecture decision records and diagrams that describe the real system, so the technical call goes better than the spreadsheet did.
-
A repeatable answer set
The second questionnaire is mostly a copy of the first, because the controls behind the answers stopped changing.
-
The compliance mapping underneath
The same controls carry into a SOC 2, HIPAA or PCI DSS conversation when the prospect after this one asks for a report.
Every repository and every cloud account stays yours. We keep no standing access after handover. See security and ownership for how that is enforced, and pricing for how an engagement is quoted.
The answers you will be able to give
These are deployed properties, not policy statements.
| What | Figure | Where it comes from |
|---|---|---|
| Cloud users with passwords or keys | 0 | The AWS Enterprise Baseline denies IAM users and access keys with a service control policy. |
| Defined access roles | 11 permission sets | The AWS Enterprise Baseline identity design, with production read-only except for named leads. |
| Security services running | 9 services | The AWS Enterprise Baseline security framework, administered centrally from a dedicated security account. |
| Networks with flow logging | 6 of 6 VPCs | Every network in the AWS Enterprise Baseline, including the shared egress hub. |
| Unused access review | Every 90 days | The access analyzer configuration in the AWS Enterprise Baseline. |
| Alarms on sensitive actions | 7 alarms | CIS-aligned alarms in the AWS Enterprise Baseline covering root usage, policy changes and audit log changes. |
The same evidence is documented page by page in the product documentation and measured against the BuiltForProd Standard.
How it works
Four steps from the first conversation to a platform your team owns.
-
Send us the questionnaire
We read it against what you run today and mark the questions that are answerable now, answerable with work, and not answerable at all.
-
Scope the gap, fixed fee
The unanswerable rows become a prioritized infrastructure plan with a price attached before anything is built.
-
Deploy the controls
Our engineers deploy the foundation into your own cloud accounts, with the security services, identity model and logging the questionnaire is asking about.
-
Answer with evidence
Your team completes the spreadsheet from deployed configuration, and holds the follow-up architecture call with documentation that matches what is running.
Yes, but…
The objections we hear on the first call, answered plainly.
The deal closes in six weeks. Is there time for this?
Sometimes yes, sometimes no. We will tell you on the first call which control areas can realistically be deployed before their review and which are better handled as a dated commitment you can actually meet.
Can't we just answer honestly and promise to improve?
You can, and for some buyers that works. The risk is that the promises become contractual dates set by their security team, on a schedule you did not choose.
Is this the same thing as getting SOC 2?
No. A questionnaire asks what you do; an audit tests it over a period. The same controls serve both, which is why teams that build them for a questionnaire are in a much better position when a report is demanded next.
Our product is the differentiator. Why is infrastructure blocking the sale?
Because the reviewer is not evaluating your product. Your competitive advantage is your application, not your network design, which is exactly why the network design should not be improvised.
Questions
What is a vendor security questionnaire?
A vendor security questionnaire is a structured assessment sent by a prospective customer's security team before they will buy, covering identity and access, encryption, network security, logging and monitoring, change management, incident response and vendor risk. Answers are expected to be evidenced.
Which sections does BuiltForProd help with?
The infrastructure sections: identity and access management, encryption and key management, network segmentation, logging and monitoring, vulnerability management and change control. Policy, HR and legal sections remain yours.
Do we get documentation we can attach to our answers?
Yes. Architecture decision records, control documentation and runbooks are part of the handover, and every code sample in them is generated from your own deployed environment.
What if the prospect asks for a penetration test report?
That is application testing and it stays with you. What the platform provides is the hardening the testers will probe: private networks, least-privilege roles, a web application firewall and workload isolation.
Will this work for the next questionnaire too?
Yes, and that is most of the value. The controls are deployed as code, so the answers stay true, and the evidence for them is produced by the platform rather than assembled by hand each time.
More answers are in the FAQ and the support center.
Send us the questionnaire.
We will read it against what you run today and tell you which answers are real, which need work, and what we would deploy to make the rest true.