Resilience Under Stress: Monitoring, Incidents, and Recovery
The subject here is what happens after a bank’s third-party service-provider arrangement goes live. The specific problem is diagnostic: which signals show that the dependency has changed, how can a cyber or supply-chain event travel into the bank’s critical service, and what evidence demonstrates that recovery is real rather than merely promised? A bank can answer those questions only by treating monitoring, incident response, continuity testing, and exit readiness as one operating loop.
Monitor for change, not just uptime
A service can be available and still become a riskier dependency. The provider’s financial condition may deteriorate, a key nth party may change, the service may move to another location, a new technology may alter the control boundary, or the bank may become more reliant on the arrangement as other internal capabilities disappear. The Basel Committee’s principles therefore require ongoing assessment of a TPSP arrangement’s performance, risks, and criticality, with reporting to senior management and the board. Monitoring is not a final check that a vendor met a service-level number. It is a way to discover when the bank’s original decision no longer describes the relationship.
The evidence comes from several directions. Performance measures show whether the provider meets contractual expectations. Audit findings may reveal a control that is weak, repeated, or not being remediated. Financial information can indicate pressure on the provider’s ability to sustain service. Security breaches, data loss, service interruptions, compliance lapses, and changes in the provider or its supply chain can all change the risk picture. The bank should also monitor its own control environment: a provider may be meeting its obligations while the bank’s access management, staffing, architecture, or escalation process makes the overall service less resilient.
This is easier to understand when monitoring is treated as a feedback loop. An observation is not yet a diagnosis. A missed performance measure is a symptom; it might reflect a temporary incident, a capacity problem, a change in a key nth party, or a deeper weakness in the provider’s controls. A security alert is evidence of possible exposure, not proof that the critical service has failed. A service interruption may be caused by a provider, a shared dependency, a bank configuration, or an attack that affects several parties at once. The bank’s job is to identify the plausible failure path, determine the effect on the critical service, and decide whether the arrangement’s risk or criticality has changed.
The OCC’s 2026 report supplies concrete threat mechanisms that can produce those signals. It describes ransomware, distributed denial-of-service attacks, account takeover, supply-chain compromise, geopolitical threats, post-quantum cryptography, digital-asset risks, and attacks enabled by artificial intelligence. These are not interchangeable risks. Ransomware can encrypt or expose information and disrupt operations. DDoS attacks can make a service unreachable. Stolen employee or third-party credentials can provide entry to trusted systems. A compromised software supplier can spread malicious activity through services used by many customers. The point is not to list every threat. It is to connect the threat to the dependency that delivers the bank’s service.