TL;DR
Third-party risk management is the practice of identifying, assessing, controlling, and monitoring the risks that come from the vendors, suppliers, and service providers a business depends on. Most guidance focuses on the score a vendor receives. For finance and procurement teams the harder problem sits behind the score: collecting the evidence, reading it, keeping it current, and tying it to whether the vendor can be paid.
Key Takeaways: The process is commonly described in five phases: identify, assess, mitigate, monitor, and offboard. A risk rating is only as good as the documents behind it. Evidence expires, so the monitoring phase is where most programs fail quietly. Payment is the point where third-party risk becomes a financial loss, which makes the vendor master and the payment run part of the program. Automation helps most where documents have to be read and rules applied the same way every time.
What third-party risk management is
Third-party risk management, usually shortened to TPRM, covers the risks a business takes on by relying on outside parties: suppliers of goods, providers of services, software vendors, contractors, and any other organization that touches its data, operations, money, or customers.
It is a subset of enterprise risk management. Enterprise risk management looks at every risk the business faces, including those that start inside it. TPRM looks at the ones that arrive through a relationship, and feeds its findings back into the wider risk picture.
The topic is usually presented from a security point of view: questionnaires, security ratings, and breach exposure. That view is valid, and it is half of the work. The other half is operational and financial, and it falls to the teams that onboard vendors and pay them. Is this vendor who it claims to be? Is its insurance in force? Did the bank account change? Is the contract still in effect? These are the questions that decide whether a third-party risk becomes a loss.
The five phases
Programs differ in labeling, but the lifecycle is commonly described in five phases. The table reframes each as a question finance can answer.
| Phase | The question | The typical failure |
|---|---|---|
| Identify | Who are our third parties, and what does each one touch? | A vendor paid through a card or an expense report never enters the list |
| Assess | How much risk does each carry, and on what evidence? | A score is recorded but the documents behind it were never read |
| Mitigate | What did we require before work or payment could start? | Controls are written into the contract and never checked afterward |
| Monitor | What has changed since we approved them? | A certificate expires and the vendor keeps getting paid |
| Offboard | Is access, data, and payment authority actually removed? | A terminated vendor stays active in the payment system |
The phases are sequential for a single vendor and continuous across the vendor base. A program that is strong at assessment and weak at monitoring will approve vendors carefully and then lose track of them.
The risks a finance team owns
Sources group third-party risk differently, so the exact number of categories varies. These are the ones that land on a finance or procurement desk.
Financial risk. The vendor fails, is acquired, or cannot deliver. Signals include late filings, repeated payment term changes, and sudden concentration of your spend with one supplier.
Operational risk. A critical vendor has an outage or misses delivery, and the process that depends on it stops. The check is whether you know which vendors your processes depend on and what the fallback is.
Compliance risk. The vendor, or the way you pay it, breaches a rule: sanctions, tax reporting, data protection, or an industry regulation. Responsibility stays with you when the failure sits with the vendor.
Security and privacy risk. The vendor holds your data or connects to your systems. This is where security ratings and questionnaires are most useful, and where finance relies on the security team rather than duplicating it.
Concentration risk. Too much depends on one vendor or on one vendor’s own supplier. It is invisible when you assess vendors one at a time and obvious when you look at the whole portfolio.
The evidence that matters
A due diligence file is a set of documents, each of which proves one thing and expires on its own schedule. A rating summarizes them. It does not replace them.
| Evidence | What it proves | What to check | What goes wrong |
|---|---|---|---|
| Certificate of insurance | Coverage exists for the work being done | Coverage types and limits, named insured, effective and expiry dates | Expired or lapsed cover on an active vendor |
| Security or assurance report (such as SOC 2) | Controls were tested by an independent auditor | Report period, scope, opinion type, and any listed exceptions | A clean-looking report that excludes the system you actually use |
| Tax form | The vendor identity matches the tax record | Legal name, tax ID, and entity type against the vendor master | Name and tax ID mismatch that surfaces at year end |
| Bank details | Payments will reach the vendor you approved | Account ownership confirmed through a channel you initiated | A changed account number accepted from an email |
| Sanctions and watchlist screening | The vendor is not a restricted party | Screening against current lists, repeated on a schedule | Screened once at onboarding and never again |
| Contract terms | You have the rights you will need if something fails | Audit rights, breach notice, subcontractor disclosure, termination | Rights that exist on paper with no one tracking them |
Two patterns recur across the table. Evidence that is collected once and never refreshed behaves like evidence that was never collected. And evidence that arrives as a document, rather than as a field, has to be read by someone before it counts. A certificate of insurance is not data until someone confirms the coverage type, the limit, the named insured, and the date.
Where the process breaks
The failures are rarely sophisticated. They are the predictable results of volume and of work that depends on people remembering to look.
Questionnaires that never come back. Requests go out, some are answered, and the unanswered ones are chased once. The vendor is approved on partial information because the business needs the work started.
Documents nobody reads. A file is uploaded and marked complete. The report it contains excludes the relevant system, or the certificate lists the wrong entity. Completeness was checked, content was not.
Renewals nobody tracks. Expiry dates live in the documents, not in a field anyone can report on, so a lapse shows up only when something goes wrong or when an auditor asks.
The payment run that ignores the file. The vendor file and the vendor master are separate systems. A vendor with an expired certificate or a failed screening is paid on schedule because nothing connects the two. Our guide to vendor payment fraud controls covers the bank-detail version of the same gap.
The common thread is that each failure is a missed check, not a missed insight. Checks that depend on someone remembering are the ones that get skipped at quarter end.
Fourth-party risk
A fourth party is a vendor of your vendor: the cloud host behind your software provider, the subcontractor behind your logistics supplier. You have no contract with them, but their failure becomes yours.
Full visibility is rarely achievable. The practical approach is narrower. Require critical vendors to disclose their own material subcontractors, hold the right to be told when those change, and look for the same fourth party appearing behind several of your vendors, which is how concentration hides.
Regulatory anchors
Two regulatory references come up most often, and both are worth reading for the structure they expect even where they do not apply to you.
In the United States, the federal banking agencies issued interagency guidance on managing risks in third-party relationships in June 2023, covering planning, due diligence, contract negotiation, ongoing monitoring, and termination. It applies to banking organizations, and it is a useful template for any business that wants a defensible lifecycle.
In the European Union, the Digital Operational Resilience Act (DORA) has applied since January 2025 and sets requirements for how financial entities manage risks from their information and communication technology providers, including a register of those arrangements.
Neither is a substitute for advice on your own obligations. Confirm which rules apply to your organization with your compliance function.
Where Kognitos fits
Kognitos is not a security ratings platform and does not monitor vendors’ external attack surface. Those products are strong at what they do, and a program often needs one alongside the work described here.
What Kognitos addresses is the operational layer in the middle: reading the documents that arrive, applying your rules to them, and acting on the result. A certificate is read for coverage type, limit, named insured, and dates. A tax form is matched against the vendor master. An expiring document triggers a request, and a vendor whose evidence has lapsed can be held at the payment step rather than discovered afterward.
Three properties matter for risk work. Rules are written and read in plain English, so the standard being applied can be inspected by a reviewer. Execution is deterministic, so the same document under the same rules gets the same outcome. And each decision leaves a record of what was determined and on what basis, which is what an auditor asks for. Exceptions go to a person, who explains the handling in plain English and sees it applied from then on.
For related material, see our guides on vendor risk assessment, vendor onboarding automation, vendor payment fraud controls, AI tools for vendor management, and AI governance. To see this applied to your vendor files, book a demo or try the platform.
