Third-party risk management stopped being a paperwork exercise on October 30, 2026, when Abrigo took its Sageworks lending platform offline at about 11:25 a.m. Eastern after spotting irregular activity in its environment. Banks and credit unions that rely on Sageworks to analyze loans, store loan documents and take borrower applications online discovered that a decision made inside someone else’s data center had become their outage. This article uses the Sageworks shutdown to show what third-party risk management has to prove in 2026, what U.S. regulators expect, and how to design your network so that a vendor going dark does not stop you from serving customers.

Definition: Third-party risk management (TPRM) is the discipline of identifying, assessing, contracting for, monitoring and exiting relationships with vendors that touch your systems, data or customers, so that a vendor’s failure does not become your own outage, breach or regulatory finding.

What Happened at Sageworks: The Facts So Far

According to BleepingComputer, Abrigo began emergency maintenance on October 30 and took Sageworks offline to investigate suspicious activity it had detected earlier that day. The outage ran through the weekend. Abrigo serves more than 2,400 community banks and credit unions, and Sageworks is the product lenders use to process applications, analyze borrower finances and monitor portfolios.

Three services were hit: Sageworks Analyst, the Sageworks API that banks’ other systems use to exchange data, and Online Portal Now, where borrowers complete applications. American Banker reported that most of the platform returned Monday morning, November 2, while borrower-facing features stayed down into Tuesday. The same report says Abrigo confirmed the activity was a data security incident involving unauthorized access, which it said had been contained, but did not say whether any data was taken. It was the third security incident involving Abrigo in about 14 months; the first two exposed business contact information tied to a Salesforce database.

Sageworks holds the documents behind commercial and small-business loans, including borrowers’ tax returns and financial statements, so the stakes go beyond downtime. eSecurity Planet cautioned that a precautionary shutdown should not be mistaken for proof of a breach, and listed what institutions should verify after recovery: which services are truly restored, whether data integrity checks are finished, and which applications were handled during the outage. Some researchers also advised customers to rotate their Sageworks API keys, per BleepingComputer. The eSecurity Planet weekly roundup and an SC Media brief place it among the week’s vendor-driven disruptions.

Third-Party Risk Management Starts With the Vendor Kill-Switch Gap

Abrigo’s choice to disable the platform was a defensible security decision; cautious providers shut down while they investigate. But it exposes what we call the vendor kill-switch gap: the distance between the moment a vendor decides to take a system offline and the moment your institution can keep serving customers without it.

Most third-party risk management programs measure the vendor: its SOC report, its financial strength, its security questionnaire. Far fewer measure the gap on your side of the contract. How long until your lending team knows? What do borrowers do in the meantime? Which of your own systems call the vendor’s API, and what happens to them when it stops answering? A strong vendor assessment lowers the odds of a kill-switch event; only your own architecture and runbooks narrow the gap when one happens anyway.

Four outages, four causes, one dependency

Public status-page records, aggregated by services such as IsDown and Pingoru, show that Sageworks users have faced several disruptions in a little over two years, each with a different trigger.

The lesson is not that Abrigo is unusually fragile. Every critical vendor sits on a stack of its own dependencies, and any layer can fail, so modern third-party risk management has to reach fourth parties: the cloud, identity and security tooling your vendor depends on. Our look at blind agent transfer in financial services makes a related point about hidden hand-offs that remove accountability.

What Regulators Expect From Third-Party Risk Management

U.S. financial regulators have been consistent: outsourcing a function does not outsource responsibility. Four pieces of guidance frame what examiners will ask after an event like Sageworks.

Interagency guidance on third-party relationships (June 2023)

The Federal Reserve, FDIC and OCC issued final interagency guidance on June 6, 2023, published as Federal Reserve SR 23-4, OCC Bulletin 2023-17 and FDIC FIL-29-2023. It replaced each agency’s earlier guidance and covers the full life cycle of a relationship: planning, due diligence and selection, contract negotiation, ongoing monitoring and termination. It also recognizes that a smaller bank may have limited negotiating leverage, which raises the value of compensating controls on your side.

The 36-hour and four-hour rules

Under the joint computer-security incident notification rule (86 FR 66424, OCC Bulletin 2021-55, FDIC FIL-74-2021), a bank must notify its primary federal regulator as soon as possible and no later than 36 hours after determining that a notification incident has occurred. A bank service provider must notify affected bank customers as soon as possible when it determines that an incident has caused, or is reasonably likely to cause, a material disruption of covered services for four or more hours. Whether a vendor meets the rule’s definition of a bank service provider is a question for counsel; the operational point is universal: your contract should name who is called, how fast, and by what channel. Credit unions follow a separate 72-hour rule in NCUA’s Part 748, which American Banker notes also reaches unauthorized access to sensitive data.

Operational resilience and business continuity

The interagency Sound Practices to Strengthen Operational Resilience (SR 20-24) and the FFIEC Business Continuity Management booklet expect institutions to map critical operations to the providers they depend on and test recovery against severe but plausible scenarios. A vendor shutdown is one. NIST SP 800-34 remains the reference for contingency planning.

New York, securities and insurance overlays

The New York Department of Financial Services issued an industry letter on October 21, 2025 clarifying expectations under 23 NYCRR Part 500: covered entities cannot delegate compliance to a provider, should assess and monitor providers across the relationship, should write baseline protections into contracts, and should fold third-party risk into incident response and continuity planning. Broker-dealers face service-provider oversight duties under the SEC’s amended Regulation S-P, insurers under the NAIC Insurance Data Security Model Law, and non-bank lenders under the FTC Safeguards Rule. Healthcare organizations should treat their vendors as business associates under the HIPAA Security Rule.

For frameworks that translate these expectations into controls, see NIST SP 800-161 Rev. 1 on cybersecurity supply chain risk management, the supply chain outcomes in the NIST Cybersecurity Framework 2.0, and the vendor-related goals in CISA’s Cross-Sector Cybersecurity Performance Goals.

The Kill-Switch Test: Five Questions Every Institution Should Answer

Use these five third-party risk management questions as a tabletop for any vendor your business could not run without for three days. If you cannot answer one with evidence, you have found your next project.

1. Will we know within the hour? Do you subscribe to the vendor’s status page, and do named staff, not a shared inbox, receive its incident notices? Does the contract set a notification clock and require two or more contacts on your side?
2. Can we still serve the customer? If the borrower portal is down, is there an approved alternate intake channel, and can staff say whether an application was received?
3. What does the vendor hold, and what can reach it? Inventory the documents, credentials and API keys that live on the vendor side or connect to it. Can you rotate every credential in a day without breaking production?
4. Can we prove what happened to our data? Do you keep your own logs of what moved to and from the vendor, and reconcile records after restoration?
5. Can we leave? Is there a documented exit plan with data export formats, a secondary provider or manual process, and termination steps that disable access?

Question four echoes our post on the VMware ESX zero-day: when the only record of an event is written by the system involved in it, independent logging on your side becomes your evidence.

Third-Party Risk Management by Lifecycle Stage

The interagency guidance organizes the work into five stages. This table turns each stage of third-party risk management into evidence an examiner, auditor or board member can request.

One pattern worth noting: Abrigo’s third incident in 14 months is exactly the kind of history that belongs in the due diligence and monitoring stages. A single event rarely disqualifies a vendor; a pattern should change how often you test and what you ask for at renewal.

Design for the Day the Vendor Goes Dark

Third-party risk management contracts and questionnaires set expectations; architecture decides outcomes. The following design choices shorten the kill-switch gap without claiming to prevent a vendor’s own incident.

Give each vendor its own zone

In practice, third-party risk management means treating every critical vendor connection as a partner zone with a dedicated egress path, allowlisted destinations and service accounts scoped to the minimum data. A segmented connection limits what a compromised credential can reach and makes a clean cut-off possible. This is the application-centric thinking we described in Secure Applications Anywhere, and it is where a modern next-generation firewall and zero trust content security controls earn their keep.

Make credential rotation boring

The advice to rotate Sageworks API keys only works if rotation is rehearsed. Keep an inventory of which keys connect which systems, use short-lived tokens where the vendor allows them, and protect keys with centralized custody. Our post on SD-WAN encryption keys explains why key location matters, and Exodus Key Management is the service family to look at for key custody.

Encrypt data in motion and at rest, under your control

If loan documents and tax returns travel to a vendor, the protection you apply before they leave is what still holds if the vendor’s environment is accessed. Review data in motion and data at rest protections, and plan for the long horizon: multi-year-sensitive documents are prime harvest-now-decrypt-later targets, which is why we track quantum computing and encryption.

Watch the connection, not just the vendor

Baselining traffic volume, timing and destinations between your network and each vendor lets you spot odd behavior before the vendor tells you anything. Detection and response services such as Exodus Aria ADR and endpoint coverage through EDR support that visibility; our help desk impersonation analysis shows how fast trust in one channel becomes broad access.

Keep your own copy and your own path

Hold a recoverable copy of critical records outside the vendor, and keep a network path that does not depend on one carrier or cloud. Backup and recovery, immutable backups, a private or hybrid cloud and a resilient SD-WAN design all shrink how much one provider’s bad day becomes yours. Orphaned circuits complicate every incident, which is why our telecom expense management guide pairs audit discipline with security.

An honest note: we have no inside knowledge of how the Sageworks incident began, and nothing here claims any product would have prevented it. The goal is narrower: limit what a vendor connection can reach, and shorten the time it takes to operate without it.

Sector Lens: Banks, Credit Unions, Insurers and Healthcare

• Community banks and credit unions: run the kill-switch test on lending, core and payment vendors, and confirm your workflow can meet the 36-hour (bank) or 72-hour (credit union) clock from a vendor’s first notice.
• Insurers: map claims, underwriting and document platforms to state data security laws modeled on the NAIC law, and ask vendors for fourth-party lists.
• Healthcare: treat revenue-cycle, imaging and cloud EHR vendors as critical and test downtime procedures. Our end-of-support edge devices post covers a related exposure inside your own perimeter.

A 30-Day Third-Party Risk Management Plan

What We Still Don’t Know

Several facts remain unclear from public reporting: how the unauthorized access occurred, whether any customer data was taken, how many institutions were affected, and exactly when borrower-facing features fully returned. Abrigo told American Banker the incident was contained but has not said whether data left its environment. Until that is clarified, third-party risk management teams should request written confirmation of scope, integrity checks and indicators of compromise, and document your own timeline. Facts here reflect public reporting through November 12, 2026 and may change.

Frequently Asked Questions About Third-Party Risk Management

What is third-party risk management?

Third-party risk management is the process of identifying, assessing, contracting for, monitoring and exiting vendor relationships. In U.S. banking it follows the five-stage life cycle in the 2023 interagency guidance.

What happened to Abrigo Sageworks?

Abrigo disabled Sageworks on October 30, 2026 after detecting irregular activity. Most services returned November 2. Abrigo later confirmed a contained data security incident involving unauthorized access.

Does a vendor shutdown mean a data breach?

Not by itself. Here unauthorized access was confirmed, but reporting has not said whether data was taken, so ask for evidence rather than assuming.

What incident-notification rules apply to banks and vendors?

Banks must notify their primary federal regulator within 36 hours of determining a notification incident occurred. Bank service providers must notify affected banks as soon as possible after an incident causing or likely to cause a material disruption of four or more hours. Credit unions follow NCUA’s 72-hour rule.

Which contract terms matter most?

Notification clocks with named contacts, audit rights, subcontractor disclosure, recovery objectives, data return and deletion, and termination assistance.

How can network architecture reduce vendor-outage risk?

Strong third-party risk management segments each vendor connection, scopes and rotates credentials, encrypt data under keys you control, monitor vendor traffic for anomalies, and keep recoverable copies and alternate paths. These steps limit reach and speed recovery; they do not prevent a vendor’s own incident.

Is Your Next Vendor Shutdown Already Scheduled?

ibm/SEIMless Communications Technologies, Inc. and Exodus QRN, Inc. help financial services, healthcare and insurance organizations pair third-party risk management with networks that keep serving customers when a provider cannot. Let’s map your critical vendors and run your first kill-switch test together.

Get StartedContact Us

Call: 646-546-5245
Email: in**@**********ss.com
Address: One Liberty Plaza, New York, NY 10006

Sources and Further Reading

• American Banker: Abrigo confirms data security incident caused 3-day outage
• BleepingComputer: Sageworks taken offline after suspected cyberattack
• eSecurity Planet: What banks should check after recovery
• Federal Reserve SR 23-4 OCC Bulletin 2023-17 · FDIC FIL-29-2023
• Federal Register: Computer-Security Incident Notification (86 FR 66424)