The Breach May Not Start With You — But Your Client Will Still Call You
A firm can do many things right and still find itself exposed.
You may have MFA. You may have endpoint protection. You may have backups. You may have an IT provider or an internal IT person who is generally competent. You may never have had a direct breach inside your own network.
And still, client data can move through a vendor, portal, SaaS platform, integration, CRM, payroll system, document-sharing tool, AI tool, or related party that your firm depends on every day.
That is the uncomfortable reality: your firm does not operate on an island. Your client-data risk lives inside an ecosystem.
Client data rarely stays inside one clean boundary.
The question is no longer only, “Are we protected?”
The better question is, “Can we show that client-data protection is being actively managed across the places where client data actually lives, moves, and gets accessed?”
That is a different standard.
Internal security is necessary. It is not the full picture.
Many firm leaders still think about cybersecurity as something inside the firm’s walls: laptops, email, firewall, backups, passwords, endpoint protection, and support tickets.
Those things matter. Ignoring them would be irresponsible.
But professional service firms now depend on a web of outside systems. A CPA or advisory firm may have client data moving through tax software, portals, e-signature tools, payroll platforms, CAS systems, outsourced bookkeeping workflows, CRM notes, email marketing platforms, cloud storage, outsourced IT tools, and vendor integrations.
Some of those systems may hold the actual client documents. Others may hold metadata, notes, contact records, billing details, opportunity notes, access tokens, or communications that become useful to an attacker.
That distinction matters. A vendor breach does not always mean your core systems were breached. It may not mean passwords were taken. It may not mean payment information was exposed.
But it can still create a business problem.
If a vendor-connected system leaks client names, business contacts, project notes, communication history, or details about services used, your clients may still ask: “What happened, what was exposed, and what are you doing about it?”
That question lands on your firm, not only on the vendor.
The real issue is not blame. It is defensibility.
When a vendor is breached, leadership usually wants a clean answer:
Were we affected?
What data was involved?
Who had access?
Was MFA enforced?
Were permissions appropriate?
Was the integration still needed?
Was there logging?
Was there a contract or security review?
Who owns the decision now?
The problem is that many firms cannot answer those questions quickly because the evidence is scattered. Some sits with IT. Some sits with the vendor. Some sits in SaaS admin portals. Some sits in email. Some is in someone’s memory. Some does not exist.
That is where confidence breaks down.
Not because no one cared. Not because the firm was careless. But because the firm never built a consistent way to review vendor-connected risk as part of its client-data protection posture.
A recent Huntress write-up about the Klue breach is a useful example of this broader pattern. Huntress described a third-party platform incident where Salesforce-related business data was impacted for multiple victims, while also stating that Huntress products, infrastructure, telemetry, passwords, and payment card data were not impacted based on current evidence.
That is the point: even when the most sensitive technical systems are not affected, a vendor-connected breach can still create a client communication, evidence, and governance issue.
A vendor breach may not compromise your network, but it can still create an evidence and trust problem.
Frameworks already point in this direction.
This is not just a cybersecurity vendor opinion.
The FTC Safeguards Rule requires covered financial institutions to maintain a written information security program designed to protect customer information. It includes risk assessment, access controls, periodic review, evaluation of apps, and service-provider responsibility. {16 CFR Part 314, Standards for Safeguarding Customer Information}
NIST Cybersecurity Framework 2.0 also treats cybersecurity as an enterprise risk issue, not merely a tool issue. Its Govern function includes cybersecurity supply chain risk management, roles, responsibilities, policy, and oversight.
NIST’s supply chain risk guidance is even more direct: technology depends on a complex, interconnected ecosystem of suppliers, service providers, partners, and digital platforms. The risk has to be identified, assessed, managed, monitored, and improved over time.
For a 50- to 200-person accounting, CAS, or advisory firm, this matters because the firm may be large enough to have meaningful client-data exposure but not large enough to have a mature third-party risk program.
That gap is common.
The practical test for leadership
This does not mean your firm should stop using vendors. That would be unrealistic and probably damaging to the business.
It means leadership should stop treating vendor-connected risk as an occasional questionnaire exercise.
Start with a simple test:
Can your firm list the vendors and platforms that touch confidential client data?
Can you identify which integrations have access to email, files, CRM, portals, accounting systems, payroll data, or client records?
Can you show which users or vendors have administrative access?
Can you prove MFA is enforced where it matters?
Can you show who reviews vendor access after employee turnover, system changes, or vendor changes?
Can you produce evidence within 48 hours if a client, insurer, or attorney asks what controls were in place?
If the answer is unclear, that does not automatically mean your firm is unsafe.
It means leadership may not yet have a clear evidence record.
That distinction matters. A firm can have good tools, responsible people, and capable vendors — and still be unable to show what is working, what is missing, what has been accepted, and who owns the next decision.
That is the gap Cyber Defensibility is designed to surface.
What Cyber Defensibility changes
Cyber Defensibility is not about pretending every breach can be prevented. It is not a certificate. It is not a promise that no vendor will fail.
It also does not mean every vendor, platform, and data path has already been fully mapped.
The point is narrower — and more practical.
A vendor breach is a reminder that leadership needs more than general confidence. It needs a repeatable way to ask: where do we have evidence, where are we assuming, where are the known exceptions, and who owns the next decision?
That is where Cyber Defensibility changes the conversation.
Instead of treating cybersecurity as a set of tools installed somewhere in the background, Cyber Defensibility gives leadership a structured view of the controls that can be observed, verified, monitored, and reviewed over time.
The goal is to help the firm see:
- Which key controls are working
- What evidence exists
- Where evidence is missing
- What exceptions have been accepted
- Which risks require follow-up
- Who owns the next decision
That does not make vendor risk disappear.
But it does reduce the larger leadership problem: operating on assumption when clients, insurers, regulators, or a breach event may demand evidence.
A firm may still need a deeper vendor inventory, data mapping exercise, legal review, or third-party risk process. But without a basic discipline around control evidence, exceptions, and ownership, even those efforts become harder to manage.
Cyber Defensibility is the operating discipline that helps leadership move from “we think this is handled” to “we know what we can prove, what we cannot prove, and what needs a decision.”
The next step is not panic. It is a self-check.
A vendor breach is a reminder that client-data protection is no longer limited to your own devices and network. Your firm’s trust boundary now includes the vendors, platforms, integrations, and related parties that help you serve clients.
That does not make the problem hopeless.
It makes the problem managerial.
You need a way to see the exposure, verify the controls, document the evidence, and decide what to improve, accept, or revisit.
Start with the quick self-check
If the self-check raises questions, the next step is a Cyber Defensibility Review. The goal is not to sit through a generic IT sales pitch. The goal is to understand whether your firm has a control gap, evidence gap, or ownership gap around client-data protection.
