The vendor was already cleared, and security reviewed it again

Here is the week you recognise. A team in one business unit picks a tool, files an intake, and waits. Security opens a full assessment: the questionnaire, the SOC 2 read, the data flow diagram, the subprocessor list, the penetration test summary. Three weeks later the vendor is approved. What nobody in that thread knows is that the same vendor cleared the same review eleven months ago for a different unit, under a different intake, owned by a person who has since changed roles. The evidence exists. It is sitting in a folder, or an old ticket, or a reviewer's memory that has already moved on. So the review runs again, start to finish, because no record connected the two efforts.

The problem is not laziness, it is the absence of a shared record

It is tempting to blame the reviewer who did not check first. That is unfair and it misreads the mechanism. Security reviews the vendor again because there is no reliable place to answer the question that would stop the work: is this vendor already in use somewhere in this company, and was it cleared. When that question has no trustworthy answer, the safe move is to assume no and start fresh. A cautious reviewer who repeats a completed review is behaving rationally inside a system that hides the prior result.

The absence persists for structural reasons. Intake forms are scoped to a single request, so the second request has no memory of the first. Approvals live in ticketing systems that expire from view. Business units run their own procurement motions and rarely reconcile them. The people who did the first review are the same scarce people asked to do the second, and they are the least able to afford the duplication. This is the same fault line we described in three teams, three vendor calls, three different answers: parallel efforts that never touch because nothing forces them to.

Duplicated diligence taxes the reviewers you can least spare

A full security review is not a form. It is a senior person reading a SOC 2 report against your control framework, chasing the vendor for a subprocessor list, and making a judgement call on data residency. That person is a bottleneck for every acquisition in the company. When their time is spent re-clearing a vendor that already passed, the cost is not just those hours. It is every other review that queued behind the duplicate.

Quantify it in the ordinary way. If a full assessment consumes, for example, twelve to twenty hours of reviewer time, and a mid-size organisation runs even a handful of avoidable re-reviews a quarter, you have burned a reviewer week on work whose answer already existed. That is a week not spent on the genuinely new vendor with the genuinely unexamined risk. The duplication does not just waste time, it misallocates the scarcest attention toward questions that are already answered.

Prior approvals are reusable evidence, if the estate holds them

The fix is a mindset before it is a tool: treat a completed approval as evidence you can cite, not a fact you rediscover. A vendor cleared by one unit for a defined data scope has produced a finding. That finding does not evaporate because a different unit files a different form. It should attach to the vendor, survive the person who ran it, and surface the moment the same vendor appears again anywhere in the company.

That is what the estate record does. Spend visibility surfaces where the vendor is already in use, and the vendor record carries the approval, the scope it covered, and when it was granted. The second request no longer starts blind. It starts with the answer in front of it, which turns a full review into a confirmation. This is the same estate discipline we mapped in the estate map, and it is a close cousin of the pattern in the intake asks to buy what a contract already gave you: a company repeatedly re-acquiring something it already holds because no record told it otherwise.

Confirm, do not repeat: the motion that removes the duplication

The platform motion is deliberately unglamorous. When a request names a vendor, the estate record answers three questions before a reviewer opens a questionnaire. Is this vendor already in use here. Was it cleared, and for what data scope. Is that clearance still current. If yes to all three and the new request fits the prior scope, security signs a confirmation. If the new request expands the scope, for example moving from marketing analytics to processing customer PII, then the delta gets reviewed, not the whole vendor again. Reviewers spend their judgement on the difference, which is where the real risk lives.

Underneath, the estate is kept current by the same background machinery that keeps the rest of the platform honest, the six specialist agents and the thirty background jobs that reconcile spend, contracts, and vendor records. Freshness matters here as much as coverage, for the reasons we lay out in how benchmark data stays fresh: a stale approval that no reviewer trusts is worth almost nothing, so the record has to carry the review date and let security judge currency for itself.

What this does not solve

Be honest about the limits. A prior approval is only reusable if it is genuinely comparable. A clearance granted for a low-risk marketing tool does not authorise the same vendor to process regulated customer data, and the platform will surface that scope gap rather than paper over it. The estate can tell security a review exists and what it covered. It cannot decide for security whether an eighteen month old finding is still current under a changed threat landscape. That judgement stays with your reviewers, and it should.

The record also depends on your data. If a prior approval was never logged anywhere the platform can read, it cannot surface what does not exist, though it will still catch the duplication the moment both requests touch the spend and estate view. And none of this substitutes for the up front discipline of getting security scope into intake in the first place, the gap we cover in the spec skipped compliance. What the platform removes is the specific, avoidable waste of re-running a review whose answer already lives in your estate. That is not the whole diligence problem. It is the part that never needed doing twice.