Best
The short answer
A third-party risk management process runs: request, tier, assess, decide, contract, onboard, monitor, re-assess, exit. Every programme stalls at the same stage, which is waiting for the supplier to return evidence. That step is the only one whose duration is outside your control, so the flow should be designed to start it early and to keep working while it is outstanding, rather than treating it as a gate that blocks everything behind it.
On this page
The nine stages
| Stage | What happens | Output |
|---|---|---|
| 1. Request | The business asks to use a supplier, ideally before signing anything | A registered request with a business owner |
| 2. Tier | Classify by what breaks if the supplier stops | A tier that sets everything downstream |
| 3. Assess | Gather evidence proportionate to the tier | A scored assessment with recorded reasoning |
| 4. Decide | Approve, approve with conditions, or refuse | A decision with an owner and a date |
| 5. Contract | Ensure the required security and regulatory clauses are present | A contract with clause coverage recorded |
| 6. Onboard | Provision access, register the supplier, set the review date | A register entry, not a closed ticket |
| 7. Monitor | Watch for incidents, certification expiry, and change | Alerts that reach a person |
| 8. Re-assess | On the cycle, and on triggers | An updated score and decision |
| 9. Exit | Offboard, revoke access, retrieve or delete data | Evidence that access actually ended |
Stage nine is the one most often missing entirely. Access that outlives the relationship is a finding waiting to happen, and it is the same failure the access review is designed to catch after the fact.
Where it actually stalls
Stage three is the bottleneck, and specifically the part of stage three where you are waiting for a supplier to return a questionnaire or a certificate. Everything before it moves at your pace. Everything after it is fast. The waiting is what turns a two-week process into a two-month one, and it is what makes the business start signing contracts without telling you.
Three design responses work better than chasing harder:
- Start the request early. Send the evidence request at the moment the business raises the request, before tiering is finalised. The worst case is that you asked for slightly more than you needed.
- Do not block the whole flow on it. Contract review and clause checking can proceed in parallel.
- Make the ask proportionate. A shorter questionnaire comes back faster, and a Tier 3 supplier does not need the Tier 1 form.
Who owns each stage
| Stage | Typically owned by | Common failure |
|---|---|---|
| Request and tier | Business owner with security | Requests arrive after the contract is signed |
| Assess | Security or compliance | Becomes a queue with no service-level expectation |
| Decide | Risk owner with authority to refuse | Nobody is empowered to say no |
| Contract | Legal | Security clauses treated as optional boilerplate |
| Onboard and monitor | Business owner | Handed off and never looked at again |
| Re-assess | Security or compliance | No trigger exists, so it never happens |
| Exit | Business owner with IT | Access is never actually revoked |
Designing the flow so it does not block
- One front door. Every supplier request enters the same way. Two routes means one of them is unmonitored.
- Tier before you assess. Tiering takes minutes and determines hours.
- Publish the service level per tier. If the business knows Tier 3 clears in two days, it stops routing around you.
- Parallelise legal and security. They do not need each other's output to start.
- Automate the chase. Reminders that fire on their own outperform a person remembering to follow up.
- Make the register the output. If the process ends in a closed ticket rather than a register entry with a review date, stage eight will never happen.
The triggers that restart the flow
A calendar cycle alone is not enough, because risk changes between reviews. Five events should push a supplier back into assessment regardless of when it was last looked at.
- The supplier is acquired or changes ownership
- The supplier suffers a security incident, disclosed or reported
- The supplier changes sub-processors or hosting location
- What they do for you materially changes, particularly if it starts supporting a critical function
- A certification lapses or its scope changes
Turning the flow into a procedure document
If you need a written third-party risk management procedure, the flow above is its spine. A usable document names, for each of the nine stages, the owner, the input, the output, the service level and the escalation path when the service level is missed. Anything beyond that is usually written to satisfy an auditor rather than to be followed, and it shows.
Keep the tier definitions in the same document. They are the part people actually need to look up.
Do this in Venvera
Venvera runs the flow as one system: the register, five-signal scoring, questionnaire campaigns with automated chasing, contract clause tracking, concentration analysis and review dates that fire on their own. Because the output is a register entry rather than a closed ticket, stages seven to nine happen by default. See third-party risk management, and how to perform a third-party risk assessment for the assessment stage in detail.
Map your flow with us
Book 30 minutes. We will walk your current process stage by stage, find where it stalls, and show you what the automated version looks like on your own supplier list.
Book a walkthroughFrequently asked questions
What are the stages of a third-party risk management process?
Request, tier, assess, decide, contract, onboard, monitor, re-assess and exit. The first two are quick and determine everything after them; the last one is the stage most often missing.
Where do third-party risk processes usually fail?
At the assessment stage, waiting for the supplier to return evidence. It is the only stage whose duration depends on someone outside your organisation, so the flow should start it early and continue other work in parallel rather than treating it as a blocking gate.
Who should own third-party risk management?
Ownership is split: the business owner raises and owns the relationship, security or compliance runs the assessment, legal handles clauses, and a risk owner with authority to refuse makes the decision. The common failure is that nobody is empowered to say no.
How do you write a third-party risk management procedure?
Name, for each of the nine stages, the owner, input, output, service level and escalation path, and include the tier definitions. That is a document people will actually use.
What triggers a re-assessment?
Acquisition or change of ownership, a security incident, a change of sub-processor or hosting, a material change to the service, and certification lapse or scope change. These sit alongside the calendar cycle rather than replacing it.
How long should the process take?
Publish a service level per tier rather than one for everything. When the business knows a low-risk supplier clears quickly, it stops bypassing the process, which is the behaviour that causes most unregistered suppliers.
