You passed the technical review and the deal went quiet for three weeks. The four documents legal asks for, what each one has to contain, and the five things that stall the longest stage.
- Published
- Updated
- Reading time
- 11 min read
- By
- Zaaf review desk
In this guide
You passed the technical review. The engineer is satisfied, the findings are fixed, and then the deal goes quiet for three weeks. This is the stage nobody warns founders about, and in the six stages of a vendor security review it is reliably the longest one: one to four weeks, often longer than the technical review that preceded it.
What makes it strange is that it is not about your security at all. It is about your paperwork.
Why this stage runs longer than the technical one
Every earlier stage asks the buyer to read something. The questionnaire, the report, the attestation letter: one person reads, and either accepts or asks a follow-up. Legal review asks the buyer to write something. Counsel produces redlines, routes them past a privacy lead and sometimes procurement, and then waits on your answer to each one.
That changes the arithmetic. The duration is not set by how hard the questions are. It is set by how many round trips happen, and each round trip is a week because it crosses two organisations' queues. Three exchanges is a month, and three exchanges is normal if you are receiving their paper and reading it for the first time.
The four documents they will ask for
| Document | What it answers | Who asks |
|---|---|---|
| Data processing agreement | What you are allowed to do with personal data your customer puts into the product. | Legal, always |
| Subprocessor list | Which third parties can reach that data, for what, and where. | Privacy, always |
| Retention and deletion schedule | How long you keep it and what happens when the contract ends. | Privacy, usually |
| Breach notification commitment | How fast you will tell them, and what the notice contains. | Legal and security |
These four travel together. The DPA is the contract; the other three are usually annexes to it, which is why an incomplete subprocessor list does not just delay one question, it holds up the signature on the whole thing.
- DataWhat personal data enters the product?
- ProcessorsWho else can reach it, and where?
- LifecycleWhen is it returned or deleted?
What each one actually has to contain
The DPA. If your buyer is subject to GDPR or UK GDPR and you process personal data on their behalf, they are legally required to have a processor contract with you. It is not a preference and there is no version of the deal without one. What is genuinely negotiable is whose paper it sits on and how the liability is shaped.
- What the contract describes. The subject matter and duration of the processing, its nature and purpose, the types of personal data and categories of data subject, and the controller's rights and obligations.
- What it commits you to. Process only on documented instructions, keep the people who handle the data under confidentiality, apply appropriate security measures, follow rules before engaging a subprocessor, help with data subject requests and with the controller's own security and breach obligations, delete or return the data at the end, and make available what they need to verify all of it.
- What gets annexed. If personal data leaves the region, standard contractual clauses are usually attached as well.
The practical move is to have your own reviewed DPA ready to offer. Not because yours is better, but because offering first means their counsel is redlining a document instead of drafting one, and that is frequently the difference between one exchange and three.
The subprocessor list. Every third party that can access customer personal data, what it is used for, and where it processes. Founders reliably under-list this. The cloud provider is obvious. The ones that get missed are the analytics tool, the support desk, the transactional email service, the error tracker that captures request payloads, and increasingly the AI vendor sitting behind a product feature.
Under-listing is the expensive mistake, because a reviewer checks the list against what your product visibly does. If they can see a chat widget on your site and it is not on the list, they now doubt the list, and a doubted list means every other answer gets a second look. Buyers also expect a mechanism to be told before you add a new subprocessor, typically with a notice period and a right to object.
Retention and deletion. How long you hold each category of data, and what happens at the end of the contract. This is the one annex that describes something you have to actually do. Committing to delete customer data within thirty days of termination means you need a way to delete it, including from backups, and a way to say when you did. Write the schedule that matches your system, then fix the system if the schedule embarrasses you. Do not write the schedule you wish were true.
Breach notification. Buyers commonly ask for notification "without undue delay" and often name a number: 24, 48 or 72 hours from the moment you become aware. This is the easiest clause in the document to sign and the hardest to honour, for a reason that has nothing to do with legal drafting.
The clock starts at awareness. Awareness depends on detection. If you have no alerting on your external surface and nothing watching for change, your awareness could lag the event by weeks, and the 24-hour commitment you signed was already unmeetable when you signed it. Agree to a window you can defend, and put the detection in place that makes it true.
What actually stalls it
- Receiving their paper cold. You read a twenty-page DPA for the first time while the deal ages. Having your own is a one-off piece of work that saves that month repeatedly.
- A subprocessor list that does not match the product. One visible omission converts the whole legal stage from processing into interrogation.
- Unlimited liability on data protection. This is the clause deals genuinely die on, and it is the one place where you need your own counsel rather than a template. It is a commercial question wearing legal clothing.
- A breach window nobody checked with engineering. Signed by a founder, discovered by an engineer, renegotiated in month two.
- Sending it late. The legal stage can run in parallel with the technical one and usually should. Nothing in it depends on the outcome of the security review.
What to prepare before anyone asks
- Your own DPAReviewed once by a lawyer. The single highest-leverage document a B2B SaaS startup can own, and reusable for every deal after.
- A current subprocessor listBuilt from your actual vendor spend, not from memory, with a date on it.
- A retention schedule that matches realityIncluding backups, which is the part that catches people.
- A defensible breach windowPlus the detection behind it. Decide the number with the person who would receive the alert.
- A place to publish the stable partsThe subprocessor list and retention summary are exactly what a trust page is for, and publishing them removes a request from every future review.
Where this meets the technical evidence
Most DPAs attach a security schedule: a description of the technical and organisational measures you have in place. This is the seam between the two halves of the review, and it is where founders write the vaguest prose in the entire document, because it is a legal annex being drafted from memory.
A reviewer treats that schedule the way they treat everything else. If it says you test your external surface and the claim is backed by a dated attestation letter and a report they can check, the schedule is accepted as drafted. If it says you follow industry best practices, they send questions, and questions in this stage cost a week each. It is the same principle that governs the questionnaire: reviewers accept what they can verify.
This does not shorten the contract negotiation. Liability caps and governing law are not affected by how good your security is. But it removes the security schedule from the list of things being argued about, and in a stage measured in round trips, removing one is worth a week.
Before you send
A quick final check
Common questions
What is a DPA and do I need one to sell to enterprise?
A data processing agreement is the contract that governs what you may do with personal data your customer puts into your product. If your buyer is subject to GDPR or UK GDPR and you handle personal data on their behalf, they are required to have one with you, so it is not optional and not negotiable in principle. What is negotiable is whose paper it sits on. Offering your own reviewed DPA early is usually faster than waiting to receive and redline theirs.
What has to be in a subprocessor list?
Every third party that can access customer personal data, what each one is used for, and where it processes the data. That means your cloud provider, and also the analytics, support desk, email delivery, error tracking and AI services that touch customer content. Buyers also expect a way to be notified before you add one. The list is checked against what your product visibly does, so an incomplete list is worse than a long one.
What breach notification window should I commit to?
One you can actually meet. Buyers commonly ask for notification without undue delay and often name 24, 48 or 72 hours from becoming aware. The number is easy to sign and hard to honour, because the clock starts at awareness and awareness depends on detection you have to already have. Agreeing to 24 hours with no alerting in place is a commitment you would breach the first time something went wrong.
Why does the legal stage take longer than the technical review?
Because it is the only stage where the other side has to write something rather than read something. Technical review is one engineer reading your evidence. Legal review is counsel producing redlines, routing them past privacy and sometimes procurement, and waiting on your answer to each one. Every round trip costs a week, so the number of round trips, not the depth of the questions, sets the duration.
Can good technical evidence speed up the legal stage?
Indirectly, and in one specific way. The security schedule attached to most DPAs describes the technical and organisational measures you have in place, and a reviewer who can check those claims against a dated report accepts the schedule as written instead of sending questions about it. It does not shorten the contract negotiation itself, which is about liability and jurisdiction rather than about your security.
NoteThis describes what enterprise buyers commonly ask for at the legal and privacy stage of a vendor security review. It is general guidance, not legal, privacy or compliance advice; requirements vary by jurisdiction, industry and data, and your own counsel should review any agreement before you sign or offer it.