A credit union’s first report of a vendor breach may come from the attacker

The week

Criminals do not usually call the authorities on their victims. On November 15, 2023, one did. The ALPHV ransomware group, also known as BlackCat, said it had filed a complaint with the Securities and Exchange Commission alleging that MeridianLink had failed to disclose a breach.

MeridianLink is a publicly traded company that makes software many banks and credit unions use for digital lending and account opening. These are the screens a customer fills in to apply for a car loan or open a checking account online. It is the kind of vendor most people never hear of, but one that may handle sensitive information on behalf of many financial institutions.

ALPHV is a ransomware operation. Ransomware is malicious software that criminals use to lock up a victim’s computer systems by encrypting them, then demand payment to unlock them. Many groups, ALPHV among them, also copy data before locking it, so they can threaten to leak it if the victim refuses to pay. ALPHV claimed it had stolen company data from MeridianLink.

The timeline the gang offered was specific. According to DataBreaches.net, as reported by BleepingComputer, ALPHV said it had entered MeridianLink’s network on November 7 and copied data without encrypting any systems. That made it a theft-and-extortion case rather than a lockout. Customers using the software would have seen no outage, because nothing was visibly broken.

On November 15 the gang also listed MeridianLink on its leak site and threatened to publish the data unless it was paid within 24 hours. It posted a screenshot of the form it said it had filed through the SEC’s online tips, complaints and referrals page, together with the automated reply confirming receipt. The complaint described a significant breach affecting customer data and operational information, and accused the company of failing to report it on Form 8-K under Item 1.05.

MeridianLink told a different story. It said it had identified and contained a cybersecurity incident and had found no evidence of unauthorized access to its production platforms. Those are the live systems that run its products for customers, as opposed to its internal corporate network.

The company added that it was still determining whether any consumer personal information had been involved, and that it would notify affected parties if so. It said the incident had caused minimal business interruption. Those were careful words, typical of the first days of an investigation. They left open the one question its bank and credit union customers most needed answered: whether their own applicants’ data had been touched.

The complaint was a pressure tactic with a twist. It cited the SEC’s new incident disclosure requirement for public companies, which obliges them to tell investors about material cybersecurity incidents. But that requirement did not take effect until December 18, so the gang was invoking a rule that did not yet apply. Legal accuracy was beside the point; the aim was to embarrass the company and push it toward paying.

Even on its own terms, the complaint misread the rule. Item 1.05 asks a company to file within four business days of determining that an incident is material, not within four days of discovering it. The determination itself must be made without unreasonable delay. A company still investigating could therefore be fully compliant while saying very little, and that gap between discovery and determination was exactly what the gang tried to exploit in public.

The complaint landed in a crowded month for financial services security. Days earlier, a LockBit ransomware attack on ICBC Financial Services, the U.S. broker-dealer arm of the Industrial and Commercial Bank of China, had disrupted some trades in the Treasury market. Mortgage servicer Mr. Cooper had disclosed a cyberattack at the start of November. On November 21, title insurer Fidelity National Financial told investors in an 8-K that it had been hit, an attack ALPHV also claimed.

The rules were moving as well. On October 27, the Federal Trade Commission approved an amendment to its Safeguards Rule. It requires non-bank financial institutions, such as mortgage brokers, motor vehicle dealers and payday lenders, to notify the FTC of breaches affecting at least 500 consumers. On November 1, New York’s Department of Financial Services finalized amendments to its cybersecurity regulation, including a new requirement to report ransomware payments. A vendor incident that autumn could touch several notification regimes at once, depending on who the vendor’s customers were.

Security reporters described the move as possibly the first public confirmation that a ransomware group had reported its own victim to a regulator. Most coverage focused on MeridianLink and the SEC. The less noticed story was further down the line, at the community banks and credit unions that used MeridianLink’s software. They now had to decide, on their own short regulatory clocks, what this meant for them and their members. They had only an attacker’s claim and a vendor’s cautious statement to work from.

The SEC’s July 2023 cyber rule left each public company to govern its own “materiality” decision: the judgment about whether a cyber incident is significant enough that investors need to be told. The MeridianLink episode raised the same kind of question one step down the supply chain, and for organizations that had never thought of themselves as part of the story.

Many of MeridianLink’s customers were community banks and credit unions. These institutions are not SEC registrants, so the SEC’s disclosure rule does not apply to them. But they have their own regulators, and their own short notification clocks.

Since September 1, 2023, federally insured credit unions had been required to notify the NCUA within 72 hours of reasonably believing a reportable cyber incident had occurred. The NCUA is the federal agency that supervises and insures credit unions. The rule expressly reaches some incidents at third parties, meaning a credit union can have a reporting obligation because of something that happened at a vendor. Banks had been under the interagency 36-hour notification rule, issued jointly by the federal banking agencies, since 2022.

For these institutions, the first public account of a vendor’s incident came from the attacker. That is an awkward place to start. Their work divided into three parts that together cover every audience: establishing the facts, deciding what regulators must hear, and deciding what customers and members must hear. First, though, comes the question of why a vendor incident is so hard to read from the outside.

Your members’ data, in someone else’s building

Modern banks and credit unions run on other companies’ technology. The core system that keeps account balances, the mobile app, the online loan application, the card processing: each may come from a different provider. Industry people call these third parties, and the discipline of managing them third-party risk management.

When a customer applies for a loan through a credit union’s website, the form may actually be hosted by a vendor like MeridianLink. The applicant’s name, address, income and Social Security number travel to the vendor’s systems, are processed there, and flow back to the credit union. From the member’s point of view, they gave their information to the credit union. From a technology point of view, a copy lives in someone else’s building.

Vendors usually run at least two separate environments. One is the corporate network: email, finance, human resources, the laptops employees use. The other is the production platform: the systems that actually run the product for customers and hold customer data. Many vendors that serve several clients keep each client’s data in a separate compartment, often called a tenant, much like separate apartments in one building.

This matters enormously when an incident is reported. “We were hacked” could mean the attacker got into the vendor’s HR files and nothing more. Or it could mean the attacker walked into the apartment where your members’ loan applications live. MeridianLink’s statement that it had found no evidence of unauthorized access to its production platforms was, in effect, a statement about which part of the building was affected. The customer institution’s job is to work out what that means for its own apartment.

Suppose a community credit union uses a vendor for online loan applications. On a Wednesday afternoon, a member services manager sees a news story: a ransomware gang says it has stolen the vendor’s data. The vendor has issued a short statement. The credit union’s 72-hour clock may or may not have started. What happens next depends almost entirely on what the credit union prepared before that afternoon.

The vendor’s vendors, and the paths between environments

The building has more than one landlord. A lending platform may run on a public cloud, send credit pulls to a bureau, use a separate company for identity verification and route documents through an e-signature provider. Each of those is a fourth party to the credit union: a vendor’s vendor, with no contract running directly to the institution. An incident at any of them raises the same question with even less information.

The wall between the corporate network and the production platform is also less solid than the apartment comparison suggests. Attackers who start on the corporate side look for the routes into production that employees use every day. These include administrative consoles, support tools that let staff view a customer’s configuration, shared login systems and the credentials engineers keep for maintenance. A vendor that says production was untouched is saying that its logs show no use of those routes.

That qualifier matters. “No evidence of access” is a statement about evidence. It depends on what was logged, for how long, and whether the attacker deleted records on the way out. Institutions should read it as a finding at a point in time, to be confirmed in writing once the investigation closes.

Corporate systems can hold customer data too. Support tickets carry screenshots of loan applications. Implementation teams keep test files built from real records. Account managers export reports and email them around. A claim limited to the corporate network is a narrower risk, but it is not automatically a harmless one for the institution’s members.

Banks and credit unions see their vendors differently

Regulatory reach over the vendor differs by charter. Bank regulators can examine many technology providers that serve banks, under the Bank Service Company Act, and the federal banking agencies jointly examine significant service providers. Their findings shape how a bank’s supervisor views a vendor before any incident happens.

The NCUA has no equivalent power. Its temporary authority to examine credit union vendors expired in 2001, and the agency has asked Congress repeatedly to restore it. A credit union therefore carries more of the burden of vetting technology providers itself, through due diligence, contract terms and whatever reports vendors choose to share. When a vendor incident breaks, its contract is often the only lever it holds.

Four sources, each with a bias

An institution learning of a vendor incident usually has four sources. The first is the attacker’s claims, made to journalists or on a leak site (a website where ransomware groups name victims and post stolen data). The second and third are the vendor’s public statement and its direct communication to customers. The fourth is the institution’s own logs, the automatic records its systems keep of who connected to what, and when.

Each has a bias. Attackers exaggerate to raise pressure; a bigger claim means a scarier headline and a stronger negotiating position. Vendors understate early, partly because they do not yet know and partly because their own disclosure obligations shape the wording. Neither tells the institution whether its own members’ data was in the affected environment.

A prepared institution can narrow the question within hours. Four practices make the difference.

• A vendor inventory that records data and location. For each critical provider, the inventory should record what data the provider holds and in which environment. A claim about the vendor’s corporate network can then be separated from one about the production platform hosting loan applications.
• A contractual right to specific answers. The contract should give the institution a right to answers to precise questions, such as whether the institution’s tenant or data sets were accessed, with a named security contact rather than an account manager. A salesperson can offer reassurance; a security contact can offer facts.
• A check of its own side. The institution can look for unusual activity on its integrations with the vendor, the automated connections that pass data back and forth. It can also check the service accounts the vendor uses (logins that belong to software rather than people) and recent file transfers.
• One incident log, kept by one person. Each finding, with its time and source, goes into an incident log. That log becomes the basis for both the regulatory and the customer decisions that follow, so it should be kept by one person from the first hour.

Back at the credit union, a prepared team opens its vendor inventory and sees that the loan vendor holds application data in a dedicated tenant on its production platform. The security lead emails the named contact at the vendor with two specific questions. Meanwhile, the credit union’s own technology staff check the integration logs for anything unusual. By the end of the day, the log shows what is known, what is not, and who said what. That is a foundation for decisions. An unprepared team, by contrast, spends the same afternoon trying to find out who at the vendor to call.

Reading an attacker’s claim without amplifying it

An attacker’s post can still be useful evidence if it is handled carefully. Leak site entries often include a description of the data, a file listing or sample documents. A security team, or a threat intelligence provider it already pays, can check whether the samples look like vendor corporate files or like customer application data, and whether the institution’s name appears.

That check has limits. Downloading stolen data can raise legal questions and can expose analysts to malicious files, so institutions should agree in advance who may look and through what service. The aim is narrow: to learn whether anything published so far points to the institution’s members, without trying to verify the gang’s whole story.

Timing matters as well. Gangs set short deadlines, then publish in stages. A sample that shows nothing relevant on day one does not settle the matter, so the log should record when each check was made and when the next one is due.

Why the vendor’s answers come slowly

Vendors in this position are rarely evasive for its own sake. Their forensic investigation is usually run through outside counsel, so that its findings can be protected by legal privilege. Courts have not always upheld that protection; in 2020 a federal court ordered Capital One to produce the forensic report on its 2019 breach. Vendors since then have tended to share conclusions in reviewed statements rather than hand over reports.

They also face hundreds of customers asking the same questions at once, an insurer that wants a say in what is admitted, and sometimes law enforcement requests to hold back details. A public vendor must also weigh what it tells investors. The result is a cadence of customer bulletins, each more specific than the last, rather than a quick answer to any one institution.

Institutions can work with that cadence instead of against it. A contract clause can require the vendor to confirm, within a set number of days, whether the customer’s tenant or data was affected, and to provide a written closing statement when the investigation ends. That closing letter is the document an examiner will want to see in the file.

72 hours, 36 hours, and a judgment call

The regimes have different triggers.

The NCUA’s rule turns on a reasonable belief that a reportable cyber incident occurred. Its definition includes disruption of business operations, vital member services or member information systems resulting from an attack on a third-party service provider. A credit union does not need to have been hacked itself; trouble at a vendor that affects its members can be enough.

The banking agencies’ rule turns on a determination that an incident has materially disrupted or degraded, or is reasonably likely to, the bank’s operations or ability to deliver services. That rule separately requires bank service providers to notify their bank customers when an incident disrupts or degrades covered services for four or more hours. So the rule obliges vendors to tell banks, as well as banks to tell regulators.

An attacker’s claim alone triggers none of them. A boast on a leak site is not, by itself, a reasonable belief that a reportable incident occurred.

That leaves room for judgment, which is exactly why the judgment needs a record. A credit union that decides a vendor incident is not reportable should be able to show what it knew, when, and why it concluded what it did. If a supervisor asks six months later, “Why didn’t you tell us?”, the answer should be a dated page in the incident log, not a recollection.

When uncertain, a short early notice to the supervisor, describing what is known and unknown, is usually cheaper than explaining a late one. When it adopted the rule, the NCUA described the 72-hour notice as an early alert that does not require a full incident assessment, and a follow-up can correct it.

Institutions should confirm their approach with counsel, because several institutions using the same vendor may reach different conclusions, and supervisors will compare them. If ten credit unions use the same software and three report while seven stay silent, the examiner’s next question to the silent seven is predictable.

Who was on which clock in November 2023

The regimes a vendor incident could trigger depended on each customer’s charter and business. For a vendor whose customers spanned banks, credit unions and mortgage lenders, the list was long.

• Federally insured credit unions. The NCUA rule, in force since September 1, 2023, requires notice as soon as possible and within 72 hours. NCUA guidance says the clock starts when a third party tells the credit union of a compromise, or when the credit union forms its own reasonable belief, whichever comes first.
• Banks. The interagency rule, with compliance required since May 1, 2022, requires notice to the primary federal regulator within 36 hours of determining that a notification incident has occurred.
• Institutions licensed in New York. The Department of Financial Services cybersecurity regulation carries its own 72-hour notice, amended on November 1, 2023. Its reach includes state-chartered banks and credit unions there.
• Non-bank lenders and mortgage brokers. The FTC’s amended Safeguards Rule, approved in October 2023 but not yet in effect, requires notice to the FTC within 30 days of discovering a breach involving 500 or more consumers.
• Public companies. The SEC’s Item 1.05 applies from December 18, 2023, with a filing due four business days after an incident is determined to be material.

The triggers are worded differently, and the wording matters. The banking rule runs from a determination, which implies some analysis. The NCUA rule runs from a reasonable belief, which can form earlier and on less information. The FTC rule turns on acquisition of unencrypted customer information. A holding company with a bank and a non-bank mortgage subsidiary could face two of these for the same vendor event, with different deadlines.

The rule that obliges vendors, and its gap

The banking rule also places a duty on the vendor. A bank service provider must tell its bank customers as soon as possible when an incident has materially disrupted, or is reasonably likely to disrupt, covered services for four or more hours. That duty is about outages. A theft of data that leaves systems running, as ALPHV described its MeridianLink intrusion, may never trigger it. Banks that want to hear about data theft promptly need a contract clause that says so, because the regulation alone will not deliver it.

What the first notice needs to contain

Early notices are short by design. The NCUA asks for the credit union’s name and charter number, a contact, when it formed its reasonable belief, and a basic description of what was affected. Its guidance tells credit unions to leave sensitive personal information, indicators of compromise and attachments out of the first report. Reports go by a dedicated phone line or secure email.

The same guidance tells credit unions to document every cyber incident, reportable or not, and describes that documentation as an audit trail for management’s reporting decisions. In effect, the regulator treats the decision record as part of compliance. An examiner reviewing a vendor event will look for the timestamps, the sources and the reasoning, alongside the report itself.

What members hear, and from whom

Members and customers may see the attacker’s claims in the press before the institution has facts. Silence invites calls to branches and the contact center, where staff have nothing to say. Nothing erodes trust faster than a teller who looks blank when a worried member asks, “Is my information safe?”

A holding statement, prepared in advance, can acknowledge that a technology provider has reported an incident, say the institution is assessing whether member information is affected, and describe how members will be told. It should not repeat the attacker’s claims or guess at scope. Repeating the claims gives them credibility; guessing at scope creates a promise that may later turn out to be wrong.

Formal notice is a separate question. It is governed by state breach notification laws, which generally turn on unauthorized acquisition of specified personal information, and by interagency guidance on response programs for customer information. Whether you must send letters depends on whether someone actually took particular kinds of personal data, not on whether there was an incident somewhere.

Contracts often let the vendor send notices on the institution’s behalf, which can help consistency but also means the institution’s name appears on a letter it did not write. Institutions should agree the content in advance, along with who pays for notices and credit monitoring.

Two further steps belong on the same day. Contact center scripts should be updated, so that frontline staff can give a calm, accurate answer. And fraud teams should watch for phishing that uses the incident as a pretext, because attackers and opportunists often contact members claiming to be the institution. An email that says “Your account may have been affected by a recent breach; click here to verify your identity” is exactly the kind of message criminals send after a story like this breaks.

Fraud controls that move with the news

Stolen application data is dangerous for a specific reason. Names, addresses, dates of birth, Social Security numbers and income are the same facts many institutions use to verify a caller’s identity. Once a vendor incident is public, the fraud team should assume those answers may be in criminal hands and lean less on them.

Practical steps include extra verification for address, phone and email changes, closer review of new accounts and loan applications, and alerts on password resets that follow a call to the contact center. Members should hear, in the holding statement and on the website, that the institution will never ask them for passwords or one-time codes. These measures add friction for honest members, so they should be time-limited and reviewed once the facts are known.

Who must send the letters

Every state now has a breach notification law, and they differ in what counts as personal information, whether a risk-of-harm analysis can excuse notice, and whether the attorney general must also be told. Some set fixed deadlines as short as 30 days. Most also say that a company holding data on behalf of another must notify the data owner, which then notifies individuals. In a vendor incident, the institution usually carries the duty to members even though the breach happened elsewhere.

Federal guidance adds a layer for banks and credit unions. The interagency guidance on response programs, and the NCUA’s parallel guidance, expect an institution to notify customers when misuse of their information has occurred or is reasonably possible. Counsel will usually map each affected member’s state of residence against these rules before anything is mailed.

The cost of notice, and who carries it

Notification has a bill attached: forensic confirmation of exactly whose records were taken, a mail house, a call center and often credit monitoring. Vendor contracts frequently cap liability at a multiple of annual fees, sometimes with a higher cap for data breaches. For a small credit union with a modest contract, that cap may not cover a large mailing. Institutions should read these clauses before an incident, not after.

The institution’s own cyber insurance matters here too. Many policies cover notification costs but require prompt notice to the insurer and use of the insurer’s approved vendors. A credit union that hires its own mail house in a hurry may find part of the cost uncovered. The incident plan should name who calls the insurer, and when.

A credit union’s first three days

The three strands run side by side. Return to the credit union, and assume it prepared well.

Hour one. The member services manager forwards the news story to the security lead, who opens the incident log and records the time, the source and the claim. The vendor inventory shows the loan vendor holds application data, including Social Security numbers, in a dedicated tenant on its production platform. The security lead sends the vendor’s named security contact two written questions: was our tenant accessed, and was any of our data copied?

Hour four. The vendor replies that it has contained an incident and has no evidence of access to the production platform, but cannot yet rule anything out. The credit union’s own staff report nothing unusual on the integration or the vendor’s service accounts. Both facts go into the log. Communications posts the pre-written holding statement to the website and sends the script to branches and the contact center. The fraud team issues an internal alert about likely phishing.

Day two. The chief executive, chief risk officer, security lead and outside counsel meet for thirty minutes. The facts do not yet support a reasonable belief that a reportable incident occurred, but the picture is incomplete. They decide to send the NCUA a short early alert describing what is known and unknown, and record why.

Day three. The vendor confirms in writing that the credit union’s tenant was not accessed. The log is updated, a brief follow-up goes to the supervisor, and the holding statement is replaced with a short update. No member letters are needed, because there was no unauthorized acquisition of their personal information.

Nothing in that sequence is heroic. Each step relies on something decided weeks or months earlier: the inventory, the contract clause, the statement, the default approach to uncertain cases. An unprepared institution facing the same three days spends most of them discovering what it does not know. It then makes its regulatory decision under the pressure of a deadline rather than on the strength of a record.

The version where the news is worse

The three days above end well. A second version shows what the same preparation buys when the facts turn the other way.

Day five. The vendor reports that a file of loan applications from a set date range was copied from a reporting database. Some of the credit union’s members are in it. The log records the time of the notice. Because the NCUA clock can start on third-party notice, an updated report goes to the supervisor the same day.

Week two. Counsel maps affected members by state of residence and confirms which laws apply. The insurer is notified and its approved vendors engaged. The holding statement is replaced with a factual notice that says what was taken and what the credit union is doing about it.

Weeks three to six. Letters go out, with credit monitoring and a dedicated phone line. The fraud team tightens checks on new loan and account applications, because stolen application data is well suited to identity fraud. Branch scripts change again. The board receives a short report with the incident log attached.

The second version requires no new decisions about process. The work is harder and more expensive, but the institution is executing a plan rather than writing one.

Decided weeks before the news breaks

Every one of these steps can be prepared now for every critical provider, without waiting on the vendor. The preparation starts with a vendor list that says what data each holds and where, and contracts that name a security contact and give a right to answers. It adds a pre-written holding statement and script, a template incident log, and an agreed position with counsel on how to approach uncertain cases.

The failures are predictable. Institutions wait for the vendor to explain, though the vendor has its own lawyers, its own regulator, its own deadlines and its own priorities. They treat the attacker’s claim as gospel or as noise, when it is one biased source among four. They let the clock run without a decision; deciding not to report is a legitimate choice, but failing to decide is not. They forget the front line, where branch and contact center staff hear about incidents from members first and need words to use. And they let a vendor send breach letters in their name without agreeing the content in advance, which can leave the institution apologizing for words it never approved.

The cost argument is straightforward. The preparation is a few days of work per critical vendor. The alternative is regulatory criticism for a late or inconsistent report, member complaints and possible attrition, and fraud losses from phishing that a timely warning might have blunted.

Owners, and the evidence they keep

Each piece of preparation needs a named owner. Vendor management owns the inventory and the contract clauses. The security lead owns the incident log and the technical checks. Compliance owns the regulatory decision and its record, with counsel. Communications owns the holding statement, and member services owns the scripts. The chief executive owns the decision to send an early notice when the facts are thin.

Examiners tend to ask for the same evidence after any vendor event. They look for a vendor inventory that classifies data and contract terms covering incident notice. They want a record of when the institution learned of the incident and from whom, the reasoning behind each notification decision, and board reporting. Records of a tabletop exercise built around a vendor incident also carry weight, because they show the plan was tested.

Small institutions, large institutions

Scale changes the approach without changing the steps. A credit union with a few dozen staff may have no full-time security lead. It can rely on a managed security provider, a credit union service organization or its league for templates and monitoring. The decision record still has to be its own.

A larger bank will have a formal third-party risk program, shaped by the interagency guidance the banking agencies finalized in June 2023. Its challenge is volume: hundreds of vendors, many with access to customer data. It needs tiering, so that the full preparation goes to the vendors whose failure would matter most.

The case against, and why it still holds

Three objections come up. The first is that small institutions lack the bargaining power to win contract clauses from large vendors. One by one, that is often so. User groups, leagues and service organizations can negotiate standard terms for many members at once, and regulators’ published expectations give even a small buyer a reason to ask.

The second is that early notices on thin facts will flood supervisors with noise. The NCUA built its rule around early reporting and asks credit unions that are unsure to contact it. Supervisors would rather triage a short note than discover a silent institution later.

The third is that attacker claims are mostly noise, and responding to each one wastes effort. A data map answers that objection. It lets a team set aside a claim about a vendor that holds nothing sensitive within minutes, and spend its time on the vendors that do.

Rehearsing it in ninety minutes

The cheapest test of all this is a short tabletop exercise. The scenario writes itself: a news story names a vendor, the vendor says little, and a regulatory clock may be running. Injects can add a reporter’s call, a member complaint on social media and a vendor bulletin that contradicts the first. The exercise should end with a written decision on whether to notify the supervisor, made by the people who would make it for real. Gaps found in that room cost far less than gaps found on the day. A second run a year later shows whether they were closed.

If a gang names our vendor tomorrow

• For each of our critical vendors, do we know what member or customer data they hold, and in which environment?
• Who would we call at the vendor, is that person a security contact or a salesperson, and do our contracts give us a right to an answer about our own data?
• Which of our regulatory clocks could a vendor incident start, and how many hours do we have?
• When we are unsure whether to report, what is our default, and has counsel agreed it?
• Can a vendor send breach notices in our name, and have we agreed what they will say and who pays?

The attacker in this case aimed its complaint at a public company. Its smaller customers felt the pressure on clocks the attacker never mentioned. The institutions that coped best were the ones that had already decided how they would answer.

With hindsight

Reporting a victim to a regulator did not become a common extortion tactic, and attacker complaints did not change the legal triggers for disclosure. The SEC’s Item 1.05 requirement, the part of the new rule that obliges public companies to report material cyber incidents, took effect on December 18, 2023 as scheduled. ALPHV’s publicity stunt turned out to be a curiosity rather than a new norm.

SEC staff later addressed the gap the gang had tried to exploit. In May 2024, Erik Gerding, director of the Division of Corporation Finance, said in a statement that Item 1.05 should be used for incidents a company has determined to be material. Companies wanting to disclose other incidents, including those still being assessed, were pointed to Item 8.01 instead. Disclosure under the rule follows the company’s own materiality judgment, whatever an attacker claims.

The group itself did not last long. ALPHV was disrupted by the FBI that month and collapsed in early 2024 after the Change Healthcare attack. The collapse appeared to be an exit scam against its own affiliates, the partner criminals who carried out its attacks. Ransomware brands come and go, while the methods, and the people using them, tend to resurface under new names.

The details of ALPHV’s end were telling. The FBI’s December 2023 operation included decryption help for victims, and the group resumed operations almost at once. In early March 2024, a wallet linked to ALPHV received roughly $22 million in bitcoin, which an affiliate said was Change Healthcare’s ransom. The administrators then shut down, posting a law enforcement seizure notice that researchers judged to be fake.

The underlying risk, trouble at a shared technology provider, arrived again almost immediately. Within weeks, a ransomware attack on a cloud services unit of Trellance, a technology provider to credit unions, caused outages at about 60 credit unions. The NCUA said it was coordinating with those affected. The agency said the attack came through FedComp, a third-party vendor that used Trellance software: a chain of vendors with credit unions at the far end. That episode showed the same pattern from a different angle: dozens of institutions, each with its own clock and its own members to reassure, all dependent on facts coming from one vendor.

The rules for vendor incidents in financial services tightened. The FTC’s Safeguards Rule amendment took effect in May 2024. That same month the SEC adopted amendments to Regulation S-P for broker-dealers, investment advisers, investment companies and transfer agents. They require notice to affected individuals within 30 days, and require firms to make sure service providers report a breach to them within 72 hours. Compliance began in late 2025 for larger firms and in 2026 for smaller ones.

Notification regimes kept multiplying. CISA proposed its critical infrastructure incident reporting rule under CIRCIA in April 2024. Funding lapses slowed the work, CISA held further town halls in June 2026, and as we write the final rule has still not been issued. For a financial institution, that means more clocks, different triggers and more supervisors who may compare notes.

What held up best was the distinction between a claim and a determination. Every regime that followed kept its trigger tied to what the regulated institution knew or reasonably believed, not to what an attacker posted. What held up less well was the hope that contract terms alone would produce fast answers. The Trellance episode showed that even willing vendors may spend days fighting their own fires before they can say much to anyone.

The preparation described here, a vendor data map, a contractual right to answers and a holding statement, applies to each new regime as it arrives. It does not need to be rebuilt each time a rule changes. An institution that knows what its vendors hold, can get straight answers from them and has words ready for its members is in a strong position. That holds whatever the next rule says, whenever it finally arrives, and whoever the next attacker turns out to be.