Third-party risk belongs inside the purchase workflow

I spent years running procurement at Discover Financial, where more than 20 teams touched some part of the buying process, including sourcing, legal, security, tax, privacy, and third-party risk management (TPRM).

TPRM carried one of the heaviest responsibilities in that process and yet had the weakest connection to it. The program lived in its own system, outside the procurement suite. Requesters didn't know when to loop in the risk team, and when a deal was moving fast, some requests went through with less diligence than they should have had.

We called it “a black box.” No one could see inside it, including the people running it.

In my experience, that disconnect causes more vendor risk failures than any bad vendor does. Every procurement team sees red flags, but the lasting damage happens when the review sits so far from the purchase that no one downstream can act upon what it finds.

Why point-in-time vendor risk assessments fall short

Traditional TPRM treats vendor risk as a gate you pass through once. You assess the vendor, file the report, and move on. 

That worked when vendor lists were shorter and buying ran through a central team. But in today’s more complex environment, it breaks down when purchasing authority is spread across dozens of departments and vendor relationships keep continually changing well after signature.

A point-in-time review can't see month fourteen of a contract. It misses everything that may slip since the last assessment, like ownership changes, new sub-processors added to a subscription, or updated security postures,

And because the review sits outside the purchase workflow, it's also easy to skip.

At Discover, I heard some version of "I didn't know I needed to loop in third-party risk" more times than I can count. Each of those people were trying to do their job correctly, but the process gave them no way to know.

The good news is there is now a better way.

How to build third-party risk management into procurement intake

Intake should know when a request needs a risk review, based on what's being bought and from whom. 

It should route the request there without anyone checking a wiki or asking a colleague. Cupcakes for an office party don't need a risk review, but a contract for AI infrastructure that touches customer data does.

Once the request is triaged, the workflow should start the right assessments for that vendor. That means TIN, VAT, and OFAC checks, bank account verification, and a review of the vendor's questionnaire responses against the risk domains, controls, and frameworks your team defines. After approval, continuous monitoring should flag any material change to the vendor's profile.

AI changes two things here. First, the document review that eats analyst hours (reading a SOC 2 report line by line, for example) can be automated. 

Second, because the checks run inside the purchase workflow, they run on every request. Enforcement no longer depends on a requester remembering. Procurement and risk work from one process and one record, and risk analysts spend their time on the vendors that need their judgment.

What changed when TPRM moved into the purchase workflow at Discover

We eventually connected the workflow at Discover. Requests that needed TPRM were routed there automatically, and review status flowed back into a single shared record.

We stopped hearing "I didn't know." Finding out when a vendor was last reviewed used to take days, and afterward it took minutes.

The programs that hold up are the ones where nobody has to hunt for answers. To see where your program stands, download Zip's new supplier risk maturity model.