32.5: Financial Services Supply Chain Controls¶

When a ransomware attack crippled Ion Group in January 2023, derivatives trading across financial markets was disrupted. Ion provided critical post-trade processing services to major banks and trading firms; its unavailability forced institutions to process trades manually, creating backlogs and settlement risks. The incident highlighted a reality regulators had been warning about for years: financial services had become deeply dependent on a relatively small number of technology providers, and the failure of any one could cascade across the industry.

Financial services regulators have developed the most mature frameworks for managing third-party risk, driven by the sector's systemic importance and history of operational failures. Third-party risk management (TPRM) in financial services encompasses vendor assessment, ongoing monitoring, concentration risk, and resilience requirements that other industries are only beginning to consider. As software supply chains become recognized as critical third-party relationships, financial services TPRM frameworks offer proven models for managing these dependencies—models that regulators increasingly expect organizations in all sectors to adopt.

Outsourcing Regulations and Oversight¶

Financial services outsourcing has been regulated for decades, with requirements evolving as technology dependence has grown.

U.S. regulatory framework:

OCC (Office of the Comptroller of the Currency): OCC Bulletin 2013-29 and subsequent interagency guidance (2023) establish expectations for bank third-party relationships:

• Risk management process: Planning, due diligence, contract negotiation, ongoing monitoring, termination
• Board oversight: Board responsible for understanding and managing third-party risk
• Critical activities: Enhanced oversight for activities that could cause significant harm if disrupted
• Subcontractors: Requirements extend to subcontractors of third parties

FFIEC (Federal Financial Institutions Examination Council): FFIEC guidance provides examination expectations:

• Risk assessment: Comprehensive evaluation of third-party risks
• Due diligence: Thorough assessment before engagement
• Contract provisions: Required terms including audit rights, performance standards, termination
• Ongoing monitoring: Continuous assessment of third-party performance and risk

European regulatory framework:

DORA (Digital Operational Resilience Act): DORA (effective January 17, 2025) creates comprehensive ICT risk management requirements for EU financial entities:

• ICT third-party risk management: Systematic identification and assessment of ICT third-party risks
• Contractual requirements: Mandatory contract provisions for ICT services
• Critical provider oversight: Enhanced requirements for critical third-party providers
• Concentration risk: Explicit requirements to manage concentration in ICT services

DORA represents the most comprehensive regulatory framework specifically addressing technology supply chain risks in any sector.

Software supply chain implications:

These frameworks increasingly apply to software dependencies:

• Open source components as third-party relationships
• SaaS providers as outsourcing arrangements
• Cloud services as critical infrastructure
• Development tools as ICT services

Financial institutions must apply TPRM frameworks to their software supply chains—a requirement that provides models for other sectors.

Concentration Risk Management¶

Concentration risk occurs when multiple organizations depend on the same provider, creating systemic vulnerability if that provider fails.

Regulatory concern:

Regulators have identified concentration as systemic risk:

• A few cloud providers serve most financial institutions
• Core banking systems come from limited vendors
• Critical market infrastructure has few providers
• Software dependencies create hidden concentration

DORA explicitly requires financial entities to:

• Identify concentration risks in ICT services
• Assess implications of provider failure
• Develop mitigation strategies
• Report critical provider dependencies to regulators

Assessment approach:

Financial services concentration risk assessment includes:

Provider mapping: - Identify all ICT service providers - Map dependencies between providers - Identify critical providers - Assess provider market share

Impact analysis: - What happens if this provider fails? - How many institutions are affected? - What are substitution options? - How long would recovery take?

Mitigation strategies: - Multi-provider strategies where feasible - Contractual protections (escrow, source code access) - Exit planning and transition capabilities - Business continuity arrangements

Software concentration:

Software supply chains exhibit severe concentration:

• The npm registry hosts virtually all JavaScript packages, even when accessed through alternative package managers like Yarn or pnpm
• A few build systems dominate (GitHub Actions, GitLab CI)
• Core libraries (OpenSSL, Log4j) are universal dependencies
• Single points of failure exist throughout

The financial services approach to concentration risk provides a model for assessing and mitigating these software dependencies.

Third-Party Risk Management Frameworks¶

Financial services TPRM frameworks provide structured approaches to managing third-party relationships across their lifecycle.

Framework elements:

Planning: - Identify need for third-party relationship - Assess inherent risk of activity - Determine required risk management intensity - Establish governance and accountability

Due diligence: - Assess provider capability and stability - Evaluate security practices and controls - Review financial condition - Assess operational resilience - Evaluate compliance and regulatory standing

Contract negotiation: - Define service levels and performance standards - Establish security requirements - Include audit rights - Define termination provisions - Address subcontracting

Ongoing monitoring: - Track service level performance - Monitor security incidents - Review financial condition - Assess control effectiveness - Evaluate regulatory compliance

Termination: - Plan for relationship end - Ensure data return and destruction - Manage transition to alternative - Document lessons learned

Risk tiering:

TPRM applies proportionate oversight based on risk:

Software application:

TPRM frameworks can apply to software dependencies:

• Planning: Assess need for new dependencies; evaluate alternatives
• Due diligence: Evaluate project health, security practices, maintenance commitment
• Contracting: For commercial dependencies, establish security requirements
• Monitoring: Track vulnerabilities, maintenance activity, project health
• Exit planning: Identify alternatives, plan migration if needed

Tools like OpenSSF Scorecard provide due diligence information; dependency monitoring tools enable ongoing oversight.

Technology Supplier Oversight¶

Regulators expect financial institutions to maintain oversight of technology suppliers with increasing rigor.

Oversight expectations:

Security assessment: - Evaluate supplier security practices - Review certifications (SOC 2, ISO 27001) - Assess vulnerability management - Review incident response capabilities

Operational resilience: - Assess business continuity capabilities - Review disaster recovery arrangements - Evaluate geographic diversity - Test recovery capabilities

Change management: - Understand change processes - Review change notification procedures - Assess testing practices - Evaluate rollback capabilities

Access management: - Understand supplier access to institution data - Review access controls - Assess privilege management - Evaluate audit logging

Critical provider designation:

DORA introduces critical ICT third-party provider designation:

• Regulators may designate providers as critical
• Critical providers subject to direct regulatory oversight
• Enhanced requirements for resilience and security
• Potential for cross-border regulatory coordination

This approach—regulatory oversight of providers serving multiple institutions—has no direct software equivalent but suggests potential direction for critical open source infrastructure.

Software supplier oversight:

Software supplier oversight might include:

• Open source projects: Assessment of governance, security practices, maintenance
• Commercial vendors: Traditional supplier assessment plus software-specific criteria
• SaaS providers: Combined operational and security assessment
• Development tools: Assessment of tool security and supply chain practices

The challenge for software is scale—organizations may have hundreds or thousands of dependencies, making individual oversight impractical without automation.

Resilience and Recovery Requirements¶

Financial services resilience requirements address both prevention and recovery from third-party failures.

Operational resilience:

Regulators expect financial institutions to:

• Identify critical business services: What must continue functioning?
• Set impact tolerances: Maximum acceptable disruption duration
• Map supporting resources: What people, processes, technology, and third parties support each service?
• Test resilience: Scenario testing including third-party failures
• Invest in resilience: Capabilities to continue operations despite disruptions

Third-party resilience provisions:

Contracts with critical providers should address:

• Service levels: Performance standards and remedies
• Business continuity: Provider BC/DR requirements
• Notification: Incident notification timeframes
• Testing: Participation in institution resilience testing
• Termination assistance: Support for transition to alternatives

Exit planning:

Financial institutions must plan for third-party exits:

• Trigger identification: Circumstances requiring exit
• Alternative identification: Potential replacement providers
• Transition planning: Steps to migrate to alternative
• Data requirements: Data extraction and transfer
• Timeline estimation: How long transition would take

Software resilience:

Software supply chain resilience includes:

• Dependency alternatives: Identifying replacement components
• Vendoring/mirroring: Local copies reducing availability risk
• Fallback capabilities: Degraded operation without specific dependencies
• Recovery procedures: Rapid response to supply chain incidents

Organizations rarely plan for software dependency failures with the rigor financial services applies to vendor failures—yet the potential impact may be comparable.

Lessons for Software Supply Chains¶

Financial services TPRM provides mature frameworks applicable to software supply chains.

Transferable practices:

Risk-based tiering: - Classify dependencies by criticality - Apply proportionate oversight - Focus resources on highest-risk dependencies

Structured assessment: - Systematic due diligence before adoption - Defined assessment criteria - Documentation requirements

Ongoing monitoring: - Continuous tracking of dependency health - Alert on significant changes - Regular reassessment

Concentration awareness: - Map common dependencies - Assess systemic risk - Develop mitigation strategies

Exit planning: - Identify alternatives for critical dependencies - Plan migration procedures - Test transition capabilities

Implementation challenges:

Applying TPRM to software faces challenges:

• Scale: Thousands of dependencies vs. dozens of traditional vendors
• Relationships: No contractual relationship with most open source
• Information: Limited visibility into open source project health
• Resources: Assessment requires expertise and time

Automation is essential—tools that provide TPRM-style assessment at scale.

Emerging tools:

Tools supporting software TPRM:

• OpenSSF Scorecard: Automated security assessment
• Dependency management platforms: Snyk, Renovate, Dependabot
• SBOM tools: syft, cdxgen, trivy
• Risk assessment: Socket.dev, Phylum (now part of Veracode)
• Governance platforms: Dependency-Track, OWASP

These tools enable TPRM-style practices at software scale, though integration and process maturity continue evolving.

Recommendations¶

We recommend adapting financial services TPRM practices to software supply chains:

For organizations:

1. Apply risk tiering to software dependencies, focusing oversight on critical components
2. Establish due diligence criteria for evaluating new dependencies before adoption
3. Implement ongoing monitoring tracking dependency health, vulnerabilities, and changes
4. Assess concentration risk identifying shared dependencies that could cause widespread impact
5. Develop exit plans for critical dependencies, including alternatives and migration procedures

For financial services:

1. Extend TPRM frameworks to explicitly cover software dependencies
2. Include open source in third-party risk assessments
3. Assess technology provider software practices as part of supplier oversight
4. Map software concentration identifying shared dependencies across the institution
5. Test software resilience including scenarios of dependency unavailability

For regulators:

1. Clarify expectations for software supply chain risk management
2. Consider critical infrastructure designation for essential open source
3. Coordinate across sectors on common software dependencies
4. Support information sharing about software supply chain risks
5. Enable proportionate compliance recognizing scale challenges

For the software industry:

1. Provide TPRM-relevant information about projects and products
2. Support assessment automation enabling scaled due diligence
3. Develop concentration metrics for software dependencies
4. Create resilience standards for critical infrastructure projects
5. Learn from financial services experience in managing third-party risk

Financial services developed sophisticated TPRM because regulators required it and incidents demonstrated its necessity. Other sectors increasingly face similar requirements and risks. The financial services model—risk-based tiering, structured assessment, ongoing monitoring, concentration awareness, and resilience planning—provides a proven framework that software supply chain management is only beginning to adopt. Organizations that apply these practices now will be better positioned as regulatory expectations extend beyond financial services.