If you’re asking why do companies get breached when they already have a firewall, antivirus, and someone watching IT, you’re asking the right question. This article walks through the four specific gaps we find most often when we go in after a company that thought it was covered: tools that were never fully configured, access that was never revoked, backups that were never tested, and one person trying to run IT and security at the same time. If you run a small or mid-sized company and no one has ever independently checked your setup, this is for you, and the honest answer is less scary than you’d think.
In August 2019, Regis University in Denver got hit with a ransomware attack right as students were arriving for fall semester. It took down phones, email, Wi-Fi, and the website. The university paid the ransom, but systems still weren’t fully restored. Recovery dragged on for months. None of that happened because the school didn’t care about security. It happened because their backups had never actually been tested. Nobody checked.
My VP, Chris Brown, has a line he uses for this: a lot of organizations, particularly in our market, think they’re too small and that nobody cares about them. But the reality is attackers are looking for easy, low-hanging fruit. That’s the real problem. It’s not that your tools are bad. It’s the space between believing you’re protected and actually testing whether you are.
THE SHORT ANSWER
Most breaches don’t happen because a company ignored security. They happen because a tool was misconfigured, an old login was never shut off, or a backup was never tested. An unvalidated security program isn’t a security program. It’s a guess.
The Honest Answer: Why Companies Get Breached Even When They Have Security Tools in Place
Here’s what we see constantly, and it’s rarely dramatic. Companies will have plenty of tool sets deployed, but they’re not actually in production, or they’re not configured correctly. There’s a tool sitting there. It’s just not doing what everyone assumes it’s doing.
We also find, just as often, that the policies and procedures on paper don’t match the technology that’s actually running. Someone wrote the policy two years ago. The environment moved on since then. Now there’s conflicting information sitting in the documentation, and nobody’s caught it, because nobody’s officially the one checking. If you’ve ever gone through a SOC 2 audit, this is exactly the kind of mismatch that gets flagged, policies that say one thing while the systems do another.
None of this means the company was careless. If you bought the firewall, ran the antivirus, and put someone in charge of IT, you did the reasonable thing. When security tools aren’t stopping breaches, it’s almost never because the tools themselves are bad. The problem is that the effort was never validated. Getting breached despite real security investment happens more than people want to admit, and it’s rarely because the investment was wrong. It’s because nobody went back and checked whether it was actually working.
| Gap | What the company believes | What we typically find |
|---|---|---|
| Security tools | Tools are deployed and working | Tools deployed but misconfigured or not in production |
| Access control | Permissions are managed | Terminated employee credentials still active |
| Backups | Backups run automatically | Backup process never tested, no valid recovery point |
| Security oversight | IT lead handles it | IT lead is half-assing two things, security always loses |
What Does a False Sense of Security Actually Look Like?
There are four patterns that show up again and again. If you recognize your company in more than one of them, that’s useful information, not a reason to panic.
Gap 1: Tools That Are Deployed but Not Running Correctly
This is the most common one. A tool gets licensed, installed, and then forgotten. It’s still technically there, throwing alerts that nobody’s reviewing, or it was never fully turned on to begin with. On paper, you have the tool. In practice, you have a line item on an invoice.
Gap 2: Access Controls That Were Never Actually Enforced
We find this in almost every termination review we run: someone leaves the company, and their login still works. Not because anyone forgot on purpose, it’s a step nobody owns. Six months later, that access is still sitting there, and it’s one of the easiest ways into an environment.
Gap 3: Backups That Were Never Tested
This is the gap that took down Regis. The rule we give clients is simple: three backups. One active, so you can reboot immediately if something happens. One offline. One offsite and offline, so a fire or a flood doesn’t take out your backup along with everything else. Most companies think they have this covered. Most companies have never actually tested it. Regis didn’t know their backups weren’t backing anything up until the day they needed them, and by then, rebuilding from scratch was the only option left.
Gap 4: An IT Team Wearing Too Many Hats
“If you’re half-assing two things, you don’t have time to whole-ass anything.” (Chris Brown, VP, Commercial Services)
This isn’t a knock on IT leads. It’s math. One person can’t run daily IT operations and a security program at full attention at the same time. Something gets deprioritized, and it’s usually security, because nothing bad has happened yet.
Curious what we actually look for when we review a company’s security posture? Read: Why Automated Scanning Isn’t Enough: What Real Pen Testing Actually Finds
Is It Possible for Companies to Do Everything Right and Still Get Breached?
Yes. I’ll say that plainly, because anything else would be dishonest.
“Anybody who makes a guarantee like that, that’s a charlatan and run for the hills. The internet is inherently a dangerous place.” (Chris Brown, VP, Commercial Services)
We don’t sell certainty, because certainty isn’t real. What changes with a validated posture isn’t whether something can happen. It’s what happens next. Regis didn’t lose four months because it got attacked. It lost four months because nobody had tested whether it could recover. A company with tested backups, enforced access, and validated tools can still get hit. The difference is it’s back up in days, not months.
What Does It Actually Take to Know Your Security Is Working?
Two things, and neither one is buying another tool.
The first is manual testing, done by an actual person, not a scanner. One of our security analysts, Angelina House, put it well: it’s the tiny things that get missed, an unsecured printer sitting on its own network, one line in an HTML script that lets someone slip past a login, fuzzing their way through the small stuff. Those are cybersecurity blind spots no scanner is built to find. They only show up when a person is actually looking for them.
“It can be tiny things of like not securing printers on their own separate network. It can be tiny things of like tiny little literal lines in like an HTML script that can get us through logins, fuzzing, things like that. It’s the small things that you wouldn’t exactly think about.” (Angelina House, Security Analyst)
The second is an outside perspective. It’s hard to see your own gaps when you’re inside them every day. Having someone else look at what you’ve built, and where you could be exposed, is really just about looking at your own environment from a different angle than the one you’re stuck in. That’s not a knock on your team. It’s just how blind spots work. You can’t spot every one of your own.
If you don’t actually know whether your tools, your access controls, and your backups are validated, that’s exactly the gap a third-party pen test exists to close. We spend about a week on OSINT, seeing what’s publicly findable about your organization, and then about a week actually trying to get in, the same way an attacker would. You get a report of what we found, what it means, and how to fix it. Then we retest to confirm it’s actually fixed.
If You’re Ready to Find Out Where You Actually Stand
You don’t need to fix every gap in your security posture at once. Start with whichever one of these actually describes you.
- If you’ve never had a third-party security review, start there. It’s not an accusation. It’s the only way to know what’s actually running versus what you believe is running.
- If you have tools in place but have never validated them, a security maturity review will tell you which ones are configured correctly and which ones are effectively off.
- If you have someone handling both IT and security, that’s not a people problem, it’s a structural one. A fractional CISO takes on the security program so your IT lead can stop half-assing two things.
- If you’ve been breached before, that’s not something to be embarrassed about. It’s a reason to make sure the gaps that let it happen are actually closed, not just assumed to be.
A top-tier CISO costs between $350,000 and $600,000 a year. PSS CaaS averages $108,000. But cost is only part of the story. Here’s the honest comparison — what each model actually delivers, when a vCISO is the better call, and the specific situations where hiring full-time is genuinely worth it. Read this article to know if a vCISO is Actually as Good as a Full-Time CISO.
Frequently Asked Questions About Getting Breached Despite Security Investments
Because having tools and using them correctly are two different things. Misconfigured software, unreviewed alerts, and access that was never revoked give an attacker the same opening as having no tools at all. Having a tool installed isn’t the same as having protection.
Yes. A firewall blocks known traffic patterns. Antivirus catches known signatures. Neither one thinks like an attacker, and neither one catches what’s specifically wrong with your environment. They’re a floor, not a ceiling.
The four we see most: tools that are installed but not actually configured correctly, access that was never shut off after someone left, backups that were never tested, and one person trying to run both IT operations and security at the same time.
It’s believing you’re safe because nothing bad has happened yet, without ever testing whether your tools, your policies, or your backups actually work. That untested assumption is exactly what an attacker is counting on.
You test them. A pen test simulates a real attack against your specific environment. A vulnerability scan checks for known issues. Neither replaces the other. If you’ve never tested whether your tools work, you don’t actually know that they do.
The things you’ve stopped seeing because you’re too close to them: policies that don’t match the technology they govern, tools that were deployed but never fully turned on, access that should have been revoked months ago. You can’t see your own blind spots as clearly as someone looking in from outside.
Ready to Find Out Where You Stand?
You don’t need to guess whether your security is working. You can know.
If you’ve never had a third-party review, start there. It’s not an audit of your mistakes. It’s an honest answer to a fair question: is what you have actually doing what you think it’s doing?
