“We need this signed by Friday.”
The procurement director does not sit down. She is standing in the doorway, laptop under one arm, phone in hand, mind already on her next meeting. End of quarter is eight business days away, and the procurement director wants this deal locked in before then. The vendor’s rep has started using phrases like commercial flexibility expires at quarter close, and the business owner wants the vendor live ASAP.
Across the table, the privacy lead does not look impressed. Mostly because he looks tired.
“We need the privacy review packet,” the privacy lead replies, without looking up. “Including subprocessor list, retention terms, cross-border transfers, whether they train models on customer data, and the DPA.”
The procurement director exhales. “It’s a standard SaaS agreement.”
The privacy lead finally looks up. “Just because you say the word standard doesn’t make a vendor standard.”
“It’s low risk,” procurement says. “We’re buying software, not launching a rocket.”
“You’re buying software that integrates with HR, ingests employee data, stores support logs, uses subprocessors in multiple regions, and has AI features enabled by default,” privacy says. “That is not no-risk. That is a review.”
The procurement director points at the queue board. “You have twelve reviews in progress.”
“Yes,” privacy says. “That is what ‘overloaded’ looks like.”
“We cannot miss this deal because your team needs perfect paperwork.”
“And we cannot bless a contract because your team discovered privacy on day fifty-seven of a sixty-day deal cycle.”
The room goes quiet in the way rooms do when everyone is technically correct.
That is what makes vendor contracting such an excellent recipe for misery. Procurement wants speed. Privacy wants guardrails. Legal wants fallback clauses. Security wants diligence. The business wants the tool yesterday. The vendor wants signatures by Friday and will absolutely describe every issue as “non-standard but market.” No one in the room is irrational. They are just operating inside a workflow that depends on urgency, improvisation, and selective surprise.
When vendor diligence is slow, the business routes around it. When vendor diligence is chaotic, the business stops trusting it. When vendor diligence is treated as just a contract exercise, privacy and security risk slips through the cracks because the real questions never get asked early enough.
The good news is that this is usually (you always have that one co-worker… right?) not a personality problem. It is a workflow problem. And workflow problems are fixable.
You do not need a giant transformation program. You need three things that sound boring and end up being surprisingly powerful, and those are a minimum viable intake packet, routing rules that replace debate with defaults, and a clear definition of what “approved” actually means.
Scale Your IRL Campaigns Like Digital Ads
Out Of Home advertising has long been effective but hard to scale—until now. AdQuick makes it simple to plan, deploy, and measure campaigns with the same efficiency and insight you expect from online marketing tools.
Marketers agree: OOH is powerful for brand growth, driving new customers, and reinforcing messaging. AdQuick makes it easy, intuitive, and data-driven—so you can treat real-world campaigns like any other digital channel.
Why this keeps happening
Most organizations still treat vendor review like an event. A request appears. Someone marks it urgent. A cross-functional thread erupts. Procurement asks for turnaround by end of week. Privacy asks basic questions nobody can answer. Legal redlines the DPA after the business has already promised a launch date. Security asks for the SOC 2 three days before signature. Then everyone concludes the process is broken because the teams are “not aligned.”
That is right but also not. They are not aligned, but alignment is not the root issue. The real problem is missing routing.
A functioning vendor privacy review program treats vendor review as a process with steps and actions that everyone knows and can be triggered before the draft contract even comes over. It starts with intake. Then triage. Then diligence scaled to risk. Then contracting guardrails. Then a recorded decision. Each step has an owner. Each step has an input. Each step has an output. It might feel like bureaucracy if you don’t have a current intake process now, but it creates clarity, visibility, and the ability for the organization to know what lane a request is in, what facts are required, what depth of review applies, and who can say yes, yes-with-conditions, no, or escalate. It even helps your teams shift one review before another based on criticality, required diligence, and timing, because all the reviews are in the same process with the same base intake criteria.
If you don’t define this process, your organization will still have it. It will just be informal, inconsistent, and impossible to defend later. It’s also how you get the worst of both worlds… deals that still move slowly and risk that still gets missed.
FREE LIVE WORKSHOP FROM THE PRIVACY DESIGN LAB!

Are you tired because every privacy issue turns into a bespoke project?
That’s not a maturity problem. That’s a change management problem.
On March 31, I’m hosting a free workshop on how the Privacy Change Engine framework helps privacy teams operationalize change using ideas borrowed from the software development lifecycle — not just static policies and lifecycle diagrams.
If your program keeps getting stuck in the messy middle between issue-spotting and implementation, this workshop is for you.
The minimum viable packet
Privacy and security cannot review a vendor based on vibes, optimism, or the sentence “everyone else uses them.” The biggest source of delay in vendor review is not the review itself. It is the scavenger hunt for basic facts after the request has already become urgent.
The fix is a minimum viable intake packet. Not a giant intake form nobody completes. Not a twenty-page questionnaire for every coffee-subscription app. A short, enforced packet with enough information to let the right team make the right call.
Sidebar: Note that if you’re a highly regulated entity, like a school district, or a government contractor, or subject to HIPAA, you might still need that long questionnaire, and I’m sorry about that, but this probably isn’t the intake form for you.
At minimum, your vendor intake packet should answer six questions:
What is the vendor doing?
A one-paragraph business description is enough. “CRM for enterprise sales” is useful. “Software platform” is not.
What data is involved?
Not just “customer data.” Be specific: employee data, consumer account data, health data, payment information, support transcripts, behavioral analytics, source code, location data, for example.
How does the vendor interact with the data?
Access only, storage, hosting, analytics, model training, support access, integration with internal systems, or direct collection from users, for example.
Where does the data go?
Regions, hosting locations, subprocessors, support locations, and whether cross-border transfers are expected.
What security and privacy artifacts are readily available?
SOC 2, ISO certifications, security summary, penetration-test summary, subprocessor list, DPA, retention terms, incident-notification commitments.
What is the business urgency?
Not “urgent.” Actual dates, dependency, and consequences. “Need production access before April 1 to support payroll migration” is meaningful. “Please rush” is not.
That packet does two important things.
First, it gives privacy and security enough signal to start. Second, it creates trust with procurement because the lane is predictable. Procurement does not actually hate process. Procurement hates vague process that somehow begins only after commercial terms are final and everyone is already angry.
A good intake packet reduces drama because it shifts work forward and forces the parties to answer basic questions before the request turns into a hostage situation.
Triage and routing: defaults beat debate
Once intake exists, the next job is triage. This is where most organizations fall apart, because everything becomes a bespoke argument. Procurement says every deal is strategic. Privacy says every data flow deserves scrutiny. Security says every integration expands attack surface. All of this might be true, but it’s not useful to get the deal signed. The goal is to replace debate with defaults.
A practical model looks like this:
Step 1: Intake
The business submits the minimum packet and attaches the vendor’s standard artifacts. No packet, no queue entry! This sounds strict because it is. It also saves everyone time.
Step 2: Tiering
Privacy or a designated risk owner assigns a tier based on a few criteria: sensitivity of the data, volume, system access, external sharing, cross-border processing, use of AI features, and business criticality.
A simple three-tier model is usually enough.
Tier 1: High-risk vendors processing sensitive or large-scale data, critical systems, or complex international transfers.
Tier 2: Moderate-risk vendors with limited personal data or bounded internal use.
Tier 3: Low-risk vendors with little or no personal data, limited integration, and standard services.
Step 3: Diligence depth
Tier determines the review depth. That is the whole point of tiering.
Tier 1 may require a fuller privacy review, targeted security diligence, legal approvals, and possibly an escalation if the vendor’s practices are unusual.
Tier 2 may require a shorter review, such as confirm data uses, confirm transfer mechanism, scan security posture, and validate baseline contract terms.
Tier 3 may need little more than a basic contract check and confirmation that no meaningful personal data is involved.
Without this step, every request becomes a fire drill because there is no shared agreement on what “enough” review looks like.
Step 4: Contracting
Legal should not reinvent fallback language every time a SaaS agreement lands. Standard positions on processing instructions, confidentiality, security measures, incident notice, deletion, audit rights, subprocessor notice, transfer language, and AI/data-use restrictions save enormous time. Know your guardrails before the redlines start. Also, that cuts down on everyone’s work.
Step 5: Decision memo
Every review should end with one of four outcomes: approve, approve with conditions, reject, or escalate. The memo can be short. It just needs to record the reasoning, conditions, residual risks, and owner of any follow-up.
That is what makes the process defensible later. Not that every deal was perfect, but that every deal had an intelligible decision.
How to keep it fast without making it useless
Speed comes from clarity. Most delays are caused by missing inputs and muddy decision rights, not by the existence of privacy review.
There are a few mechanics that make a disproportionate difference, and I’m going to go through them in turn.
Set service levels for review by tier. If the organization knows low-risk reviews move in two business days, medium-risk in five, and high-risk in ten, urgency becomes something you can manage. SLAs also force a more honest conversation. For instance, if the business starts procurement two days before quarter close, that is not a privacy failure. That is a planning failure. And as they say… your failure to plan is not my emergency.
Offer a short scoping call for complex vendors. Fifteen minutes with procurement, privacy, security, and the business owner can eliminate forty-seven emails worth of ambiguity. We all hate another meeting, but not when it speeds up fact-finding.
Use standard artifacts as your baseline and ask targeted follow-ups. A SOC 2 is not magic, but it is a useful starting point. So are ISO certifications, subprocessors lists, and public documentation. Do not ask a hundred generic questions when five specific ones will tell you what you need to know to plan.
Keep a vendor register. This is one of the least glamorous and most valuable controls in the whole system. If you know what was reviewed last year, what conditions were imposed, what data categories were approved, and when the agreement renews, repeat purchases become dramatically faster. You can also start to see patterns that inform future reviews, risk tiering, etc. The alternative is institutional amnesia.
Make ownership explicit. The business owns business justification and timing. Procurement owns the commercial process. Privacy and security own the risk call. Legal owns contract language. Executives own exceptions. If ownership is fuzzy, every difficult decision becomes an exercise in finger-pointing.
And define what “approved” means. This matters more than it sounds. In many organizations, “approved” actually means one of a five different things:
low enough risk to be acceptable as is,
acceptable risk with specific conditions,
acceptable if a feature is disabled,
acceptable for a narrow use case, or
acceptable because the business expressly accepted the risk.
If that distinction is not documented, people hear what they want to hear.
Where AI and cross-border issues now sneak in
Modern vendor review is no longer just about whether a vendor encrypts data and will sign your DPA. AI features and cross-border processing now show up as default product behavior, not edge cases.
A vendor may say it does not “train on customer data” in the marketing FAQ but reserve broad service-improvement rights in the terms. A collaboration tool may route support tickets globally. A transcription feature may invoke a third-party model provider. A product that was low-risk last year may now summarize user content, generate outputs from it, or retain prompts in ways the original review never contemplated.
That is why your intake packet should explicitly ask: Do you use customer data for model training? Are AI features enabled by default? Can they be disabled? What subprocessors support those features? Where are they located? What data-residency options exist? What transfer mechanism governs cross-border processing? Can customer data be segregated from service-improvement pipelines?
You do not need a perfect answer to every edge case on day one. But you do need to stop being surprised by the basics.
That is the real maturity move in vendor review. An elaborate fortress is not always the best path. Instead, try building a system that catches ordinary risk early enough that quarter-end does not become a hostage negotiation between procurement and privacy.
Because the procurement director is not wrong to want speed. And the privacy team is not wrong to want guardrails. The mistake is forcing both sides to fight the same preventable battle at the worst possible moment.
Fix the intake. Define the routing. Scale the diligence. Record the decision.
Then the next time someone says, “We need this signed by Friday,” the answer does not have to be panic. It can just be process.
Become a paid subscriber to get access to all of the mini tools that we publish with each post. For instance, this post includes a Vendor Intake Minimum Viable Packet.
Finally, reminder that the opinions expressed in this article are the opinion of The Privacy Design Lab. They are not legal advice, and no attorney-client relationship is formed by reading this article or downloading the M&A Privacy Integration Map. If you need to consult legal counsel, you can book a consult with ARLA Strategies or other legal counsel you trust!

If you’re tired of privacy advice that only works in theory, you’re in the right place.
The Privacy Design Lab exists for people who want to practice privacy, not just talk about it. It focuses on practical, repeatable ways teams actually learn. We offer hands-on workshops, downloadable systems, and the Design Studio community where teams and practitioners can go deeper. Paid Fieldnotes subscribers get access to our full archive, plus supporting materials you can actually use.
If that sounds like your kind of work, we’d love to have you.



