Building a third-party risk management framework for NIS2 and DORA

A supplier review often starts with one question: "Can someone send me our latest vendor register?" A few minutes later, the search begins.

One team pulls up a spreadsheet that was last touched eight months ago. Another points to a shared drive full of signed contracts, none of them indexed by supplier or renewal date. Someone else remembers a security questionnaire a supplier completed once, at onboarding, and never again. Emails get searched. A review gets vaguely placed as having happened "sometime last year." Nobody in the room is completely wrong, but nobody has the full picture either.

This is usually the moment an organization discovers it doesn't have a third-party risk management (TPRM) framework. It has pieces of one. A practical framework isn't another policy document sitting in a compliance folder — it's the working definition of how ICT suppliers are identified, reviewed, monitored, and documented, from onboarding through contract renewal. It gives every team involved in supplier oversight the same process to follow, instead of a different answer depending on who you ask.

If supplier oversight becomes difficult to explain, it will almost certainly become difficult to maintain.

What you'll learn

• What a practical TPRM framework looks like
• Why supplier assessments alone are rarely enough
• The records every TPRM process should maintain
• When a spreadsheet is sufficient and when TPRM software becomes worthwhile
• Common TPRM mistakes that weaken supplier oversight

A third-party risk management framework should make decisions easier

Most organizations already have the pieces of a TPRM framework without realizing it. There's a supplier list somewhere. Procurement has a process for onboarding new vendors. Security sends out questionnaires. Legal reviews contracts. Someone runs an annual risk assessment. The problem is that these activities usually happen independently of each other.

Procurement doesn't know when security last completed an assessment. Security doesn't know whether the contract was updated after a renewal. Compliance doesn't know who actually owns the relationship with a given supplier. Each function is doing its part, but nobody is connecting the parts into a single view.

A framework connects these activities into one repeatable process. Every supplier follows the same lifecycle. Every review has a named owner. Every decision can be traced back to evidence, rather than to someone's memory of a call that happened months ago. That's what makes the process repeatable instead of reactive.

What every third-party risk management framework should include

A framework is more than a policy statement. It's a working structure that every team can follow the same way, whether they're onboarding a new supplier or preparing for an audit. Five components make that possible.

Which ICT suppliers do we depend on?

Everything starts with a complete inventory: which ICT suppliers the organization uses, what services each one provides, who owns the relationship internally, and how each supplier supports day-to-day business operations. Without this baseline, every other step is guesswork.

Which suppliers create the greatest business risk?

Not every supplier carries the same risk. Classification should be based on business impact, operational dependency, and the level of access a supplier has to systems and data. This is what allows review effort to be focused where it actually matters.

What contractual security requirements have been agreed upon?

Contracts should document cybersecurity responsibilities, incident notification requirements, audit rights, subcontractor expectations, and business continuity commitments. If this information only exists as scattered clauses across dozens of contract documents, it isn't usable during an actual incident or audit.

Ownership and governance

Every supplier relationship needs clear ownership. Someone has to be responsible for business decisions, someone for risk management, and someone for keeping review schedules and follow-up actions on track. Shared responsibility without a named owner tends to mean no responsibility at all.

Evidence and documentation

Every review should produce evidence: assessment results, review dates, contract references, and supporting documentation. This is what turns a review from something that happened into something that can be demonstrated.

Why supplier assessments are only one part of TPRM

A supplier assessment answers one question: what is this supplier's risk today? A framework answers a different one: how do we manage that risk over time?

The common pattern looks like this. A questionnaire gets completed during onboarding. The supplier passes. Everyone moves on. Then, over the following months, the supplier expands the services they provide, the contract gets renewed, new systems get connected, or ownership on the supplier's side changes entirely. The original assessment, meanwhile, stays exactly as it was.

The assessment wasn't wrong. It simply represented one point in time.

Effective TPRM connects assessments with ongoing governance: contract reviews, clear ownership, defined review schedules, and evidence that gets updated as circumstances change. That's what turns a one-time activity into a repeatable process.

When does TPRM software make sense?

A spreadsheet and dedicated TPRM software solve the same underlying problem in different ways. The right choice depends on the maturity of the framework behind it, not on the tool itself.

With a smaller number of ICT suppliers, a structured register is often enough. As the supplier ecosystem grows, manual processes get harder to sustain, especially once multiple teams are involved in reviews. At that point, dedicated software becomes valuable: it automates repetitive tasks, improves visibility across the supplier base, and manages larger portfolios without adding headcount.

The important point is this: software supports a mature process. It doesn't replace one.

Common TPRM mistakes that weaken supplier oversight

Most organizations don't ignore third-party risk on purpose. They struggle because good intentions at the start of the process turn into outdated information by the time anyone needs it.

Supplier assessments become a one-and-done exercise

A questionnaire completed at onboarding is treated as permanent proof of low risk, even years later, long after the supplier's services, systems, or ownership have changed.

Every supplier gets treated the same

A payroll provider handling sensitive employee data gets the same review cadence as the vendor supplying office plants. Without risk-based classification, review effort gets spread evenly instead of where it's actually needed.

Security commitments stay inside the contract

Incident notification timelines, audit rights, and subcontractor obligations exist somewhere in a signed PDF, but nobody outside legal can find them quickly when it matters.

Everyone is involved, but nobody owns it

Procurement, security, legal, and compliance all touch supplier oversight at different points, but no single person is accountable for the relationship as a whole.

The register only appears before an audit

Supplier information gets pulled together and cleaned up right before an audit or review, then goes stale again until the next one is scheduled.

Wrapping up

A third-party risk management framework doesn't have to be complicated. The difficult part isn't designing it — it's following the same process every time a supplier is onboarded, reviewed, or changes the services it provides.

When supplier information, ownership, contracts, and review history are maintained in one place, oversight becomes easier to manage day to day and easier to demonstrate when an audit asks for it.

The goal isn't to collect more documents. It's to know the answers before someone asks the questions.

FAQ

What does TPRM mean?

TPRM stands for third-party risk management. It refers to the process of identifying, assessing, and monitoring the risk that external suppliers, vendors, and service providers introduce to an organization, particularly where those suppliers have access to systems, data, or critical business processes.

What is the best third-party risk management software?

There isn't a single best option for every organization. The right TPRM software depends on the number of suppliers being managed, how many teams are involved in reviews, and how much automation and reporting the business actually needs. A smaller supplier base is often managed well with a structured register, while larger, more complex supplier ecosystems benefit from dedicated software with workflow automation and audit trail features.

What should I look for in third-party risk management solutions?

Look for a solution that supports a full supplier lifecycle rather than just questionnaires: supplier inventory and classification, configurable review schedules, ownership assignment, contract and evidence storage, and reporting that can be handed to an auditor without extra manual work. A tool is only useful if it reflects a process your teams already understand.

What is the difference between a supplier register and a third-party risk assessment?

A supplier register is the ongoing record of every ICT supplier, its owner, classification, and review history. A third-party risk assessment is a point-in-time evaluation of a specific supplier's risk, usually carried out during onboarding or a scheduled review. The register is the framework; the assessment is one input into it.

What should a third-party risk management policy include?

A TPRM policy should define how suppliers are identified and classified, what triggers a review, who owns supplier relationships, what contractual security requirements are mandatory, and what evidence must be kept to demonstrate oversight. It should describe a process teams can actually follow, not just a set of principles.

What are the best third-party risk management practices?

Maintain a single, current inventory of ICT suppliers. Classify suppliers by business impact and access level rather than treating them all the same. Assign a named owner to every supplier relationship. Review suppliers on a schedule tied to their risk classification, not just at onboarding. And keep evidence of every review as it happens, so oversight can be demonstrated at any time, not only reconstructed before an audit.