You Failed a Customer Security Review. Here Is How to Reopen the Deal

Direct answer: Ask for the specific findings in writing, fix the ones that are blocking rather than all of them, and go back with evidence inside two weeks. Most failed reviews are recoverable, because the reviewer usually wanted to approve you and could not justify it on what they were given.

Find out what actually failed

"Did not meet our security requirements" is not a finding, it is a summary. Ask your champion for the specific items. Reviewers will normally share them, because a vendor that closes gaps is less work than running a new procurement.

When the list comes back, separate the blocking items from the nice-to-haves. A missing SOC 2 report is usually blocking. A missing formal asset inventory usually is not, if you can show the underlying control works.

Fix the blockers, not everything

The instinct after a rejection is to overhaul the whole programme. That takes months and the deal will not wait. Work only the items that stopped the approval, get evidence for each, and leave the rest for the programme you build afterwards.

Sometimes the blocker is not a control at all. It is that you answered inconsistently across the questionnaire, or claimed something you could not evidence. That is fixed with a corrected, documented response rather than engineering work.

Going back

Send a short written response that lists each finding, what changed, and the evidence attached. Do not re-argue the original answers. Reviewers respond well to a vendor who took the list seriously and came back quickly, because it tells them what you will be like as a supplier.

Speed matters more than completeness here. A response in two weeks with four of six items closed and dates on the rest lands better than a perfect response in three months, by which point the budget has usually moved.

The part that matters after the deal

A failed review is a preview. The next enterprise buyer will run the same process, and probably a stricter one. Fixing the blockers reopens this deal; building the programme is what stops the next review going the same way.

Enterprise Security Review Support is built for exactly this moment, and if the recurring blocker is that you have no report to hand over, SOC 2 in 75 Days is the usual answer.

What the reviewer is actually scoring

It helps to understand the position the person on the other side is in. A vendor security reviewer at an enterprise is rarely trying to keep you out. They have an internal standard, a queue of vendors, and a requirement to justify every approval to their own auditor. Their risk is not that you have a weak control. Their risk is approving you and then having to explain the decision after an incident.

That changes what a good response looks like. You are not persuading someone that your security is adequate in the abstract. You are giving them the artefacts they need to write "approved" next to your name and defend it later. A screenshot with a date on it does that. An assurance from your CTO that the control exists does not, because they cannot put it in a file.

It also explains why reviewers so often accept a remediation plan. A dated commitment with an owner is something they can attach to a conditional approval. Silence is not.

The blockers that come up most often

Across the reviews we get pulled into, the same handful of items stop approvals. Knowing which one you hit tells you roughly how long the fix takes.

No third-party assurance report. No SOC 2, no ISO 27001 certificate, nothing an auditor produced. This is the slowest blocker because you cannot fix it in a fortnight. It is also the one where a partial answer works best, and we cover that below.

No recent penetration test. Common, and much faster to resolve. Most reviewers want a report dated inside twelve months with a defined scope, and many will accept a scheduled test with a start date if the rest of the picture is solid.

Access control evidence. Multi-factor authentication on admin access, a joiner and leaver process with proof it ran, and quarterly access reviews. Reviewers ask for the last review, not the policy describing it. Companies fail here far more often on evidence than on the underlying control.

Encryption and key handling. Encryption at rest and in transit is normally fine. What trips people is who can decrypt, where keys live, and whether production database access by engineers is logged.

Logging and detection. "We have CloudTrail enabled" is not what is being asked. The question is whether anything reads the logs, who is alerted, and what the response time commitment is.

Sub-processors and data residency. Increasingly the sharp one, particularly if the buyer is Canadian public sector or a regulated financial firm, or if you have quietly added an AI feature that ships customer content to a model provider you never disclosed.

Business continuity. A restore that has never been tested. Reviewers ask for the date of the last restore test, and a surprising number of companies have never run one.

When the blocker is "you have no SOC 2"

This is the hard case, because the honest timeline for a Type II is longer than the deal will wait. There are four moves that work, in rough order of strength.

A Type I report covers design of controls at a point in time and can be produced far faster than a Type II. Some reviewers accept it as an interim with a committed Type II window. Ask before you spend money on one, because a minority of reviewers explicitly do not.

A documented readiness position is the next best thing. That means the control list, the owner for each, the evidence you already hold, the gaps, and dated remediation. It is not an assurance report and you should never present it as one, but it converts "no security programme" into "a programme mid-build with an external timeline". Documenting that position carries weight with audit firms as well as buyers. On one engagement the audit firm reduced its own quote by $11,000 once the readiness position was documented, which is described in more detail here.

A recent independent penetration test carries real weight with technical reviewers, because it is the one artefact that shows an outsider actually attacked the product rather than reading a policy.

Contractual commitments are the last resort and are sometimes enough for a mid-market buyer: a security exhibit in the agreement committing you to a certification date, with a termination right if you miss it. Only offer this if you intend to meet the date. Missing it is a worse conversation than the one you are in now.

Writing the response so it gets read

The response document should be boring and short. One table, one row per finding, four columns: the finding as the reviewer worded it, what changed, the evidence attached, and the date it was completed. Attach the evidence as separate named files rather than pasting screenshots into a slide deck, because the reviewer will file them individually.

Use their wording, not yours. If they wrote "no formal vulnerability management process", do not respond under a heading called "Patch Programme Improvements". Reviewers reconcile your response against their original list line by line, and any item they cannot match reads as unaddressed.

For items you have not fixed, give a date and a named owner rather than a status. "In progress" is the phrase most likely to get your response bounced back. "Access review process defined, first quarterly review scheduled 14 October, owned by the VP Engineering" is answerable.

Send it to your champion and ask them to forward it to the reviewer, unless the reviewer has already contacted you directly. Going around the champion to the security team is occasionally the right call, but only after telling the champion you are going to.

When the review was not really the reason

Sometimes the security review is where a deal that had already died went to be buried. The signals are reasonably clear. The findings arrive vague and stay vague after you ask for specifics. Your champion goes quiet rather than helping you chase. The list includes items no buyer of that size normally requires, or the requirements shift after you close the first set.

If two of those are true, spend an hour testing the deal rather than a month rebuilding controls. Ask your champion directly whether closing these items gets the purchase approved this quarter. A champion who wants the product will answer. If the answer is hedged, you have learned something more useful than any remediation plan would have taught you, and you have saved the engineering time.

Stopping the next one arriving in the same shape

The lasting fix is not a better questionnaire answer, it is removing the need for the questionnaire to be answered from scratch each time. Three things do most of the work.

Keep one answer library, owned by one person, where every questionnaire response is stored with the evidence that supports it. The inconsistent-answer failure mode is caused almost entirely by three people answering three questionnaires from memory in different weeks. A shared register, whether that is the free traztech Workspace or something you build yourself, ends it.

Publish what you can before you are asked. A trust page with your policies, sub-processor list, uptime, architecture summary and current certification status deflects a meaningful share of reviews entirely and shortens the rest.

Diarise the evidence that expires. Penetration test reports, access reviews, restore tests and risk assessments all go stale, and a review failed on a stale artefact is the most avoidable kind. Put the renewal dates in the same calendar as your audit dates.

When you should handle this without us

If the findings list is short and technical, close it yourself. Enabling MFA on your cloud console, turning on backups with a tested restore, and writing down your onboarding and offboarding steps are engineering tasks, and paying a consultancy to project-manage four fixes is money you should spend on the penetration test instead.

If you already have a security lead, this is their work and they will do it faster than an outsider who has to learn your architecture first. Bring in help for the artefact you cannot produce internally, usually the independent test or the audit, and keep the questionnaire work in-house.

And if this is your first enterprise buyer and the rest of your pipeline is small and mid-market, think hard before committing to a full certification on the strength of one deal. A fixed-scope readiness engagement costs a fraction of an audit and tells you what the real gap is. Commit to the audit when two or three buyers in a row have asked, not when one has. Where outside help genuinely earns its cost is the recurring case: reviews arriving monthly, each one pulling engineers off the roadmap, at which point a standing arrangement is cheaper than the interruptions.