Fourth-party risk management that finds the single points of failure behind your vendors, before an outage or a regulator does
Single points of failure found before an outage or a regulator does.
See one case, screen by screen ↓Fourth-party risk management is knowing which of your vendors' own subcontractors your critical services depend on, and where many of them end at the same provider. Fourth-Party Risk Management finds those subcontractors from SOC reports, contracts, DPAs, trust pages and public notices, cites every link, counts the concentrations against your impact tolerances and watches the providers for incidents. Seven agents do the reading and counting; your resilience manager decides and signs.
How to choose AI solutions for back-office and enterprise work →
Updated
Your vendors depend on the same few clouds, payment processors, telecom carriers and support centres. On the vendor list they look unrelated; behind them, five of them may run in one cloud region. Vendors list sub-processors for personal data, not the subcontractors that keep a service running, and the hosting region often appears only in a SOC report's section on subservice organisations or on a status page. So the chain from critical service to vendor to subcontractor lives in a spreadsheet that is out of date by the next renewal, and concentration is judged by eye.
When a big provider fails, the first hours go on emailing every vendor to ask whether they are affected. Nobody can say in advance which services would run past their impact tolerance after a 24-hour loss. And DORA, which applies since 17 January 2025, asks financial entities to list, by rank, the subcontractors that effectively underpin each ICT service supporting a critical or important function, in register template RT.05.02, and for an assessment of ICT concentration risk. Rows without ranks or identifiers fail the supervisors' data-quality checks, and rows that disagree with the contracts do not survive an audit.
Estimated split for one quarterly review of 22 critical services and the vendors behind them, by hand and with the solution. Waiting for vendors to answer is not counted.
Seven agents find, check, count, simulate and watch the chain; the resilience manager decides and signs.
At 07:18 on 14 October, Altocirra Cloud reports degraded compute and storage in its Frankfurt region, FRA-1. Kestrel & Vane Group reaches Altocirra only through its vendors. Here is what happens next, screen by screen, in the working solution.
Tomasz Nowak, the Operational Resilience Manager, opens his home screen to a feed of what the agents did and what needs him: 22 critical services, 131 fourth parties, 9 concentrations, 6 decisions and 1 incident live. The Watch agent has matched Altocirra's status notice to the map six minutes after it was posted. Each message carries its sources and the next step as a button.
Watch agent: “Altocirra Cloud FRA-1 is degraded since 07:18. It sits behind 7 of our 22 critical services through 5 vendors. Warehouse operations is affected now.”
On the concentration map, critical services sit in the centre ring, the 38 vendors that deliver them in the next, and their subcontractors outside. Lit by the incident, 7 of 22 services reach FRA-1 through Paylinea, Quorvel Payments, Ledgerline Treasury, Brightwave Contact and Fennick WMS. Beside the picture, each service shows its tolerance and a result: Payroll (EU) and Warehouse operations over, card authorisation uncertain, four within.
Concentration agent: “I ran a 24-hour loss of FRA-1 against our tolerances. Payroll (36 h vs 24 h) and Warehouse operations (18 h vs 8 h) would run over. Four hold. Card authorisation is uncertain.”
The scenario is a full loss of FRA-1 for 24 hours. For each service the agent uses the vendor's own failover evidence: Paylinea is single-region with a restore in AMS-2 within 36 h; Ledgerline has a warm standby at Kelderan Cloud in Dublin, tested 12 June; Fennick WMS has no secondary and falls back to manual pick lists. Result: 2 over tolerance, 1 uncertain, 4 within. The same run can be set before the 24 October pay run, or compared with an AMS-2 loss.
“Unknown failover is never assumed: it shows as uncertain.”
From the incident watch, Tomasz opens the notices for the seven exposed services and their owners: Carla Jensen for payroll and time and attendance, Joost de Wit for card authorisation and dealer payments, Elise Marchetti, Daniel Okoye and Marta Kowalczyk. The drafted message says what happened, that warehouse operations is already affected and what a full-day outage would mean, and asks each owner to confirm their continuity contact by 12:00.
“Drafted by the Watch agent. Edit anything; nothing is sent until you press Send.”
Paylinea's questionnaire answer said only “Hosted in the EU with a leading cloud provider.” The Discovery agent read 5 Paylinea documents, 180 pages, and found production in Altocirra FRA-1 in the SOC 2 Type II report, the DPA v5 annex and the trust page; AMS-2 holds backups only, restored in 36 h. The Verifier confirmed FRA-1 from a second source. Two links found in one document only wait for the vendor.
Verifier: “Confirmed FRA-1 from a second source, the DPA annex. Mailroute Relay and Vettra appear in one source only: I suggest asking Paylinea.”
Re-running discovery on a vendor shows the plan and each source as it is read: which documents changed since the last run, the SOC report's subservice organisations, the contracts and DPA annexes, the trust and status pages, and the Verifier's second read of each new link. Overnight the agents re-read 46 documents for 12 vendors and found 4 new links and 2 retired.
Quorvel's contract, Schedule 3 §2.4, says the tokenisation vault runs active-active across FRA-1 and AMS-2. The newer DPA annex, revision 3 dated 14 August 2026, puts it in FRA-1 only, and Quorvel's newsroom agrees. The Verifier does not average the two: it puts both passages to Ravi Menon. He rules the DPA is current, with a reason, and card authorisation moves to over tolerance in every FRA-1 scenario.
Ravi's reason: “The DPA annex is newer (Aug 2026) and matches the newsroom; the contract schedule predates the consolidation.”
The Concentration agent proposed accepting Brightwave Contact: the contact centre fails over in 4 h against an 8 h tolerance, and the failover was tested on 3 March 2026. Tomasz picks the reason code “Within impact tolerance — tested failover”, a review date of 14 Oct 2027, the compensating control “Yearly failover test with Brightwave”, and signs with his password. The acceptance is recorded in the register and the audit trail.
Meaning of the signature: “I accept this concentration for the period stated.”
For payroll and the warehouses Tomasz opens exit plans instead, owned by Amara Okafor. The Exit planner drafts three options for payroll from the chain and the contracts: Paylinea's “Resilience Plus” hot standby in AMS-2 (€64,000 a year, 3 months, 4 h failover), a move to another payroll provider (€420,000 one-off, 9 months), or a tested manual fallback before the 24 October pay run. Five steps follow, each with an owner and a date.
The Exit planner drafts; Amara approves the plan and schedules its test.
The Register agent keeps the RT.05.02 rows for Kestrel & Vane Financial Services in step with the confirmed links and the decisions: 74 rows, 9 new and 3 changed. 114 of 116 checks pass; the two failures come with fixes found in the sources: Siltrace's identifier from its annual report, and Ostrander Messaging Hub corrected to rank 2 from Ledgerline's DPA. The Quorvel row waited for Ravi's ruling. Pieter van Dalen validates, then signs the export.
Register agent: “Each fix waits for your approval. The Quorvel row stays out until Ravi Menon rules.”
The same morning, seen by the five people who carry it: what fourth-party risk looked like before, and what it looks like now.
Seven agents find, check, count, simulate and watch the chain; the resilience manager decides and signs.
Finds each vendor's subcontractors at rank 2 and theirs at rank 3 from SOC reports (subservice organisations), contracts, DPA annexes, trust pages and public notices, and cites the passage for each.
Re-reads each link from a different source without seeing the first read, and marks it confirmed, single-source or contradicted.
Links critical services to the vendors that deliver them, from contracts, the CMDB and the business impact analysis.
Counts how many critical services and vendors end at each fourth party, and runs outage scenarios against each service's impact tolerance.
Reads status pages, incident news and notices about the 131 fourth parties, matches them to the map and drafts the notices to service owners.
Writes the DORA RT.05.02 supply-chain rows from confirmed links, keeps them in step with decisions and runs the 116 checks.
Drafts exit options with the contract terms that allow each, cost, time and the continuity test that proves it.
Accepts, opens exit plans, signs. The agents propose; a named person decides.
The map, the vendor chains, the incident watch and the register each have a conversation with the agents beside them. Ask about any service, vendor or fourth party, or give an instruction in plain words. Every answer is cited, and nothing changes until you confirm.
Which services stop if Altocirra FRA-1 is down for a day?
If FRA-1 is lost for 24 hours, Payroll runs 36 h against 24 h and Warehouse operations 18 h against 8 h, both over tolerance. Time and attendance, dealer payments, treasury (standby in Dublin) and the contact centre hold. Card authorisation is uncertain until Ravi rules.
Why is card authorisation uncertain?
Quorvel's contract says the tokenisation vault runs active-active in FRA-1 and AMS-2. Their DPA annex from August puts it in FRA-1 only, and their newsroom says they consolidated it in August. If the DPA is right, a FRA-1 loss stops card authorisation for up to 6 h against a 2 h tolerance. Ravi Menon decides which document is current.
Which fourth parties sit behind payroll?
Behind Payroll (EU) are 9 fourth parties through Paylinea and Tallis HR. The one that matters: production on Altocirra FRA-1 with a 36-hour restore. Also Ferrow Print & Post for payslips, and Mailroute Relay, still awaiting Paylinea's confirmation.
Watch Siltrace daily
Here is my plan: read Siltrace's status page every 5 minutes and its notices daily; on any signal, run the 5-service scenario and post the result here. Shall I start?
13 screens from the working solution, on its sample data. Pick one to see it large.
What counts as a concentration, and how a link is confirmed, are settings. Changes are versioned and logged, and a new threshold goes to the risk committee as a draft.
| Setting | Default | Choose from |
|---|---|---|
| A fourth party is a concentration when it sits behind at least | 3 critical services | Policy §4.2. At 2 the preview shows 14 concentrations instead of 9, saved as draft version 5 for the risk committee to approve |
| …or behind at least | 3 vendors of critical services | Counted alongside the services threshold |
| Count standby sites | Off | Off: only primary paths count, standby regions are shown but not counted · On |
| Confidence floor for a link | 0.80 | Below it, a link is “probable” and needs a second source |
| A link is confirmed when two independent sources agree | On | SOC report, contract, DPA, trust page, notice, or the vendor in writing |
| Re-discover each vendor | Every 90 days and at renewal | And whenever a document is added |
| Agent autonomy | Propose only | Propose only · Act with approval, which needs the risk committee's sign-off |
| Vendor confirmation | 10 working days | Reminders on day 5 and day 10, then to the third-party risk manager |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
“demo” = seen in the working solution, on its sample data · “target” = the design goal, measured in the live solution · “estimated” = our estimate · “typical” = published figures (Verizon 2025 Data Breach Investigations Report: 30% of breaches involve a third party; Parametrix: an estimated $5.4 billion direct loss to US Fortune 500 companies from one faulty update on 19 July 2024; European Supervisory Authorities' 2024 register dry run: about 6.5% of firms passed all 116 data-quality checks). DORA: Regulation (EU) 2022/2554, Art 28–29; register template RT.05.02 from Implementing Regulation (EU) 2024/2956. Kestrel & Vane Group, its vendors and providers, and the people named on this page are fictional: characters and sample data in the working solution.
Fourth-party risk management is knowing which of your vendors' own subcontractors your critical services depend on, and where many of them end at the same provider. Fourth-Party Risk Management finds those subcontractors from SOC reports, contracts, DPAs, trust pages and public notices, cites every link, counts the concentrations against your impact tolerances and watches the providers for incidents. Seven agents do the reading and counting; your resilience manager decides and signs.
The Discovery agent reads each vendor's SOC report section on subservice organisations, contract schedules, DPA sub-processor annexes, trust and status pages and public notices, and records each subcontractor with its rank, role, region and the exact passage. The Verifier re-reads every link from a different source; it is confirmed only when two sources agree. A questionnaire answer counts only with a document.
The Concentration agent counts how many critical services and vendors end at each fourth party. In the working solution, a fourth party behind 3 or more critical services or 3 or more vendors is a concentration (policy §4.2); the threshold is a setting your risk committee approves. It then runs outage scenarios, a given provider, failure and duration, against each service's tolerance, using only each vendor's documented failover.
The Watch agent reads status pages, incident news and notices, matches the provider and region to the map and posts the exposed services and vendors with citations. In the working solution, a cloud region's degradation at 07:18 showed 7 of 22 critical services exposed through 5 vendors within six minutes. It drafts notices to the service owners; a person sends them.
The Register agent writes the RT.05.02 supply-chain rows, by rank and with identifiers, from confirmed and cited links, and keeps them in step with your decisions. It runs the 116 data-quality checks and proposes a fix for each failure from the sources. Pending links stay out, and the DORA officer validates, signs and exports; the agent never submits.
No. The demo company is a diversified group whose finance arm falls under DORA; the group runs the same map, scenarios and decisions for all 22 of its critical services. The register rows are written only for the entity that needs them.
Yes. The agents read, count, simulate and draft; they never accept a risk, contact a vendor, send a notice or submit the register. A named person rules on contradictions, only the Operational Resilience Manager accepts a concentration, for at most 12 months, and every decision is signed, with its reason.
The Agentic Solution Engine builds and deploys it from your requirements and documents, such as your business impact analysis, vendor master, resilience policy and a sample of vendor SOC reports, contracts and DPAs, and it goes live once every quality gate has passed. We will walk you through it on your own vendors first.
Exceptions weighed and every user-entity control owned before the SOX year-end test.
1-min demoThird-Party Contract ReviewMissing audit, exit and subcontracting clauses fixed before renewal, not at inspection.
1-min demoSupply Chain Due DiligenceDetained goods released with a trace to the raw material, every link proved.
1-min demoWe'll run Fourth-Party Risk Management on your own critical services and a sample of your vendors' SOC reports, contracts and DPAs.