7 Mistakes to Avoid in a Major Security Breach
Most Companies Get These 7 Things Completely Wrong, Here’s How to Avoid Them
👋 Hello Technocrats!
2025 has barely begun and we’ve already heard the news of some massive security breaches. I’m going to break down the 7 common mistakes companies makes AFTER they have a major breach & how to avoid them.
Cheers & let’s dive in! 🦈
Bobby
The security breaches this year have already been *brutal*—and yet, so many companies *still* don’t know how to handle them properly.
I don’t entirely blame them. These days, both the complexity and the damage from a major breach is *much* harder to determine.
The immediate fallout might be lost revenue or customers, but over the next few years? Lost market position, lost brand integrity, and lost trust can result in very bad things long after you’ve forgotten about the breach.
So, when a breach does happen its critical to handle remediation in the right way to lower the short and long-term ramifications.
Lets talk through 7 common pitfalls to avoid.
1. Prioritization - Don’t Over or Under React
Some companies make breach remediation their *only* focus—shutting down all other operations, stopping product development, and putting every team into crisis mode.
This is a mistake. You still have a business to run. Customers still need support, and operations still have to function.
On the flip side, some companies treat a breach like just another initiative on the roadmap, juggling it alongside feature releases, quarterly planning and the yearly Christmas party.
Also a mistake.
The right thing is that the CEO and CTO need to set the correct level of urgency & then maintain that until the company is in the clear.
Breach response should be a top priority, but not the only one.
Assign dedicated executive bandwidth to handle the breach while ensuring business continuity. If you ignore this balance, you’ll either burn out your organization or fail to respond effectively.
Giving a major security breach 20% to 30% of the time in every ELT call until the issue tapers off is very fair.
2. Root Cause is an Art
Companies spend thousands of hours investigating breaches, only to produce a 200-slide deck filled with corporate gibberish that the Board doesn’t really buy.
The reality is that major breaches rarely have a single root cause—they’re almost always systemic failures.
To bring *real* clarity, root cause analysis should be split into 3 buckets:
Business Failures – Was security underfunded? Were there ignored warnings?
People Failures – Were there lapses in judgment, misconfigurations, or human error?
Technical Failures – Was this due to vulnerabilities, outdated software, or weak controls?
If you don’t categorize root cause this way, you’ll almost always end up with a high technical explanation that stakeholders instinctually know doesn’t explain everything.
You want to avoid that by clearly articulating the multiple root-causes (if the breach is big enough).
If you just go with the purely technical side (as is common) not only will the Board not buy it, but worse—you’ll fail to permanently fix the underlying problems.
3. Board Reporting is Half the Battle
Fixing the breach isn’t enough. You need to properly report on the situation to the Board on a continuous basis probably for a long time to come (several quarters at least).
And Boards don’t just want technical details—they want the overall business response plan as well as a thousand other things.
They’ll demand:
Clear root cause analysis – what *really* happened and why?
The "never again" fix – how do you guarantee this won’t happen in the future?
Damage assessment & recovery plan – what’s been lost, and how will it be recovered?
And most Boards will not accept internal assurances alone. That makes sense because some amount of trust has been lost.
So if the breach is big enough, expect them to demand external validation from third-party security firms.
Translation: it’s going to cost a lot of money so your budget will take a hit. Talk with your CFO quickly and prepare.
By the way, the main person doing the incident reporting has to be fairly articulate, cool under pressure and have some technical chops.
If you can get your Board back to a good place you know you’re doing a good job remediating the situation.
4. Hire the Right Legal Help
Most companies just call the biggest law firm they can afford. But that’s not the move.
Sometimes the law firm with the best name will get you off the hook just by showing up, but this isn’t TV and that’s pretty rare.
And maybe you have in-house legal counsel which is good, but chances are they are not going to be the best help in this kind of situation.
Depending on how big the security breach is I like to use 2 law firms.
One for security forensics and technical matters – the firm should have actual security professionals on staff, not just lawyers.
The 2nd for regulatory, reputational, and external response management – this firm handles lawsuits, government disclosures, and public messaging.
Most law firms don’t excel at both, so hiring one for each side makes sense. But some of the bigger, more expensive law firms are good at both.
And btw, if you’re looking at paying $1M or more for the breach then this isn’t the time to cheap out on legal help.
5. Accountability - Who Takes the Fall?
I’ve found that companies either scapegoat a random person on staff or let *everyone* off the hook in the event of a major security breach. Both are bad choices.
I view accountability in this way:
If the breach happened due to underfunding security, the CEO should be under fire.
If it was a strategic or systemic technical failure, the CTO takes the heat.
If it was a day to day operational breakdown, the CISO is on the hook.
And if the breach is major enough it might be all three.
Of course, there are innocent human failings where perhaps an individual developer made an error and caused a multi-million dollar negative event.
People do get fired in these situations and that is a legitimate option. But I would also look at setting clear security KPIs for your staff & holding them accountable to those.
Btw, a lot of times in these incidents people know the firing happens only after all the dust has settled. So be careful to manage stress, culture, optics and so forth during the remediation phase.
6. Negotiate with Attackers
Too many companies panic and accept the first ransom demand.
But the reality is that ransomware demands are usually negotiable.
Attackers expect negotiations and often start with an inflated price, knowing it will come down.
Skilled negotiation can save millions—but only if you have the right person / team handling it.
Get ransomware negotiation specialists involved before making a dollar decision.
If you do negotiate on your own make sure you:
Research the attacker
Anonymize communications (don’t use your own email)
Have a payment ceiling
Have a strategy for delaying payments
Contingency plan if negotiations fail
Make sure there’s a legal review
Many attackers are in it purely for the payout (vs. malicious intent to ruin the company) and will give you back your data if you come to an agreement on payment.
7. Pen Tests are Mostly for Show
Stakeholders love penetration tests because they’re very familiar. But the truth is that in many scenarios pen-tests alone are usually not enough to validate that your ecosystem is secure.
For a major breach, you will often need to:
Rethink your security investment strategy
Review the entire product suite & supporting / administrative tools & functionality while asking the question, ‘does this really need to exist in this way?’
Examine your team for any bad faith internal actors
Take a close look at 3rd party partners & vendors
Examine your application software architecture
Review all internal systems / tools — especially legacy systems (even those passing a pen-test)
Look at whether your processes are designed correctly & being followed consistently
Btw, I advocate for your own engineers to get involved in security testing your applications. There is really no one else who knows the products better.
You could pay an outside party but they will take months to understand your software and will still miss things only your engineers will know.
Of course, the downside with getting your own engineers to help is that your roadmap capacity may drop significantly, so Product Management must be prepared for this early on.
Closing Thoughts
These 7 mistakes are very, very common errors companies make when handling security remediation and the strange thing is that organizations still don’t learn to avoid them.
I’ve actually seen companies make the same post-breach remediation mistakes across multiple security incidents without really learning.
Don’t be that way.
Having major security issues is fairly typical for most organizations in today’s highly digitized world. In fact, all CEOs and CTOs should realize that criminal security attacks is a real business model that works because ransoms very frequently do get paid.
So your company WILL likely be targeted the longer you stay in business — it’s just a reality every executive has to deal with at some point.
The key is to prepare and learn from others before you have an event.
One of my good friends is a CISO and he’s frequently taking his company through table-top exercises and real world incident scenarios even though they haven’t had a breach.
It takes a bit of time out of each department but if you create the right culture it all just gets baked in. And when you do have a major security breach one day you’ll be ready.
Last note: a security breach can be brutal at a personal level for the CTO or CISO managing the situation — but it can also be an opportunity for them.
The opportunity is to:
Show calm professionalism in the middle of fear, uncertainty and doubt
Make wise decisions & not have any strategic missteps
Own your part of the root cause; its not all on you but its probably partially on you
If you do this you will be well regarded by stakeholders, learn more from the situation, and potentially use the incident as a jumping off point for better future success.
By the way, reach out for help if you need it: bobby@technocratic.io.
And in the meantime, keep the shark swimming! 🦈