How Small Business Breaches Actually Start: The Root Causes That Keep Repeating

Read enough breach coverage and you start to notice that the stories are never really about the company in the headline. Different industry, different size, different month, and underneath it the same small set of failures.

This article is about that set. Not what happened last quarter, which will be stale by the time you read it, but the entry points that have stayed on the list year after year and show no sign of leaving. If you want a single incident examined in depth, the MGM Resorts breach is that article. This one is the pattern behind the incidents.

Why the same causes keep winning

Attackers are economically rational. They reuse what works, and what works is whatever is cheapest to exploit across the largest number of targets. A technique stays in circulation as long as enough businesses remain vulnerable to it, which means the persistence of these root causes is a statement about defenders, not about attacker sophistication.

Nearly every one of them is also structural rather than technical. Something was never finished, never owned by anyone in particular, or was reasonable at the size the business used to be and was never revisited. That is why they repeat, and why a new product rarely closes them.

Root cause 1: a password is still enough to get in somewhere

Credentials are the most durable entry point on this list, because they do not require an exploit. Whoever holds them is authorized by definition.

They reach an attacker in ordinary ways: reused on a service that was itself breached, phished, sitting in a password manager on a compromised home machine, or guessed because the pattern was predictable. Buying working credentials is an established market, which means the gap between a leaked password and someone using it against you is not a period of obscurity you can rely on.

The defense is well understood and still incompletely deployed. Multi-factor authentication is not the problem. The gaps are. Almost every business I look at has enabled it broadly and left exceptions behind: the legacy protocol that cannot support it, the shared mailbox nobody owns, the service account created for an integration in 2019, the VPN or remote desktop endpoint that predates the rollout, the contractor account nobody revisited. Attackers do not test the covered doors.

Worth separating clearly: knowing that enforcement should be universal is easy, and knowing where your actual exceptions are is the real work. That inventory question is the one to ask.

Root cause 2: someone was convinced, not hacked

Social engineering endures because it targets the part of the system that cannot be patched and is explicitly rewarded for being helpful.

The forms rotate. Invoice and payment-change fraud, where a real vendor relationship is hijacked and banking details are quietly altered. Executive impersonation, where urgency and authority substitute for verification. Multi-factor fatigue, where a user approves a prompt on the tenth attempt just to stop the buzzing. Helpdesk impersonation, where the attacker calls support and asks for a reset with enough context to sound like an employee - which is now among the most reliable methods there is, because it bypasses the technical controls entirely by asking a human to bypass them.

The countermeasure is procedural and costs nothing but discipline. Any request that moves money, changes payment details, or resets access gets verified out of band, through a channel and a contact you already had, never one supplied in the request. Write it down, apply it to the owner as strictly as to everyone else, and make refusing to bypass it a thing people get praised for. The mechanics of impersonation are worth understanding in more detail.

Root cause 3: something internet-facing was never patched or never inventoried

Anything reachable from the internet is scanned continuously, by everybody, forever. That includes the things you forgot you had.

Two versions of this failure. The first is a known vulnerability in a VPN appliance, firewall, remote access gateway, or web application that had a patch available and did not get it. The gap between a public exploit and mass scanning is short, and edge devices are frequently outside whatever patching discipline covers laptops and servers.

The second is worse, because it is invisible: an exposed service nobody remembers. Remote desktop opened temporarily during an office move. A test server from a project that ended. A management interface exposed by a default configuration. Firewall rules accumulated over years by different providers with no record of why. You cannot patch an asset you do not know you own, and the asset inventory is the least glamorous and most load-bearing document in security.

CISA's Known Exploited Vulnerabilities catalog is the pragmatic patching priority list - it is a record of what is actually being exploited rather than a theoretical severity ranking.

Root cause 4: a vendor's access became your breach

Most businesses have quietly granted standing administrative access to a set of third parties: an IT provider, a software vendor's support team, a bookkeeper, a marketing agency in the CRM, an integration authorized years ago that still holds a token.

Two distinct exposures come from this. Their compromise becomes your compromise, because the access they hold is real. And their outage becomes your outage, which is the same conversation with a different ending.

The pattern that repeats is standing access that is broader and older than the work requires - full administrative rights where read access or scoped rights would do, accounts that outlive the engagement, tokens with no expiry and no review. Nobody grants that deliberately. It accumulates, because revoking access is somebody's job only if it has been made somebody's job.

If you use cloud platforms, the shared responsibility boundary is part of this same category, and it is consistently misread in the customer's disfavor.

Root cause 5: nobody was watching, so it ran for weeks

This one does not cause breaches. It converts small ones into large ones, which makes it the most expensive item on the list.

The failure is not usually an absence of logs. It is that nothing reads them, alerts go to a mailbox nobody monitors, coverage stops at five o'clock, or retention is shorter than the intrusion. Intrusions get discovered by a bank, a customer, a law enforcement notification, or a ransom note far more often than anyone is comfortable admitting.

Two questions separate businesses that catch things from businesses that do not. Who looks, at two in the morning on a Saturday? And how far back can we actually see? Both have specific answers, and how long an intruder operates before anyone notices is exactly the window those answers govern.

Root cause 6: the recovery plan had never been tested

Every business believes it has backups. Considerably fewer have restored from them under pressure, at full scale, recently.

The recurring discoveries are consistent: the backup silently stopped months ago; it covers the file server but not the cloud mail or the line-of-business SaaS; it can be deleted using the same administrative credentials as everything else, which makes it a target rather than a safeguard; or it works but takes so long that the business cannot survive the restoration window. The last one is the cruelest, because technically nothing failed.

The related failure is the plan itself. When the phone rings, who decides to shut things down, who calls the insurer, who talks to customers, who is authorized to spend money at midnight. If that is not written and rehearsed, the first hours go to improvisation, which is when the expensive mistakes happen. A tabletop exercise surfaces all of it in an afternoon.

Root cause 7: nobody owns security, so it is nobody's fault

This is the root cause under the root causes, and it is the one most specific to small and mid-sized businesses.

Below a certain size there is no security function. There is an IT provider handling operations, an office manager holding some administrative credentials, a founder making the final call on spend, and an assumption on all sides that someone else is tracking the exceptions, the vendor access, the retention window, and the untested restore.

Every item on this list is somebody's job in a large organization. In a business of thirty people they are nobody's job by default, and default is where they stay. Assigning ownership - even part-time, even external - is what converts a list of good intentions into things that actually get closed. That is the entire premise of fractional security leadership, and the reason the role exists at all.

What this means for where you spend

The uncomfortable pattern in this list is that almost nothing on it is exotic, and almost nothing on it is solved by buying a product. Universal multi-factor coverage with no exceptions. A verification rule for money and access. A known inventory of what is exposed and a patching cadence that includes it. Vendor access that is scoped and reviewed. Someone watching, with logs that reach back. A restore you have actually performed. One named owner.

That list has barely changed in years, and I do not expect it to change much in the next few. A business that genuinely closes those seven is not immune, but it stops being the cheapest target in the room - and most of this activity goes wherever cheap is.