Third Party Risk Management Software Problems: The 5 That Break in a Crisis, and How to Avoid Them

Why does a vendor risk project become a questionnaire library?

The requirement that reaches a build team is usually send assessments, collect evidence, score vendors, repeat annually. That is a well understood product and it is what most of the market sells, so it is what gets built. It also inverts the actual work. Sending a standard questionnaire or requesting a service organisation control report is evidence collection. The assessment is the judgement about whether this third party, performing this activity, at this criticality, with these controls, is acceptable.

Systems that make the questionnaire the centre of gravity produce a score, and the score becomes the risk. Then a supplier with a clean questionnaire and a critical dependency looks the same as one with a clean questionnaire and no dependency at all.

The regulatory direction is the other way. The 2023 interagency guidance on third party relationships issued by the United States banking agencies frames the obligation around the risk of the activity, and the European Union Digital Operational Resilience Act, applying from January 2025, requires a register of information about contractual arrangements and treats concentration in critical providers as a systemic issue. Both push toward mapping third parties to services and dependencies, which a questionnaire library does not do.

Scope the first release around inventory reconciliation, criticality tiering derived from business services, and an assessment workflow whose depth follows the tier. That is $70,000 to $150,000 over 12 to 18 weeks in our delivery experience. Build the incident impact view early rather than deferring it, because it is usually the capability that justifies the programme to the board.

What goes wrong when the inventory is imported rather than reconciled?

The single most common way these projects lose credibility is importing the existing spreadsheet. It is the fastest path to a populated system and it means the new platform inherits every blind spot the old one had, now with better reporting on top.

You do not have an inventory. You have three lists that disagree. Procurement holds a supplier master keyed to payment. Legal holds a contract repository. Technology holds applications and integrations, and identity management holds accounts belonging to external parties. The gaps between them are systematic rather than random: a supplier engaged on a corporate card never reached procurement, a contract auto-renewed after its owner left, a software service was adopted by a business team without any of the three knowing.

Reconcile instead of importing. Pull the supplier master, the contract repository, the application inventory, the accounts payable ledger and external identity records, normalise entity names, match them, and treat every difference as work: unmatched payees above a threshold, contracts without a supplier record, external accounts without a contract. Entity name normalisation is the part that takes real effort, because the same firm appears as three legal entities, an abbreviation and a former trading name.

Run it continuously rather than once. A programme built on an inventory nobody reconciles gets undermined the first time an examiner finds a supplier you did not know you had, and they find them by looking at your payments.

Why do the procurement, contract and identity feeds break after launch?

These integrations break in ordinary ways with disproportionate consequences. A procurement platform upgrade changes a supplier record structure. A contract repository migration renames document types. An identity management change alters how external accounts are flagged, so the population you were reconciling against silently shrinks.

The consequence is specific to this domain. When a feed degrades, the reconciliation reports fewer differences, which looks like improvement. A vendor risk platform whose exception count is falling is either genuinely improving or quietly blind, and nothing on the screen distinguishes the two. Teams celebrate the wrong thing for a quarter.

The fix is to monitor the inputs rather than the outputs. Track record counts and match coverage per source on every run and alarm on a shift, not just on a failure. Assert expected volumes: if accounts payable returns eleven thousand payees this month and fourteen thousand last month, that is an incident regardless of what the reconciliation says. Keep the entity normalisation rules versioned and reviewable, because a change there moves match rates across the whole estate.

Name an owner for each feed, in the business rather than in technology. The person who will be asked by an examiner why a supplier was missing is the one who keeps the feed alive.

What happens when contract obligations and exit plans are not covered?

An assessment finds a supplier has no tested recovery arrangement for the service you depend on. The finding is logged, and then nothing happens, because the remedy lives in the contract and the contract is a document in a different system. Most programmes cannot answer whether a given agreement contains a right to audit, an incident notification window, a subcontracting consent requirement, a data location commitment or an exit assistance clause, which means a finding stays a note instead of becoming a negotiating position at renewal.

Model contracts as structured obligations extracted at signature: term and renewal mechanics, notice periods, right to audit, incident notification window, subcontracting consent, data location and transfer terms, service levels with remedies, exit assistance and data return. Then link findings to obligations. Document extraction has a legitimate role proposing that structure from executed agreements for a lawyer to confirm, and it is usually the only realistic way to clear a historic backlog nobody was ever going to read.

Exit planning is the deferred item that costs most when it is needed. For critical relationships the question is not whether the supplier is good, it is what happens if they stop. That means a documented alternative, an estimate of the time to move, the data you would need returned and in what format, and the contractual right to get it. Firms discover the gap when they try to leave. Hold exit plans as living records with a review date, tied to the same criticality tier that drives assessment depth.

Should you build custom or configure what you already own?

If you carry a few hundred third parties, no operational resilience regime applies to you, and your main need is running assessments on a cycle and retaining the evidence, do not build. Venminder, Prevalent and ProcessUnity all do that well, and Venminder in particular suits mid-market financial institutions because it combines the platform with assessment services. A build would be an expensive way to reach the same place. Keep BitSight or a comparable ratings provider regardless of what you build, since external monitoring data is a subscription rather than a project, and keep any questionnaire content you licence rather than rewriting it.

Before commissioning anything, do the reconciliation once by hand. Export your supplier master, your accounts payable payees for the last twelve months and your external identity accounts, and match them in a spreadsheet. It is a week of unglamorous work and it will tell you the size of your real problem more honestly than any vendor demonstration. Most firms find suppliers nobody registered, and that finding is the business case.

Build when two or more of these are true. You must map third parties to business services with disruption tolerances and no product's data model matches your service taxonomy. Your inventory cannot be reconciled to your payments and identity records, which means the programme's foundation is not credible. You need contractual obligations linked to findings so renewals actually change something. You need concentration analysis across fourth parties and shared infrastructure. Or your licence is priced per assessment and the cost has started shaping which vendors you assess.

How do hidden costs get into the quote?

Four items produce most of the overrun.

• Source system count. Each procurement, contract, application and identity platform in the reconciliation is its own integration with its own access approval, and quotes routinely price the reconciliation as one piece of work.
• Contract repository condition. It is almost always worse than expected. Whether obligation extraction is a project or an ordeal depends on how many agreements exist only as scanned documents with no consistent naming, and nobody knows the answer until someone samples them.
• Regulatory scope. A register of information for one regime is not the same artefact as another's. Each has its own required fields, and supporting two is close to twice the mapping work rather than a report variant.
• Service taxonomy. Agreeing what your business services actually are, and their disruption tolerances, is a workshop exercise with your resilience function and the business. It is not a coding task and it gates everything downstream.

The unpriced cost is legal time. Obligation structures need a lawyer to confirm, and exit plans need one to review. Book it early, because legal capacity is usually the constraint.

What separates a build that works from one that fails here?

Ask how they would reconcile your vendor inventory. A team that has done this starts with accounts payable, because payments are the ground truth that catches suppliers nobody registered, and asks about entity name normalisation and thresholds. A team that starts by importing your existing spreadsheet has agreed to inherit your blind spots and will deliver a tidier version of the problem.

Ask how tiering works. It should derive from the activity, the data touched and the business service supported, not from the vendor or the spend. If the demonstration shows a criticality dropdown on a vendor record, ask what happens when one supplier provides both a critical and a trivial service, because that is common and it breaks vendor-level tiering immediately.

Ask to see an incident impact view. Given a supplier, it should name the affected business services, their tolerances, the regulatory notification requirements with their clocks, the contractual notice obligations and the documented contingency, on one screen. If that view does not exist, the system will not help on the morning it is needed.

Ask how continuous monitoring signals are routed, because an unrouted feed becomes wallpaper and, worse, creates a record showing you were informed and did nothing. Then settle ownership in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire another firm. At Digital Heroes the code is yours from the first commit. There is an obvious irony in a third party risk programme that is itself an unmanaged single-vendor dependency.