Cultivating Security

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.

  1. APR 7

    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 assessm

    24 min

  2. MAR 31

    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. Hav

    17 min

  3. MAR 24

    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.

    21 min

  4. MAR 17

    Week 11: When ‘Best Practices’ Don’t Apply

    Every security framework, every certification course, every vendor white paper tells you what you should do. Implement least privilege. Segment your network. Patch within 30 days. Enforce MFA everywhere. Use zero trust architecture. All of this is good advice. In theory. In practice, you’re working in an environment with legacy systems that can’t be easily changed, technical debt that accumulated over years, resource constraints that limit what’s actually achievable, and business requirements that sometimes conflict with security best practices. So you’re left figuring out: when do I insist on the textbook approach, and when do I accept that we need a different solution that’s good enough given our constraints? This is where judgment matters. Where experience matters. Where understanding the difference between “this is suboptimal but acceptable” and “this is actually dangerous and we can’t accept it” makes the difference between being effective and being either rigid or reckless. The Legacy System Problem You have a legacy application that’s critical to the business. It runs on an operating system that’s no longer supported. It can’t be upgraded because the vendor doesn’t support newer OS versions. It can’t be replaced because it would cost millions and take years. Best practice says: don’t run unsupported operating systems. They don’t get security patches. Every vulnerability that gets discovered remains unpatched forever. Reality says: this system is running business-critical processes and it’s not going away anytime soon. So what do you do? You can’t magically make the application work on a supported OS. You can’t wave a wand and get budget for a multi-million dollar replacement project. You can’t just turn it off because the business depends on it. What you can do is implement compensating controls. Segment it so it’s not directly accessible from the internet or the general corporate network. Monitor it closely. Restrict access to only the people and systems that absolutely need it. Put additional layers of defense around it. Accept that the system itself is vulnerable, but reduce the likelihood and impact of that vulnerability being exploited. Is this ideal? No. Is it acceptable given the constraints? Sometimes yes. The judgment call is whether the compensating controls are sufficient to reduce the risk to an acceptable level. Sometimes they are. Sometimes they’re not, and you need to escalate and push for the replacement project even though it’s expensive and difficult. The Technical Debt Trap Technical debt accumulates. Applications get built with hard-coded credentials because that was expedient at the time. Service accounts get created with overly broad permissions because figuring out the minimum necessary access was time-consuming. Integrations get implemented in ways that work but aren’t secure because the deadline was tight. Best practice says: fix all of it. Implement proper secrets management. Enforce least privilege. Rebuild integrations properly. Reality says: you have finite resources and fixing all the technical debt would take years of dedicated effort that you don’t have bandwidth for. So you prioritize. What technical debt creates the most risk? What’s easiest to fix relative to the risk reduction? What can be addressed incrementally versus what requires a big-bang fix? You might decide that hard-coded credentials in production applications are unacceptable and need to be fixed even if it’s difficult. But hard-coded credentials in rarely-used internal tools are lower priority and can wait until you have time. You might decide that overprivileged service accounts with access to production databases get fixed first. Overprivileged accounts in development environments get fixed eventually but not immediately. This is triage. You’re making trade-offs based on realistic assessment of risk versus effort. Not because you don’t care about the other technical debt, but because you can’t fix everything at once and you need to focus on what matters most. The Resource Constraint Reality Best practices assume you have adequate resources. Budget for tools. Staff to implement and maintain controls. Organizational capacity for change. Leadership buy-in and support. Most organizations don’t have adequate resources. You have to work with what you’ve got. Maybe you’d like to implement a full SIEM with a security operations center. But you have budget for a basic logging solution and no headcount for analysts. So you implement what you can afford, automate what can be automated, and accept that your detection capabilities are limited. Maybe you’d like to have dedicated security engineers embedded in development teams. But you have three security people for the entire organization. So you build security champions in the dev teams, provide guidance and tools, and accept that you can’t review everything. Maybe you’d like to implement comprehensive security awareness training with simulations and role-based content. But you have budget for an annual basic training module. So you focus on the highest-risk behaviors and supplement with targeted communications about active threats. Maybe you’d like to enforce stronger access controls across legacy systems. But leadership doesn’t see it as a priority and won’t support the organizational change required. So you focus on the highest-risk systems where you can make the case, document the gaps in the rest, and work incrementally toward broader coverage when you can build more support. None of this is ideal. But it’s making realistic trade-offs based on actual constraints. The mistake would be doing nothing because you can’t do everything. Partial implementation of security controls is still better than no implementation. The Business Requirement Conflict Sometimes business requirements genuinely conflict with security best practices. The business needs to share data with partners who have weaker security practices than you’d like. Best practice would be to only share with partners who meet your security standards. Business reality is that you don’t always get to choose your partners—sometimes the business relationship is critical and you have to work with what you’ve got. The business needs to enable a workflow that requires more privileged access than you’d ideally grant. Best practice would be to redesign the workflow. Business reality is that redesigning the workflow would affect revenue-generating processes and isn’t happening. The business needs to deploy a new feature on a tight timeline that doesn’t allow for complete security review. Best practice would be to never deploy without thorough security assessment. Business reality is that missing the market window has costs too. In these situations, your job isn’t to just say no. It’s to understand the business requirement, assess the risk it creates, and figure out what mitigations are possible given the constraints. Maybe you can’t redesign the partner integration, but you can limit what data is shared and monitor the integration closely. Maybe you can’t change the privileged access requirement, but you can add additional logging and alerting. Maybe you can’t delay the feature launch, but you can implement basic security controls now and plan for improvements in the next release. You’re not accepting risk blindly. You’re making informed trade-offs with appropriate mitigations. The “Good Enough” Threshold How do you know when something is good enough versus when it’s unacceptably risky? There’s no formula. It’s judgment based on understanding the specific risk, the specific environment, and the specific constraints. Some factors that matter: Exposure. Is this accessible from the internet, or is it internal-only? Is it in a DMZ, or is it on the general corporate network? Exposure level changes the risk calculation significantly. Data sensitivity. Does this system handle customer PII, financial data, health information? Or is it internal operational data that’s not particularly sensitive? Risk to sensitive data raises the bar for what’s acceptable. Likelihood of exploitation. Is this a known, actively exploited vulnerability? Or is it a theoretical weakness that would be difficult to exploit in practice? Active threats raise urgency. Compensating controls. What other layers of defense exist? If this control is weak but there are multiple other controls that would prevent the same attack, that’s different from this being a single point of failure. Cost and complexity of improvement. Is there a straightforward fix, or would proper remediation require major architectural changes? Sometimes “good enough” is what’s achievable, and perfect is years away. Organizational risk tolerance. Different organizations have different appetites for risk based on industry, regulatory environment, and business model. What’s acceptable in a startup is different from what’s acceptable in a bank. The judgment call is weighing all of these factors and deciding whether the current state is acceptable or whether it needs to be escalated and addressed despite the difficulty. When to Insist on Best Practice There are situations where you shouldn’t compromise. Cryptography. Don’t accept weak encryption because it’s easier to implement. Don’t accept custom cryptography because someone thought they could do better than standard algorithms. This is an area where best practices should be followed strictly because the consequences of getting it wrong are severe and the expertise required to do it correctly is specialized. Authentication to critical systems. MFA for administrative access to production s

    20 min

  5. MAR 10

    Week 10: Compliance Is Not Security (But You Still Have to Care)

    Every security person eventually has this realization: passing the audit doesn’t mean you’re secure. You can check every box in the compliance framework. You can get your SOC 2 certification. You can satisfy your PCI audit. And still have significant security gaps that the auditor never looked at because they weren’t in scope. Compliance frameworks test for specific controls. They verify that you’re meeting defined requirements. They don’t assess whether those requirements are sufficient for your actual risk profile. They don’t test for risks that aren’t in the framework. They don’t evaluate how well your security program actually functions beyond what’s documented. But here’s the thing: you still have to care about compliance. Because compliance failures have immediate business consequences. Customer contracts depend on it. Regulatory penalties apply when you’re non-compliant. Business opportunities get lost if you can’t demonstrate compliance. So you’re stuck navigating this tension: compliance isn’t security, but you can’t ignore it. You need to pass audits without letting audit requirements become your entire security program. What Compliance Actually Tests Compliance frameworks test for the presence of controls and documented processes. They verify that what you say you do is what you actually do. “Do you have a documented information security policy?” Yes. Box checked. “Do you perform background checks on employees with access to sensitive data?” Yes. Box checked. “Do you have a process for reviewing user access quarterly?” Yes, here’s the documentation. Box checked. This is not trivial. Having documented policies and processes matters. Consistency matters. Being able to demonstrate that you’re following your own policies matters. But it doesn’t tell you whether your policies are adequate. Whether your access review process actually catches inappropriate permissions. Whether your incident response plan would work during a real incident. Auditors are testing against a standard, not against your specific risks. They’re verifying that controls exist, not that those controls are effective for your environment. The Scope Problem Audits have scope boundaries. They test the systems and processes that are in scope. Everything else is excluded. Your SOC 2 audit might cover your production environment. Your development environment isn’t in scope. Your DevOps pipeline isn’t in scope. Your SaaS applications might not be in scope. Your PCI audit covers the cardholder data environment. Everything that’s properly segmented out of the CDE isn’t in scope. This creates blind spots. Systems that matter for your security posture but aren’t included in compliance scope don’t get tested. Risks that aren’t addressed by the compliance framework don’t get evaluated. You can be fully compliant and still have significant security issues in out-of-scope systems or risks that the framework doesn’t address. Understanding scope is critical. Compliance tells you something about the systems and controls that were tested. It tells you nothing about what wasn’t tested. The Documentation vs. Reality Gap Auditors test documentation. They verify that your processes are documented and that you can show evidence of following them. If your documentation says you review access quarterly and you can produce evidence of those reviews, you pass. Whether those reviews actually resulted in removing inappropriate access is a different question. If your incident response plan is documented and you can show that people are trained on it, you pass. Whether it would actually work during a high-stress incident with incomplete information is not tested. If your change management process is documented and you can show approval records, you pass. Whether unapproved changes happen anyway because the process is too cumbersome and people work around it—that might not be visible to the auditor. Compliance measures adherence to documented processes. It doesn’t measure effectiveness of those processes or whether people actually follow them consistently. This creates an incentive to optimize for the audit rather than for actual security. Make sure the documentation is clean, make sure the evidence is available, make sure you can demonstrate compliance. Whether the security posture is actually strong is secondary. Good organizations resist this incentive. They use compliance as a minimum baseline and build beyond it. Less mature organizations treat compliance as the goal and stop there. The Snapshot Problem Audits are point-in-time assessments. They look at your security posture during the audit period, verify controls, and issue a report. That report becomes stale immediately. Your environment changes. New systems get deployed. Configuration drift happens. People leave and new people join. The documented state that passed audit diverges from current reality. Some compliance frameworks require continuous monitoring or periodic re-assessment. That helps. But there’s always a gap between the last time something was verified and the current state. Organizations with weak security discipline let that gap grow large. They tighten up for the audit, pass, then drift back to less rigorous practices until the next audit cycle. Organizations with strong security discipline maintain consistent practices regardless of audit timing. The audit verifies what they’re already doing. But either way, a compliance certification tells you what was true when it was issued. Not what’s true now. When Compliance and Security Align There are areas where compliance requirements and good security practice overlap significantly. Access controls. Most frameworks require some form of least privilege and access review. That’s also good security practice. Logging and monitoring. Frameworks typically require audit logging. That’s foundational for security as well. Encryption. Frameworks require protecting data in transit and at rest. That’s baseline security. Incident response. Having a documented plan and testing it is both a compliance requirement and a security necessity. In these areas, compliance requirements push organizations to do things they should be doing anyway. The compliance forcing function can be valuable—it creates business pressure to implement controls that might otherwise get deprioritized. This is where you can leverage compliance to advance security. “We need to do this to pass the audit” is often an easier sell than “we should do this for security reasons.” Use that when it works. Where Compliance Falls Short Compliance frameworks are generic. They’re designed to apply to many different types of organizations. That means they can’t be optimized for your specific risk profile. You might have unique risks that the framework doesn’t address. You might be in an industry with specific threats that generic frameworks don’t account for. You might have architectural patterns that create vulnerabilities the framework doesn’t test for. Compliance gives you a baseline. It doesn’t give you a complete security program. Frameworks also tend to lag behind threat evolution. By the time a control becomes a compliance requirement, it’s often already considered baseline security practice. The bleeding-edge threats and risks aren’t in the framework yet because there isn’t consensus on how to address them. If you’re only doing what compliance requires, you’re behind. Compliance is the floor, not the ceiling. The Audit Relationship Auditors are evaluating you against a standard. They’re not adversaries, but they’re also not consultants there to help you improve. Their job is to verify that you meet the requirements. They’re looking for evidence of compliance. When they find gaps, they document them as findings. How you respond to findings matters. Some findings are legitimate—you’re not meeting a requirement and you need to fix it. Some findings are debatable—you’re meeting the requirement differently than the auditor expected, or there’s ambiguity in how the requirement should be interpreted. You can push back on findings if you have a legitimate case. But pick your battles. Fighting every finding burns relationship capital and creates friction that might make future audits harder. It’s also worth building a good working relationship with your auditors. Being organized, responsive, and transparent makes the audit process smoother. Trying to hide problems or being difficult to work with makes auditors dig deeper. Auditors talk to each other. Your reputation with auditors affects how they approach your audit. If you’re known as an organization that takes compliance seriously and is straightforward to work with, that helps. If you’re known as an organization that cuts corners and fights everything, that works against you. Using Compliance as a Forcing Function Compliance requirements can be useful for getting resources and organizational buy-in for security work. “We need to implement MFA to maintain our SOC 2 certification” is often more compelling than “we should implement MFA because it’s good security practice.” “We have an audit finding that requires remediation by end of quarter” creates urgency that “we should probably address this risk at some point” doesn’t. “Customer contracts require us to maintain PCI compliance” is a business driver that’s hard to argue with. This isn’t manipulation. It’s recognizing that different stakeholders respond to different motivations. Leadership might not prioritize security risk in the abstract, but they will prioritize avoiding failed audits or lost business

    17 min

  6. MAR 3

    Week 9: Reading the Room: What Your CISO Actually Cares About

    If you’re trying to get security work done, you need to understand what your leadership cares about. And I mean actually cares about, not what they say in all-hands meetings or what’s in the security strategy document. Because there’s often a gap between the official priorities and the real priorities. Between what sounds good and what actually drives decisions. Between the aspirational vision and the day-to-day reality of what gets resources and attention. This isn’t about your CISO being dishonest. It’s about the difference between what they wish they could focus on and what they’re actually accountable for. Between long-term strategic goals and immediate pressures. Between building the ideal security program and managing the organization they actually have. Understanding this gap—and learning to operate effectively within it—is critical. Because if you’re optimizing for what you think leadership cares about instead of what they actually care about, you’re going to be confused when your priorities don’t get support. The Board and Executive Pressure Your CISO has a boss. Usually it’s the CEO or CFO or CIO. And that person has priorities that shape what your CISO can realistically focus on. If the board is asking about cybersecurity risk quarterly, that’s going to drive attention to board-presentable security initiatives. Things that show measurable progress. Things that can be explained to non-technical executives. Things that demonstrate the organization is taking security seriously. That might mean compliance certifications even if they’re not the most impactful security work. That might mean high-visibility projects like MFA deployment even if there are more critical but less visible gaps. That might mean metrics that look good in a board deck even if they’re not the most meaningful security measurements. This isn’t your CISO being shallow. This is them managing upward to people who control budget and strategic direction. If the board cares about something, the CISO has to care about it—or at least has to show they’re addressing it. Similarly, if the CEO is worried about customer trust, security work that protects customer data gets prioritized. If the CFO is worried about financial risk, security work that prevents fraud or reduces insurance premiums gets attention. If the business is pursuing enterprise customers who require SOC 2, that becomes the priority. Your CISO’s priorities are shaped by what their leadership cares about. If you want to understand what will get resourced, start there. The Audit and Compliance Reality A lot of CISOs spend more time on compliance than they’d like. Not because compliance is the most important security work, but because compliance failures have immediate, measurable consequences. Audit findings have remediation deadlines. Compliance certifications affect customer contracts. Regulatory requirements have penalties for non-compliance. These create forcing functions that security improvements often don’t have. Your CISO might know that improving detection capabilities is more valuable than fixing the specific audit finding. But the audit finding has a deadline and potential business impact. The detection capability is important but not urgent. So compliance work gets prioritized. Not because it’s the best security work, but because it’s the security work with clear deadlines and clear consequences for not doing it. Understanding this helps you frame security initiatives. If you can connect your project to compliance requirements, it’s more likely to get resources. If you’re proposing work that’s purely about risk reduction without any compliance component, you’re competing against things that have regulatory or contractual forcing functions. That doesn’t mean you can’t get non-compliance work funded. But you need to make a stronger case, because it doesn’t have the built-in pressure that compliance work has. (We’ll dive much deeper into the compliance-versus-security tension in Week 9. For now, just understand that your CISO is navigating this dynamic constantly—compliance creates forcing functions that security risk assessments often don’t.) The Incident Pressure If your organization has had a security incident recently, that shapes priorities dramatically. The weakness that got exploited suddenly gets attention. If it was a phishing attack, now there’s budget for security awareness training. If it was unpatched vulnerabilities, now there’s pressure to improve patch management. If it was inadequate logging that made investigation difficult, now there’s support for logging improvements. This is unfortunate because it means security improvements are reactive rather than proactive. But it’s also reality. Incidents create urgency and political will that risk assessments often don’t. Your CISO is operating in this environment. If there’s been a recent incident, proposals that address similar risks get easier approval. Proposals that address different risks have to fight harder for attention. If your organization hasn’t had a major incident, there’s less urgency generally. Security is important, but it’s competing with other important things that have more immediate pressure. The other dynamic is incident preparedness. If your CISO is worried about the next incident (because of industry trends, peer organizations getting hit, increasing threat activity), they’re going to care about detection, response capabilities, and forensic readiness. Projects that improve those capabilities align with that concern. The Resource Constraints Your CISO is managing with finite budget, finite staff, and finite organizational capacity for change. They might know that the ideal security program includes a dozen major initiatives. But they can realistically fund three this year. They have to choose. They might want to hire five more security analysts. But they’re approved for two headcount and they’re competing with every other department that also wants to hire. They might want to implement comprehensive security improvements. But the IT team is already overloaded, and asking them to take on more work means something else gets delayed or dropped. These constraints are real. Acknowledging them when you’re proposing work shows you understand the environment you’re operating in. This ties directly back to what we covered in Week 7 about why security projects fail. Budget competition, finite staff capacity, and organizational bandwidth constraints aren’t excuses—they’re the reality your CISO navigates every day. Understanding these constraints helps you propose work that can actually succeed. This means being realistic about scope. Proposing a multi-year initiative when there’s budget for a one-year pilot. Proposing something that can be implemented with existing staff or modest contractor help rather than requiring three new headcount. Proposing something that integrates with current work rather than requiring a separate dedicated effort. Your CISO is looking for proposals that deliver value within realistic constraints. Not proposals that require perfect conditions and unlimited resources. The Risk They’re Actually Worried About Your CISO has a mental model of the organization’s biggest security risks. That model might not match yours. Maybe you think the biggest risk is inadequate network segmentation. They think it’s third-party vendor risk because of recent supply chain attacks in your industry. Maybe you think the priority should be improving vulnerability management. They think it’s insider threat because of recent employee incidents. Maybe you think the focus should be technical controls. They think it’s security culture because the organization keeps making the same mistakes. Understanding what they’re actually worried about—not what the risk assessment says, but what keeps them up at night—helps you align your work with their priorities. Sometimes you can learn this from direct conversation. “What are you most concerned about right now?” is a reasonable question. Sometimes you can infer it from what gets attention and resources. What do they ask about in meetings? What do they fund even when budget is tight? What do they escalate when incidents happen? If you’re proposing work that addresses a risk they’re not worried about, you need to make the case that they should be worried about it. If you’re proposing work that addresses a risk they are worried about, you’re aligned with their existing priorities and you’ll get a much warmer reception. The Measurable Progress Problem Leadership loves metrics. Your CISO probably has to report security metrics to executive leadership or the board. This creates pressure to work on things that produce measurable improvement. Patch compliance percentages. Percentage of systems with MFA. Number of security training completions. Time to detect and respond to incidents. Not all valuable security work produces clean metrics. Cultural change is hard to measure. Architectural improvements might not show up in standard dashboards. Detection engineering doesn’t produce a simple percentage. But measurable work gets reported up the chain. It shows progress. It demonstrates that the security program is doing something. Your CISO cares about work that produces results they can show their boss. If your proposal will improve security but won’t produce any measurable evidence of that improvement, that’s a harder sell. This doesn’t mean you should only work on things that produce metrics. But it does mean that if you can articulate how success will be measured and demonstrated, your proposal becomes more attractive. The Political Capital B

    18 min

  7. FEB 24

    Week 8: Why Security Projects Fail (And It’s Usually Not Technical)

    You’ve probably seen this: a security initiative that makes perfect technical sense, that addresses real risk, that has clear value—and it dies anyway. Not because the technology doesn’t work. Not because the solution is flawed. It dies in a conference room during a budget meeting, or gets deprioritized when a business initiative takes precedence, or gets killed because nobody wants to deal with the organizational change it requires. Security projects fail for organizational and political reasons far more often than they fail for technical reasons. And if you don’t understand those dynamics, you’re going to keep proposing good ideas that go nowhere, and you’re going to get frustrated wondering why leadership “doesn’t take security seriously.” Often they do take it seriously. They’re just managing constraints and priorities that you might not see or understand. Your job is to figure out how to work within those constraints, or how to change the constraints if they’re actually fixable. A note on broader applicability: This post focuses on security projects specifically, but the organizational dynamics we’re covering—budget competition, change resistance, executive sponsorship, political navigation—apply to ANY initiative that requires organizational change and resources. If you’re a network engineer trying to get budget for infrastructure upgrades, a developer advocating for technical debt reduction, or an operations manager proposing process improvements, the same patterns apply. Understanding these dynamics makes you more effective regardless of what type of initiative you’re trying to drive. The Budget Reality Security competes with everything else the organization needs to spend money on. That SIEM you want? That’s $200K annually. Which is also three mid-level engineers. Or a business analyst the sales team has been requesting. Or infrastructure upgrades that have been delayed for two years. Or the CRM implementation that’s going to improve customer retention. Money is finite. Saying “security is important” doesn’t create budget. Every dollar spent on security is a dollar not spent on something else. Your leadership is making trade-offs constantly. Revenue-generating initiatives tend to get prioritized because they justify themselves—”if we invest X, we’ll generate Y in additional revenue.” That’s a clear ROI calculation. Security investment is about avoiding negative outcomes. “If we invest X, we reduce the probability of a breach that might cost Y.” That’s a risk reduction calculation, which is inherently squishier and less compelling. It shouldn’t be that way. The cost of a breach can be quantified reasonably well. But psychologically, spending money to enable growth is more appealing than spending money to prevent hypothetical harm. Understanding this dynamic doesn’t mean accepting inadequate security budgets. It means framing your requests in ways that acknowledge the reality of budget competition and make the clearest possible case for why this particular investment matters more than the alternatives. The Organizational Change Problem A lot of security improvements require people to change how they work. And people hate changing how they work. Implementing MFA means users have to do an extra step when they log in. Rolling out a new access review process means managers have to spend time reviewing permissions. Enforcing least privilege means people lose access they’ve had for years and have to request it when they need it. These are all reasonable security measures. They’re also friction. And friction generates resistance. Sometimes the resistance is loud. “This is going to slow us down.” “This is going to hurt productivity.” “Users are going to hate this.” Sometimes it’s passive—people just don’t do the thing, or they find workarounds, or they complain until leadership caves. Either way, if your security project requires organizational change and you haven’t planned for managing that change, you’re going to struggle. This means communication. Explaining why the change is happening, what the actual impact will be, how it benefits people (or at least the organization). It means providing support during the transition—help desk staffing for the initial rollout, documentation, training. It means having executive sponsorship so that when people push back, leadership reinforces that this is happening. A lot of security people treat this as someone else’s problem. “I designed the technical solution, implementation is operations’ job, change management is HR’s job.” But if you care whether the project succeeds, you care about adoption. And adoption requires managing the human factors, not just the technical ones. The “Not Right Now” Problem Even when people agree a security project is valuable, it’s often not the highest priority right this moment. There’s a major product launch coming. There’s an acquisition being integrated. There’s a regulatory audit happening. There’s a system migration in progress. There’s always something. “Let’s do this after the launch.” “Let’s wait until the audit is done.” “Let’s revisit this next quarter when things calm down.” Sometimes this is legitimate. Timing matters. Implementing major security changes during a critical business period might genuinely be a bad idea. Sometimes it’s avoidance. Next quarter there will be a different reason why it’s not the right time. Things never actually calm down. This is how security work gets perpetually deprioritized. The difference is whether there’s actually a plan to revisit it or whether “not right now” is a soft no. If leadership says “this is important but we need to wait until after the product launch, let’s schedule planning for next month,” that’s different from “we’ll get to this when we have time” with no actual commitment. Your job is to distinguish between realistic timing constraints and indefinite deferral disguised as timing constraints. The Executive Sponsorship Gap Security projects that don’t have executive sponsorship rarely succeed. You can have the best technical plan. You can have identified a real risk. You can have a clear implementation path. But if nobody with organizational authority is backing it, it’ll get killed the first time it creates friction or competes with something else. Executive sponsorship means someone in leadership who will say “this is happening” when people push back. Someone who will defend the budget when it’s challenged. Someone who will prioritize it when other initiatives compete for resources. Someone who has the authority to make decisions and the political capital to make them stick. Without that, you’re trying to implement organizational change through force of argument and technical competence. Which doesn’t work when you don’t have decision-making authority. Finding an executive sponsor means understanding who cares about what you’re trying to accomplish and why. Maybe it’s the CFO who’s worried about financial risk. Maybe it’s the COO who’s concerned about operational disruption. Maybe it’s the General Counsel who understands regulatory exposure. Frame the security work in terms they care about. Build the relationship. Get them bought in. Then they can be your advocate in rooms you’re not in. The Competing Priorities Reality Organizations have finite attention and capacity. Even if budget isn’t the constraint, bandwidth is. The IT team is already working on five major projects. The infrastructure team is underwater dealing with technical debt. The application team is fully allocated to new feature development. The operations team is firefighting daily. Your security project requires time and effort from all of them. Where does that time come from? Either something else gets deprioritized (which means someone else’s project gets delayed or killed, and they’re not going to be happy about that), or people work more hours (which isn’t sustainable and leads to burnout), or your project gets sequenced after their current work (which means it’s delayed, possibly indefinitely). This is the reality of working in organizations. Everything competes for the same resources. Your project isn’t evaluated in isolation—it’s evaluated against everything else people could be doing instead. Understanding this means being realistic about timing and scope. Maybe you can’t do the full implementation right now, but you can do phase one. Maybe you can’t get dedicated resources, but you can get part-time support. Maybe you can’t launch in Q2, but you can realistically launch in Q4. Flexibility in how you approach the work makes it more likely to actually happen. The “We Already Did Security” Problem Sometimes organizations think they’ve already addressed security adequately, and new initiatives are viewed as unnecessary. “We already have a firewall.” “We already do patching.” “We already have antivirus.” “We already passed the audit.” Therefore, additional security investment must not be needed. This is frustrating because security isn’t binary. Having basic controls doesn’t mean you have adequate controls. Passing an audit doesn’t mean you’ve addressed all your risks—it means you’ve met the specific requirements that audit tested. But try explaining that without sounding like you’re moving goalposts or just asking for more budget because security is never done. The way through this is demonstrating gaps clearly. Not theoretical risks—actual gaps in visibility, detection, or capability. “We have a firewall, but we can’t detect lateral movement inside the network.

    21 min

  8. FEB 17

    Week 7: Reporting to IT: How to Build Security When You’re Not in Charge

    A lot of security people find themselves in this position: you’re the security person, or the security team, reporting up through IT leadership that didn’t come up through security. Maybe your boss is the CIO who built their career in infrastructure. Maybe it’s an IT Director who came up through application development or helpdesk management. Maybe it’s a VP of Technology who understands the business side but not necessarily the security nuances. Or maybe it’s someone in a non-technical role entirely—a VP of Operations, a Chief Administrative Officer, whoever happened to have budget room when the organization finally decided they needed “someone doing security.” You got placed there not because it made organizational sense, but because they didn’t know where else to put you. Nothing wrong with those backgrounds. But the risk calculus is different when you’re thinking about security versus when you’re thinking about delivering projects, maintaining uptime, or supporting users. And if you’re reporting to someone in a non-technical role, that gap can be even wider—you’re translating not just security to IT, but security to business operations without a shared technical foundation. Either way, that difference creates friction that you need to navigate if you’re going to get anything done. This isn’t an impossible situation. Plenty of people build effective security programs while reporting through IT or operations. But it requires skills that aren’t technical—communication, political awareness, strategic patience, and the ability to pick your battles. The Fundamental Tension IT and security have overlapping responsibilities but fundamentally different objectives. IT is measured on delivery. Did the project launch on time? Are systems available when users need them? Are tickets getting resolved? Are users happy? Success is visible and tangible. Security is measured on things not happening. No breaches. No compliance failures. No incidents. Success is invisible, and when you’re doing your job well, it looks like you’re not doing much of anything. That creates a natural tension. IT wants to move fast, deliver projects, say yes to business requests. Security’s job is to make sure those things happen in ways that don’t create unacceptable risk. Here’s where a lot of security people get it wrong: they think their job is to say no. It’s not. Your job is to say “here’s the risk, here are options for managing it, here’s what I recommend, and here’s what happens if we don’t.” That’s a completely different conversation than just “no.” When your IT leadership came up managing infrastructure or applications, their instinct is to solve problems by delivering solutions. Security means helping them deliver those solutions in ways that manage risk appropriately—which sometimes means different approaches, additional controls, or adjusted timelines, but it shouldn’t mean “we can’t do this.” That’s not a personality conflict. It’s structural. And understanding that it’s structural—not personal—helps you navigate it more effectively. Excellent point – this is a HUGE problem. IT using security as the scapegoat/bad guy without actually consulting security is incredibly common and damaging. This probably fits better in a different section though – maybe under “Common Pitfalls” or “What Makes This Harder” rather than “Fundamental Tension.” Here’s why: The fundamental tension is about legitimate structural differences in objectives. What you’re describing is a dysfunctional communication pattern that makes everything worse. When IT Speaks for Security (Without Asking) Here’s a dynamic that complicates everything: IT managers citing security as the reason for decisions without actually consulting security. ‘Security won’t allow it’ becomes the convenient explanation for things they don’t want to do—maybe it’s extra work, maybe it’s technically challenging, maybe they just think it’s a bad idea. Now you’re positioned as the obstacle before you’ve even seen the request. When you do show up to meetings, people expect you to say no—because someone’s already been saying no on your behalf. Sometimes this is well-intentioned. They genuinely think you’d object, so they’re trying to save everyone time. But they’re also putting words in your mouth and framing security as the department of no before you’ve even seen the request. Other times it’s strategic. Security becomes the convenient excuse for not doing things they don’t want to do for completely unrelated reasons. It’s easier to blame security policy than to explain they don’t have the resources, or don’t think the project is a good idea, or just don’t want to. Either way, it’s a problem. Because now when you do show up to meetings, people expect you to say no. You’ve been positioned as the obstacle before you even open your mouth. And when you actually do raise legitimate security concerns, people assume you’re just doing your “security says no” routine again. You can’t completely prevent this, but you can address it: Make yourself available for consultation before decisions get made. If IT can easily ask “would security have issues with this?” they’re less likely to guess at your answer. When you find out it’s happened, have a direct conversation with the person who spoke for you. Not confrontational—just “hey, next time loop me in before using security as the justification, because I might have a different take.” Be consistent about your actual positions. If people know where you actually stand on common issues, they can’t as easily invent objections on your behalf. And when you’re in meetings, be explicit about what you’re actually concerned about versus what you’re fine with. Don’t let people fill in blanks about your position. Understanding Non-Technical Leadership If your boss has a strong technical background but not specifically in security, they understand technology but might not intuitively grasp security risk the way you do. They know what a vulnerability is, but they might not have the pattern recognition to distinguish between “this is bad” and “this is drop-everything critical.” They understand access controls conceptually, but they might not see why least privilege matters so much. They get that patching is important, but the urgency of a critical vulnerability in an internet-facing system might not register the same way. This isn’t ignorance. It’s just a different mental model built from different experience. If your boss doesn’t have a deep technical background at all, the challenge is different. They need you to translate technical risk into operational and business impact. “This vulnerability could allow lateral movement” doesn’t mean anything to them. “If this gets exploited, we lose access to our primary business application and potentially trigger breach notification requirements under state law”—that’s actionable. But here’s the fine line: when you’re translating risk into business impact, you can easily slip into scare tactics—either intentionally or without realizing it. And once you do that a few times, once you cry wolf about critical risks that don’t materialize into actual incidents, your credibility is gone. They start viewing everything you say as overblown. When you actually do have a drop-everything problem, they won’t believe you. So be careful with your language. Have data. Have justification. Don’t say “this could lead to a catastrophic breach” when what you mean is “this is a gap we should close but the exploitability is low and we have other controls in place.” Save the urgent language for things that are actually urgent. They’re managing budgets, vendor relationships, board expectations, competing priorities across IT, and a dozen other things you might not see. Your job is to help them understand security risk in that broader context—accurately, not dramatically. What Actually Works Speak their language. Risk in terms of business impact, not technical details. “This creates compliance exposure” is better than “the encryption implementation is weak.” “This could cause a production outage” is better than “the architecture violates security principles.” You need to be able to explain why something matters in terms they care about. Revenue impact. Regulatory penalties. Customer trust. Operational stability. Audit findings. Those are the frames that resonate. Understand their pressures. IT leadership is constantly balancing competing priorities. If you come in with “we need to do this immediately” every week, you’ve trained them to ignore you. Not everything is actually urgent. Some things are important but can be scheduled. Some things are nice-to-have. Learning to distinguish between “drop everything” and “let’s plan this for next quarter” and “we should do this when we have time” is critical. If you make everything urgent, nothing is. If you’re consistently accurate about what’s actually urgent versus what can wait, you build credibility. Build credibility through small wins. You’re not going to get budget for a SOC on day one. You’re going to get budget for MFA after you’ve demonstrated that the phishing simulation you ran (which cost almost nothing) revealed a genuine problem. And a note on those phishing simulations: stop doing “gotcha” phishing that’s designed to trick people and then shame them. That builds resentment, not awareness. Do educational phishing that reinforces what you’ve actually trained people on. Start with obvious examples, progressively make them harder as people get better. T

    26 min
See All (20)

About

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.

Information

  • Creator
    Cultivating Security
  • Years Active
    2025 - 2026
  • Episodes
    20
  • Rating
    Explicit
  • Copyright
    © 2026 Cultivating Security. All rights reserved.
  • Show Website
    Cultivating Security