Pinnacle Financial Partners, Inc. has disclosed a data breach involving Mercadien, P.C., CPAs, a third-party accounting firm that provided advisory services to Pinnacle. The disclosure was filed with state regulators including the Massachusetts Attorney General and reported in the week of 20 July 2026.

The timeline is the story:

  • 17 September – 9 October 2025: an unauthorized party accessed and acquired data from Mercadien’s network.
  • 16 June 2026: Pinnacle determines that information belonging to some of its clients was included in the affected data.
  • July 2026: Pinnacle notifies affected individuals.

The potentially exposed data is extensive: names, dates of birth, addresses, Social Security numbers, Individual Taxpayer Identification Numbers, financial account numbers, and government-issued identification numbers including driver’s licence and passport numbers. Affected individuals are being offered 24 months of complimentary credit monitoring and identity protection through Experian IdentityWorks. Reporting on the underlying Mercadien incident indicates it affected in excess of 400,000 people across the firm’s client base.

Roughly nine months elapsed between the intrusion and Pinnacle’s determination that its clients were implicated. Understanding why that happens — and it happens constantly — is more useful than criticising it.

The identification lag is structural, not negligent

The sequence in a fourth-party exposure runs like this. The vendor is breached and does not immediately know what was taken. The vendor completes forensics and determines the volume and general character of exfiltrated data. The vendor then performs document review to identify individuals. Only after that can the vendor tell each of its own clients which of that client’s data was involved. The client — here, Pinnacle — then has to match those identities against its own customer records to determine its notification population and the applicable state statutes.

Each handoff adds weeks. Some are unavoidable. Most are longer than they need to be, for three reasons that are entirely within a financial institution’s control to change:

The contract does not specify a timeline for the identification phase. Vendor agreements routinely require notification of a security incident within a defined period. They almost never require the vendor to complete client-specific data identification within a defined period. The result is that the clock that matters most is the one nobody contracted for.

The institution has no visibility into progress. Pinnacle would have known there was a Mercadien incident well before June 2026 — the incident was public. What it lacked, presumably for months, was confirmation of whether its own clients were in scope. Contracts should require periodic written status on the identification workstream, not a single terminal notification.

The institution does not know what the vendor holds. If Pinnacle had maintained a current record of exactly which client data sets had been provided to Mercadien, for which engagements, in which periods, it could have begun its own risk assessment and customer-protection measures in October 2025 rather than June 2026 — without waiting for the vendor’s list. This is the highest-leverage fix available and it is a data governance task, not a security one.

The obligations a bank actually carries here

GLBA and the Interagency Guidelines

Pinnacle Bank is a depository institution, which places it under the Gramm-Leach-Bliley Act § 501(b) and the banking agencies’ Interagency Guidelines Establishing Information Security Standards (12 CFR Part 30 Appendix B for OCC-supervised institutions, with parallel provisions for Federal Reserve and FDIC supervision).

Two components govern this fact pattern directly.

Service provider oversight. The Guidelines require an institution to exercise appropriate due diligence in selecting service providers, to require them by contract to implement appropriate measures designed to meet the objectives of the Guidelines, and — where indicated by the institution’s risk assessment — to monitor its service providers to confirm that they have satisfied their obligations. That monitoring obligation is where most programmes are thin. Collecting a SOC 2 Type II report annually is due diligence. It is not monitoring.

The Interagency Guidance on Response Programs (the § 501(b) response program guidance) requires an institution to develop and implement a response programme addressing unauthorized access to sensitive customer information, including procedures to assess the nature and scope of an incident, notify its primary federal regulator as soon as possible when the institution becomes aware of an incident involving unauthorized access to or use of sensitive customer information, and notify affected customers when misuse of their information has occurred or is reasonably possible. Critically, the guidance states expressly that these obligations extend to sensitive customer information maintained by a service provider on the institution’s behalf.

The regulator-notification trigger is therefore “becomes aware of an incident involving unauthorized access to sensitive customer information” — and a bank that knows its accounting firm was breached, and knows it gave that firm customer data, has arguably become aware of such an incident well before the vendor produces a name list.

The 36-hour computer-security incident notification rule

Since May 2022, 12 CFR §§ 53.3, 225.303, and 304.23 require a banking organization to notify its primary federal regulator as soon as possible and no later than 36 hours after determining that a notification incident has occurred — defined as a computer-security incident that has materially disrupted or degraded, or is reasonably likely to do so, the organization’s operations, its lines of business, or the delivery of banking services, or that poses a threat to US financial stability.

A vendor data theft that does not disrupt operations may well fall outside the 36-hour rule’s definition. That is a legal determination requiring documentation, not an assumption. The same rule separately obligates bank service providers to notify affected banking organization customers of computer-security incidents that have materially disrupted or degraded, or are reasonably likely to disrupt or degrade, covered services for four or more hours — an obligation whose scope, again, turns on service disruption rather than data theft.

FTC Safeguards Rule — on the vendor’s side

Mercadien, as a firm providing tax and accounting services, is a financial institution under the FTC Safeguards Rule (16 CFR Part 314). Its obligations include a written information security programme with a designated qualified individual, written risk assessment, encryption of customer information at rest and in transit, MFA for any individual accessing information systems, service provider oversight, an incident response plan, and — under the 2023 amendment — notification to the FTC within 30 days of discovering a security event involving the unencrypted information of 500 or more consumers.

That the exposed data includes unencrypted-appearing SSNs, ITINs, and account numbers for a population in the hundreds of thousands makes the FTC notification obligation squarely applicable to the accounting firm.

State notification law

The field list here triggers notification in every US state, and the presence of financial account numbers and passport numbers expands the trigger under statutes that define those categories separately. Several states impose 30- or 45-day deadlines from determination. Pinnacle’s June determination followed by July notification is consistent with those; the vendor’s own timeline is the one that will attract scrutiny.

The fourth-party gap

Most bank third-party risk programmes are built around vendors that touch systems: core processors, digital banking providers, payment networks, cloud infrastructure. These receive rigorous due diligence, contractual security schedules, right-to-audit provisions, business continuity requirements, and continuous monitoring.

Professional services firms are governed by a different process, or by none. An accounting firm, a law firm, a consultancy, an executive search firm, or a benefits broker is engaged by a business unit, contracted through a professional services agreement drafted by procurement or legal, and never enters the third-party risk inventory — because it does not connect to a system. It merely receives files.

The data risk is identical or worse. A core processor’s access is scoped, logged, and monitored. An accounting firm receives a spreadsheet by email, stores it on a file share, and retains it for the duration of its own records policy, entirely outside the bank’s visibility.

The Interagency Guidance on Third-Party Relationships: Risk Management, issued jointly by the OCC, Federal Reserve, and FDIC in June 2023, is explicit that the framework applies to business arrangements, not merely to technology vendors, and that the level of due diligence should be commensurate with risk rather than with vendor category. A professional services firm receiving customer SSNs and account numbers is a high-risk relationship by any risk-based reading.

This is the same failure mode documented in Citizens and Frost Bank’s Everest ransomware vendor exposure and, in a non-banking setting, in EY’s support-ticket breach disclosed the same month.

What to do in the next 60 days

Inventory by data flow, not by system connection. Ask every business unit which external parties have received files containing customer personal or financial information in the past 24 months. Expect the answer to include relationships absent from your vendor register. Those are your unmanaged exposures.

Add identification-phase obligations to contracts. Specify: security incident notification in hours; a written status update on client-data identification at defined intervals; a maximum period for completing client-specific identification; and an obligation to preserve and provide the forensic record.

Reduce what leaves. For each professional services engagement, ask whether the firm needs identified data at all. Tokenised, masked, or aggregated data satisfies a great many advisory engagements. Where identified data is genuinely required, transmit it through a controlled channel with expiry rather than by email attachment.

Impose and verify deletion. Contractual deletion at engagement close, with written certification. The Mercadien intrusion window was three weeks in autumn 2025; the data taken had been accumulating for however long the firm’s retention policy permitted.

Pre-position the notification machinery. Know in advance which regulator you notify, under which rule, on which trigger, and who makes the determination. The 36-hour rule, the § 501(b) response guidance, and 50 state statutes have different triggers and different clocks. Deciding which apply during an incident wastes the days you have least of.

Conclusion

Pinnacle Financial did not suffer a breach of its own systems. It suffered the consequences of having provided identified customer data — Social Security numbers, taxpayer identification numbers, account numbers, passport numbers — to an accounting firm, and of having no independent means of knowing, for nine months, whether that data had been stolen.

The regulatory frameworks that apply to banks have said for two decades that outsourcing an activity does not outsource the responsibility. What this incident illustrates is a narrower and more actionable point: an institution that cannot answer what customer data does this vendor hold right now has, by that fact alone, surrendered control of its own breach response timeline to a third party’s document review schedule.

That question is answerable today, at low cost, for every vendor relationship in the book. It becomes unanswerable at exactly the moment it matters.

This article is provided for informational purposes only and does not constitute legal advice.