The Central Bank of Ireland's CP173 — "Guidance on Good Practices for the Sound Management of Third-Party Risks" — turns outsourcing into a subset of a much wider duty. If your DORA register captures ICT providers and a spreadsheet captures the rest, CP173 is the moment those two have to become one register, kept current, with the same evidence behind every entry.
CP173 is the Central Bank of Ireland's consultation paper on third-party risk, published in October 2026 and open for submissions until 3 December 2026. It is cross-industry and outcomes-focused — it says "should", not "must" — and when it is finalised, expected in Q1 2027, it withdraws the 2021 Cross-Industry Guidance on Outsourcing. The draft names publication of the final guidance as the effective date, with no transition period yet proposed, so the Central Bank is specifically asking firms for views on how long they need.
The shift that matters is in scope. CP173 covers any arrangement where a third party provides services or support on an ongoing or recurring basis — cloud providers, partnerships, joint ventures, and intra-group providers included. Outsourcing becomes one slice of "third-party arrangements", and the Central Bank is explicit that relabelling an arrangement as "delegation" does not move it out of scope. The question is no longer "is this outsourcing?" but "is a third party doing something your firm relies on?"
DORA already governs ICT third-party risk for financial entities, uniformly across the EU. The EBA's final guidelines on third-party risk and CP173 extend standards broadly aligned with DORA to non-ICT arrangements too — the stated aim is a single, harmonised approach rather than one rulebook for your cloud provider and another for your outsourced claims handler, your print bureau, or your facilities and professional-services providers.
For a firm already applying DORA and the binding EBA guidelines, CP173 adds limited new content for the ICT arrangements themselves. Its practical bite is elsewhere: it pulls the non-ICT third parties you have been managing on the side into the same register, the same criticality methodology, and the same lifecycle discipline. The firms the commentary expects to feel it most are the ones without a comprehensive DORA framework already in place — smaller insurers, credit-servicing and retail-credit firms — and anyone whose "register" for non-ICT suppliers is a spreadsheet nobody reconciles against the contracts.
CP173 expects a complete, current register covering every third-party arrangement — in the Central Bank's template format. These are the fields, split into the baseline every entry needs and the extra fields a critical or important arrangement adds.
Provider identity including its LEI; the service and the data locations; whether personal data is involved; and the critical-or-important classification with the rationale behind it. No arrangement sits off-register because it is "only" non-ICT.
The approver and governing law; audit and due-diligence dates; the sub-contractor chain; a substitutability rating from "not substitutable" to "easily substitutable"; recovery objectives; named alternative providers; and continuity and exit test dates.
The register has to be complete and current on request. A snapshot that was true last quarter is the gap supervisors find first — the register the operational team actually works from is the one that survives a review.
CP173 organises its good practices around the life of an arrangement. Each stage has foundational practices (the core) and supporting practices (enhancements you apply where your own risk assessment justifies them). The board stays accountable throughout — it can delegate the work, never the accountability, and the Central Bank repeats its warning against letter-box entities.
Beyond the lifecycle, CP173 gives dedicated treatment to four risks. None is prohibited — each has to be assessed and mitigated, with the residual risk owned.
Document your risk appetite. Only agree where the sub-contractor meets the law and grants equivalent access and audit rights, with prior approval built into the contract.
Single-provider dependence, several services from one provider, single-region exposure, and shared fourth parties. Dominant providers are allowed — unassessed residual risk is not.
Same rigour as an external provider: arm's-length terms, conflict-of-interest provisions, and local summaries of group assessments and exit plans.
Not discouraged, but assess regulatory, legal, political, climate and time-zone risk — and never let the arrangement impede the firm's or the regulator's access.
1. Two registers that should be one. ICT in a DORA register, everything else in a spreadsheet, means two sources of truth, two owners, and no single view of a provider that supplies both. CP173 expects one register across ICT and non-ICT, in the Central Bank's format.
2. Criticality you can't show your working for. "Everyone knows that provider is critical" is the finding. CP173 expects a documented classification methodology, applied consistently, reviewed periodically, and watched for reliance that grows over time — with a named approver on each critical entry.
3. Evidence, substitutability and exit that only exist in people's heads. For every critical arrangement CP173 wants the audit and diligence dates, the sub-contractor chain, a substitutability rating, recovery objectives, named alternatives, and a tested exit. A cell that says "exit plan: yes" is not that.
FiorLab is an EU-native supplier risk platform, Dublin-built (CRO 813471). It was designed around exactly the problem CP173 formalises: one evidence-backed register across every third party, not a separate silo for ICT.
What FiorLab does not do is write your CP173 submission or make the classification calls for you — those are your firm's, and this page is an informational summary, not legal advice. What it gives you is the register, the evidence, and the methodology that make CP173's expectations demonstrable rather than aspirational. Every capability above is in production today.