How to build a third-party risk management program, step by step

A third-party risk program is a small set of decisions made in the right order: what do we have, which of it matters, how hard do we look, what do we require in writing, how do we notice change, and how do we exit. Teams that start with the tooling decision usually discover they bought answers to questions they had not yet asked. The sequence below follows the lifecycle that regulators and standards bodies already use, so the program you build can be explained to an examiner without translation.

The lifecycle you are building toward

You do not need to invent a model. The US banking agencies' Interagency Guidance on Third-Party Relationships: Risk Management (June 2023; also issued as OCC Bulletin 2023-17) describes five stages: planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination. NIST SP 800-161 Rev. 1 structures supply-chain risk management across the enterprise, mission and operational levels, and the cybersecurity supply chain category in NIST CSF 2.0 sits inside its Govern function, which tells you where it belongs organizationally: it is a governance responsibility first and a security task second. In the EU, Regulation (EU) 2022/2554 (DORA) adds a register of information and mandatory contract content for ICT providers. The terminology differs; the shape does not. See frameworks for how they fit together.

Step 1: Get a defensible inventory

Everything downstream depends on knowing which third parties exist. Start from three independent sources and reconcile them: accounts-payable and procurement records, SSO and identity-provider app lists, and a short survey of business owners. Each source misses something. Finance misses free-tier tools and subsidiary-paid vendors; SSO misses vendors with no login; owners forget the integrations they set up years ago. For each vendor record the business owner, the service, the data types touched, the access granted, and the contract end date. Do not wait for a perfect list. A register that is 80 percent right and has named owners is more useful than a complete one nobody maintains.

Step 2: Tier by consequence, not by spend

Tiering decides how much work every later step costs, so get it roughly right early and revisit it often. Base it on what would happen if the vendor failed or were breached: sensitivity and volume of data, depth of system access, operational criticality, regulatory exposure, and how replaceable the vendor is. Spend is a poor proxy; a small API provider with production credentials can matter more than a large vendor with none. Keep the scheme to three or four tiers, and write down the rule that puts a vendor in each so two analysts reach the same answer. The mechanics are in vendor tiering, and the logic behind it in inherent vs. residual risk.

Step 3: Define a proportionate assessment standard

For each tier, decide in advance what evidence is required before onboarding and how often it is refreshed. A workable pattern: the lowest tier gets a basic intake and an external check; the middle tier adds a recognized report such as SOC 2 or ISO/IEC 27001 certification plus a short questionnaire; the top tier adds a full questionnaire such as the SIG or CAIQ, document review, and where warranted, validation of the answers. Pick an existing questionnaire rather than writing your own; vendors answer the standard ones faster and you inherit years of refinement. The point to hold onto is that a questionnaire is a vendor's statement, not a test. Decide which claims you will verify and how, which is the subject of automated evidence collection.

Step 4: Set contract baselines

Agree with legal on a minimum security schedule by tier, so contract terms follow risk rather than negotiating leverage. At a minimum: breach notification within a defined window, subprocessor disclosure and change notice, audit or evidence rights, data return and deletion at exit, and a requirement to remediate material findings. Regulated entities will have mandated content on top; DORA Article 30, for example, lists required provisions for ICT service contracts, and the compliance pages cover how other regimes treat service-provider agreements. A clause you cannot invoke because nobody tracks the underlying obligation is decoration, so link each baseline term to something the program actually checks.

Step 5: Decide how you will notice change

An assessment describes one moment. Vendors change hosting, acquire companies, lose staff, and get breached between reviews. Define what triggers reassessment off-cycle (a public incident, a material change of subprocessor, a certification lapse, a new critical vulnerability on an exposed service) and how that signal reaches an owner. Annual reviews alone leave a long window; see continuous vendor monitoring and vendor attack surface monitoring. Include your vendors' vendors, at least for the top tier: fourth-party risk and concentration risk only appear when you ask for subprocessor lists and compare them.

Step 6: Close the loop on findings and exits

A finding is only useful if it has an owner, a due date, and a recorded outcome, including accepted risk with a named approver. Route findings into the ticketing system your teams already use. Plan the exit too: every contract should have a defined offboarding procedure for access revocation and data return or destruction, covered in vendor offboarding. Programs that skip this step accumulate dormant vendors with live credentials.

Step 7: Report, then tune

Give leadership a small set of numbers they can act on: share of in-scope vendors assessed in the last cycle, open critical findings by age, vendors past their reassessment date, and coverage of the top tier. Resist counting activity (questionnaires sent) as if it were outcome. Review tier thresholds and assessment depth yearly against actual incidents and near-misses.

Where tooling fits

Once steps 1 to 4 are written down, tooling becomes a fair question: which parts of the lifecycle are you spending analyst hours on that software can do reliably? Intake, evidence collection, monitoring and finding routing are common candidates; tier policy and risk acceptance stay under your rules. Platforms differ meaningfully here, and no single one fits every program. Rescana is one option among several; our neutral roundup and the evaluation guide cover how to weigh them. If you are starting from nothing, a register and a written tiering rule beat any purchase.

Frequently asked questions