Cultivating Security

About Cultivating Security

Deep examinations of industry incidents, vendor risk, and operational security decisions from 25+ years in the field. AI-narrated episodes transform written analysis into practical insights for security professionals who need to understand what really happens when security meets operational reality. No certifications required, just real-world experience.

Publisher

Cultivating Security

Category

business · news · technology

Language

en

Explicit

Yes

First episode

2 Dec 2025

Latest episode

7 Apr 2026

Latest episodes

20 episodes in the feed.

1. 

   7 Apr 2026

   Week 14: What I Wish Someone Had Told Me

   Twelve weeks ago, we started this series talking about a gap in how people learn security work. You can get certified, read the frameworks, know the technical fundamentals—and still walk into your first real security role completely unprepared for how the work actually functions. Nobody teaches you the organizational part. The political part. The part where your technically perfect solution dies in a budget meeting. The part where you discover that half your environment isn’t documented and everyone just works around it. We’ve spent twelve weeks filling that gap. Talking about the realities that textbooks don’t cover and certifications don’t test for. The organizational dynamics, the political navigation, the pragmatic trade-offs, the gap between theory and practice. These are the things I wish someone had told me earlier in my career. Or maybe they did try to tell me, and I wasn’t ready to hear it yet. Sometimes the lesson doesn’t land until you’ve seen enough to recognize what it means. Some of this I learned through mistakes—my own and others’. Some through painful experience during incidents, failed projects, and organizational friction. Some through watching seasoned practitioners navigate situations I didn’t understand yet. And some through finally understanding what a mentor or manager had been trying to tell me for months, once I had the context to make sense of it. I can’t give you the experience—that you have to earn yourself. Experience is what engrains these lessons in ways that reading never can. But what I can give you is context. Frameworks for understanding what you’re experiencing, so the lessons land faster and with less confusion. Explanations for why your boss, your manager, your lead, your VP does the things they do—not because they’re wrong or don’t care about security, but because they’re operating with constraints and pressures you might not see yet. And maybe—hopefully—this series will help reduce some of the stress. The frustration of proposing good ideas that go nowhere. The confusion when leadership makes decisions that seem obviously wrong. The exhaustion of fighting battles that never seem to end. If you understand the organizational dynamics, the political realities, the resource constraints, the competing priorities—it doesn’t make the work easy, but it makes it make sense. And when it makes sense, you can try different approaches. Different framing. Different timing. Different tactics. You’ll have tools, techniques, and methods to try when your first approach doesn’t get traction. Not because the first approach was wrong, but because you’ll understand why it didn’t work and what might work better given the specific organizational context you’re in. The work is still hard. But understanding why it’s hard—and having strategies for navigating that difficulty—makes it sustainable in ways that just grinding through without context never is. I can’t give you the experience—that you have to earn yourself. But I can give you the framework for understanding what you’re experiencing, so the lessons land faster and hurt less. The Patterns That Kept Appearing If you’ve been following this series from the beginning, you noticed certain themes surfacing repeatedly. That wasn’t accidental. These are the patterns that underpin how security work actually gets done: Understanding before securing. We started with asset inventory and environmental knowledge (Week 1) because you can’t protect what you don’t know exists. But that principle echoed through every subsequent week. You can’t manage risk in systems you haven’t inventoried. You can’t build detection for attacks you have no visibility into. You can’t secure identities you haven’t cataloged. You can’t assess vendor risk without understanding what access they have. You can’t navigate organizational politics if you don’t understand the business context. It all starts with understanding what you’re actually working with. Not what the documentation says. Not what people think is there. What’s actually there. Fort Knox isn’t the goal. We covered this explicitly in Week 2, but it came up again in Week 7 (why security projects fail), Week 10 (when best practices don’t apply), and everywhere we talked about pragmatic trade-offs. Perfect security is impossible and often counterproductive. Your job is managing risk proportionally within realistic constraints, not eliminating all risk. Learning to calibrate your risk tolerance to organizational reality—to distinguish between “this is dangerous and unacceptable” and “this is uncomfortable but pragmatic given our constraints”—that’s professional growth. It’s also what prevents burnout when you realize you can’t achieve the textbook ideal. Documentation is operational, not bureaucratic. I recommended starting a risk register in Week 1, and it kept proving useful throughout the series—critical in Week 2, essential in Week 6, valuable again in Weeks 10 and 11. It’s not compliance theater. It’s how you track what you’ve found, what the organization has accepted, what you’re working on, and what you’re carrying forward. It’s how you demonstrate progress over time. It’s how you protect yourself from inheriting responsibility for decisions made years before you arrived. But it’s also a working tool for prioritization. When you choose a risk assessment methodology—and we didn’t cover that in this series, but you’ll need one—your risk register becomes the map that shows you what to address first, what to tackle next, what’s lower priority but still needs eventual attention. It helps you move the program forward strategically instead of just reacting to whatever’s loudest or most recent. Without it, you’re operating from memory and reacting to pressure. With it, you have a coherent view of your security posture and a rational basis for prioritizing work. When someone asks “what security issues do we have,” you have an answer. When leadership accepts a risk you’re uncomfortable with, you document it and move on. When you’re trying to show improvement year over year, you have the receipts. Incremental progress beats perfect plans. This showed up everywhere—Week 2’s risk management, Week 7’s project failures, Week 10’s pragmatic trade-offs. You won’t fix everything at once. You won’t get unlimited resources. You won’t have perfect organizational support. But consistent, demonstrable improvement over time? That’s achievable. That’s what separates effective security practitioners from people who burn out fighting for impossible standards. Close ten risks this quarter. Close twelve next quarter. That’s progress. The risk register still has 150 items? Sure. But it had 172 six months ago. You’re moving in the right direction. And here’s the thing: not all 150 items are critical. If they are, you probably need to revisit how you rank and categorize risks—your methodology might be inflating everything. More likely, the majority are actually lower risk. They’re still risks you need to treat (compensating controls where possible, documentation where you can’t), but they’re not drop-everything urgent. Look at what you actually closed: this quarter, 12 items—half were critical, 2 were medium, 4 were low. Prior quarter, maybe you closed 10 items—3 critical, 5 medium, 2 low. That’s tangible risk reduction in a short period of time. You’re not just moving items off a list—you’re systematically reducing your organization’s exposure to the risks that actually matter most. The critical findings are getting addressed. The high-severity gaps are closing. The attack surface is shrinking in the areas that count. That’s the kind of progress leadership can understand and you can be proud of. And it’s only visible if you’re tracking it properly. Organizational literacy matters as much as technical skill. Understanding how decisions get made, who influences them, what pressures leadership faces, how to communicate in business terms, when to fight and when to document and move on—these came up in Week 6 (reporting through IT), Week 7 (why projects fail), Week 8 (reading the room), and honestly everywhere. Technical competence gets you in the door. Organizational effectiveness determines whether you can actually get security work done. You can be the smartest security person in the room and still accomplish nothing if you don’t understand how to operate in the organization you’re actually in. Vendor promises and reality rarely align. Week 5 covered this extensively, but it echoed in Week 3’s visibility gaps and Week 4’s identity sprawl. Whether it’s logging capabilities, incident response commitments, authentication mechanisms, or SLA definitions—verify everything, get commitments in writing, plan for failure. This isn’t cynicism. It’s professionalism. Vendors are businesses with business objectives. Their incentives aren’t perfectly aligned with yours. Understanding that dynamic helps you manage the relationship effectively instead of being repeatedly surprised when they don’t deliver what you expected. Compliance and security aren’t the same thing. Week 9 made this explicit, but the tension appeared in Week 6 (using compliance as a forcing function), Week 8 (understanding what your CISO actually cares about), and Week 10 (when best practices don’t apply). Passing an audit doesn’t mean you’re secure. Compliance frameworks test for specific controls at a point in time—they don’t evaluate your comprehensive risk posture. But compliance requirements can be useful. They create forcing functions that get resources allocated. They provide deadlines that security risk assessments often don’t. Use them strategically, but don’t let them define your entire program. Pattern recognition comes from repetition. Week 12 was about learning from public breaches, but the principle applies more broadly. After you see enough incidents, enough vendor failures, enough project dynamics, enough organizational patterns—you start recognizing them earlier. You develop intuition for what’s likely to succeed versus what’s going to struggle. You get better at predicting which risks matter and which ones are theoretical. That intuition can’t be taught directly. But it can be accelerated by deliberately learning from others’ experiences instead of only your own. What We Didn’t Cover (And Why) This series was never meant to be comprehensive. It was focused on a specific gap: the organizational and practical realities of security work that don’t get taught in formal programs. We didn’t do technical deep-dives. How to configure a SIEM. How to write detection rules. How to perform threat modeling. How to implement zero trust architecture. Not because those aren’t important—they absolutely are—but because there are plenty of good resources for learning those things. The gap isn’t technical knowledge. It’s organizational context. We didn’t do tool recommendations or vendor comparisons. Tools change constantly. What’s cutting-edge today is legacy tomorrow. The principles of what you need (visibility, detection, response capability, identity management) don’t change. The specific products that deliver those capabilities change all the time. Besides, the right tool depends on your environment, your constraints, your use cases—there’s no universal answer. We didn’t cover advanced topics like threat hunting, red teaming, sophisticated detection engineering, or security research. Not because those aren’t valuable career paths, but because this series was aimed at people 1-5 years into security work who are still building foundational organizational literacy. Those advanced topics come later, and they build on the foundations we’ve covered here. We didn’t go deep on specific compliance frameworks or regulations. GDPR, HIPAA, PCI-DSS, SOC 2, ISO 27001—the specifics vary, but the organizational dynamics we covered in Week 9 apply broadly. The tension between compliance and security, the way audits work, the importance of documentation, the scope boundaries—those patterns repeat regardless of which framework you’re working with. We didn’t cover career progression, salary negotiation, resume building, interview preparation, or other career development topics. Important? Yes. But outside the scope of “how to actually do security work effectively once you’re in the role.” The focus was deliberate: the organizational, political, and practical realities of security work that usually take a decade of painful experience to learn. Everything else—the technical skills, the tool knowledge, the advanced specializations—you can find elsewhere or will learn as you need them. The Skills That Compound Some skills plateau relatively quickly. You learn a technology, you get proficient, you maintain that proficiency. That’s valuable, but it doesn’t keep growing exponentially. Other skills compound over time. They get more valuable the longer you practice them, and they apply across changing contexts even as technologies and tools evolve. Communication skills compound. Learning to translate technical risk into business impact, to tailor messages for different audiences, to advocate for security work without being preachy or alarmist—these skills improve with practice and apply regardless of what security domain you’re working in or what technologies you’re using. Ten years from now, the specific security tools will be different. The need to communicate effectively with non-technical stakeholders will be exactly the same. Organizational navigation skills compound. Understanding how decisions get made, building relationships with stakeholders, recognizing political dynamics, knowing when to push and when to document and move on—these get easier with experience and apply across different organizations and roles. You’re building pattern recognition for organizational behavior that transfers. Judgment and prioritization skills compound. Learning to distinguish between critical risks and theoretical concerns, knowing what’s worth fighting for and what’s worth accepting, making intelligent trade-offs with imperfect information—this is the skill that separates senior practitioners from junior ones. It takes years to develop because it requires seeing enough situations to build reliable intuition. Systems thinking compounds. Understanding how pieces fit together, recognizing second-order effects, seeing patterns across seemingly different problems—this improves continuously as you accumulate more context and experience. The person who can see how an identity sprawl problem (Week 4) connects to vendor risk (Week 5) connects to organizational structure (Week 6) connects to compliance requirements (Week 9) is thinking systemically. That’s a skill that develops over years and applies broadly. Relationship building compounds. The trust you build with colleagues, the credibility you establish with leadership, the reputation you develop in your professional community—these accumulate over time and make future work easier. The security person who’s known for being reasonable, competent, and effective gets more organizational support than someone with identical technical skills but no relational capital. Technical skills matter. You need them. But they’re also more volatile—what’s cutting-edge today is outdated in five years. The compounding skills we’ve focused on throughout this series? Those stay valuable throughout your entire career. Knowing When to Stay, When to Move Not every organization is a good fit for every practitioner. And not every challenge is worth pushing through. But let me be clear up front: this section isn’t about quitting security. It’s about recognizing when you need to move to a different organization to continue growing in this field. The work matters. You staying in this field matters. Sometimes that means finding an environment where you can actually do the work effectively. Some situations are hard but developmental. You’re learning, building skills, making progress even if it’s slower than you’d like. The organization has constraints and you’re figuring out how to operate within them. Leadership isn’t perfect but they’re reachable. Resources are limited but you’re able to demonstrate value and make incremental improvements. You’re frustrated sometimes, but you can see a path forward. That’s worth staying for. That’s where you build the organizational literacy and political skills that compound over time. Other situations are hard in ways that aren’t developmental—they’re just dysfunctional. You’re hitting the same walls repeatedly. Security work gets killed for reasons that don’t make sense even after you understand the context. You’re excluded from decisions until it’s too late to influence them. Leadership says security matters but their actions show it doesn’t. You’re expected to accept responsibility without being given authority. Your professional opinions are solicited but never actually valued. We talked about some of these patterns in Week 6 (reporting through IT leadership). The questions to ask yourself: Are you making progress, or are you just spinning your wheels? If you’ve been trying the approaches we’ve covered—building relationships, communicating in business terms, demonstrating value, picking your battles—for a year or more and nothing is changing, that tells you something about whether the organization is actually ready to invest in security. Is the situation challenging in ways that are building your skills, or is it just draining your energy without growth? There’s a difference between “this is hard but I’m learning how to navigate it” and “this is dysfunctional and I’m just absorbing damage.” Have you had honest conversations with your management about the walls you’re hitting? Not venting, not just complaining—but explaining the specific obstacles and working together to figure out how to break them down or work around them. “Here’s what I’m trying to accomplish, here’s where I’m getting stuck, here’s what I’ve tried, what are your thoughts on how we might approach this differently?” Sometimes leadership doesn’t realize the structural barriers you’re facing. Sometimes they have context that explains why things are the way they are. Sometimes they can help remove obstacles if they understand what you need. If you haven’t had those conversations, have them before you decide the situation is unfixable. But if you have had them—repeatedly, clearly, professionally—and nothing changes, that’s information. Are the structural problems fixable, or are they fundamental to how the organization operates? Sometimes reporting structure can evolve as you demonstrate value. Sometimes organizational culture is so deeply rooted that one person can’t shift it, and trying will just burn you out. Are you asking for perfection from an organization that’s comfortable with “good enough”? This is a real question you need to sit with. We talked in Week 2 about calibrating your risk tolerance to organizational reality. Some organizations aim for security maturity. Some organizations aim for “adequate enough not to get breached, and we’ll deal with it if we do.” Neither is inherently wrong—they’re different risk appetites serving different business strategies. If you’re pushing for Fort Knox and the organization is comfortable with three locks and a guard dog, that’s a mismatch. Not necessarily because either of you is wrong, but because your expectations don’t align with their reality. That’s a conversation worth having with leadership explicitly: “What’s our actual goal here? Are we trying to be best-in-class, or are we trying to meet baseline requirements and regulatory obligations? I need to understand what success looks like for this organization so I can calibrate my work appropriately.” Are you experiencing physical symptoms from the stress? Losing sleep, anxiety that persists outside work hours, health impacts—these are signals that the situation isn’t sustainable regardless of whether you’re learning. We mentioned this briefly in Week 6, but it’s worth repeating: no job is worth destroying your health. If the organizational dysfunction is affecting you physically, something has to change. Either the situation improves, or you need to be somewhere else. The difference between “this is hard but worthwhile” and “this is damaging and I need to leave” isn’t always immediately clear. Give situations a fair chance. Use the strategies we’ve covered. Build skills and credibility. Have the hard conversations with management about what’s not working and how to improve it. Be honest with yourself about whether you’re asking for perfection or asking for basic functionality. But also be honest about whether you’re making progress or just enduring dysfunction. Moving to a different organization isn’t failure. Sometimes it’s the most professional choice you can make. The field needs you. If you’re in an environment that’s preventing you from growing or actively damaging you, finding a better fit is how you stay in this career long-term. Don’t leave security. But don’t stay in situations that are breaking you, either. The Moments That Make It Worthwhile Security work is hard. There will be days where everything you propose gets shot down. Weeks where you’re underwater on compliance requirements while actual security work gets deprioritized. Months where you’re fighting fires instead of making progress. Incidents that reveal gaps you knew existed but couldn’t get resourced to fix. But there are also moments that make all of it worthwhile. When you prevent something bad from happening—and maybe nobody else even knows. You caught the phishing campaign before it spread. You identified the misconfiguration before it was exploited. You flagged the vendor risk before it became a breach. The threat was real, you stopped it, and it never made headlines because that’s how good security works. When leadership finally understands what you’ve been saying for months. You’ve been raising a risk, documenting it in your risk register, communicating it clearly. And finally—maybe because of a public breach that demonstrates the exact scenario you described, maybe because they’ve accumulated enough context, maybe because the timing is finally right—they get it. And they fund the remediation. That validation feels incredible. When a process you built actually works during a crisis. The incident response plan you documented. The logging you fought to implement. The relationships you built across teams. The escalation paths you defined. When an actual incident happens and everything clicks into place—people know their roles, the documentation is there, the logs exist, the communication flows—that’s satisfying in ways that are hard to describe. When you look at your risk register from a year ago and realize how much you’ve actually closed. Fifty risks remediated. A hundred issues addressed. Technical debt that existed for years, finally fixed. Controls that didn’t exist, now implemented. The work felt incremental day-to-day, but looking back across a year the progress is undeniable. When a junior colleague comes to you with a problem and you can help because you’ve been there. You’ve navigated the same organizational friction. You’ve had the same conversation with that executive. You’ve solved the same technical challenge. And you can save them some of the pain you went through because someone’s finally asking the questions you wish you’d known to ask. When you see evidence that security is becoming part of how the organization thinks, not just a checklist. Development teams including you in design reviews without being told to. Business units asking about security implications before making decisions. Leadership considering security risk alongside other factors instead of treating it as an afterthought. Culture change is slow, but when you see it happening it’s incredibly rewarding. These moments don’t happen every day. Sometimes they don’t happen every month. But they do happen. And when they do, they erase a lot of the hard days. The key is recognizing them when they happen and letting yourself feel good about them. Security success is often invisible—the things that don’t happen, the crises that never occur. Train yourself to notice and acknowledge the wins, even the quiet ones. They’re what keep you going through the challenging stretches. The Long Game Security careers are long. Measured in decades, not years. Where you are right now—1-5 years in—you’re still building foundations. Learning the technologies, yes, but more importantly learning how organizations actually work. How decisions get made. How to communicate effectively. How to navigate politics without becoming political. How to make progress within constraints. This phase is about building competence and credibility. Demonstrating that you understand the business, not just the security. Showing that you can work within realistic constraints, not just advocate for ideal solutions. Establishing relationships and reputation that will make future work easier. At five years, you should have solid technical fundamentals and growing organizational literacy. You understand your environment well. You can identify risks and communicate them effectively. You can implement security controls and demonstrate their value. You’re starting to see patterns and develop intuition. You’re trusted to handle incidents competently. At ten years, you should have strong pattern recognition across multiple domains. You can assess a security program and quickly identify the high-value improvements. You understand organizational dynamics well enough to navigate them strategically. You can mentor others effectively because you’ve seen enough to articulate the lessons clearly. You’re building security programs, not just implementing controls. This isn’t about titles or hierarchy—it’s about capabilities and impact. The ten-year practitioner who’s built robust security programs in constrained environments has skills that compound indefinitely. The person who’s only chased certifications and job titles without building organizational effectiveness hasn’t grown the same way. And here’s something nobody tells you early on: the work gets more satisfying as you get better at it. Not easier—it’s still hard—but more satisfying. Because you’re making bigger impact, seeing the long-term results of work you did years ago, mentoring people who are where you used to be, solving more complex problems that require the experience you’ve accumulated. The first few years can be frustrating because you see all the gaps but you don’t have the organizational positioning or credibility to address them as fast as you want. That gap between what you know should happen and what you can actually make happen—it’s demoralizing sometimes. But as you build competence, credibility, and organizational capital, that gap narrows. Not because the problems get easier, but because you get more effective at solving them. This series covered twelve weeks of content, but it’s really about giving you frameworks for understanding the next decade. The organizational patterns, the political dynamics, the pragmatic trade-offs—these are things that typically take years of painful experience to learn. You’ll still need the experience. But hopefully you’ll recognize what you’re experiencing more quickly, make better sense of it, and extract the lessons with less pain and confusion. What’s Next (And What You Want to Hear About) I’ve built two security programs from the ground up in different-sized companies. I’ve worked for major nationwide organizations and small operations. I’ve been the solo security person and I’ve been part of larger teams. These twelve weeks covered the challenges I see most security practitioners face regardless of organization size—the foundational organizational and political realities that transcend specific industries or company stages. But there are things I didn’t cover. Some because they felt too specific or too advanced for this series. Some because they’re skills I’ve internalized to the point where I don’t think about them consciously anymore—like systematic thinking and how I can hear one scenario, build out the attack vectors in my head, and mentally scroll through defense-in-depth layers to identify gaps. (Actually, that’s a topic we didn’t talk about at all, and maybe we should have.) So here’s what I want to know: What are you facing that we didn’t cover? What topics are top of mind for you right now? What organizational challenges are you hitting that don’t fit neatly into the twelve weeks we just went through? What skills do you wish you had better frameworks for understanding? Maybe it’s how to think systematically about security architecture. Maybe it’s how to build a security culture when you’re not in a leadership position. Maybe it’s how to handle specific political dynamics we touched on but didn’t fully explore. Maybe it’s technical topics where you want the organizational context—not just “how to implement X” but “how to get X funded and adopted in a resistant organization.” Maybe it’s something I’ve never thought about because my experience is different from yours, or because I’ve been doing it so long I don’t realize it’s not obvious. I’m listening. What would be useful? One Last Thing You’re going to make mistakes. You’re going to advocate for things that don’t get funded. You’re going to miss things during incidents. You’re going to communicate risk poorly and watch decisions get made based on incomplete understanding. You’re going to implement controls that don’t work as well as you hoped. You’re going to accept trade-offs you’re uncomfortable with and occasionally rationalize things you shouldn’t. That’s normal. That’s part of learning this work. The difference between effective practitioners and struggling ones isn’t that effective practitioners don’t make mistakes—it’s that they treat mistakes as information. What didn’t work? Why? What would I do differently next time? What pattern am I seeing here that I should watch for in the future? Every failed project teaches you something about organizational dynamics. Every incident reveals gaps in your defenses or your processes. Every awkward conversation with leadership shows you what resonates and what doesn’t. Every vendor disappointment calibrates your expectations. The experience compounds if you let it. If you’re paying attention, reflecting, adjusting based on what you learn. Security work matters. It matters for the organizations that depend on it. It matters for the people whose data you’re protecting. It matters for the broader ecosystem—every organization that gets breached makes the threat landscape worse for everyone else. You’re building something worthwhile. Maybe not quickly. Maybe not perfectly. Maybe not with the resources you wish you had. But you’re building it. The twelve weeks we’ve spent together covered a lot of ground. Environmental understanding, risk management, visibility gaps, identity sprawl, vendor relationships, organizational navigation, project dynamics, executive priorities, compliance tension, pragmatic trade-offs, incident response, and learning from others’ mistakes. But really, it’s been about one thing: how to do security work effectively in the real world, with real constraints, with real people, in real organizations that are messy and imperfect and don’t match what the textbooks describe. You know more now than you did thirteen weeks ago. Not just facts—frameworks for understanding the work you’re doing. Context for the challenges you’re facing. Strategies for operating more effectively. Patterns to watch for. Pitfalls to avoid. The work is still hard. But you’re better equipped for it. I wish someone had told me this stuff earlier. I’m glad I could tell you. Now go build something. The post Week 14: What I Wish Someone Had Told Me (https://cultivatingsecurity.com/ftnt-14-what-i-wish-someone-had-told-me-security/) appeared first on Cultivating Security (https://cultivatingsecurity.com).

2. 

   31 Mar 2026

   Week 13: Learning from Incidents You Didn’t Have

   The security community has a gift that we don’t use effectively enough: every major breach becomes public eventually. Companies have to disclose incidents. Researchers analyze and publish findings. Post-mortems get written. We can learn from other organizations’ failures without having to experience them ourselves. But most people don’t extract meaningful lessons from public breaches. They read the headlines, maybe feel a moment of “glad that wasn’t us,” and move on. Or they read the technical details but don’t connect them to their own environment. That’s a missed opportunity. Because the patterns that lead to breaches are often similar across different organizations. The attack techniques that work against one target often work against others. The organizational and cultural failures that allowed an incident to happen probably exist in your organization too. Learning to read public breaches for useful lessons—and applying those lessons to your own environment—is a skill that takes practice. But it’s valuable because it helps you build pattern recognition and intuition without having to learn everything through painful personal experience. What to Look for in Public Breaches When you read about a breach, the headline usually tells you what happened: “Company X suffered data breach affecting Y million customers.” That’s not the useful part. The useful part is understanding how it happened and why. What weaknesses existed that allowed the breach? What organizational or process failures contributed? What could have prevented it or detected it earlier? Not all of this information is available. Companies don’t always release detailed post-mortems. But often there’s enough information available—from the company’s disclosure, from researchers who analyzed the incident, from forensic reports if they’re public—to understand the key factors. Initial access vector. How did the attacker get in? Phishing? Vulnerability in internet-facing system? Compromised credentials? Third-party compromise? This tells you what defenses failed or were absent. Privilege escalation and lateral movement. Once inside, how did the attacker expand their access? Did they find unpatched vulnerabilities? Exploit weak access controls? Find credentials stored insecurely? This tells you what internal controls failed. Dwell time. How long was the attacker present before detection? Days? Weeks? Months? This tells you something about detection capabilities—or lack thereof. What finally triggered detection? Was it internal monitoring? External notification from law enforcement or a third party? A ransom demand? This tells you whether detection worked or the organization got lucky. Data accessed or exfiltrated. What did the attacker actually get? How was it protected (or not)? This tells you about data security practices. Response and remediation. How did the organization respond? How long did containment and recovery take? What mistakes were made? This tells you about incident response maturity. The Pattern Recognition Skill After you’ve read about enough breaches, you start seeing patterns. Certain attack paths are common. Phishing to initial access, credential theft, lateral movement through weak internal controls, eventual access to high-value systems or data. This pattern repeats across different industries and organization types because it works. Certain organizational weaknesses are common. Poor asset inventory leading to unknown or forgotten systems. Inadequate logging making investigation difficult. Over-privileged access enabling lateral movement. Lack of segmentation allowing attackers to reach sensitive systems once they’re inside. Certain cultural or process failures are common. Security updates that don’t get applied because of operational concerns. Security tools that exist but aren’t properly configured or monitored. Security processes that exist on paper but aren’t followed in practice. When you recognize these patterns, you can evaluate whether they exist in your own environment. Not “could we get breached the exact same way” but “do we have the same types of weaknesses that contributed to that breach?” This is more valuable than trying to defend against specific attack techniques. Attack techniques evolve. But organizational weaknesses tend to persist. Translating to Your Environment The question to ask when reading about a breach isn’t “could this exact attack work against us” but “what similar weaknesses do we have?” If a breach happened because of an unpatched internet-facing system: Do we have good visibility into our internet-facing attack surface? Do we have a reliable patching process? Do we know when new systems get exposed to the internet? If a breach happened because of over-privileged service accounts: Do we know what service accounts exist? Do they have more access than necessary? Have we reviewed them recently? If a breach happened because logging wasn’t retained long enough to understand the full scope: How long do we retain logs? Is that adequate for investigation? Do we have gaps in what we log? If a breach happened because a third-party vendor was compromised: How do we assess third-party risk? Do we have visibility into what access third parties have? Do we monitor that access? This translation from “what happened to them” to “what does this mean for us” is where the learning actually happens. What Doesn’t Apply Not every breach lesson is relevant to every organization. If a breach happened because of a weakness in a specific technology or product you don’t use, the specific technical details might not matter to you. But the category of weakness might still be relevant. If a breach happened in a highly regulated industry with requirements that don’t apply to you, some of the lessons might not translate. But organizational and process failures often do translate even across different regulatory environments. If a breach happened at a massive scale and you’re a much smaller organization, some of the systemic issues might not apply. But the fundamental weaknesses often do. The judgment call is distinguishing between lessons that apply broadly versus lessons that are specific to circumstances you don’t share. This requires understanding your own environment well enough to make that judgment. If you don’t know your architecture, your access patterns, your third-party relationships—you can’t evaluate whether a particular breach lesson is relevant. Avoiding Threat Inflation There’s a risk in reading about breaches: everything starts to look like an emergency. “This sophisticated attack campaign targeted our industry. We need to immediately implement defenses against it.” Maybe. Or maybe this is an advanced persistent threat that you’re not actually likely to face, and there are more realistic threats you should be focusing on. Reading about sophisticated attacks is interesting. It’s good to understand what’s possible. But it shouldn’t drive your priorities unless you have specific reason to believe you’re a likely target for that threat. Most organizations get breached through common attack paths, not sophisticated novel techniques. Phishing. Unpatched vulnerabilities. Weak credentials. Misconfigurations. These are the things that actually happen frequently. Sophisticated nation-state attacks make headlines. They’re not what most organizations need to optimize their defenses against. So when you’re learning from public breaches, pay attention to the common patterns, not just the exotic ones. The boring failures that happen repeatedly are more likely to be relevant than the once-in-a-decade sophisticated campaign. The Supply Chain Lesson One pattern that’s become increasingly important: third-party compromise as an attack vector. Organizations get breached through their vendors. Through their software supply chain. Through their business partners. The attacker compromises an organization that has trusted access to the real target, then uses that access to pivot. This is hard to defend against because you don’t fully control the security practices of third parties. But you can at least be aware of the risk and take some mitigation steps. Understand what third parties have access to your environment. What data, what systems, what permissions. Limit that access to what’s actually necessary. Monitor it for anomalies. Assess third-party security practices as best you can. Due diligence, questionnaires, certifications—these aren’t perfect but they’re better than nothing. Have contingency plans for what happens if a critical third party gets compromised. Can you disable their access quickly? Can you operate without them temporarily if necessary? Supply chain risk is one of those lessons that keeps appearing in breach post-mortems. If you’re not thinking about it, you should be. The Detection Gap A common theme in breach post-mortems: the attacker was present for a long time before detection. Sometimes this is because the organization had no detection capabilities at all. More often, it’s because they had detection tools but those tools weren’t configured effectively, weren’t being monitored, or weren’t tuned to detect the specific activity that was happening. The lesson isn’t “buy better detection tools.” It’s “make sure the tools you have are actually useful.” Are you collecting the logs that would reveal common attack techniques? Are those logs being analyzed, or just stored? If you’re generating alerts, is anyone actually responding to them or have they become noise? Detection is only valuable if it actually detects things and if you respond when it does. Having expensive security tools that aren’t properly configured or monitored is security theater. This is one of those lessons that appears over and over. Organizations that got breached often had tools that could have detected the attack if they’d been properly implemented and used. The failure wasn’t technology—it was implementation and process. The Organizational Culture Patterns Some breach post-mortems reveal organizational culture issues that contributed to the incident. Security teams that raised concerns but weren’t listened to. Security processes that existed on paper but were routinely bypassed because they were inconvenient. Security tools that were deployed to check a compliance box but never actually used. These are harder lessons to apply because culture change is hard. But they’re important because they reveal that technical controls are only part of security. Organizational culture and process discipline matter just as much. If your organization routinely prioritizes speed over security, bypasses security reviews, or treats security as an annoying checklist rather than a real concern—you have cultural risk that no amount of technical controls fully addresses. Reading about breaches that happened partly because of cultural failures should prompt honest reflection about your own organization’s culture. The Hindsight Bias Trap When reading about a breach after the fact, it’s easy to think “how did they not see this coming?” Everything looks obvious in hindsight. The warning signs that were missed, the vulnerabilities that should have been patched, the access that should have been revoked. But in real-time, with competing priorities and incomplete information and resource constraints, those decisions probably seemed reasonable. Or at least understandable. This doesn’t mean the decisions were right. But it means you should be humble about judging them, because you’re probably making similar trade-offs in your own environment. The question isn’t “how were they so stupid” but “what similar trade-offs are we making that might look obvious in hindsight if we get breached?” That’s uncomfortable to think about. But it’s more useful than smugness. Putting It Into Practice The framework I’ve described works best when you see it applied to actual incidents. I write detailed breach analyses at cultivatingsecurity.com/category/analysis (https://cultivatingsecurity.com/category/analysis) that walk through this exact process—taking public breach disclosures and extracting actionable lessons for your environment. For example, my analysis of the Marquis Software breach examines how a 40-year-old vendor serving 700+ financial institutions appears to have lacked basic security controls like MFA on VPN accounts, adequate logging, and EDR deployment. The piece walks through: How the attack unfolded and why it took 74 days for Marquis to notify the financial institutions (their direct customers), then 104 days to notify the actual individuals whose data was compromised What the post-breach remediation reveals about control gaps that existed beforehand Why standard vendor due diligence failed to identify these issues How to translate those patterns to your own vendor risk management That’s the level of detail needed to truly extract lessons—more than we can cover in this post. If you want to see the framework in action with specific breach examples, those analyses demonstrate exactly how to move from “here’s what happened” to “here’s what it means for you.” Building Intuition The real value of learning from public breaches is building intuition over time. You start to recognize patterns. You develop a sense for what types of weaknesses are common and consequential. You build mental models of how attacks actually unfold in real environments. This intuition helps you prioritize. It helps you identify risks that matter. It helps you avoid getting distracted by exotic threats that are unlikely to affect you. It also helps you communicate risk more effectively. “Here’s a recent breach that happened because of the same type of weakness we have” is more compelling than abstract risk discussions. But building this intuition requires consistently reading about breaches and thinking critically about what they mean. Not just reading headlines—actually understanding what happened and why. Practical Takeaways Every public breach is a learning opportunity. Most people don’t extract the useful lessons from them. Look for how and why breaches happened, not just what happened. Initial access, lateral movement, detection failures, organizational weaknesses. Recognize patterns across multiple breaches. Common attack paths, common organizational failures, common cultural issues. Translate lessons to your own environment. Not “could this exact attack work” but “do we have similar weaknesses.” Distinguish between lessons that apply broadly and lessons specific to circumstances you don’t share. Avoid threat inflation. Focus on common attack patterns, not exotic sophisticated techniques unless you have reason to believe you’re a target. Pay attention to supply chain risk patterns. Third-party compromise is increasingly common. Detection failures are a recurring theme. Having tools isn’t enough—they need to be configured and monitored effectively. Cultural patterns contribute to breaches. Security processes that exist on paper but aren’t followed in practice create risk. Avoid hindsight bias. Decisions that look obvious afterward were made with incomplete information and competing priorities. Build intuition over time by consistently learning from public incidents. This helps with prioritization and risk communication. Read breach post-mortems not to feel smug but to understand what similar risks exist in your environment and how to address them. The post Week 13: Learning from Incidents You Didn’t Have (https://cultivatingsecurity.com/ftnt-13-learning-from-public-breaches/) appeared first on Cultivating Security (https://cultivatingsecurity.com).

3. 

   24 Mar 2026

   Week 12: Incident Response Is Half Politics

   You’ve planned for incidents. You have a documented incident response plan. You’ve done tabletop exercises. Your team knows their roles. You have runbooks for common scenarios. Then an actual incident happens, and you discover that the plan didn’t account for half of what actually matters. Because incident response isn’t just technical. It’s organizational, political, and human. You’re not just trying to contain and remediate a security issue—you’re managing executive panic, communicating with stakeholders who don’t understand security, making decisions with incomplete information under time pressure, and documenting everything for the inevitable post-incident review. The technical part is hard. The organizational part is often harder. And if you’re not prepared for both, you’re going to struggle even if your technical response is solid. What Actually Happens During Incidents Your incident response plan probably has clean steps: detect, contain, eradicate, recover, lessons learned. Real incidents are messier. You detect something that might be an incident or might be normal but anomalous activity. You don’t know which yet. You need to investigate without making assumptions. You start investigating and realize you don’t have the logs you need. Or the logs you have don’t go back far enough. Or the thing you’re investigating happened in a system you don’t have good visibility into. You think you’ve contained it, but then you find evidence that the attacker had access earlier than you thought. Or broader than you thought. So now your containment boundary was wrong and you have to expand it. You’re trying to eradicate the threat, but you’re not entirely sure you’ve found all the persistence mechanisms. How long do you search before you’re confident enough to say it’s gone? You’re trying to recover, but business stakeholders are pressuring you to restore systems quickly, and you’re trying to balance speed against the risk that you haven’t fully remediated. None of this is clean. All of it involves judgment calls with incomplete information. And all of it is happening while people are watching and asking questions and wanting answers you don’t have yet. Managing Executive Attention Executives care when there’s an incident. Suddenly you have attention from people who normally aren’t involved in security operations. This is both helpful and challenging. Helpful because you might get resources you wouldn’t normally get. Authority to make decisions quickly. Budget for emergency response. Organizational cooperation that would usually take weeks to coordinate. Challenging because executives want answers and certainty, and you often don’t have those yet. They want to know: What happened? How bad is it? When will it be fixed? Are we going to have to notify customers? What’s this going to cost? And your honest answers are often: We don’t know yet. We’re still investigating. It could be anywhere from minor to severe. We can’t estimate time to resolution until we understand the full scope. We’ll know about notification requirements when we know what data was accessed. That’s not satisfying. But it’s honest. And giving false certainty is worse than admitting uncertainty. What helps: Regular updates. Even if you don’t have new information, update stakeholders on what you’re doing. “We’re still analyzing logs from the authentication system. We’ve ruled out X, we’re investigating Y, we expect to have more information in two hours.” Translate technical findings into business impact. Don’t just say “we found lateral movement.” Say “the attacker accessed multiple systems, including ones that contain customer data. We’re working to determine what specific data was accessed.” Set expectations about timelines. If investigation is going to take days, say so. Don’t let executives think this will be resolved in hours just because you don’t want to give bad news. Be honest about what you don’t know. “We don’t know yet” is a legitimate answer. It’s better than speculating or giving false assurance. Have a single point of contact for executive communication. Multiple people giving updates creates confusion and inconsistent messaging. Designate one person to communicate with leadership. The Notification Decision One of the most fraught decisions during an incident is whether you’re required to notify customers, regulators, or the public. This isn’t just a security decision—it’s a legal and business decision. And it needs to be made carefully, with input from legal counsel. But security has to provide the information that drives that decision. What data was accessed? How many people are affected? What’s the evidence for and against data exfiltration? The pressure is to minimize. “We don’t have evidence that data was exfiltrated, so maybe we don’t need to notify.” But absence of evidence isn’t evidence of absence. If the attacker had access and you don’t have comprehensive logging, you might not have evidence even if exfiltration occurred. The conservative approach is to assume the worst case unless you have evidence otherwise. If the attacker had access to customer data and you can’t definitively rule out exfiltration, you probably have to notify. This creates tension with business stakeholders who want to avoid notification because of the cost and reputational damage. Your job is to provide accurate information about what you know and don’t know, and let legal and executive leadership make the decision. But you have to be clear about the uncertainty. If you say “we don’t think data was exfiltrated” and they decide not to notify based on that, and then you later find evidence that it was—that’s a problem. Be precise about what you know, what you don’t know, and what the evidence supports. Documentation Under Pressure You’re supposed to document everything during an incident. Timelines of actions taken, decisions made, evidence collected. This is critical for post-incident analysis and potential legal or regulatory proceedings. In practice, when you’re in the middle of an active incident and everyone’s working frantically, documentation often slips. People forget to log what they did. Decisions get made verbally and nobody writes them down. Evidence gets collected but the chain of custody isn’t properly documented. This is understandable but problematic. After the fact, when you’re trying to reconstruct what happened, incomplete documentation makes that much harder. What helps: Designate someone as scribe. One person whose job during the incident is to document what’s happening. Not doing technical work—just capturing the timeline, decisions, and actions. Here’s a recommendation: if your organization is big enough and the incident grows beyond initial response, get an executive admin or a business analyst from the PMO to help with this. If you force one of your technical team members to be the scribe, they’ll resent being pulled off technical work when their skills are needed elsewhere. But someone who’s good at taking notes and asking clarifying questions can be invaluable here. You’re probably already hours or even days into the incident before you realize you need dedicated documentation support. Once you get that person, take an hour or two to backfill. Go over what happened in the last few hours or days and reconstruct the timeline together. It takes time, but it’s worth it—especially if there’s eventual legal or regulatory scrutiny. Use a shared document or chat channel for incident updates. Something where everything is automatically logged and timestamped. This creates a timeline even if nobody’s actively maintaining documentation. Document decisions with rationale. Not just “we decided to isolate the server” but “we decided to isolate the server because we found evidence of data exfiltration and needed to prevent continued unauthorized access.” Preserve evidence properly. If you’re collecting logs or taking disk images or capturing memory dumps, document chain of custody. This matters if there’s ever legal action. Don’t destroy evidence accidentally. Rebuilding a compromised system cleans up the evidence of how it was compromised. Make sure you’ve collected everything you might need before you wipe and rebuild. The Communication Challenge You’re going to be communicating with different audiences who need different information. Technical team: Detailed technical information. IOCs, attack techniques, affected systems, remediation steps. They need enough detail to do their jobs. Executive leadership: Business impact. What systems are affected, what’s the impact to operations, what’s the potential for customer or regulatory notification, what resources are needed, what’s the timeline. Legal counsel: What data was potentially accessed, what evidence you have, what gaps in visibility exist, what regulatory requirements might apply. Affected users or customers (if notification is required): What happened, what data was potentially affected, what you’re doing about it, what they should do, how they can get more information. Each audience needs different levels of detail and different framing. Explaining attack techniques to executives wastes time. Giving customers vague reassurances without specific information frustrates them. Tailor your communication to the audience. And make sure the messages are consistent—you can’t tell executives one thing and customers something contradictory. The Blame Dynamic When something bad happens, people want to know whose fault it is. This is often counterproductive during incident response. Yes, maybe someone clicked a phishing link. Maybe someone misconfigured a system. Maybe someone disabled a security control that would have prevented this. But during active response, blame doesn’t help. It makes people defensive. It makes them less likely to come forward with information. It creates an environment where people are more worried about protecting themselves than solving the problem. And here’s a critical reason to avoid premature blame: you often don’t have the full picture yet. I’ve worked an incident where we detected two or three credentials being used regularly during the attack. The initial reaction from some stakeholders was to identify and confront those users. But we held off. Through investigation, we were able to confirm that two of those people had their passwords compromised—keylogger, credential stuffing from a breach, something along those lines. They weren’t involved; their credentials were just stolen and used by the attacker. If we’d blamed those people early and pushed for immediate termination, we could have gotten innocent people fired. One of the accounts we could never definitively determine—whether it was willing participation or another compromised credential. My gut says compromised, but we couldn’t prove it the same way we did with the others. Point is: during an active incident, you don’t always know who did what or whether apparent insider activity is actually an insider or just stolen credentials. Making it about blame before you have facts creates injustice and destroys trust. Save the accountability discussion for after the incident is resolved. During the incident, focus on fixing the problem. This requires discipline from leadership. If executives start demanding to know who’s responsible while the incident is still active, that needs to be redirected. “We’ll do a full post-incident review to understand what happened and how to prevent it in the future. Right now we need everyone focused on response.” Blameless post-mortems are a cultural practice worth adopting. Understand what happened, what contributed to it, what can be learned, how to prevent it in the future—without making it about punishing individuals. This creates an environment where people are more honest about mistakes and near-misses, which makes the organization more resilient. When the Plan Doesn’t Fit Your incident response plan probably covers common scenarios. Malware infection. Phishing compromise. DDoS attack. Unauthorized access. Then you get an incident that doesn’t fit any of those patterns. Or fits multiple patterns. Or involves systems or attack techniques your plan didn’t anticipate. Here’s a structural recommendation: you need an overarching incident response framework—the generic process that applies to any incident—and then specific playbooks underneath it for common scenarios. The framework covers the principles: detect, contain, investigate, eradicate, recover, document. The decision-making process. The communication structure. The escalation paths. The playbooks cover specific scenarios: “user clicked phishing link,” “DDoS in progress,” “ransomware detected.” Step-by-step guidance for that particular situation. But here’s the problem with overly prescriptive plans: real incidents don’t stay in neat categories. You might have an incident that involves phishing, credential compromise, and malware. Which playbook are you following? All of them? And if you try to put every possible notification scenario and every regulatory obligation into a single incident response plan, you end up with a 200-page document that nobody will actually use during a crisis. So keep the framework generic enough to be useful regardless of the specific incident type. Use playbooks for common patterns but understand they’re guidance, not rigid scripts. The plan is a starting point, not a script. You still have to adapt to what you’re actually seeing. This is where judgment and experience matter. Understanding principles (contain the threat, collect evidence, minimize impact) rather than just following procedures. Being able to make decisions when the playbook doesn’t give you an answer. And being willing to escalate when you’re out of your depth. If the incident involves sophisticated techniques you don’t have experience with, bring in help. That might be external incident response consultants. That might be specialists from vendors. That might be law enforcement if there are criminal implications. One important note about law enforcement: they’re not there to do your forensics or incident response. If someone committed a crime, they’ll build a case—but only if they believe they can prosecute. Their priorities and timelines are different from yours. They can be valuable partners, but don’t assume they’ll solve your incident for you. You still need your own response capability. Knowing when you need help is itself a valuable skill. The Recovery Pressure During an incident, there’s pressure to restore normal operations as quickly as possible. Every hour that systems are down costs the business money. Users can’t do their jobs. Customers can’t access services. This creates tension with thorough remediation. To be confident you’ve removed the threat, you need time to investigate, clean compromised systems, verify that persistence mechanisms are gone. Rushing this means potentially missing something and having the attacker return. But business stakeholders want systems back up. They want to know why it’s taking so long. They’re weighing the cost of continued downtime against the risk of incomplete remediation. Sometimes the right answer is strategic shutdown—taking systems offline deliberately to enable proper containment. Early in my career, I was working on a resource management team—basically server admins for a divisional office. We were fighting a worm—I can’t remember the exact name 25+ years later, but I remember it was incredibly annoying. We’d clean one system, move to the next, then the next—and before we could finish, the first system would be reinfected. Cat and mouse. Whack-a-mole. Finally I came up with an idea: “Boss, I’m taking down the network for 45 minutes.” “WHAT? NO!” “We can’t get ahead of this worm. If we take the ring down”—yes, I’m old, it was a Token Ring network—”the worm can’t move while we eradicate it. We have a very efficient cleanup process. The problem is the worm moves during the process.” We took the network down. Cleaned every system systematically while the worm couldn’t propagate. Brought it back up clean. Problem solved. The lesson: sometimes you need to create the conditions for successful remediation, even if that means deliberate downtime. But sometimes the right answer is strategic patience—not shutting things down immediately so you can ensure you’ve found everything. Years later, I was working for a retailer. We’d been in incident response for weeks after getting alerts from the card brands about compromised payment cards. We finally found something—confirmed the compromise, started notifications, and identified a system that was actively exfiltrating data. We repositioned sensors and monitoring to watch it. During an update call, an executive demanded to know why we hadn’t shut the system down immediately. I explained that while we’d found one command-and-control server, we couldn’t prove a second one didn’t exist. At that point we’d already lost tens of thousands of cards. Another day with maybe 5,000 more cards exposed wasn’t going to fundamentally change the impact, but it could help us verify we’d found everything. The executive essentially kicked and screamed to shut it down now. But we held the line. We wanted to watch the next exfiltration—what the attacker touched, what commands they issued, just to be certain we had the full picture. It paid off. During the next data exfiltration, the attacker sent a ping to a system we hadn’t suspected. We grabbed a forensic image, quickly analyzed it, and verified it was a silent secondary C2 server that we would have missed if we’d shut down the first one immediately. Then we took both systems offline simultaneously and cut off the attacker’s access completely. We monitored for three days. Not one reconnection attempt. Not one similar pattern. Clean containment. If we’d shut down the first C2 when the executive demanded, the attacker would have still had access through the second one. We’d have thought we were contained, restored operations, and the breach would have continued. The lesson: sometimes you need patience to ensure complete containment, even when stakeholders are demanding immediate action. Your job is to be clear about the trade-offs. “We can restore this system now, but we haven’t fully verified that all malware is removed. If we restore it and the attacker still has access, we might be back in the same situation.” versus “We need another six hours to complete analysis and be confident in the remediation.” Sometimes leadership will accept the risk of faster restoration. That’s their call if they understand what they’re accepting. But they need to understand it clearly—and sometimes you need to make the strategic call, whether that’s taking systems down to enable cleanup or keeping them running to ensure you’ve found everything. The Post-Incident Review After the incident is resolved, you need to do a proper post-incident review. What happened? How was it detected? How long did response take? What worked well? What didn’t work? What would we do differently? What changes do we need to make to prevent similar incidents or respond better next time? This is where you capture lessons learned and turn them into improvements. It’s also where you document the incident fully for future reference. Be honest in this review. If something didn’t work, say so. If someone made a mistake that contributed to the incident, document that without making it personal. If you got lucky and the impact could have been worse, acknowledge that. The goal is learning, not blame. The goal is making the organization more resilient, not making people feel bad about what went wrong. And actually implement the improvements that come out of the review. Too many post-incident reviews result in great recommendations that never get acted on. If you’re going to take the time to document lessons learned, follow through on them. Practical Takeaways Incident response is organizational and political, not just technical. Plan for both. Real incidents are messier than tabletop exercises. You’ll make decisions with incomplete information under time pressure. Manage executive communication carefully. Regular updates, translate technical to business impact, be honest about uncertainty. Notification decisions are legal and business decisions. Provide accurate information about what you know and don’t know. Document everything during the incident. Designate a scribe, use shared timelines, document decisions with rationale. Tailor communication to different audiences. Technical detail for responders, business impact for executives, clear information for affected parties. Avoid blame during active response. Save accountability discussions for post-incident review. Plans are starting points, not scripts. Be prepared to adapt to incidents that don’t fit the playbook. Balance recovery pressure with thorough remediation. Be clear about trade-offs and risks. Do proper post-incident reviews and actually implement the improvements. Turn incidents into learning opportunities. The post Week 12: Incident Response Is Half Politics (https://cultivatingsecurity.com/ftnt-12-incident-response-politics/) appeared first on Cultivating Security (https://cultivatingsecurity.com).

Contact Cultivating Security

Guest appearances

Does not typically book guests

Based on episode analysis; this does not confirm that the show is currently accepting guests.