Plan
Define the business need, service owner, data and system access, criticality, alternatives, concentration exposure, risk appetite, and exit assumptions before a vendor is selected.
Third-party governance
Govern third-party technology risk as an owned business dependency.
A vendor questionnaire is not a third-party risk program. Build a lifecycle that identifies what the organization depends on, who owns the risk, what evidence was relied on, which contractual and technical controls matter, how concentration and resilience are tested, and how the relationship can be changed or exited safely.
Substantively reviewed . This revision corrects the Federal Reserve source from unrelated SR 23-11 to SR 23-4, separates PRA SS2/21 from the SS1/21 impact-tolerance framework, and incorporates the PRA's 2026 future reporting changes and APRA's 2026 CPS 230 amendments.
Applicability first
Use regulatory material as scoped authority, not universal vendor law.
Third-party governance is a broadly useful operating discipline, but the legal and supervisory sources cited on this page apply to different sectors and jurisdictions. The 2023 U.S. interagency guidance, for example, applies to banking organizations supervised by the Federal Reserve, FDIC, and OCC. The Federal Reserve expressly says the guidance describes sound risk-management principles and does not impose new requirements on banking organizations.
Likewise, PRA SS2/21 applies to specified PRA-regulated firms; DORA applies to financial entities within its scope; APRA CPS 230 applies to APRA-regulated entities; and OSFI Guideline B-10 applies to federally regulated financial institutions within its stated scope. Organizations outside those regimes can still use the operating patterns here, but should not represent the cited supervisory material as binding on them without a separate applicability analysis.
For legal, regulatory, contractual, privacy, or sector-specific obligations, validate the current source and applicability with the responsible legal or compliance function.
Lifecycle
Make every material relationship move through the same decision system.
Assess
Collect evidence proportionate to the risk: security, resilience, privacy, financial condition, subcontracting, legal terms, service performance, architecture, control attestations, and known incidents.
Contract
Translate material requirements into enforceable terms, service levels, evidence rights, notification duties, data handling, subcontracting controls, continuity, termination, transition, and deletion or return obligations.
Operate
Monitor the service, control evidence, material changes, incidents, vulnerabilities, financial or ownership changes, concentration, exceptions, and fourth-party dependencies.
Reassess
Revisit materiality and risk when usage expands, data changes, architecture changes, the provider reorganizes, a critical subcontractor changes, or an external event alters the risk profile.
Exit
Test the ability to transition, recover data, remove access, replace integrations, preserve records, revoke credentials, and continue the business service without relying on an untested plan.
Materiality and dependency
Classify the dependency by consequence, not by vendor brand.
A large vendor can support a low-consequence service, while a small specialist can become a single point of failure. Evaluate the relationship using the service and dependency actually created.
- Business consequence. What service, mission, customer, financial process, safety function, legal duty, or critical operation fails if the provider is unavailable or compromised?
- Access and data. What privileged access, sensitive data, production connectivity, signing authority, administrative capability, or decision influence does the provider receive?
- Substitutability. How long would replacement take, what data or configuration must move, and are interfaces or skills proprietary?
- Concentration. Do multiple critical services depend on the same provider, cloud, identity service, network, managed-service firm, payment rail, or fourth party?
- Change sensitivity. Could a change in ownership, financial condition, subcontracting, geography, service scope, or architecture materially alter the risk?
DORA Article 28 requires in-scope financial entities to manage ICT third-party risk within the ICT risk-management framework and maintain a register of information for contractual arrangements involving ICT services. Article 29 also requires consideration of concentration risk for ICT services supporting critical or important functions. Those are sector-specific requirements, but the underlying dependency questions are useful more broadly.
Due diligence
Ask for evidence that can change the decision.
Due diligence becomes performative when every vendor receives the same questionnaire and every answer is accepted at face value. Start from the risk hypothesis and request evidence that can confirm, reduce, transfer, or reject that risk.
| Risk area | Evidence to consider | Decision question |
|---|---|---|
| Security | Architecture, identity model, vulnerability process, independent assurance, penetration-test summary, incident history | Can the provider protect the access and data this service requires? |
| Resilience | Recovery design, dependency map, test evidence, restoration results, regional/provider dependencies | Can the service recover within the business's tolerable disruption? |
| Data | Locations, subprocessors, retention, deletion, encryption, access controls, export capability | Can the organization meet its own data obligations and leave cleanly? |
| Operations | Service levels, support model, change process, maintenance windows, escalation, staffing | Can operational failures be detected and resolved at the required speed? |
| Concentration | Shared infrastructure, critical subcontractors, single-region or single-provider dependencies | Does this relationship increase an existing systemic dependency? |
| Exit | Formats, APIs, migration support, credential revocation, termination assistance, deletion evidence | Is replacement realistically executable rather than contractually imaginable? |
Contract controls
Put consequential expectations where they can be enforced.
Contract terms should follow from the risk assessment instead of being a disconnected legal template. For higher-risk relationships, consider the organization's applicable requirements for service descriptions, performance, security, confidentiality, access controls, incident and change notification, audit or evidence rights, records, subcontracting, business continuity, data location, return or deletion, termination assistance, and regulatory access.
Do not promise that a SOC report, ISO certificate, or contractual warranty eliminates the organization's responsibility. DORA explicitly states that in-scope financial entities remain fully responsible for their obligations when using ICT third-party services. U.S. banking guidance similarly emphasizes lifecycle risk management rather than outsourcing accountability itself.
For cloud and platform relationships where standard terms limit negotiation, record the residual risk and available compensating controls. The governance decision should be visible rather than disguised as “contract complete.”
Ongoing monitoring
Monitor the dependency that exists now, not the vendor assessed years ago.
- Service performance: availability, material incidents, recovery performance, support escalation, recurring defects, and SLA exceptions.
- Control evidence: current assurance reports, material findings, remediation status, penetration or resilience-test evidence, and expired certifications where relied upon.
- Change: ownership, financial condition, product architecture, data location, material subcontractors, security model, terms, or service scope.
- Exposure: newly disclosed vulnerabilities, provider incidents, threat intelligence, regulatory actions, sanctions or jurisdictional changes where relevant.
- Concentration: growth in the number or importance of services dependent on the same provider or fourth party.
- Exceptions: overdue remediation, accepted risks nearing expiration, temporary controls, and contractual gaps still awaiting resolution.
Resilience and exit
Test the failure mode that matters to the business service.
PRA SS2/21 sets expectations for outsourcing and third-party risk management and explicitly complements the PRA's separate operational-resilience framework. The impact-tolerance concept belongs to that broader operational-resilience framework rather than being created by SS2/21 itself. The current SS2/21 version is the November 2024 version effective December 31, 2024; the PRA published a March 2026 future version that becomes effective March 18, 2027 as part of new operational-incident and material-third-party reporting changes.
APRA's CPS 230 initially took effect in 2025 and now has a current amended version in force from July 1, 2026. APRA finalized targeted 2026 amendments concerning certain non-traditional service-provider contractual requirements while retaining the core operational-risk, critical-operations, and service-provider objectives.
Use scenario tests that challenge the actual dependency: provider outage, identity/control-plane failure, ransomware, regional cloud loss, telecommunications loss, data corruption, compromised support access, critical fourth-party failure, abrupt contract termination, or provider insolvency. Measure whether the business service can remain within its approved tolerance or recovery objectives and whether the exit plan is executable.
Governance evidence
Keep a compact record of why the relationship remains acceptable.
| Record | Minimum useful content |
|---|---|
| Relationship record | Provider, service, business owner, technical owner, contract owner, data/access, systems, start/end dates |
| Materiality decision | Business consequence, critical services, substitutability, concentration, rationale, approver, review trigger |
| Risk assessment | Material risks, evidence reviewed, gaps, compensating controls, residual risk, decision |
| Contract map | Material requirements, clause/evidence location, gaps, exceptions, renewal trigger |
| Monitoring record | Performance, incidents, assurance, findings, material changes, overdue actions |
| Resilience/exit record | Scenario tested, recovery/transition result, dependencies, data portability, lessons and actions |
Board or executive reporting should emphasize concentration, unresolved high-risk exceptions, material incidents, critical-service dependencies, overdue remediation, and decisions requiring acceptance or investment. Raw questionnaire-completion counts are weak governance metrics when they do not change a risk decision.
Primary sources
Current authorities used for this review.
- Federal Reserve SR 23-4 — Interagency Guidance on Third-Party Relationships: Risk Management.
- PRA SS2/21 — Outsourcing and third party risk management.
- PRA PS7/26 — Operational incident and third-party reporting.
- Regulation (EU) 2022/2554 — Digital Operational Resilience Act.
- European Banking Authority — DORA oversight and current CTPP resources.
- APRA — CPS 230 Operational Risk Management.
- APRA — 2026 targeted amendments to CPS 230.
- OSFI Guideline B-10 — Third-Party Risk Management.
The operating controls in this guide are general implementation patterns. Regulatory examples are scoped to the entities covered by their source instruments and should be revalidated before a consequential decision.
Related tools and guides
Put this guide to work
Turn Third-Party Technology Governance Guide into a decision-ready next step.
Use the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.