You answered the questionnaire, sent the evidence, survived the technical pass, and the reply is not a yes or a no. It is a yes with a list attached. This is the most common way a real review ends, it is the last of the six stages, and how you spend the next two weeks decides whether the deal closes this quarter or next.
Founders lose time here for one avoidable reason: they read a conditional approval as a rejection and go quiet while they fix things. The buyer is waiting for a reply.
The three ways a review ends
| Outcome | What it means | What moves |
|---|---|---|
| Approved | Nothing to do. Rare on a first enterprise review unless the tier was low. | Everything. |
| Approved with conditions | They have decided to proceed. Things you must do are attached, with dates. | Contracting usually continues in parallel. |
| Deferred pending remediation | Named findings block the decision. No decision exists yet. | Nothing until those findings are closed. |
The middle one and the last one look similar in an email and are not the same situation. Find out which you have before you plan anything, and if the wording is ambiguous, ask. "Is this blocking signature, or can we run it alongside contracting?" is a one-line question that changes your whole fortnight.
Answer the same day, before you have fixed anything. Acknowledge each condition, say who owns it and when it will be done, and flag anything you think you cannot do. Silence while you work reads identically to silence because you are stuck.
Read the conditions properly
A conditions list usually mixes three different things, and they have different costs.
- Fix this. A specific finding with a deadline. The only kind that needs a re-test.
- Show us this. A document you have not sent yet: a policy, a subprocessor list, the DPA annexes. Cheapest to clear, and often the actual blocker.
- Commit to this. Something ongoing, like rescanning on a schedule or notifying them of new subprocessors. Costs nothing today and everything if you forget it in month four.
Sort the list into those three before you start. The second category is usually a day of work sitting behind an assumption that the whole list is engineering.
What actually closes out a finding
Not the words "this has been resolved". A reviewer closing a finding has to write down why they closed it, and "the vendor said so" is not something they want in the file. Give them what they can check:
- The finding, restated as they wrote it. Same identifier, same target, same description. If they have to work out which finding you mean, you have added a round trip.
- What changed. One or two sentences. Not a commit log.
- Proof it no longer reproduces. A re-test of that specific finding, dated after the fix. This is the part people skip and it is the part that closes the item.
- Who verified it. An external re-test carries further than your own engineer's word, for the same reason a signed attestation carries further than a paragraph in an email.
Send them in one batch, not as they land. A reviewer picking up five separate emails over a week does five separate context switches and takes longer than one review of a complete pack.
From where the reviewer sits, an unverified fix and no fix look the same. Both are claims. The re-test is what converts your work into something that can be filed, and filing it is the thing that unblocks the deal.
Findings you cannot fix
Some conditions are genuinely not achievable on their timeline: they need an architecture change, a vendor who will not move, or a rewrite you are not going to do for one deal. This is normal and reviewers have a process for it.
What they need is a risk acceptance: the finding, why it cannot be fixed now, what you have done instead to reduce the exposure, and when you will revisit. Someone on their side signs it. What breaks the process is going quiet, or marking it resolved and hoping. The second one is much worse than the first, because when it surfaces it does not just reopen that finding, it makes the reviewer re-check everything else you told them.
Offer the compensating control yourself rather than waiting to be asked. "We cannot move off the shared instance this quarter; here is the network restriction and the monitoring we added, and here is the migration date" is a conversation. "Cannot fix" is an escalation.
How long you actually have
If the conditions carry dates, those are the dates. If they do not, the common shape is critical and high within 30 days, medium within 90, low at the next release. Ask rather than assume, and negotiate at the start rather than at the deadline.
The thing worth protecting is your own credibility on dates. A reviewer who watches you hit a date you set starts treating your other claims as reliable, which is worth more than the fortnight you would have saved by promising something faster. That is the same currency the questionnaire runs on.
The mistake that restarts the clock
Two things push a conditional approval back into technical review, and both are avoidable.
The first is changing something material about the system while you are closing findings. If you ship an architecture change during remediation, the assessment they did is now partly about a system that no longer exists, and a careful reviewer will say so. Fix the findings; ship the redesign after the file is closed.
The second is evidence that does not match the finding: a re-test against a different host, or run before the fix, or covering the class rather than the instance. It reads as either carelessness or an attempt to paper over something, and neither is recoverable in the same week.
What good looks like
Same-day acknowledgement with owners and dates. The document requests cleared in 48 hours. One batched evidence pack per deadline, each finding restated as they wrote it, each with a dated re-test. Anything unfixable raised early with a compensating control attached. And if the conditions include an ongoing commitment, a way to keep it that does not depend on remembering.
Done that way, a conditional approval is not a setback. It is the last stage of a process you have nearly finished, and it is the one where being organised is worth more than being fast.
Prove the finding is gone, not just fixed.
Vulnytics exploit-verifies each finding, re-tests after you fix so you can show it no longer reproduces, and issues a dated attestation letter your buyer's reviewer can file. The scheduled rescans also cover the ongoing conditions, so the commitment you made in month one is still true in month four.
Common questions
What does approved with conditions mean in a vendor security review?
How quickly do I have to fix the findings?
What evidence actually closes out a finding?
What if I cannot fix a finding?
Does closing out conditions restart the whole review?
This describes how enterprise reviewers commonly handle conditional approvals and remediation, and is general guidance rather than legal, compliance or contractual advice; the conditions you receive and your own counsel govern what you agree to. Vulnytics combines exploit-verified automated assessment with hands-on expert review by a person. We are not an accredited penetration-testing firm, so our re-test complements, and does not universally replace, one from an accredited firm where a buyer specifically requires that the original tester signs off.