Resetting TPRM around a continuous monitoring supplier lifecycle

Most third-party risk programmes were designed for a world that no longer exists. They were built around an annual questionnaire, a once-a-year SOC 2 review, and a contractual right-to-audit that nobody exercises. That model produced a tidy binder and a comforting line in the audit report. It does not produce risk intelligence. And under DORA, NIS2 and the supply-chain provisions that now sit inside every serious financial supervisor's playbook, the binder is no longer enough, the regulator expects to see a programme that knows what its critical vendors are doing this week, not what they self-attested last year.

The failure modes are now well understood

Five failure modes recur across every TPRM reset I have seen. Questionnaire fatigue, where suppliers cut-and-paste prior answers and reviewers skim them. Data staleness, where the SOC 2 in the file is two regulator-years old. Tier inflation, where every vendor ends up "high risk" because nobody wanted to defend a lower tier in front of the audit committee. Process orphaning, where onboarding has an owner, renewal has an owner, and the period in between has nobody. And exit blindness, where the offboarding control assumes a clean termination that the contract does not actually enable. Any one of these will embarrass a programme. All five together, which is the default starting point, guarantee it.

The reframe: a supplier security lifecycle anchored in risk

The right mental model is not "the questionnaire." It is the supplier security lifecycle, a continuous loop with five named phases, each with explicit entry and exit criteria, each producing structured artefacts that flow into the next.

1. Intake and inherent risk. Before any due diligence, classify the engagement by what the supplier will actually do: data accessed, systems connected, criticality to a regulated service, geographic exposure. Inherent risk drives depth of diligence, not the other way round. A SaaS expense tool and a cloud co-location provider should not get the same questionnaire.

2. Due diligence and tiering. Tier on inherent risk, then run diligence proportionate to the tier. Tier 1 (critical to a regulated service or with privileged data access) gets the deep review: certifications, financial health, sub-processor chain, incident history, architecture walkthrough where warranted. Tier 3 (commodity SaaS, low data exposure) gets the lightweight pack and an automated external scan. The whole point of tiering is to free human time for the engagements that actually matter.

3. Contractual controls. Right-to-audit is the floor, not the ceiling. Critical-vendor contracts should encode incident notification thresholds with named SLAs, sub-processor change notice, evidence-on-demand for specific controls, exit assistance obligations, and, for DORA-in-scope arrangements, the full Article 30 contractual register. Most contract gaps in TPRM are not legal problems; they are programme design problems wearing legal clothes.

4. Continuous monitoring. The phase that distinguishes a modern programme from a 2015 programme. Signal flows from external attack surface tools (BitSight, SecurityScorecard, UpGuard, Panorays, Black Kite), breach intelligence feeds, certificate transparency monitoring, dark-web monitoring for credential exposure, and, increasingly, the vendor's own Trust Centre. Signal is correlated against the inherent-risk tier and the contractual SLA, and material changes are ticketed against a named owner with a defined response window. The point is not to have a dashboard. The point is to detect material change between point-in-time reviews and act on it.

5. Periodic deep review and exit. Tier 1 vendors get a periodic deep review on a defined cadence, annually at minimum, more frequently when signal warrants. Exit is a phase, not an event: data return, key rotation, access revocation, evidence of destruction, and a contractual hold-back where the regulator expects one. A programme that cannot describe its exit posture for its top ten critical vendors does not yet have a programme.

What "anchored in risk" actually means

Every artefact in the lifecycle ties back to two numbers: inherent risk (what could go wrong if this supplier failed completely) and residual risk (what could still go wrong after controls). The board's question is always some form of "where is our residual risk concentrated?", by supplier, by service, by geography, by sub-processor. If the programme cannot answer that question in the room, the rest of the binder is decoration.

The tooling honestly

No single tool does the whole lifecycle well. A pragmatic stack is: a GRC platform (ServiceNow VRM, ProcessUnity, OneTrust, Prevalent) for the workflow and the register; an external attack surface and rating tool (BitSight, SecurityScorecard, UpGuard, Panorays, Black Kite) for continuous signal; a breach intelligence feed; and a contract lifecycle tool that the legal team will actually use. Buy for integration, not for feature lists. The signal is worthless if it cannot flow into the ticket.

What to do on Monday morning

• List your top 20 vendors by inherent risk, not by spend. If the list is significantly different from your spend-ranked list, you have an immediate communication problem with finance.
• Pick the top 5 and check three things: when was the last point-in-time review, what continuous signal do you have on them today, and can you describe the exit plan from memory.
• Stand up an external attack surface tool against the top tier this quarter. The cost is small; the signal-to-noise ratio is good enough to be useful immediately.
• Write the exit playbook for one critical vendor end-to-end. The exercise will surface every contractual gap in your portfolio.

Closing

Third-party risk is no longer a once-a-year exercise. The regulators have moved, the threat landscape has moved, and the tooling has finally caught up. The programmes that survive the next supervisory cycle will be the ones that have replaced the questionnaire-and-binder mental model with a supplier security lifecycle anchored in risk. The rest will keep producing tidy artefacts that do not answer the question the audit committee is actually asking.