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.
Your buyer's counsel does this every week and has a house position on every clause. You are reading a data processing agreement carefully for the first time. The side that has done it before sets the pace, unless you arrive with your own.
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.
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.
A processor contract has to set out 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. It also has to commit you to a specific set of behaviours: 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 the controller respond to data subject requests, help with their own security and breach obligations, delete or return the data at the end, and make available what they need to verify all of it. If personal data leaves the region, standard contractual clauses are usually annexed 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 an intercom 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. The trap here is that 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.
Breach notification is where the legal stage and the technical stage meet. It is a contractual promise about how fast you will notice, which makes it the only paperwork in this stage that your engineering setup either supports or quietly contradicts.
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 costs a few hundred dollars once and 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 DPA, reviewed once by a lawyer. The single highest-leverage document a B2B SaaS startup can own, and it is reusable for every deal after.
- A current subprocessor list. Build it from your actual vendor spend, not from memory, and put a date on it.
- A retention schedule that matches reality. Including backups, which is the part that catches people.
- A defensible breach window, plus the detection behind it. Decide the number with the person who would receive the alert.
- A place to publish the stable parts. The 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.
Make the security schedule the part nobody argues with.
Vulnytics gives you an exploit-verified report on your external attack surface, continuous monitoring so your breach-notification clock starts when the event does rather than when someone notices, and a dated attestation letter your buyer's counsel can attach to the DPA.
Common questions
What is a DPA and do I need one to sell to enterprise?
What has to be in a subprocessor list?
What breach notification window should I commit to?
Why does the legal stage take longer than the technical review?
Can good technical evidence speed up the legal stage?
This 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, and it is not a substitute for your own counsel, who should review any agreement before you sign or offer it. Requirements vary by jurisdiction, by industry and by the data involved. Vulnytics combines exploit-verified automated assessment with hands-on expert review by a person. We are not a law firm and we are not an accredited penetration-testing firm, so our report complements, and does not universally replace, one from an accredited firm where a buyer specifically requires it.