The Most Dangerous Sentence an Executive Can Say
The most dangerous sentence in business isn't "we got hacked." It's "we've never had anything like that happen to us." Here's why, and how to test your incident response plan before you need it.
Most executives assume they have an incident response plan. What they usually have is a document nobody has rehearsed and a set of quiet assumptions about who does what. In this episode I break down what an incident response plan actually is (a business capability, not an IT document), why a tabletop exercise is the only way to find the gaps before a real breach does, and a five-phase framework for running one. I walk through it with a real-world scenario: a $400,000 wire fraud that starts with one tired employee and a convincing email.
- Why "we've never had that happen" usually means "we haven't detected it"
- Why the most common insider threat is your best employee on a bad day
- The five phases of a tabletop exercise: scenario, the right room, injects, communication plan, and debrief
- Notification windows and cyber insurance requirements to know before an incident
- The first fifteen minutes and the first four hours of a real response
If you're a business executive looking for an independent strategy advisor, apply for a 30-minute call at https://titanof.tech.
Watch the video version: https://youtu.be/mmOCDG3IO4o
---
Independent fractional CIO for owners of $5M to $50M businesses. Technology and cybersecurity strategy, with no tools to sell, no commissions, and no conflict.
Work with me: https://titanof.tech
Transcript
John Barker (2025): Your accounts payable manager just wired
Speaker:$400,000 out of the company.
Speaker:It's 9:15 on a Tuesday morning.
Speaker:She has no idea anything is wrong.
Speaker:She didn't make a mistake.
Speaker:She followed the company process exactly.
Speaker:She got an email from your CFO marked urgent asking her to send the wire.
Speaker:The name was right, the title was right, the domain looked right,
Speaker:but your CFO never sent that email.
:00 when someone finally notices, the money is gone, and the clock on
:a dozen decisions your company has never made before just started running.
:Who gets called first?
:Who has the authority to freeze the accounts?
:When or if do you tell your clients?
:When do you call your lawyer?
:Do you even know if your cyber insurance still covers you
:once you start making moves?
:Here's the part nobody wants to hear.
:The reason most companies lose far more than that first $400,000 isn't
:the attack, it's the next four hours, and almost none of them have
:ever rehearsed those four hours.
:Almost none of them believe they will ever need to.
:If you ever heard someone in your company say some version of, "Well,
:we've never had that happen before"
:here's what that sentence actually means.
:It doesn't mean your organization hasn't been targeted.
:It doesn't mean you haven't been breached.
:It means you haven't detected anything, and those are not the same thing.
:The average time between an attacker entering an environment
:and an organization discover them is measured in months.
:The executive who says, "We've never had that happen," may be completely sincere.
:They may also have an active intrusion right now that nobody has found yet.
:That sentence is not a security posture, it is a gap in your
:awareness dressed up as confidence.
:Today, we're gonna talk about what an incident response plan actually
:looks like, why most organizations don't have one, and how to build the
:muscle before you need it because the one guarantee I can give you
:is that you will eventually need it
:So let me ask a direct question.
:If a cyber incident hit your organization right now, not
:tomorrow, right this second, who is the first person that gets called?
:Who makes the decision to shut systems down?
:Who calls clients?
:Do you need to call clients?
:Who talks to the press if it gets that far and you're on, on that level of radar?
:Who notifies regulators if you're legally required to?
:Most executives, if I ask that question, either go quiet or start describing
:something that sounds like a plan but is actually a general assumption that
:someone else has to figure it out.
:The IT team assumes leadership will communicate.
:Leadership assumes IT will contain it.
:Legal assumes someone will loop them in.
:And in the gap between all of those assumptions, a containable incident
:becomes something probably a little bit more catastrophic than probably
:initially would have happened.
:So here's the harder truth.
:The plan not existing is not the IT team's fault.
:Incident response is not a technical document.
:It's a business document.
:It requires business decisions about what gets shut down, who
:gets notified, what gets disclosed, how fast all that has to happen.
:Those decisions cannot be made in real time by people who have never
:rehearsed them but know their roles in them, so they cannot be made by an
:IT team alone But before we build the framework, we need to clear something up.
:Most people hear insider threat.
:They picture a disgruntled employee stealing files on their way out the door.
:So it's someone that's a bad actor with intent, someone you
:can identify and prosecute.
:I've actually seen that happen personally, but that is
:probably the minority of cases.
:The far more common insider threat is your best employee, someone who's been
:there for years, who you trust completely, who clicked on a phishing link at four
:PM on a Friday 'cause they were tired, and it looked legitimate, and they
:were also ready to get out the door.
:That employee did not intend to create an incident, but they did.
:Insider threat does not require malicious intent.
:It requires access and a moment of human error.
:And since every employee in your organization has access to
:something, whether that's email, files, systems, client data, every
:employee is a potential threat.
:This is not an indictment of your people.
:This is just a statement of how incidents actually happen.
:Not sophisticated nation-state attacks, not zero day exploits.
:An email that looks real enough at the wrong moment.
:I've seen some really good ones.
:So which means that you need to have your incident response plan has to account for
:human failure, not just technical failure.
:And the only way to know if it does that is to test it That is
:what a tabletop exercise is for.
:A tabletop exercise is pretty much exactly what it sounds like.
:Everybody sits around a table or on a conference call, Zoom, Microsoft Teams,
:whatever, and you walk through a realistic scenario as if it's happening right now.
:No actual systems are touched, no real data's at risk, but every decision
:that would need to be made in a real incident gets made in real time by the
:real people who would be making them.
:The goal is not to just pass a test.
:The goal is to find out where your assumptions break down before they break
:down in the real world, in production.
:So here's the framework.
:Phase one, you gotta define the scenario.
:So the scenario you're gonna pick to test is gonna be something realistic for
:either your industry or your organization.
:So for most small businesses, probably even large businesses,
:that's going to be a phishing.
:Someone on your team receives a convincing email, clicks a link, and hands over their
:credentials without ever realizing it.
:For Department of Defense contractors, credential, theft is a primary
:vector, attackers targeting the access points into controlled systems as
:well as the working environments.
:for healthcare organizations, ransomware is a big-time one, targeting patient
:records, which is statistically the most likely scenario you will face.
:Start with what is most probable, but for your environment.
:The exotic scenario is less useful than the boring one you're actually
:likely to experience Phase two, now you've gotta assemble the right room.
:This is where most organizations get it wrong.
:They run the drill with IT and nobody else.
:But a real incident touches every department in your organization.
:IT and security handle technical containment, legal handles
:notification requirements, regulatory obligations, and liability.
:HR is involved the moment the incident involves an employee,
:even an accidental one.
:Your finance team needs to assess cost, activate cyber insurance,
:and manage vendor communications.
:Marketing and communications own the external message, and the executive
:team makes the decisions that none of those functions can make independently.
:If those people are not in the room during the drill, they will not know
:their role during the real thing.
:So phase three, run the injects.
:An inject is a new piece of information introduced during the
:exercise that changes the situation.
:So you start with the initial scenario that somebody's credentials
:were compromised, their login credentials to a computer system.
:Then you add the attacker been in the environment for
:seventy-two hours before detection.
:Then client data may have been accessed.
:Then word gets leaked out, and a journalist is calling for comment.
:Each inject forces a new set of decisions.
:Who authorizes shutting down a revenue-generating
:system to stop the spread?
:At what point do you notify clients?
:How do you notify them?
:What do you say publicly before you know the full scope of the incident?
:These are the decisions that cause organizations to freeze during real
:incidents, not because the people are incapable, but because they've never
:rehearsed the decision under pressure.
:So phase four, the communication plan.
:This is the piece nobody builds until they are in the middle of
:an incident wishing they had it.
:They want that playbook then.
:Your communication plan defines three things in advance.
:First, the internal notification chain.
:Who gets called first when an incident is detected?
:In what order does that escalate?
:What is the threshold for waking up the CEO at two AM versus handling
:it at an operational level?
:This needs to all be written down, not in a shared drive nobody can access
:when the systems are down, but on a document that, that exists outside of
:the network that's always accessible.
:Second, you're gonna have your external notifications.
:Depending on your industry, you have legal obligations, and this
:clock starts running the moment you discover the breach or incident, not
:the moment you finish containing it.
:SEC rules require public companies to disclose material incidents.
:DOD contractors will have those, under CMMC or DFARS.
:And if you miss those windows because your team is focused on remediation and assumed
:disclosure could wait, that can carry its own consequences, regulatory fines,
:loss of contracts, in some cases personal liability for the executives who signed
:off on the compliance to start with.
:the responsible parties, and the draft language need to be
:ready before you need them.
:Third, you need to let your cyber insurance carrier know.
:Most cyber insurance policies have specific requirements
:about how an incident must be handled to preserve coverage.
:Approved incident response vendors, notification timelines, documentation
:requirements, an organization that manages an incident without following
:their policies, procedures may have invalidated the claim at the
:exact moment they need it the most.
:Your communication plan needs to include a step that says, "Call
:the insurer early before you made decisions that can't be undone."
:Fourth, you're gonna have client and vendor communication.
:Who is authorized to speak to clients?
:What do you say when you don't know the full scope?
:The answer is usually not silence.
:Silence is a thing that turns a client into a former client.
:Silence is always the worst thing in almost every situation.
:Your plan needs a holding statement, a timeline for updates, and a single
:point of contact so clients are not getting different information from
:different people And then in phase five, you're gonna have a debrief, and
:this is where the real value lives.
:After the exercise, you capture everything that broke down,
:during your table talk exercise.
:Every moment where someone didn't know their role, every decision
:that couldn't get made because the authority wasn't clear, every
:gap in the communication chain.
:Two things come out of almost every debrief regardless of the organization.
:First, the notification chain either doesn't exist or has
:never been communicated to the people who need to execute it.
:Everyone assumed someone else had that list.
:Second, leadership realizes that decisions requiring executive authority
:have never been discussed in advance.
:What to shut down, what to disclose, whether to pay a ransom.
:Making those decisions for the first time during an active incident when
:you're under pressure with incomplete information is where organizations
:make their most expensive mistakes.
:I've been in places where we've had communication plans very well specced
:out, and we stored it in multiple disparate systems, so it was always
:accessible if something happened to one of the multiple systems, and there were
:instances where it was definitely used
:Now I want to come back to that wire transfer from the start of the video.
:Because before we walk through the response minute by minute, I want
:you to hold onto something about that employee in accounts payable
:They followed a process.
:They did what the email asked.
:They had no reason to believe it wasn't legitimate.
:Tonight, they are going home carrying the weight of a financial loss that was
:not their fault because the organization never built a verification step into
:the workflow, never trained them on what a spoofed request looks like,
:and never gave them a way to confirm a large transfer through a second channel.
:That is an insider threat.
:That is an organizational failure, and that employee deserved better.
:Keep that in mind as we walk through the response because incident response
:that ignores the human cost of how the incident happened will build a
:culture where employees hide mistakes instead of reporting them fast.
:And speed of reporting is the single biggest factor in how bad
:something like this would get.
:So in the first fifteen minutes, IT needs to determine whether this was a
:spoofed email or whether the CFO's actual account has been compromised because
:those are two very different scenarios with two very different responses.
:While that's happening, who is making decisions?
:Who has the authority to freeze outgoing transactions?
:Is that IT?
:Is that finance?
:Is it the COO?
:The attacker had access to the CFO's email for seventy-two hours.
:You do not yet know what was read, forwarded, or exfiltrated,
:the data removed from the system.
:Who gets notified internally?
:When does legal get involved?
:If any of that email contained client information, and of course, the
:CFO's email probably almost certainly does, what are your notification
:obligations and what is your timeline?
:The clock on those obligations started seventy-two hours ago,
:and you're already behind.
:You call your cyber insurance carrier now before the next decision gets made.
:Hours two through four, you've contained the immediate breach.
:Systems are being audited.
:Now the external questions begin.
:Do clients need to be notified?
:Has this reached a regulatory disclosure threshold?
:Is there any chance that this becomes public?
:And if it does, who speaks?
:What do they say?
:By the end of the day, maybe the wire transfer is partially recoverable.
:The reputational damage is contained because communication was handled very
:quickly, clearly, and from a single authorized voice, or most likely it isn't
:because nobody knew who was supposed to send the client notification, so
:nothing went out, and a client found out from somebody else entirely.
:The difference between those two outcomes is not technology.
:It's
:preparation
:We've never had anything like that happen to us before.
:I need you to retire that sentence.
:it conflates not detecting something with not experiencing it, and
:because the organizations that said it with the most confidence
:are the ones that called me later.
:An incident response plan is not a technical document
:sitting in an IT folder.
:It is a business capability.
:It requires your executives to know their roles, your departments to know the
:chain of command, your legal obligations to be met before the clock starts, your
:insurance carrier is to be on speed dial, and your communication plan to
:be ready before anyone is panicking.
:Seen way too much panicking.
:The tabletop exercise exists so the first time your team makes these decisions
:is not during an actual incident.
:It's in a controlled environment where the cost of getting it wrong
:is a lesson, not a lawsuit or irreparable harm to your business.
:You do not need to be a cybersecurity expert to run one.
:You just need a realistic scenario, the right people in the room, and
:someone facilitating who knows where the gaps tend to hide.
:Build the muscle now.
:The question is never if, it is always when, and whether your
:team is ready when it gets there.
