Most vendor security reviews end with a yes and a list. How to read the conditions, what evidence actually closes a finding, what to do with the ones you cannot fix, and the mistake that restarts the clock.
- Published
- Updated
- Reading time
- 9 min read
- By
- Zaaf review desk
In this guide
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, 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. If the wording is ambiguous, ask: "Is this blocking signature, or can we run it alongside contracting?" One line, and it changes your whole fortnight.
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 retest.
- 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. It 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 hiding behind the assumption that the whole list is engineering.
- RecordCapture the exact condition, as they wrote it.
- AssignName an owner and a target date.
- VerifyAttach evidence of the changed state.
What actually closes 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 retest 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 retest carries further than your own engineer's word, for the same reason a signed attestation carries further than a paragraph in an email.
- # Restated as written in the review
- Finding ZF-0098-03 Invoices visible across workspaces
- Target GET /v1/invoices/{id}
- Changed Ownership check on the invoice workspace
- Retest 2026-06-18, after the fix
- Result HTTP/1.1 403 Forbidden
- Verified Named researcher, Zaaf review desk
Illustrative. Same finding, same target, dated after the fix.
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.
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 it. Someone on their side signs it. What breaks the process is going quiet, or marking it resolved and hoping. The second is much worse: 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, a 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 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.
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. Ship an architecture change during remediation, and the assessment they did is now partly about a system that no longer exists. 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 retest against a different host, run before the fix, or covering the class rather than the instance. It reads as carelessness or as papering over something, and neither is recoverable in the same week.
What good looks like
Same-day acknowledgement with owners and dates. Document requests cleared in 48 hours. One batched evidence pack per deadline, each finding restated as they wrote it, each with a dated retest. Anything unfixable raised early, with a compensating control attached. And for ongoing commitments, a way to keep them 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 the one where being organised is worth more than being fast.
Before you send
A quick final check
Common questions
What does approved with conditions mean in a vendor security review?
The buyer has decided to proceed and has attached things you must do. Commercially it is a yes: contracting can usually continue in parallel. It is very different from deferred pending remediation, where nothing moves until named findings are closed.
How quickly do I have to fix the findings?
Whatever the conditions say, and if they do not say, ask. Common shapes are critical and high within 30 days, medium within 90 and low at the next release. Agree a date you can meet, then meet it.
What evidence actually closes a finding?
Something the reviewer can check: a retest of the specific finding showing it no longer reproduces, dated after the fix, with enough detail to tell it is the same finding and the same target.
What if I cannot fix a finding?
Say so early, explain what stops you, and offer a compensating control and a date. Reviewers handle this with a documented risk acceptance, usually signed by someone on their side.
Does closing out conditions restart the whole review?
Usually not, unless you change something material about the assessed system, or send evidence that does not match the finding as written.
NoteThis describes how enterprise reviewers commonly handle conditional approvals and remediation. It is general guidance, not legal, compliance or contractual advice; the conditions you receive and your own counsel govern what you agree to.