When the bank is secure but the vendor is breached: Third-party risk lessons from the Bank of America-Infosys McCamish Incident

Banks increasingly depend on technology companies, cloud providers, payment processors, data centres, software vendors and specialist service providers to deliver critical functions. Outsourcing provides access to expertise, scalability and cost efficiencies, but it also creates a fundamental risk-management challenge: a bank may protect its own systems effectively and still suffer operational, regulatory and reputational consequences because a service provider is compromised.

The 2023 cyber incident involving Infosys McCamish Systems and Bank of America provides a useful real-world case study of this problem.

The Incident

Infosys McCamish Systems, or IMS, provides technology and processing services supporting products such as life insurance, annuities and deferred compensation plans. Bank of America used IMS in connection with certain deferred compensation plan services.

In November 2023, IMS disclosed that some of its applications and systems had become unavailable following a cybersecurity incident. IMS later confirmed that ransomware had encrypted certain systems and that unauthorised activity had taken place between 29 October and 2 November 2023. Data was also subject to unauthorised access and acquisition.

The consequences extended beyond IMS itself.

On 24 November 2023, IMS informed Bank of America that corporate client data relating to deferred compensation plans managed by the bank might have been compromised. Importantly, Bank of America’s own systems were not compromised. The exposure arose because information associated with the bank’s business had been held or processed within the environment of its third-party service provider.

A breach notification filed with the Maine Attorney General reported 57,028 potentially affected persons. Information potentially involved included names, addresses, business email addresses, dates of birth, Social Security numbers and other account information. Bank of America offered eligible affected individuals two years of identity-theft protection.

The incident illustrates one of the central principles of third-party risk management:

Outsourcing a process does not outsource the risk associated with that process.

Why the Case Matters to Banks

Modern banks may have hundreds or even thousands of external relationships. Some provide relatively routine services, while others process customer information or support functions whose failure could materially affect operations.

This creates an expanded digital ecosystem.

Traditionally, cybersecurity teams concentrated heavily on defending the bank’s own network perimeter. Today that perimeter effectively extends to cloud environments, software providers, outsourced processors and subcontractors.

A bank may have strong firewalls, sophisticated security operations and robust authentication controls. But if sensitive customer data is transferred to a vendor, weaknesses in the vendor’s environment can indirectly expose the bank.

The Bank of America case is particularly instructive because the bank itself was not reported as having been directly breached. The problem travelled through the vendor relationship.

Lesson 1: Data risk follows the data

One of the most important questions before appointing a vendor should be:

What information will this third party actually possess?

Banks sometimes classify vendors according to the service being purchased rather than the information to which the provider will have access.

The better approach is to map:

Data →Vendor →System →Location →Access →Subcontractor

A provider holding personally identifiable information, financial records, authentication data or customer account information should receive significantly greater oversight than a provider handling non-sensitive administrative information.

Data minimisation is equally important. A service provider should receive only the information necessary to perform the contracted activity.

If information does not need to leave the bank’s environment, it should not be transferred simply because doing so is operationally convenient.

Lesson 2: Due diligence cannot be a one-time exercise

Banks usually assess vendors before contracting with them. They may examine financial strength, security certifications, internal controls, business continuity arrangements and previous incidents.

But cybersecurity conditions change continuously.

A vendor considered strong three years ago may subsequently experience management changes, introduce new technologies, outsource functions, accumulate technical vulnerabilities or expand its customer base significantly.

Third-party risk management therefore requires continuous monitoring, not merely initial approval.

High-risk vendors should be periodically assessed for areas such as:

• cybersecurity controls;
• vulnerability management;
• incident history;
• penetration testing;
• business continuity;
• disaster recovery;
• financial condition;
• changes in subcontractors;
• regulatory compliance; and
• remediation of previous audit observations.

The United States banking agencies’ third-party guidance similarly treats vendor risk management as a lifecycle covering planning, due diligence, contracting, ongoing monitoring and termination rather than a single procurement decision.

Lesson 3: Incident notification speed matters

A bank cannot respond effectively to a vendor incident unless the vendor informs it promptly.

Contracts should therefore clearly specify:

• what constitutes a reportable security incident;
• how quickly the bank must be notified;
• who must receive the notification;
• what preliminary information must be provided;
• how forensic evidence will be preserved; and
• how subsequent updates will be communicated.

In the McCamish incident, the investigation required time to determine what information might have been accessed, and the notification materials acknowledged that it was unlikely to be possible to establish with certainty exactly which personal information had been accessed.

This highlights another important issue: forensic uncertainty itself is a risk.

Banks should understand whether their vendors maintain logging, monitoring and evidence-preservation capabilities sufficient to reconstruct an incident after it occurs.

Lesson 4: Understand fourth-party risk

A bank may contract with Vendor A, but Vendor A may rely on cloud providers, software companies, data processors or other subcontractors.

The bank therefore has indirect exposure to organisations with which it may have no contractual relationship.

This is generally described as fourth-party risk.

Strong vendor contracts should require transparency regarding material subcontractors and specify circumstances in which prior approval from the bank is required.

This becomes particularly important when sensitive information is moved across multiple organisations or jurisdictions.

Lesson 5: Criticality is more important than vendor size

A large international technology company is not automatically low risk, nor is a small provider automatically unacceptable.

The appropriate question is:

What happens to the bank if this particular vendor fails?

Criticality assessment should consider:

• customer impact;
• availability of alternative providers;
• volume of data involved;
• importance of the supported process;
• recovery time;
• financial impact;
• regulatory consequences; and
• difficulty of migrating the service.

A relatively small vendor supporting a crucial authentication process may pose more operational risk than a much larger provider delivering a non-critical function.

Lesson 6: Exit strategy must exist before the crisis

Banks frequently negotiate how a vendor relationship will begin but devote insufficient attention to how it will end.

Suppose a critical vendor suffers repeated cyber incidents or becomes financially unstable. Can the bank move the service elsewhere?

Does it have access to its data?

Can another supplier operate the system?

How long would migration take?

An effective third-party framework needs an exit strategy before the relationship becomes problematic.

Exit planning should include data portability, transitional assistance, secure deletion of information, alternative providers and procedures for bringing critical processes back in-house if necessary.

The RBI Perspective

The case is highly relevant to Indian banks.

The Reserve Bank of India (Outsourcing of Information Technology Services) Directions, 2023 make clear that outsourcing does not diminish a regulated entity’s responsibility towards its customers. RBI requires regulated entities to maintain a Board-approved outsourcing policy, conduct due diligence, monitor service providers and maintain a comprehensive risk-management framework for outsourced information technology services.

The RBI framework specifically emphasises that regulated entities remain responsible for the confidentiality and integrity of customer data available to service providers. It also requires contractual provisions dealing with subcontractors, regulatory access, termination rights and other controls.

RBI’s Information Technology Governance directions further require appropriate vendor risk assessment even for relevant third-party arrangements that fall outside the outsourcing directions, including controls addressing concentration risk.

The regulatory philosophy is therefore clear: a bank cannot respond to a vendor failure by saying, “The problem occurred outside our systems.”

From the customer’s perspective, the service has been entrusted to the bank.

A practical third-party risk framework

The lessons from the incident can be converted into a simple lifecycle:

Identify →Classify →Assess →Contract →Monitor →Test →Respond →Exit

Banks should maintain a central inventory of vendors and classify them according to risk and criticality. Critical vendors should undergo enhanced due diligence and continuous monitoring.

Contracts should establish cybersecurity requirements, audit rights, breach-notification obligations, data protection standards, business-continuity requirements and controls over subcontracting.

Banks should also conduct scenario exercises involving the failure of major vendors.

For example:

What happens if our critical service provider is unavailable for seven days?

What if customer information is stolen from the vendor?

What if both the vendor’s production and recovery environments are affected?

Can customers continue receiving essential banking services?

These questions transform vendor management from compliance documentation into operational resilience.

Conclusion

The Bank of America-Infosys McCamish incident demonstrates the changing perimeter of banking risk.

Bank of America’s systems were not reported as compromised, yet information connected with its clients and deferred compensation business was potentially exposed because a third-party service provider suffered a ransomware incident.

This is the essence of modern third-party risk.

Banks increasingly operate through interconnected ecosystems rather than self-contained technology environments. The reliability of a banking service therefore depends not only upon the institution’s own controls but upon the resilience of numerous organisations supporting it.

The most important lesson is not that banks should avoid outsourcing. Outsourcing is essential to contemporary banking and can provide substantial benefits.

The lesson is that every critical vendor must be managed as an extension of the bank’s own risk environment.

A bank may outsource technology, processing or infrastructure. It may transfer contractual responsibilities and operational activities.

But it cannot outsource accountability for the risk.