Module · Third-Party Risk Workbench

    Your fourth party is the one that takes you down.

    Most third-party programmes are questionnaire archives. Supervisors have stopped asking whether the questionnaire was returned and started asking whether the institution could keep operating without the provider. That is a resilience question, so it belongs in the same operating layer as everything else.

    The workbench

    Providers in register

    6

    Registered at onboarding with service, data classes and jurisdictions.

    Critical without a tested exit

    2

    Substitutability asserted rather than evidenced.

    Shared fourth-party clusters

    1

    Two or more providers resolving to the same dependency.

    Reading

    Core payments processor

    Not substitutable inside a plausible disruption window

    Business service
    Domestic and cross-border payments
    Tested time to replace
    52 weeks
    Exit plan tested
    No
    Attestation age
    14 months

    What drives the reading

    • Criticality critical against Domestic and cross-border payments.
    • Tested time to replace is 52 weeks — beyond a plausible disruption window.
    • Exit plan documented but not tested; substitutability is asserted rather than evidenced.
    • Assurance attestation is 14 months old and outside the supervisory window.
    • 3 open finding(s) against this relationship.
    • 2 dependency at fourth party or beyond.

    Dependency chain

    • Tier 4 · Hyperscale region (single)Processing concentrated in one region with no tested failover.
    • Tier 4 · Sanctions screening engineScreening supplied by a sub-processor under the same contract.
    DORA Articles 28–30
    NIS2 Article 21

    Concentration, read across the register

    A register that lists providers one at a time cannot see this. The exposure is where separate relationships resolve to the same dependency.

    • Hyperscale regionCore payments processor · Enterprise identity provider

    Figures shown are computed against a demonstration register. Client portfolios are assessed inside the engagement environment against that institution’s own providers and evidence.

    The lifecycle

    Stage 01

    Intake

    Provider registered with service, data classes, jurisdictions and downstream dependencies captured at onboarding — not at renewal.

    Stage 02

    Criticality

    Assessed against important business services, not spend. A low-cost provider inside a payment path is critical.

    Stage 03

    Substitutability

    Time-to-replace, tested exit plan, and whether a credible alternative exists at institutional scale.

    Stage 04

    Concentration

    Fourth-party mapping surfaces the cloud region, the model provider and the settlement rail three vendors deep.

    Stage 05

    Continuous monitoring

    Provider posture, incident history and attestation currency tracked between reviews, not once a year.

    Stage 06

    Evidence

    Contract clauses, audit reports, penetration test summaries and AI attestations bound to the control they satisfy.

    Obligations it evidences

    DORA Articles 28–30

    Register of information, contractual requirements, critical-provider designation and exit strategies.

    OSFI B-10

    Third-party risk lifecycle, criticality assessment and concentration reporting.

    OSFI E-23

    Model and AI provider governance where the model is supplied rather than built.

    NIS2 Article 21

    Supply-chain security measures for essential and important entities.

    FFIEC / OCC 2023-17

    Third-party relationship lifecycle expectations for US banking organisations.

    EU AI Act Article 25

    Obligations along the AI value chain where a provider becomes a deployer.

    Feeds ORS third-party dimensionShares the CFIA dependency graphOne evidence vault, no parallel archive
    Scope a third-party programme