Third-Party Risk Management Software: How to Define Your Requirements Before You Build a Shortlist

Almost every guide to evaluating third-party risk management platforms starts the same way: a feature comparison table, vendor by vendor, capability by capability. That approach assumes the hard part is already done — that your organisation already knows what it needs, and simply has to find the tool that matches. In practice, the hard part is the step before that: most teams walk into vendor conversations without having answered, internally, what problem they’re actually solving, which regulatory obligations are driving the purchase, and who inside the company will have to use the thing every day. This article is about that step — the one no feature comparison can do for you.

Start with Your Programme Maturity, Not the Feature List

Before comparing any platform, be honest about where your third-party risk programme actually stands today. Most organisations sit in one of three positions: no formal programme at all, with supplier evaluation handled through spreadsheets and email threads; an established programme that has outgrown its current tooling and needs consolidation and scale; or a mature programme that has hit the ceiling of what a manual or semi-manual process can sustain, and needs continuous monitoring and automation to keep up.

Each of these positions calls for a genuinely different purchase. A team with no formal programme that buys a platform built for continuous, event-driven monitoring of thousands of suppliers will pay for capability it cannot yet operationalise — there’s no internal process mature enough to act on the alerts the platform generates. A team with a mature, high-volume programme that buys a platform designed for a first-time, low-volume rollout will hit its ceiling again within a year. Before any vendor conversation, count how many third parties you currently track, describe how an evaluation is triggered and completed today, time how long a full cycle actually takes, and name who owns escalation when a risk is found. That exercise, done honestly, tells you more about what you need than any vendor’s feature list.

Map Your Regulatory Obligations First — European Requirements Change the Evaluation

The single biggest mistake in a TPRM evaluation is treating “third-party risk” as one generic category. In Europe specifically, the regulatory regimes driving these programmes require genuinely different platform capabilities, and a tool built primarily around one of them may be structurally weak on the others.

DORA requires an ICT-specific Register of Information, aligned to a defined technical format, with fields for sub-outsourcing chains and concentration risk across ICT providers — a platform without a data model built around this structure will require heavy customisation to produce a compliant export. The French Sapin II anti-corruption law expects a segmentation of third parties into homogeneous risk groups and the collection of probity-specific signals — sanctions exposure, beneficial ownership, adverse media — that a generic vendor-risk platform built for financial or cyber scoring typically does not cover out of the box. The French Loi de Vigilance and the EU’s CSDDD require a human rights and environmental risk mapping deep enough to survive a civil liability claim, with a documented, timestamped decision trail rather than just a risk score. CSRD requires an evidence base structured to feed ESRS disclosures under limited assurance, linked back to a double materiality assessment run by the sustainability function, not the procurement function. NIS2 adds a supply chain cybersecurity dimension that overlaps with DORA for financial entities but applies more broadly elsewhere.

Before writing a single requirement for a vendor, list every regulatory regime your organisation is subject to today, and — if you sell into regulated customers — every regime your largest customers are pushing down onto you as a supplier. Then check, regime by regime, whether a platform under consideration natively supports the specific workflow each one requires, or whether “supported” really means “could be configured to, eventually, with services engagement.”

Which Three Teams Need to Use the Platform Daily?

A TPRM platform selected by a single function almost always disappoints someone else in the organisation within the first six months. Three teams typically need to use the platform on a recurring basis, and each brings a different, non-negotiable requirement.

Procurement and other operational staff are the ones who onboard new suppliers and run first-line evaluations; for them, the platform’s daily usability and the friction it creates for suppliers matter more than any reporting feature, because a clunky onboarding flow is what actually determines whether the register stays populated and current. Compliance and risk teams are the ones who need the audit trail, the second-line review workflow, and the regulatory export formats — for them, traceability and defensibility under scrutiny matter more than interface polish. IT, security or legal — depending on which regulatory regime is driving the purchase — need integration with existing systems (ERP, contract management, identity and access tools), a security posture that satisfies internal architecture review, and, increasingly, clarity on data hosting and legal jurisdiction. A platform chosen by compliance alone, without procurement’s input on daily usability, tends to produce a technically compliant tool nobody uses consistently. A platform chosen by IT alone, without compliance’s input on evidentiary requirements, tends to produce a tool that looks efficient but cannot survive a regulator’s or a court’s scrutiny.

What Five Questions Should You Answer Before You Write an RFP?

Before any RFP goes out, your internal stakeholders — not the vendors — should be able to answer five questions in writing. First, how many third parties need to be tracked today, and realistically within the next eighteen months, given known growth or acquisition plans. Second, which existing systems — ERP, procurement platform, contract management, identity provider — the new platform must integrate with as a hard requirement, as opposed to a nice-to-have. Third, who holds final authority to classify a third party as high-risk, and whether that person needs to work inside the platform directly or simply needs to receive its output in a format they can act on. Fourth, what your organisation’s tolerance is for supplier-facing friction — whether you can require every supplier to complete a fresh onboarding process, or whether the platform needs to absorb data suppliers have already provided to other systems or other customers. Fifth, what volume and frequency of regulatory exports you need to produce, in which formats, and on what deadlines.

A requirements document built from honest answers to these five questions, written before any vendor is contacted, does more to shape a successful evaluation than any demo ever will — it gives your team a fixed script to hold every vendor conversation against, rather than being led by whatever the vendor chooses to demonstrate first.

The European Data Sovereignty Question Most Evaluations Skip

Most evaluations ask where a vendor’s servers are physically located and stop there. That question answers data residency, not data sovereignty, and the two are not the same thing. Following the Schrems II ruling, geographic hosting inside the EU is not sufficient on its own: the ruling requires supplementary technical measures — customer-controlled encryption in particular — because a vendor’s legal ownership structure can expose EU-hosted data to foreign legal demands regardless of where the servers physically sit. A cloud instance in Frankfurt operated by a company that is itself subject to the US CLOUD Act remains, in principle, accessible to a US government request, hosting location notwithstanding. A further Schrems III case is currently before the Court of Justice of the EU, with a ruling expected before the end of 2026, and the long-term durability of the EU-US Data Privacy Framework — the current legal basis for many transatlantic transfers — remains genuinely uncertain.

For a TPRM platform specifically, this question deserves more scrutiny than for most other enterprise software, because of what the platform actually holds: financial health data, beneficial ownership structures, sanctions and adverse media exposure across your entire third-party ecosystem — precisely the category of information a foreign jurisdiction’s legal request would be most interested in. Before shortlisting, ask each vendor directly whether it, or any parent or affiliate, falls under CLOUD Act jurisdiction; what encryption key control your organisation retains as the customer; and whether a sovereign-hosting option exists if your own regulatory exposure — DORA in particular — makes this a material consideration. Several sovereign-cloud infrastructure options have matured enough to be genuine choices in 2026: AWS’s European Sovereign Cloud, with its first region in Brandenburg; Microsoft’s EU Data Boundary; Google’s S3NS joint venture with Thales in France; and Bleu, the Capgemini-Orange-Microsoft venture pursuing SecNumCloud qualification. Whether any of these matter for your specific evaluation depends on your answers to the regulatory mapping exercise above — but the question should be asked deliberately, not skipped because the vendor’s marketing page already says “hosted in the EU.”

What Does “Supplier Adoption Rate” Actually Tell You?

Every vendor will offer a completion or adoption rate statistic during an evaluation. The number on its own tells you very little — what matters is why suppliers actually complete what’s asked of them, because friction at onboarding is one of the most reliable predictors of whether a register stays accurate a year after go-live rather than degrading back into the spreadsheet chaos it was meant to replace.

Ask a vendor for a reference customer of comparable size and sector, and ask that reference specifically about the supplier-side experience, not just the buyer-side dashboard. Amadou Seck, Head of Procurement at the Université Paris-Est Créteil Val-de-Marne (UPEC), describes exactly the kind of frictionless adoption this question is trying to surface: “With Aprovall, using a simple connection and the awardee’s SIRET number, we carry out the full set of regulatory checks simply, quickly, securely and with full traceability. Aprovall was deployed in two weeks.” A two-week deployment and a verification flow simple enough for buyers to run in a single connection is exactly the kind of low-friction design that keeps completion rates high over time — not because suppliers are compelled to comply, but because complying costs them almost nothing. That’s the adoption signal worth asking about, rather than a headline completion percentage with no explanation of what made it achievable.

How Should You Structure a 3-Week Evaluation Process?

With the groundwork above in place, a focused evaluation can run in three weeks rather than the multi-month cycle most organisations default to. In the first week, complete the internal alignment work: assess programme maturity, map every applicable regulatory regime, gather requirements from all three stakeholder teams, and answer the five RFP questions in writing. The output of week one is a single internal requirements document, agreed by procurement, compliance and IT or legal, before a single vendor is contacted.

In the second week, hold structured conversations with a small number of vendors — two to four is usually enough — using the requirements document as the fixed agenda for every call, rather than letting each vendor lead with its own demo script. Request reference calls with each vendor’s existing customers in a comparable regulatory situation, and ask those references the adoption and friction questions directly. In the third week, complete the data sovereignty and security review for the remaining candidates, assemble the total cost of ownership picture needed to build an internal business case, and hold a single decision meeting with all three stakeholder teams present, so the choice is made jointly rather than ratified after the fact by teams who weren’t in the room for the trade-offs.

Once the shortlist is built this way, the feature-by-feature comparison that most guides start with finally has something solid to compare against.