How to Build a Third-Party Cyber Risk Program

Most third-party cyber risk programmes are questionnaire factories: enormous effort spent collecting documents that nobody reads, on a cycle too slow to catch anything. A programme that actually reduces risk looks different — it spends its scarce human attention on a small number of relationships and automates everything else.

Why programmes fail

The failure is almost always structural rather than technical. Assessment effort is distributed evenly across a vendor population where risk is distributed extremely unevenly; assessments happen at onboarding and then never again; and the output is a filed document rather than a decision. Meanwhile a substantial share of breaches continue to arrive through third parties, a pattern the Verizon DBIR has tracked as a growing share of incidents.[3]

NIST's supply chain guidance is unambiguous that third-party risk management must be a continuous, risk-tiered programme integrated with procurement — not a onboarding gate.[1] The six stages below are how that principle turns into an operating model.

Stage 1: Inventory

You cannot manage what you have not enumerated, and almost every organization underestimates its vendor count by a wide margin — because procurement records, expense claims and shadow SaaS are three different populations.

• Sources to reconcile — accounts payable, procurement contracts, SSO and OAuth grant logs, expense reports, and DNS/certificate records showing third-party services on your domains.
• Minimum record — legal entity, service provided, business owner, data accessed, systems integrated, contract renewal date.
• The critical field — what would break, and for how long, if this vendor went dark tomorrow. This is the field that drives everything downstream.

Stage 2: Tiering

Tiering allocates attention. It must be driven by consequence — what the vendor could cost you — not by contract value, which correlates poorly with risk. A $9,000 monitoring tool with privileged production access outranks a $3M facilities contract.

Stage 3: Assessment depth by tier

The purpose of tiering is that Tier 3 and 4 vendors — usually the large majority — never consume analyst time unless evidence says they should. For them, an externally measured score is the assessment.

For Tier 1 and 2, layer methods deliberately: start from external evidence to know where to look, then use questionnaires and document review only for controls external observation genuinely cannot see — backup testing, segmentation, joiner-mover-leaver process, subprocessor management. Asking a Tier 1 vendor 300 generic questions produces less insight than asking twelve pointed ones informed by what you already observed. Why the questionnaire cannot carry the load alone is examined in the limits of vendor security questionnaires.

Stage 4: Contractual controls

Contracts are where a programme gets its enforcement power, and the clauses must be negotiated before signature — leverage disappears afterwards. ISO/IEC 27036 provides the reference structure for security in supplier relationships.[5]

• Incident notification — a defined maximum notification window in hours, not "promptly", with a named contact and required content.
• Right to assess — the right to reassess on a defined cadence and upon material change, including after the vendor's own incidents.
• Subprocessor disclosure and approval — the entry point to fourth-party visibility — see supply chain risk.
• Minimum control commitments — specific and testable (MFA on all administrative access, encryption at rest, defined recovery objectives) rather than "industry standard practices".
• Remediation obligations — timelines for critical findings, with escalation and termination rights if missed.
• Return and destruction of data — verified, on a deadline, at termination.

Stage 5: Continuous monitoring

This is the stage that separates a programme from a paperwork exercise. Vendor posture changes constantly; an annual review is blind for 51 weeks. Continuous external monitoring closes that window, and its value is entirely in the alerting logic: a stream of score fluctuations nobody triages is noise.

CISA's known-exploited catalogue is the practical benchmark for the second row: exposure to a catalogued vulnerability is a materially different signal from a generic CVE.[4]

Stage 6: Offboarding

Terminated vendors remain a risk while they retain access or data, and offboarding is the most commonly skipped stage. A minimum checklist: revoke SSO, OAuth grants and VPN access; rotate any shared credentials and API keys; confirm data return or destruction in writing; remove network allowlist entries and DNS delegations; and close the register entry with a date. Dormant integrations from vendors nobody has paid in three years are a recurring finding in real incidents.

What to automate

• Automate — discovery reconciliation, external scoring of the entire population, monitoring and alert triage, evidence collection reminders, and register hygiene.
• Keep human — tiering decisions, interpretation of Tier 1 findings, negotiation, exception approval and termination judgements.

The economics only work with this split. Scoring every vendor externally — no questionnaires, no vendor cooperation required, under the patented Xcigence method[6] — is what frees analyst capacity for the twenty relationships that carry most of the risk. See third-party cyber risk scoring for how that baseline is produced and maintained.

Metrics that matter

Report outcomes, not activity. Questionnaires completed is activity; the metrics below are outcomes, and they map to the governance expectations of NIST CSF 2.0.[2]

• Coverage — percentage of the reconciled vendor population under active monitoring.
• Concentration — percentage of Tier 1 vendors below your sector threshold, and the largest shared dependency across your book.
• Time to remediation — median days from critical vendor finding to verified closure.
• Ecosystem exposure — aggregate quantified loss exposure attributable to third parties, trended quarterly.