What I Wish Every Leader Understood About Incident Response
What I Wish Every Leader Understood About Incident Response
Fletus Poston III, Senior Cybersecurity and IT Leader
It’s 7:45 AM and I’m three sips into my coffee when my phone buzzes. Not an alert but a text from a friend who just made VP of Operations at her company: “We got hit last night. Ransomware. Board call in an hour. What do I even say?”
That question “what do I even say?” is really the question behind every question Apex Assembly sent me. So, let’s get into it.
Q1. Given the increasing frequency and sophistication of ransomware attacks, how do you assess potential impact, and what strategies do you have in place to prevent, detect, and respond effectively?
I don’t start with “how bad is this.” I start with four questions I ask in the first five minutes, every time: Is this touching a critical business system? Could there be lateral movement happening right now? Is sensitive data at risk? Are customers or operations feeling this yet? Those four answers dictate everything else: who I call, how fast, and how loudly.
On prevention, I’ve stopped treating it as a technology problem alone. The strongest control I’ve added in the last two years isn’t a tool; it’s a rehearsed decision tree. When the team already knows who owns containment versus who owns communication, you save the twenty minutes most companies burn arguing mid crisis. Detection and response only work as fast as your decision-making does.
Q2. How do you manage and monitor third-party vendor risks, especially with respect to data privacy and security?
Here’s an uncomfortable truth. Most organizations can’t answer “what happens if Vendor X goes down” without a meeting and a spreadsheet hunt. I don’t let that stand. Before I care about a vendor’s SOC 2 report, I want a one page map of what relies on them. I need to understand which processes stop, which data flows through them, what our fallback is. A security questionnaire tells you what a vendor promises. A dependency map tells you what you’re actually exposed to. I’d rather have the second one.
Q3. As remote work continues, what measures are you taking to secure endpoints and ensure employee devices are protected?
Honestly, this one’s less exciting than it used to be, which is a good sign. Zero trust principles, MDM on anything touching corporate data, and conditional access based on device posture aren’t cutting-edge anymore; they’re table stakes. The part people still get wrong is personal devices. If someone can read a client email on their own phone, that phone is part of your attack surface whether you’ve acknowledged it or not. Acknowledge it!
Q4. How do you structure and maintain an effective IT risk management framework?
I think in tiers, not in one flat list of risks. Not every system deserves the same urgency, and pretending otherwise is how teams burn out chasing low value fires while the real one smolder. I sort systems into three buckets so that I can gather the following information such as the ones that can’t be down more than a few hours, the ones that can wait a day, and everything else then I build my monitoring, my staffing, and my board conversations around that hierarchy. NIST SP 800-61 gives you the skeleton; the tiering is how you put muscle on it so it reflects your business, not a textbook.
Q5. What are the key challenges in aligning IT and business objectives with regulatory requirements, and how do you embed risk management into company culture?
The challenge isn’t usually the regulation, it’s translation. Legal speaks in obligations, engineering speaks in tickets, and the business speaks in revenue. My job is being the translator standing between all three, and I do that by building response teams that cross those lines permanently, not just during a crisis: someone who owns technical recovery, someone who owns the business workaround, someone who owns compliance exposure, and one person, an incident commander, who can talk to all of them in their own language. When that structure already exists before an incident, “integrating risk into culture” stops being a slogan and starts being Tuesday.
Q6. How do you balance the need for innovation with the need for robust security measures?
I don’t see these as opposing forces, and I’ve stopped letting my teams frame them that way. The fastest way to kill security’s credibility with the business is to be the department that only says no. So, I ask a different question before I ask, “Is this secure?” then I ask “What does this new capability actually depend on, and where does that dependency break?” Most of the time, the answer isn’t “don’t do it.” It’s “do it but build the fallback first.” That’s a much easier sentence to say to a CEO than “no.”
My friend from that 7:45 AM text made it through her board call. She didn’t have every answer. But she had a plan, a chain of command, and four questions she could answer fast. That’s the whole game.
About the Author Fletus Poston III
As a cybersecurity professional with nearly two decades of experience spanning from IDS operations to senior leadership roles, Fletus has experience in finance, utilities, software development and manufacturing sectors, where he has successfully managed comprehensive cybersecurity initiatives.
What Fletus bring to the table:
- M.S.I.S. in Information Assurance with 12+ industry certifications (CISSP, SSAP, GISF, GSEC, GCED, GPCS, GMON, GCCC, GSLC, GSOM, GCIL, GSCL )
- Proven track record in building and scaling security operations across diverse industries
- Deep expertise in threat detection, incident response, and security architecture
- Passion for mentoring teams and advancing cybersecurity excellence
SHARE THIS ARTICLE
