Software · TPRM · Requirements
An audit finding, a regulatory requirement or client obligations explain why you are exploring software, but they do not define its requirements.
Write down the problem first, then compare third-party risk management (TPRM) products against it.
Key takeaway
You'll know what problem the software must solve, how obligations and the services you deliver shape the depth of each review, and what still needs deciding, before you compare TPRM products.
An audit finding, a client's request, a third party that let you down or a review backlog explains the trigger. Write down what is going wrong, who it affects and which decision or action needs to improve. The examples below turn vague starting requests into requirements colleagues and suppliers can work with.
Throughout this page, third parties are the vendors and partners you already work with, and suppliers are the software companies you'll be comparing.
We need to assess all our vendors.
Full reviews for third parties that support critical services or handle sensitive data, lighter checks for the rest.
We need to comply with the Digital Operational Resilience Act (DORA).
For services to European Union financial clients, record the third parties involved, the terms clients require and the evidence we must show.
We need continuous monitoring of our third parties.
For our highest-risk third parties, alert the relationship owner to significant changes and record the response.
Third-Party Risk Management (TPRM) Software Capabilities covers how products vary in meeting obligations like these.
Some third parties that matter, such as affiliates or contractors, may not appear on your procurement system's vendor list. Others on it, such as stationery vendors, need little or no risk review. Decide which relationships need oversight and link each one to the services, locations, systems and data it supports.
Then agree how categories and risk tiers work together. They answer different questions.
A category, such as IT services or logistics, decides the evidence you ask for. An IT provider might be asked for an ISO 27001 information security certificate, a transport company for insurance and safety records.
A category can also set a minimum tier. For example, any third party that hosts your data might never fall below medium.
A tier, such as high, medium or low, decides how deep the review goes, who approves it and how often it's repeated.
Above any minimum, the tier depends on the third party: how critical the supported service is, how badly a failure would hurt, how easily it could be replaced, its access to data or systems, and whether it relies on its own subcontractors.
Placements will change over time. What each category and tier requires should stay settled.
A regulated client can write requirements into its contract for incident notification, audit evidence, continuity or subcontractor oversight, even when the regulation itself doesn't apply to you directly.
For each obligation, record its source, the services and third parties it affects, the evidence needed and who's accountable. An outside risk rating doesn't tell you what a third party's failure would do to you; for each important relationship, ask these questions.
What business activity or client service depends on it?
Who's affected, how quickly and for how long, and is there a workaround?
Which shared sites, platforms or subcontractors are also exposed?
Different teams hold different parts of the picture, and each decision about tiers, exceptions and risk needs a clear owner.
Some requirements will be confirmed, others assumed or still open. A confirmed client obligation shouldn't carry the same weight as one colleague's preference.
Third-Party Risk Management (TPRM) Software Demo Evaluation shows how to test your brief once it's ready.
Planning reference: This guidance is for planning a software purchase. Which obligations apply will depend on your organisation's own circumstances.
A new regulation or an audit finding often starts the purchase, and it's tempting to turn it straight into a list of features. If an audit says third-party reviews are inconsistent, the quick answer is "we need a questionnaire tool". But the underlying gap may be that no one has decided which third parties need a full review. A questionnaire tool makes reviews faster, but it can't make that decision for you.
Write a short problem statement: what is going wrong, who it affects and which decision or action must improve. Name the person who owns the outcome.
Procurement lists group third parties by category, such as logistics, IT services or facilities, and it's tempting to give each category one risk level. But two transport companies can carry very different risk. One moves your largest client's goods to port every day. The other covers an occasional local delivery that another firm could take over tomorrow. The category is the same, but what would stop if each one failed is not.
For each third party, record the service it supports, what would stop if it failed, and whether it can reach your data or systems. Use those answers, not the category, to decide what is in scope.
Once third parties are placed in tiers, each tier should lead to a different level of review. Too often a tier is just a label. A "high" and a "medium" third party get the same questionnaire, the same approver and the same review cycle, so the tiering effort adds work without changing anything.
For each tier, state how deep the review goes, who approves it and how often it's repeated. Record the business reasons that place a third party in each tier.
Each obligation comes from somewhere specific, such as a regulation, a client contract or your own policy, and covers certain services and third parties. A financial services client's contract, for example, may require the third parties behind its service to report incidents quickly and allow audits. Copying those terms into every third-party review, including ones with no link to that client, slows reviews and adds work without reducing any real risk.
For each obligation, record where it comes from, which services and third parties it affects, what evidence it needs and who is accountable.
Rating services score third parties on things like security or financial health, and those scores are useful. A cloud provider may score well, which tells you its controls look sound. It doesn't tell you that if it went down, your client portal would be offline within the hour with no fallback. The score describes the third party. Only you can judge what its failure would do to your business.
For each important third party, note what its failure would stop, how quickly it would hurt, whether you have a workaround and who responds.
Setting up TPRM software means choosing tiering rules, questionnaires and who can approve an exception. If the business hasn't agreed these beforehand, the person configuring the software fills the gaps, often without the authority or context to make those calls. The choices then get built into the system and are hard to undo.
Agree who provides information, who approves tiers and exceptions, who accepts risk and who acts when something changes.
A buying brief usually holds three kinds of requirement: some confirmed, some based on assumptions and some still undecided. When they aren't labelled, an assumption, such as every third party needing to log in to a portal, reads like a firm requirement. Suppliers are then compared against something nobody actually agreed.
Label each important requirement as confirmed, assumed or open. Give every assumption and open question an owner and a date to decide.
Fit-based software matching
Tell us what the software must support, how your teams work and which delivery constraints matter. Centvra uses those inputs to build a focused supplier shortlist.
Your operating brief
Fit-based shortlist
Share the problem you need to solve, what is driving it and your delivery constraints. Centvra matches that against supplier data and returns a shortlist with the reasons each one fits.
Not which third party sits in which tier. That will keep changing as your services, contracts and risks change. What needs agreeing is what each tier means in practice: how deep the review goes, who approves it and how often it's repeated.
Also agree what moves a third party between tiers, such as a new service, access to sensitive data or a serious incident. That's what the software must support. The placement of individual third parties can be refined once it's running.
Yes. A client contract may place obligations on your organisation that you can only meet by managing the third parties involved in delivering that client's service. These can include incident notification, data protection, approval of subcontractors, audit evidence, continuity arrangements and recovery expectations.
Identify which client commitments depend on third parties, then link each one to the relevant service, third parties, evidence and owner. The software doesn't manage the client relationship itself. It should help you show that the third parties behind the service are meeting the obligations you have accepted.
Define the minimum information needed to identify each third party, link it to the services it supports, assign an owner and set its risk tier. Record where this information sits today, which source should be trusted and which details are missing or unreliable.
The requirements should also cover how records will be brought together, duplicates removed, gaps tracked and owners assigned for fixing the data. Don't assume the software will fix poor data automatically. Decide what must be ready before implementation and what can be improved in phases afterwards.
It helps to keep at least a basic record of every third party, but not every one needs an active risk review. A third party that only sells low-value office items, with no access to your premises, systems or data and no role in an important service, may only need that record and an initial check.
Base the level of oversight on the service provided, how much the business depends on it, access to systems or data, any regulatory or contract obligations, and the impact of disruption. Also include relationships you don't manage through procurement, such as affiliates or partners, which may still carry significant risk.