Scope
This guide shows you how to build a third-party risk management program that satisfies SS2/21, PS26/2, DORA, and the EBA Guidelines on ICT and security risk management. It's tailored for financial institutions operating under multiple European regulatory regimes that need to demonstrate compliance without maintaining separate control sets.
You'll find requirement mappings, implementation priorities, and a reference table to trace each control back to its regulatory source. This isn't about checking boxes; it's about building a defensible, auditable program that scales as your vendor ecosystem grows.
Key Concepts and Definitions
Regulatory Convergence: When multiple regulatory frameworks impose overlapping obligations on the same operational domain. In third-party risk, SS2/21, PS26/2, DORA, and the EBA Guidelines all require due diligence, ongoing monitoring, and incident management, but with different emphasis points and terminology.
Control Objective Mapping: Identifying where a single control satisfies multiple regulatory obligations. For example, a vendor exit plan that documents data retrieval and service continuity addresses DORA's operational resilience requirements, EBA's outsourcing guidelines, and SS2/21's operational risk framework simultaneously.
Vendor Risk Profile: A structured assessment that captures inherent risk (what the vendor does), residual risk (what controls are in place), and regulatory exposure (which frameworks apply to this relationship). Your profile structure determines whether you can reuse assessments across regulatory contexts.
Impact Tolerance: DORA's term for the maximum level of disruption an organization can absorb from an ICT service failure. This concept appears in different forms across all four frameworks; EBA calls it "proportionality," SS2/21 references "materiality thresholds."
Requirements Breakdown
SS2/21 and PS26/2 Core Obligations
These PRA and FCA rules establish outsourcing and third-party risk requirements for UK financial institutions. The core obligations include:
- Due diligence before entering material arrangements
- Written contracts with specific risk management clauses
- Ongoing monitoring of third-party performance and control environment
- Contingency planning for service failure or exit
- Board and senior management oversight of material outsourcing
DORA's ICT Third-Party Framework
DORA applies to EU financial entities and introduces specific requirements for ICT service providers:
- Pre-contractual analysis of concentration risk
- Register of all ICT third-party arrangements
- Digital Operational Resilience Testing of critical providers
- Contractual provisions for access, audit, and termination rights
- Notification requirements for ICT-Related Incidents at third parties
EBA Guidelines on Outsourcing
The EBA Guidelines provide detailed expectations for outsourcing arrangements, including:
- Risk assessment methodology covering operational, compliance, and concentration risks
- Documentation standards for risk analysis and decision rationale
- Sub-outsourcing oversight requirements
- Specific contractual clauses on audit rights, data protection, and business continuity
- Exit strategies with defined timelines and responsibilities
Implementation Guidance
Build Your Unified Control Framework
Start by mapping control objectives, not individual requirements. Create a matrix with these columns: control objective, control description, SS2/21 reference, PS26/2 reference, DORA article, EBA guideline section.
You'll find that vendor onboarding due diligence satisfies obligations across all four frameworks. Document it once, reference it four times. The same applies to contract templates, ongoing monitoring procedures, and incident response protocols.
Structure Your Vendor Risk Profile
Your assessment questionnaire should capture:
Service classification: Is this an ICT service under DORA? Does it meet the materiality threshold for SS2/21? The same vendor might be material under one framework but not another.
Inherent risk factors: Data access, criticality to operations, substitutability, concentration exposure. These dimensions appear in all four frameworks.
Control environment: Security controls, business continuity capabilities, incident management processes, sub-contractor oversight.
Contractual provisions: Audit rights, termination clauses, data retrieval procedures, notification requirements. DORA and the EBA Guidelines specify particular language; build those clauses into your standard template.
Prioritize by Regulatory Exposure
Not every vendor triggers all four frameworks. A UK-only institution using a non-ICT service provider might only need SS2/21 compliance. An EU entity using a critical ICT provider needs the full DORA treatment plus EBA Guidelines.
Tag each vendor with applicable frameworks during intake. This prevents over-assessment (wasting time on controls that don't apply) and under-assessment (missing a regulatory obligation because you assumed the vendor was out of scope).
Use Technology for Multi-Framework Reporting
Manual spreadsheets can't maintain traceability when you're mapping controls to four different regulatory sources. You need a system that:
- Stores control evidence once and links it to multiple framework requirements
- Generates framework-specific reports without duplicating underlying data
- Tracks remediation of deficiencies and shows which regulatory obligations are affected
- Maintains an audit trail showing when assessments were completed and by whom
An Integrated Risk Management (IRM) Platform with multi-framework mapping capabilities eliminates the need to maintain separate compliance programs.
Common Pitfalls
Treating Frameworks as Identical
DORA requires Digital Operational Resilience Testing for critical ICT providers. The EBA Guidelines emphasize proportionality and don't mandate testing for all material outsourcing. If you apply DORA's testing requirements to every EBA-covered vendor, you're over-engineering. If you skip testing for DORA-covered ICT services because EBA doesn't require it, you're non-compliant.
Read each framework's scope provisions carefully. Map them to your vendor universe. Apply the most stringent requirement where frameworks overlap, but don't extend requirements beyond their regulatory scope.
Ignoring Contractual Language Differences
DORA Article 30 specifies particular contractual provisions for ICT third-party arrangements: full access and audit rights, notification of ICT-Related Incidents, termination rights with adequate notice. The EBA Guidelines have similar but not identical language.
Don't assume your standard contract satisfies both. Cross-reference the specific articles and guidelines. Build contract templates that explicitly address each framework's requirements, or maintain framework-specific addenda.
Underestimating Documentation Requirements
All four frameworks require documented risk analysis, not just completed assessments. You need to show:
- Why you classified a vendor as material or critical
- What alternatives you considered
- How you evaluated concentration risk
- What mitigating controls justified accepting residual risk
If your documentation is a scored questionnaire with no narrative analysis, you haven't met the standard. Build documentation templates that capture decision rationale, not just yes/no answers.
Failing to Maintain Separate Registers
DORA requires a register of ICT third-party arrangements. SS2/21 expects a register of material outsourcing. These aren't the same population; your ICT register will be broader (it includes all ICT services, not just material ones), while your SS2/21 register might include non-ICT material outsourcing.
Maintain both registers. Use your platform to generate them from the same underlying vendor data, filtered by the appropriate criteria. Don't try to force a single register to serve both purposes.
Quick Reference Table
| Requirement Domain | SS2/21 | PS26/2 | DORA | EBA Guidelines |
|---|---|---|---|---|
| Pre-contract due diligence | Required for material outsourcing | Required for material outsourcing | Required for all ICT arrangements | Required, proportionate to risk |
| Written contract required | Yes, with specified clauses | Yes, with specified clauses | Yes, Article 30 provisions | Yes, Annex provisions |
| Ongoing monitoring | Performance and controls | Performance and controls | Includes resilience testing | Risk-based monitoring |
| Incident notification | Material operational incidents | Material operational incidents | ICT-Related Incidents per Article 19 | Significant incidents |
| Concentration risk assessment | Implicit in risk assessment | Implicit in risk assessment | Explicit requirement, Article 28 | Guideline 3.4 |
| Exit planning | Required for material arrangements | Required for material arrangements | Required with defined timelines | Required, proportionate |
| Sub-outsourcing oversight | Required | Required | Required for critical functions | Detailed requirements in Section 12 |
| Register maintenance | Material outsourcing register | Material outsourcing register | ICT third-party register | Outsourcing register |
| Board oversight | Material arrangements | Material arrangements | ICT risk strategy approval | Outsourcing policy approval |
Bookmark this table. When you're evaluating a new vendor or updating your program documentation, trace each control back to its regulatory source. You're not building four programs; you're building one program that satisfies four sets of regulators.
