Third-Party ICT Risk: The Board's Blind Spot

The Hidden Risk in Your Technology Stack

When I ask boards, “How many critical ICT service providers do you have?” the most common answer is somewhere between 5 and 10. When we conduct an independent assessment, the actual number is typically 50 to 100+.

This isn’t because management is hiding information—it’s because most boards only hear about the obvious vendors (core banking system, cloud provider, cybersecurity) while remaining blind to the sprawling ecosystem of dependencies that keep modern financial services operating.

DORA (Digital Operational Resilience Act) makes this blind spot extremely expensive. The regulation demands comprehensive board-level oversight of all critical ICT third-party relationships, with significant regulatory consequences for inadequate governance.

Why Third-Party ICT Risk Keeps Me Up at Night

The Concentration Illusion

Case Study:
A mid-sized Luxembourg bank proudly showed their board a diversified ICT vendor landscape: separate providers for core banking, payments, backup, cybersecurity, and cloud infrastructure.

During an independent review, we discovered:

• The core banking system ran on AWS
• The payment gateway ran on AWS
• The backup provider stored data on AWS
• The cybersecurity vendor’s monitoring tools ran on… AWS

The Reality:
What looked like diversification was actually massive concentration risk hidden beneath vendor layers. An AWS regional outage wouldn’t just impact one system—it would cascade across their entire operational infrastructure.

The Exit Strategy Fiction

Most third-party contracts include exit provisions. Most boards believe this means they can actually exit if needed.

The Hard Truth:
For truly critical systems, “exit strategy” is often fiction:

• Core banking migrations take 18-36 months minimum
• Data extraction from proprietary systems is complex and error-prone
• Knowledge transfer requires extensive documentation rarely available
• Transitional service agreements are expensive and limited in duration
• Regulatory approval for system changes adds months to timelines

Board Question to Ask:
“If our core banking provider gave us 90 days notice, could we actually exit without operational collapse?” The honest answer is almost always no—which means your “exit strategy” needs serious rethinking.

DORA’s Third-Party Requirements: What Boards Must Oversee

1. The Register of Critical ICT Third-Party Service Providers

DORA mandates maintaining a comprehensive register of all critical ICT providers—but defining “critical” is where boards often fail.

What Makes a Provider “Critical”?

• Systems without which you cannot process transactions or serve customers
• Providers supporting functions required for regulatory compliance
• Services whose failure would cause material financial or reputational harm
• Providers whose substitution would take more than 6 months

Board Action:
Don’t accept a simple spreadsheet. Demand a visual dependency map showing:

• Primary ICT services and their providers
• Underlying infrastructure dependencies
• Data flows between systems
• Geographic concentration of critical services
• Contractual termination notices and estimated migration timelines

Red Flag:
If your register only includes direct vendors but not sub-processors and infrastructure providers, you’re only seeing the tip of the iceberg.

2. Contractual Governance and Regulatory Access

DORA requires specific contractual provisions in agreements with critical ICT providers:

Mandatory Contract Terms:

• Full audit rights for the financial institution and its regulators
• Data access and portability requirements
• Exit assistance obligations with defined service levels
• Incident notification timeframes (often more stringent than standard SLAs)
• Business continuity and disaster recovery commitments
• Sub-contracting restrictions and notification requirements
• Data location and cross-border transfer provisions
• Termination rights for regulatory concerns

The Legacy Contract Problem:
Many existing agreements predate DORA and lack these provisions. Re-negotiating contracts with critical providers—especially dominant vendors—is a significant board-level challenge.

Board Question:
“What percentage of our critical ICT contracts have been updated for DORA compliance?” If the answer is less than 50%, you have material regulatory exposure.

3. Continuous Monitoring and Performance Management

Signing a contract isn’t oversight—it’s the beginning of oversight.

Board Oversight Requirements:

• SLA Performance Tracking: Quarterly reports on availability, performance, and incident metrics
• Security Posture Monitoring: Regular third-party security assessments and penetration test results
• Financial Stability: Monitoring vendor financial health (vendors can fail too)
• Regulatory Compliance: Ensuring vendors maintain required certifications and compliance status
• Change Management: Oversight of vendor system changes that could impact your operations

Practical Implementation:
Your CTO/CIO should present a Third-Party Risk Dashboard quarterly showing:

• Critical provider availability performance
• Outstanding security vulnerabilities in vendor systems
• Incident trends and root cause patterns
• Contract renewal timelines and renegotiation status
• Concentration risk metrics

4. Resilience Testing of Third Parties

DORA requires regular testing of not just your systems, but your critical providers’ resilience.

Testing Requirements:

• Failover Testing: Can the vendor actually restore services within their committed timeframes?
• Disaster Recovery Validation: Do backup systems work as advertised?
• Data Restoration: Can you recover complete and accurate data from vendor backups?
• Incident Response: How quickly does the vendor detect and respond to issues?
• Capacity Testing: Can vendor systems handle peak loads or stress scenarios?

Case Study:
A payment service provider had contractual 4-hour disaster recovery commitments from their cloud provider. When they actually tested failover, the real recovery time was 18 hours due to configuration complexities not documented in their contract. The board mandated monthly failover tests until actual performance matched SLAs.

Managing Concentration Risk: Beyond Provider Diversification

Geographic Concentration

Many boards focus on vendor diversification but ignore geographic risk:

• Data centers in the same region vulnerable to natural disasters
• Network infrastructure using common fiber routes
• Regulatory jurisdiction concentration (all providers subject to the same government authority)

Luxembourg Example:
Multiple financial institutions using different cloud providers discovered their data was all physically located in the same Luxembourg data center complex. Geographic diversification required contractual changes specifying exact data center locations.

Technology Stack Concentration

Modern software dependencies create hidden concentration:

• Multiple vendors using the same underlying database technology
• Shared programming language runtime vulnerabilities
• Common open-source component vulnerabilities (log4j-style risks)
• Shared authentication provider (Okta, Auth0, etc.)

Board Oversight:
Your technology leaders should maintain a “technology dependency matrix” showing common components across critical systems. This reveals concentration risks that vendor diversification doesn’t solve.

Provider Interconnection Risk

Vendors increasingly depend on each other, creating concentration through interconnection:

• Your payment provider depends on telecommunications provider X
• Your cloud provider depends on networking equipment from vendor Y
• Your security monitoring depends on threat intelligence from provider Z

The 2022 Cloud Outage Lesson:
Multiple “independent” cloud providers experienced simultaneous issues because they all relied on the same underlying internet routing infrastructure. Apparent diversification offered no actual resilience.

The Board’s Critical Vendor Playbook

Questions to Ask Your CTO/CIO Quarterly

1. Dependency Visibility:
   “Show me our top 10 critical ICT dependencies—including sub-layers. If each failed tomorrow, what’s the business impact?”

2. Concentration Assessment:
   “Where do we have concentration risk we haven’t adequately mitigated? What’s our plan?”

3. Contract Status:
   “What percentage of critical provider contracts are DORA-compliant? What’s blocking the remainder?”

4. Exit Capability:
   “For our top 5 critical vendors, how long would it actually take to exit? What’s our exit readiness level?”

5. Testing Results:
   “When did we last test failover for each critical provider? Did they meet their SLA commitments?”

6. Incident Trends:
   “What vendor-related incidents occurred this quarter? Are we seeing patterns?”

7. Financial Stability:
   “Are any of our critical vendors showing signs of financial distress or M&A activity?”

8. Regulatory Concerns:
   “Has any regulator raised concerns about our vendor relationships or concentrations?”

Annual Board Actions

1. Third-Party Risk Deep Dive Session
Dedicate a full board session annually to third-party ICT risk:

• Walk through the complete dependency map
• Review concentration risk assessment
• Challenge exit strategies for top vendors
• Assess Board’s own understanding of critical dependencies

2. Regulatory Compliance Assessment
Confirm that:

• All critical vendor contracts meet DORA requirements
• Required testing has been completed
• Incident reporting obligations are being met
• The register of critical providers is current and comprehensive

3. Vendor Risk Appetite Review
Update the board’s risk appetite for:

• Acceptable level of concentration risk
• Minimum required exit timeframes
• Geographic diversification requirements
• Financial stability thresholds for critical vendors
• Security posture expectations

4. Crisis Scenario Planning
Participate in a tabletop exercise simulating critical vendor failure:

• Major cloud provider outage
• Core banking system provider insolvency
• Payment network disruption
• Critical security vendor breach

Why Independent Technical Oversight is Critical

Management presentations about third-party risk are naturally optimistic. Vendors provide reassuring documentation. Contracts include protection provisions.

But:

• Have those contracts actually been tested in failure scenarios?
• Do technical architectures expose hidden dependencies?
• Are risk assessments based on actual capability testing or vendor attestations?
• Has anyone independently validated that exit strategies are practical?

This is where fractional CTO/CISO oversight provides invaluable perspective:

• Independent technical review of vendor architectures
• Validation of concentration risk claims
• Testing of vendor SLA achievements vs. commitments
• Practical assessment of exit strategy viability
• Translation of technical vendor risks into board-level decisions

From Risk Management to Strategic Resilience

The most sophisticated boards are moving beyond “vendor risk management” to “ecosystem resilience strategy.”

Strategic Questions:

• How do we structure vendor relationships to maintain negotiating leverage?
• Where should we consider bringing capabilities in-house to reduce critical dependencies?
• How can we collaborate with peer institutions to improve collective vendor oversight?
• What emerging providers offer genuine alternatives to concentrated markets?

Example:
A consortium of Luxembourg banks collectively negotiated improved contract terms with a dominant core banking provider by presenting a unified position. Individual institutions lacked leverage; collective action succeeded.

Conclusion: Boards Must Go Deeper

Third-party ICT risk is not an operational detail—it’s a strategic board-level concern. DORA recognizes this reality and holds boards accountable for what happens in vendor systems, not just internal systems.

The boards that will thrive under this regime are those that:

• Truly understand their critical dependencies (including hidden layers)
• Actively manage concentration risk, not just provider diversification
• Test vendor resilience capabilities, not just read contracts
• Maintain independent technical advisors who can validate vendor claims
• Integrate third-party risk into overall operational resilience strategy

The fundamental question every board must answer:
“If our most critical ICT vendor failed tomorrow, could we keep serving customers?” If you’re not certain the answer is yes, it’s time for deeper third-party oversight.

---