Third-Party Risk Management

Visual overview

Third-Party Risk Management at a glance — Vendor risk, outsourcing, service level agreements.

Vendor Risk, Outsourcing, and Service Level Agreements

Modern banking operates through an intricate web of third-party relationships that extend the bank's capabilities while introducing new vulnerabilities. Information technology vendors maintain core banking systems, cloud providers host critical data and applications, payment processors handle transaction flows, business process outsourcing firms manage back-office operations, and fintech partners deliver innovative customer-facing services. When these third parties fail, the bank fails regardless of how well its own operations function. Third-party risk management has emerged as a critical discipline ensuring that outsourced activities meet the same standards of security, resilience, and compliance that apply to the bank's own operations.

Third-party risk matters because using an external provider does not remove the bank's responsibility to meet the legal, regulatory and supervisory obligations that remain with the bank. The contractual allocation of liability between bank and provider can still matter, so it is too broad to say that a bank is automatically liable for every vendor failure regardless of contract or law. Operational dependence, cyber exposure, data access and concentration can nevertheless make provider failures material to customers and financial stability, which is why supervisors increasingly expect structured third-party risk management.

Third-party risk encompasses multiple categories that must be assessed and managed. Operational risk arises when vendor systems fail, causing bank services to go down and potentially preventing customers from accessing their accounts or completing transactions. Cyber and data risk involves vendor data breaches that expose customer information or provide attackers access to bank systems. Compliance risk emerges when vendors violate anti-money laundering, data protection, or other regulations in ways that implicate the bank. Concentration risk reflects multiple banks depending on the same cloud provider, core banking vendor, or payment processor, creating single points of failure for the financial system. Reputational risk transfers to the bank when vendors engage in unethical practices or suffer public scandals. Contractual risk involves vendors failing to meet service level agreements or attempting to exit relationships without adequate transition support. Country and geopolitical risk affects vendors in jurisdictions subject to sanctions, political instability, or data localization requirements. Business continuity risk involves vendor bankruptcy or market exit that suddenly terminates essential services.

Effective third-party risk management spans the full relationship lifecycle from initial planning through eventual exit. The planning and risk assessment phase begins with identifying the business need for outsourcing and evaluating whether the activity can safely be performed externally. Risk categorization classifies proposed relationships as critical, important, or standard based on the potential impact of vendor failure. Regulatory notification may be required for certain outsourcing arrangements, particularly those involving customer data or core banking functions.

Due diligence should be proportionate to the service's criticality and risk. It can cover financial condition, operational capability, information security, privacy, regulatory compliance, resilience, location, subcontracting and the provider's control environment. Certifications or assurance reports such as ISO 27001 or SOC reports can be useful evidence where relevant, but they are not universal substitutes for bank-specific assessment. The bank should understand what was tested, the scope and date of the assurance, material exceptions and whether the evidence actually addresses the risks created by the proposed service.

Contracting translates the risk assessment into enforceable rights and obligations. Relevant clauses can include service levels, security requirements, confidentiality, data use and return, incident notification, audit and regulatory access, subcontracting controls, business continuity, termination and transition support. There is no universal 99.9% uptime standard or single breach-notification interval for every outsourced service; targets should reflect customer impact, criticality, law and the bank's resilience requirements. Data rights also depend on the processing arrangement and applicable law, so the contract should describe permitted use, access, retention and deletion precisely rather than rely on a generic statement that every dataset is handled identically.

Ongoing monitoring ensures that vendors continue meeting expectations throughout the relationship lifecycle. Service level agreement performance reviews conducted monthly track achievement against uptime, response time, and resolution targets, identifying trends before they become critical failures. Risk reassessments conducted annually or when triggered by significant events re-evaluate the vendor's continuing suitability as circumstances change. On-site audits for critical vendors provide direct examination of controls, operations, and security practices that cannot be fully verified remotely. Security assessments including SOC 2 report review and penetration testing verify that security postures remain adequate against evolving threats. Financial health checks monitor vendor financial statements for signs of distress that might threaten relationship continuity. Incident reviews analyze any failures that occur to identify root causes and required improvements.

Exit and transition planning prepares for relationship termination whether due to contract completion, performance failure, or vendor distress. Transition plans must be documented before any outsourcing begins, ensuring that exit options exist before they are needed. Data return and destruction requirements ensure that all bank data is returned in usable formats and that vendor copies are verifiably destroyed, preventing unauthorized retention. Knowledge transfer ensures that institutional knowledge about the bank's requirements and processes moves to replacement vendors or internal teams without loss. Alternative providers should be identified in advance where possible, reducing transition time when changes become necessary.

In India, third-party requirements must be read from the framework that applies to the activity. RBI's 2023 Master Direction on Outsourcing of Information Technology Services applies to the regulated entities and IT arrangements within its scope, while separate instructions govern outsourcing of financial services and other activities. These frameworks address governance, risk assessment, contracts, access and audit rights, business continuity, data protection, subcontracting and exit. The central principle is that outsourcing should not diminish the regulated entity's ability to meet customer obligations or impede RBI supervision. Whether a particular function may be outsourced, and under what conditions, must be checked against the current rule for that institution and activity rather than a single universal list.

Real-world vendor failures demonstrate the consequences of inadequate third-party risk management. The Amazon Web Services outage of 2021 disrupted mobile and internet banking for multiple institutions, demonstrating cloud concentration risk. The Wipro breach of 2019 saw attackers use the IT services provider's network to compromise banking clients, illustrating supply chain attack vectors. The SolarWinds attack of 2020 affected financial institutions globally through compromised software updates, showing how trusted vendor relationships can be exploited. The CrowdStrike outage of 2024 caused global IT disruptions affecting banking, airlines, and hospitals, demonstrating how security tools themselves can become sources of operational risk. These incidents underscore that third-party risk management is not merely a procurement or compliance exercise but an essential element of operational resilience.

Third-party risk management is now a core part of operational resilience, cyber risk, compliance and business governance. The Basel Committee's current principles use a broader third-party risk lens because important dependencies extend beyond traditional outsourcing contracts. A mature bank therefore knows which services and providers are critical, what risks and concentrations they create, how performance is monitored, what subcontractors are involved, how incidents are escalated and how the service can be exited or replaced without unacceptable disruption.

Deep Dive: Third-Party Risk Across the Full Banking Service Chain

Banks depend on technology companies, payment processors, cloud providers, data vendors, call centres, card processors, market-data services, software suppliers, consultants and many other external parties. Some relationships are traditional outsourcing; others are subscriptions, managed services, network dependencies or specialist platforms. The risk question is therefore broader than “which jobs has the bank outsourced?” It is which external dependencies could materially affect customers, data, compliance, financial position or the bank's ability to deliver critical services?

The Basel Committee's current third-party risk principles use this wider lens. RBI's frameworks similarly require regulated entities to govern outsourcing and IT-service dependencies within their respective scopes. The practical consequence is that third-party risk management must connect procurement, business ownership, technology, security, privacy, legal, compliance, operational resilience and exit planning.

1. Start with a complete third-party inventory

A bank cannot manage dependencies it does not know exist. The inventory should identify the legal provider, service, business owner, contract, locations, data access, systems supported, subcontracting and criticality.

Shadow procurement can create gaps when teams buy cloud software or data subscriptions on corporate cards without passing through formal onboarding. Acquired businesses may also bring old vendor relationships that are absent from the group inventory.

Periodic reconciliation against accounts-payable data, technology inventories and procurement records can help identify missing relationships. The inventory should be more than a contract register; it should describe what the provider actually does for the bank.

2. The service matters more than the vendor's brand

A large, reputable provider can deliver both critical and non-critical services. Risk should therefore be assessed at the arrangement level, not only by vendor reputation.

Using a major cloud provider for a public marketing site is different from hosting authentication and account-processing workloads. The same supplier may require different controls for each service.

The bank should understand the business process, customer dependency, data sensitivity and recovery requirements associated with the specific arrangement.

3. Criticality determines control intensity

Not every supplier needs the same level of due diligence. Office stationery and a core-banking platform create very different consequences if they fail.

Criticality assessment can consider whether the service supports critical operations, the scale of customers affected, substitutability, data sensitivity, financial exposure, regulatory relevance, recovery time and concentration.

The criteria should be documented and periodically reassessed. A service can become critical as transaction volume grows even if it was minor at onboarding.

4. Business ownership cannot be outsourced

Procurement can manage commercial negotiation and a central risk team can set standards, but the business using the provider should remain accountable for the service outcome.

The owner should understand performance, incidents, dependencies, change and exit. A vendor should not become “IT's problem” merely because it supplies technology.

Where a payment processor misses service levels, for example, the payments business needs to understand customer and settlement impact while Technology investigates the technical cause.

5. Due diligence should be proportionate and evidence-based

Due diligence examines whether the provider is capable of delivering the proposed service within the bank's requirements. Areas can include financial condition, operational capability, security, privacy, resilience, regulatory compliance, location, legal issues and subcontracting.

The bank should distinguish self-attestation from independent evidence. A provider questionnaire saying “we encrypt data” is less informative than architecture evidence, assurance reports and control testing appropriate to the risk.

At the same time, requesting hundreds of documents from every small supplier creates bureaucracy without better risk management. Depth should match materiality.

6. Financial condition matters even for technology services

A technically strong provider can still fail because of weak finances. Banks should understand whether a critical supplier has a sustainable business model, sufficient resources and concentration in a few customers or investors.

Private companies can provide less financial transparency, so the bank may need alternative evidence such as audited statements where available, credit information, funding history or parent support.

Financial deterioration should trigger reassessment, especially when replacement would take a long time.

7. Information security assessment needs context

Security certifications can provide useful assurance but do not prove that every service is secure. The bank should understand scope, date, exceptions, architecture, access model and data flows.

A provider may have a strong corporate certification while one newly acquired product falls outside its scope. Similarly, a penetration test can be useful but may not cover the exact environment used by the bank.

Security due diligence should therefore connect external evidence to the actual service design.

8. Data mapping should show what the provider can see

The bank should know which customer, employee, transaction or confidential data leaves its controlled environment, where it is processed, where it is stored and who can access it.

Data mapping supports privacy, banking secrecy, security and exit planning. It also reveals whether the provider receives more information than necessary.

Where tokenisation, masking or pseudonymisation can reduce exposure, the design should consider those controls before sending full production data externally.

9. Location can affect legal and operational risk

Provider operations may span several countries. Data residency, supervisory access, sanctions, local law, geopolitical events and cross-border transfer rules can therefore matter.

The bank should know where material processing and support occur. “Hosted in Europe” may be insufficient if privileged administrators access the service from several other regions.

Location risk should be assessed under current legal requirements rather than through broad assumptions that offshore is always unsafe or onshore is always safe.

10. Subcontractors extend the dependency chain

A provider may rely on cloud infrastructure, data centres, support firms or software components. These fourth-party relationships can be critical even though the bank has no direct contract with them.

Contracts and due diligence should establish appropriate visibility and controls over material subcontracting. The bank should understand which subcontractors support critical services and whether provider changes require notice or approval under the applicable framework.

The objective is not to directly audit every small subcontractor. It is to avoid being surprised by a hidden concentration or dependency.

11. Concentration risk exists at several levels

A bank can be concentrated in one provider across many internal services. Several banks can also depend on the same external provider, creating sector concentration.

Within the bank, concentration analysis should identify common platforms, geographic locations, data centres and subcontractors. Two apparently separate vendors may both rely on the same cloud region.

The bank may not be able to eliminate concentration, especially for highly specialised services. It should understand the dependency and design resilience and exit options accordingly.

12. Contracts should reflect the risk assessment

A generic procurement contract is rarely enough for a critical banking service. Terms should address responsibilities, service levels, security, confidentiality, data, incidents, audit, regulator access, business continuity, subcontracting, change, termination and transition as applicable.

Requirements should be realistic and enforceable. A contract that demands an impossible notification time or unlimited audit at any moment may look strong but provide little practical value if no provider will comply operationally.

Legal and business teams should understand which clauses are regulatory necessities and which are commercial protections.

13. Service levels should measure customer-relevant performance

Availability percentages are useful but can hide important failure. A payment service could meet monthly uptime while failing during peak payroll processing.

Service levels should therefore reflect what matters to the business: availability, latency, processing accuracy, recovery, support response, reconciliation or other outcomes.

The bank should define measurement source and exclusions. Vendor-calculated service levels should be reconciled with the bank's own experience where possible.

14. Incident notification should support bank response

The provider should notify the bank quickly enough for the bank to meet its own legal, regulatory and customer obligations. The exact interval depends on the incident and applicable requirements.

Notification clauses should define which events matter, what information is provided and how updates continue. A first notice may be incomplete; the bank needs a process for ongoing communication and final root-cause analysis.

Contact details should be tested rather than discovered during a severe outage.

15. Access rights should be usable in practice

Regulatory and audit access clauses are important, but a right that cannot be exercised is weak. The bank should understand whether it will receive reports, remote evidence, on-site access or pooled audits and under what conditions.

For hyperscale providers, direct access may operate through structured assurance mechanisms. The bank still needs enough evidence to meet supervisory expectations.

Access arrangements should also survive termination long enough to support regulatory inquiries and record-retention obligations.

16. Ongoing monitoring should be risk-based

Monitoring can include service performance, incidents, security assurance, financial health, audit findings, regulatory developments, subcontractor changes and remediation.

Critical providers normally receive more frequent and deeper oversight than low-risk suppliers. Monitoring should not become an annual questionnaire that repeats onboarding information without checking actual performance.

The business owner should understand trends and escalate deterioration before a formal breach becomes severe.

17. Change at the provider can change the bank's risk

A provider may acquire another company, move data centres, change cloud architecture, replace subcontractors or launch a major platform version. These changes can affect the original risk assessment.

Contracts should define which material changes require notification. Internally, the bank should decide when reassessment or testing is needed.

A vendor migration can be as significant as a bank's own system change if it alters data, connectivity or resilience.

18. Software supply chain risk needs visibility

Modern services use open-source libraries, commercial components and automated deployment pipelines. A vulnerability in one component can affect many providers and banks simultaneously.

Third-party security governance should therefore consider software-development and vulnerability-management practices for material technology providers.

The bank may use software bills of materials or other evidence in selected cases, but the control should be proportionate and integrated with vulnerability response rather than collected as paperwork only.

19. Cloud risk is shared responsibility

Moving a workload to cloud does not mean the provider manages every control. The bank may remain responsible for identity, configuration, data classification, application security and monitoring depending on the service model.

Many cloud incidents arise from customer configuration rather than provider infrastructure. Governance should therefore define the shared-responsibility model clearly.

Cloud concentration and regional resilience should also be assessed for critical workloads.

20. Payment processors create financial as well as technology risk

A payment processor can affect transaction routing, settlement files, card authorisation, clearing or reconciliation. Failure may create incorrect balances, duplicated transactions or delayed settlement.

Oversight should therefore include processing accuracy and financial reconciliation, not only IT uptime. The bank should know how to detect missing files, duplicate messages and settlement mismatches independently of the provider.

A strong contract cannot replace end-to-end financial control.

21. Customer-facing outsourcing creates conduct risk

Call centres, collection agencies and sales partners interact directly with customers. Poor behaviour can create complaints, legal breaches and reputational damage even when the underlying product is sound.

The bank should define scripts, training, monitoring, complaint handling and escalation. Quality assurance can use call recordings, mystery shopping or case sampling where appropriate.

Customers should not receive materially weaker protection simply because the interaction is outsourced.

22. KYC and financial-crime dependencies need careful boundaries

External providers can supply identity verification, screening data or technology, but responsibility for the bank's AML framework and decisions remains governed by applicable law and regulation.

The bank should understand data quality, matching logic, update frequency, false positives, service continuity and escalation. A screening provider outage can affect payment release or onboarding.

Vendor outputs should therefore be treated as inputs to a controlled bank process, not unquestioned truth.

23. Resilience testing should include providers

A bank can have excellent internal disaster recovery yet still fail if a critical provider is unavailable. Resilience scenarios should include provider outage, data corruption, cyber compromise and loss of connectivity.

Testing can use joint exercises, provider evidence, failover demonstrations or bank-side simulations. The bank should verify whether stated recovery objectives are achievable for the end-to-end service.

A provider recovering its platform in two hours does not help if the bank then needs twelve hours to reconcile lost transactions.

24. Business continuity plans need alternative operating methods

For some services, an alternate provider or secondary region is possible. For others, the bank may need manual contingency or controlled service suspension.

Continuity planning should specify what the bank will actually do during the outage. “Vendor has DR” is not a bank contingency plan.

Customer communication, liquidity, settlement and backlog processing should be considered where relevant.

25. Exit planning begins before the contract is signed

A bank should know how it could leave a critical arrangement before becoming dependent on it. Exit planning considers data extraction, replacement systems, licences, intellectual property, staff knowledge, connectivity, testing and transition time.

The plan should distinguish planned exit from stressed exit. A provider in financial distress may offer less cooperation than one completing a normal contract.

Exit feasibility should be revisited as the service becomes more embedded.

26. Data return and deletion need evidence

At termination, the bank may need data returned in a usable format and provider copies deleted subject to legal retention requirements.

The contract should define format, timing, backup treatment and certification. The bank should also validate that extracted data are complete before shutting down the old service.

For complex platforms, data portability can become a major barrier to exit and should be tested before dependency grows too far.

27. Stressed exit can require temporary risk acceptance

If a provider suffers severe distress or breach, immediate termination may create more customer harm than controlled continuation while migration occurs.

Crisis governance should assess security, legal, operational and customer risks of each option. Temporary controls may be needed while an alternative service is built.

The decision should be documented with senior ownership because stressed exit often involves choosing between imperfect options.

28. Procurement price is not total service risk

The cheapest supplier may create higher transition, resilience or compliance cost. Procurement decisions should therefore consider risk-adjusted value rather than price alone.

A provider with stronger control evidence and easier exit can be economically preferable even at a higher fee. Conversely, demanding premium controls for a trivial service can waste resources.

The sourcing decision should make these trade-offs explicit.

29. Fourth-party concentration can hide beneath vendor diversity

A bank may proudly use three different software providers, yet all three host on the same cloud region or rely on the same identity service.

Dependency mapping should therefore look through material providers where practical. Industry incidents repeatedly show how shared infrastructure can create correlated outages.

Understanding concentration does not always produce an easy mitigation, but it improves contingency planning and board awareness.

30. Risk acceptance should have expiry and ownership

A provider may have a control gap that cannot be fixed immediately. The bank can decide to accept the risk temporarily if authority and policy permit.

The acceptance should state the issue, residual risk, compensating controls, owner, expiry date and remediation. Repeated extension without improvement is a warning sign.

Third-party risk teams should report material open acceptances to appropriate governance forums.

31. Provider incidents should connect to operational risk

A material vendor outage is also a bank operational event. Incident management should capture customer impact, financial loss, regulatory reporting, root cause and lessons learned.

The event should update provider risk assessment and may change criticality or monitoring. If several providers fail for the same shared cause, enterprise concentration analysis should be updated.

This connection prevents third-party events from remaining isolated inside procurement reporting.

32. Board reporting should focus on critical dependencies

Boards do not need a list of every supplier. They need visibility over critical or important arrangements, material concentrations, severe incidents, overdue remediation and exit readiness.

Metrics might include critical-provider population, service breaches, unresolved high-risk findings, concentration and resilience-test outcomes. The exact dashboard should match the bank's risk profile.

A green average across hundreds of low-risk vendors should not hide one critical unresolved dependency.

33. RBI IT outsourcing requirements need scope awareness

RBI's Master Direction on Outsourcing of Information Technology Services, effective from 1 October 2023, establishes requirements for regulated entities and arrangements within its scope. It addresses governance, risk management, contracts, data, business continuity, audit and supervisory access among other areas.

Separate RBI instructions address outsourcing of financial services and related subjects. A project team should therefore determine which framework applies rather than copy one IT checklist into every third-party contract.

Scope analysis is itself an important compliance control.

34. A core-platform scenario

A bank uses an external provider for a major lending platform. The vendor has strong security certifications and meets availability targets, so management considers the relationship low concern.

During a regulatory reporting cycle, the bank discovers that a provider software update changed one field used to classify loan status. Transactions still process correctly, but downstream regulatory data are wrong.

The incident shows why third-party oversight must include change control, data lineage and financial or regulatory outcomes, not just cyber security and uptime.

35. A cloud outage scenario

A mobile banking service runs across two availability zones in one cloud region. The provider advertises high resilience, but a regional control-plane incident affects both zones.

The bank's application team cannot deploy changes or fail over because the secondary environment depends on the same identity service. Customer logins fail for several hours.

A useful post-incident review examines architecture, shared dependencies, customer communication, provider escalation and recovery assumptions rather than arguing only about whether the contractual SLA was technically breached.

36. A call-centre scenario

A bank outsources first-line customer support. Complaints rise about staff pressuring customers to accept fee-based product upgrades. The provider is meeting call-answer and handling-time targets.

The problem is therefore not traditional service performance; it is conduct. The bank should review scripts, incentives, recordings, complaints and quality assurance, then determine whether customer remediation is needed.

Third-party monitoring must reflect the risks created by the service, not only the metrics easiest for the provider to measure.

37. The mature third-party risk standard

A mature bank knows which external relationships matter, what data and processes they touch, how failure would affect customers, and which other providers sit behind them. Due diligence is proportionate. Contracts support real oversight. Performance and incidents are monitored. Critical dependencies are tested. Risk acceptances are visible. Exit is planned before it becomes urgent.

Most importantly, the bank does not confuse procurement completion with risk transfer. External providers extend the bank's operating model; they do not remove the need for bank-level accountability, financial control, resilience and supervisory transparency.

Third-Party Risk Continuation: Governance for Dependency, Concentration and Exit

The bank should distinguish outsourcing from broader third-party dependency

Traditional outsourcing usually involves an external provider performing an activity that the bank could otherwise perform itself. Modern dependency is broader. A bank can rely materially on telecommunications, market infrastructure, software, data feeds or cloud platforms without every relationship fitting a narrow outsourcing definition.

This distinction matters because regulatory rules may apply differently, while operational resilience still depends on the service. A mature framework therefore classifies the legal and regulatory nature of the arrangement but does not ignore risk simply because Procurement labels it “software” rather than “outsourcing.”

Materiality should be reassessed after business growth

A small provider can become critical when a product scales rapidly. The original risk rating may have been correct at onboarding and wrong two years later.

Banks should define triggers such as increased transaction volume, new data types, additional legal entities, expanded customer populations or a move from support to production use. Those changes can require new due diligence, stronger contractual terms or resilience testing.

Criticality is therefore a living assessment rather than a permanent vendor label.

Service mapping should connect providers to critical operations

Operational-resilience programmes increasingly map the people, processes, technology, facilities, data and third parties needed to deliver important business services.

This view helps the bank understand whether one provider supports several customer journeys. A seemingly technical identity platform may be common to mobile banking, corporate payments and staff access, making it more important than its contract value suggests.

Dependency mapping should support scenario testing and recovery decisions.

Contract value is a poor proxy for risk

A low-cost open-source support provider can influence a highly critical system, while an expensive consulting engagement may create little operational dependency after completion.

Risk models should therefore avoid using annual spend as the dominant materiality measure. Customer impact, data, substitutability, regulatory importance and recovery time usually provide a stronger picture.

Spend remains useful for procurement and concentration analysis, but it should not determine control intensity by itself.

Vendor onboarding should include business architecture

Due diligence is stronger when the bank understands how the service fits into its architecture before sending questionnaires. Teams should know interfaces, authentication, data flows, downstream dependencies and failure modes.

Without that design, it is difficult to ask the provider meaningful questions. Generic questionnaires often produce generic answers because the bank has not defined what it actually needs to know.

Architecture review can also reveal opportunities to reduce dependency before contract signature.

The bank should verify who signs and who can commit the provider

Large suppliers can have complex sales structures. Commercial promises made in presentations may not appear in the final contract or may be offered by staff without authority to bind the company.

Procurement and Legal should ensure critical requirements are captured in executed documents or other enforceable arrangements. Operational teams should not rely on informal assurances that cannot be demonstrated later.

Contract schedules should align with operational controls

Security, data, resilience and service requirements are often spread across several schedules. Contradictions can arise when one appendix promises a recovery objective and another excludes the supporting component.

The bank should maintain a coherent contract baseline and govern amendments. Change orders can quietly alter risk if teams focus only on price and functionality.

Renewal is a control point, not an automatic procurement event

Contract renewal provides an opportunity to reassess performance, risk, concentration, changes and exit options. Automatically extending a critical arrangement because migration is inconvenient can create lock-in.

The business owner should confirm that the provider remains suitable and that unresolved issues are understood before renewal. High-risk gaps can be incorporated into contractual remediation where feasible.

Provider mergers and acquisitions need review

A supplier can be acquired by another company, changing ownership, strategy, financial condition, location or subcontracting. The bank should assess whether the change affects security, service or regulatory obligations.

Change-of-control clauses can provide notification or termination rights, but the practical response depends on criticality and alternatives.

Subcontractor change can create data-location risk

A provider may move support or processing to a new subcontractor in another jurisdiction. Even if service quality improves, the change can affect privacy, supervisory access or sanctions exposure.

Material subcontractor governance should therefore connect contractual notification to legal and risk reassessment rather than remain a procurement record only.

Vendor personnel access should be controlled like internal privileged access

Third-party engineers may require production access for support. Their accounts should have approved purpose, least privilege, strong authentication, logging and timely removal.

Shared external accounts make investigation difficult. Time-bound or just-in-time privileged access can reduce exposure where architecture permits.

Offboarding should be triggered when the individual's provider role ends, not only when the vendor contract terminates.

Remote support tools require particular attention

Remote administration can create powerful access paths into bank environments. The bank should understand which tools are used, how sessions are authenticated, whether recording or approval is required and how emergency access works.

An attacker compromising the provider can exploit these same paths, so vendor access architecture is part of cyber defence.

Provider logging should support bank investigations

When an incident occurs, the bank may need logs held by the provider. Contracts and technical design should define retention, access and timestamp quality for relevant evidence.

If logs are retained for only a few days while fraud or regulatory investigations begin weeks later, important evidence may be lost. Retention should match risk and legal requirements.

Encryption responsibilities should be explicit

Statements such as “data are encrypted” are incomplete. The bank should understand encryption in transit and at rest, key ownership, key management, administrative access and any cases where data must be decrypted for processing.

For highly sensitive services, customer-managed keys or other designs may reduce risk, but they also create operational responsibility for the bank. Architecture choices should be made consciously.

Data minimisation reduces third-party exposure

The safest sensitive field at a vendor is often the one never sent. Product and technology teams should ask whether the provider needs full customer identity, account information or transaction detail for the stated purpose.

Masking, tokenisation or selective fields can reduce breach impact and simplify exit. Data minimisation should be designed early because removing fields later can require major interface change.

Testing environments can leak production data

Banks sometimes send copies of production data to vendors for testing or troubleshooting. Non-production environments may have weaker access controls and longer retention.

Third-party governance should address test data explicitly. Synthetic or masked data should be preferred where feasible, and exceptions should be approved and controlled.

Service credits are not risk mitigation

A contract may refund part of the fee after an outage. That can provide commercial compensation, but it does not restore customer access, prevent regulatory breach or reconcile failed transactions.

Management should not treat SLA credits as the primary control for a critical service. Resilience architecture, contingency, monitoring and exit are the real mitigants.

Penalties should not create perverse incentives

Very severe contractual penalties can encourage providers to dispute incident classification or hide borderline breaches. Commercial terms should support transparent cooperation as well as accountability.

The bank should prioritise rapid recovery and root-cause learning during an incident, then address contractual consequences through the agreed process.

Joint incident exercises build relationship readiness

Critical-provider exercises can test contact paths, decision authority, technical recovery and communication. They reveal whether the bank and vendor share the same understanding of severity and responsibilities.

Exercises should include weekends or out-of-hours scenarios where appropriate because real incidents do not respect office schedules.

Cyber compromise is different from simple outage

If a provider is hacked, restoring connectivity immediately may be unsafe. The bank may need to isolate interfaces, rotate credentials, validate data and determine whether malicious changes occurred.

Continuity plans should therefore distinguish availability loss from integrity or confidentiality compromise. A fast recovery target can conflict with safe recovery after cyber attack.

Data corruption scenarios need reconciliation plans

A provider can remain online while sending incorrect data. This can be harder to detect than total outage.

Banks should identify independent controls that reveal missing, duplicate or corrupted processing. For payments, reconciliation to clearing or ledger records can expose problems even if the vendor reports green availability.

Provider bankruptcy needs a different playbook

Financial failure can create abrupt staff loss, loss of support and uncertainty over intellectual property or data. The bank should know contractual rights, escrow arrangements where relevant, data access and alternative support options.

Stressed exit planning should consider whether the service can continue safely while insolvency proceedings unfold.

Intellectual-property dependency can block exit

A bank may own its data but still be unable to move because configurations, interfaces or custom code depend on provider intellectual property.

Exit analysis should therefore cover documentation, licences, source-code access where appropriate and the ability of replacement teams to reproduce essential functions.

Data ownership alone does not guarantee portability.

Knowledge concentration should be tracked

Some critical services depend on a few vendor specialists who understand custom bank configurations. If those people leave, recovery or migration can become difficult.

The bank can require documentation, cross-training or named backup resources for material arrangements. Internally, relationship knowledge should also be shared so one bank employee is not the only person who understands the contract and architecture.

Fourth-party assurance should be risk-based

Banks cannot directly govern every component in a global technology chain. They can require the primary provider to manage subcontractors effectively and provide appropriate transparency over material dependencies.

For the most critical fourth parties, additional assurance or contingency may be justified. The approach should focus on concentration and impact rather than attempt infinite due diligence.

Open-source dependency is a third-party question too

A bank may use software maintained by a community rather than a contracted vendor. There may be no service agreement or financial entity to assess.

Risk management should consider maintenance activity, vulnerability response, internal ownership and the bank's ability to patch or replace the component. The absence of a contract changes the control model; it does not remove dependency.

Regulatory notification duties should be mapped in advance

Outsourcing, incident or material-change rules can require notification or approval depending on jurisdiction and activity. The relationship owner should know which events trigger Legal or Compliance review.

Discovering a notification requirement after contract signature or after an outage creates avoidable regulatory risk.

Cross-border groups need local third-party inventories

A global bank may negotiate one master agreement, but local subsidiaries can have separate regulatory responsibilities and different uses of the service.

Group governance should allow enterprise oversight while preserving local legal-entity accountability. One global risk rating may need local overlays for data, customer or regulatory differences.

Provider risk ratings should influence procurement decisions

Risk assessment should not be a formality completed after the vendor is selected. If one finalist has materially weaker resilience or data controls, the sourcing decision should consider that difference.

Where the business chooses the higher-risk option for legitimate reasons, the residual risk and required mitigation should be approved transparently.

Exceptions should not be hidden inside contract negotiation

A provider may refuse a required clause or control. That is a risk acceptance, not merely a Legal negotiation point.

Material deviations should be recorded, assessed and approved by the right authority. Otherwise the final contract can silently contain weaker protections than the risk team believes were agreed.

Offboarding must remove connectivity as well as accounts

Terminating a vendor requires more than disabling named users. API keys, VPN tunnels, certificates, service accounts, data feeds and physical access may remain active.

A structured exit checklist should confirm that technical connections are removed or transferred safely and that monitoring detects unexpected post-termination activity.

Post-exit data retention should follow law and contract

Some provider data may need to be retained for legal or audit reasons even after service ends. Other copies should be deleted.

The bank should distinguish required retention from unnecessary persistence and obtain evidence appropriate to the arrangement. Backup deletion may follow a defined cycle rather than instantaneous destruction, which should be documented accurately.

Third-party risk and operational resilience should share one risk story

Third-party teams may rate the vendor while resilience teams map business services. Those processes should connect. A provider classified as “medium” should be reconsidered if service mapping shows that its failure stops a critical customer journey.

Consistent dependency information reduces contradictory risk reporting to senior management.

Final perspective: external capability still requires internal control

Third parties allow banks to access scale, expertise and innovation that would be costly to build alone. The objective is not to avoid external providers. It is to use them with clear accountability and a realistic understanding of dependency.

A bank demonstrates mature third-party governance when it can explain who provides each critical service, what failure would mean, how it monitors the relationship, which hidden dependencies exist, and how it would continue or exit if the provider could no longer perform.

Third-Party Risk Continuation II: Managing the Service After the Contract Is Signed

Onboarding is only the beginning of third-party risk

A detailed due-diligence exercise can create false comfort if the relationship is barely monitored afterward. A provider's ownership, financial health, technology stack, subcontractors, control environment and service volumes can change materially during a multi-year contract. The bank therefore needs ongoing monitoring proportionate to criticality rather than treating approval as permanent certification.

The business owner should review service performance, incidents, control reports, material changes, financial condition and unresolved audit findings on a defined cycle. Technology and security teams may need separate monitoring for vulnerabilities, certificates, privileged connections or cloud configuration. Procurement can track contractual obligations, but the business must understand whether the service still performs safely in the actual banking process.

Change notification needs a meaningful threshold

Contracts often require providers to notify the bank of material changes, but the word “material” is useful only when both parties understand it. A provider moving customer data to a new country, replacing a critical subcontractor, changing a recovery design or introducing a new privileged support model can alter the bank's risk even if the commercial service name remains unchanged.

The contract and operating procedure should therefore identify changes that require notice, assessment or prior approval according to the applicable framework. The bank also needs a route to reassess criticality and controls rather than filing the notification with the contract.

Exit planning should be tested before the bank needs to leave

An exit plan that says “migrate to another supplier” is not operational. The bank should know what data must be returned, in which format, how long migration could take, which licences or interfaces are needed, how customer service continues during transition, and how the old provider will delete or retain data according to legal obligations.

For a critical technology service, exit can require application changes, data conversion, security recertification, capacity at the replacement provider and parallel operation. These activities can take months or years. Concentration risk is therefore partly an exit-time problem: several banks may depend on the same few providers because alternatives are not immediately substitutable.

Exit assumptions should be rehearsed through tabletop exercises or technical tests where practical. The objective is not to switch suppliers unnecessarily but to discover dependencies while the relationship is stable.

Fourth parties can become first-order operational risks

A bank may contract with one provider that relies on cloud hosting, telecommunications, identity services or specialist software supplied by others. The bank has no direct contract with those subcontractors, yet their failure can stop the banking service.

Third-party governance should therefore understand material subcontracting chains and where several direct providers depend on the same underlying company or location. This is especially important for cloud regions, network providers and widely used software components.

The bank does not need to manage every subcontractor as if it were a direct vendor. It does need enough transparency to assess concentration, incident impact, data location, resilience and the provider's own oversight of material dependencies.

Incident response needs pre-agreed information flows

When a critical vendor suffers a cyber incident or outage, the bank needs fast facts: affected service, start time, customer impact, data exposure, recovery estimate, workaround and next update. A contract clause requiring notification “promptly” is not enough if operational contacts, escalation routes and reporting formats have never been tested.

Joint exercises can expose practical gaps such as expired contact lists, time-zone coverage, unclear authority to invoke disaster recovery or disagreement about who communicates with customers. The bank should also preserve its own incident command. A provider can supply facts and recovery actions, but the bank decides how the event affects its customers, regulatory obligations and critical operations.

Third-party risk becomes mature when the institution can continue governing the service under stress, not merely when it possesses a complete vendor file.

Final Third-Party Depth: Ongoing Assurance

External assurance needs interpretation

Banks often receive independent reports, certifications and control evidence from important service providers. Collecting those documents is not the same as understanding the remaining risk. The bank should check which service and locations are covered, the period assessed, identified exceptions, responsibilities that remain with the bank, and whether material subcontractors sit outside the review scope.

Evidence also has a time dimension. A report covering last year may not reflect a recent platform migration or operating-model change. Conversely, one reported exception does not automatically make a provider unsuitable; the bank should understand the affected control, duration, remediation and relevance to the actual banking service.

The service owner and risk specialists should turn external assurance into a clear internal conclusion: what has been evidenced, what is still uncertain, what the bank itself must control, and when follow-up is required. Third-party governance becomes useful when evidence changes decisions rather than merely filling a repository.