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. The goal is to build skills and confidence, not to catch people failing so you can prove you were right about needing security training.

Show that you understand the business. Deliver value incrementally. Prove that you’re not just identifying problems but helping solve them in ways that are realistic for the organization.

Document clearly but professionally. When you raise a risk and it doesn’t get addressed, document it. Not in a “cover your ass” way that’s obvious and annoying, but professionally.

Email summary after meetings. Risk register that’s maintained. Clear, factual documentation of what was discussed, what was decided, what the rationale was.

If risks you’ve documented do materialize, having a track record of having raised them—not to say “I told you so,” but to establish that your risk assessment is calibrated correctly—builds credibility for the next time you raise something.

Align with their goals. If IT is measured on project delivery, figure out how to make security an enabler rather than a blocker.

“We can get you to production faster if we build this in from the start rather than trying to retrofit it during UAT” is much more effective than “you need to delay launch for security review.”

Find ways to frame security work as helping them achieve their objectives, not preventing them from achieving their objectives.

Pick your battles. Not every hill is worth dying on.

Here’s what this actually means: You raise a risk. You explain it clearly. You document it. Leadership decides not to address it right now—maybe because of budget, maybe because of competing priorities, maybe because they assess the likelihood differently than you do. Your job at that point is to accept the decision and move on. You’ve done your part by identifying and articulating the risk. You’ve given them the information to make an informed choice. If they decide the risk is acceptable given everything else on their plate, that’s their call to make.

Document this in your risk register. The risk, the recommendation, the decision not to address it, who made that decision, and when. This isn’t about blame—it’s about having a factual record of organizational risk acceptance.

Other risks are different. These are the ones where the potential impact is severe enough, and the likelihood is high enough, that you can’t just document and move on. For these, you need to understand why the answer was no and whether there’s a path forward. We’ll dive deeper into how to navigate those situations in the next section on political navigation.

Wisdom is knowing the difference. And understanding that even when you do everything right on a critical risk, leadership might still make a choice you disagree with. That’s not failure on your part. That’s organizational risk acceptance.

If you fight everything with the same intensity, you’ll lose credibility and burn out. If you’re selective—if you clearly differentiate between ‘here’s a risk to be aware of’ and ‘this requires more thorough discussion before we decide’—people learn that when you say something is critical, you mean it.

The Political Navigation

You’re going to encounter situations where leadership makes decisions you disagree with. Sometimes because they have context you don’t. Sometimes because they’re willing to accept risk you’re not comfortable with. Sometimes because they’re just wrong.

Learning to tell the difference is important.

When it’s context you’re missing: Ask questions. Understand the trade-offs being made. This is where “Help me understand what’s driving this decision” becomes critical.

Maybe it’s budget constraints—there’s no money this year, but it could be revisited next quarter. Maybe it’s resource contention—finishing another critical project would be delayed if people get pulled to work on this. Maybe it’s that they assess the likelihood differently than you do and need more evidence. Maybe it’s organizational politics you’re not seeing. Maybe you didn’t present it clearly enough and they didn’t fully grasp the impact.

That information is valuable. It tells you what you need to address to get a different answer. If it’s budget, you can propose a phased approach or wait for the next cycle. If it’s resource contention, you can help find ways to reduce the implementation burden or adjust the timeline. If they need more evidence, you can gather it. If your presentation wasn’t clear, you can reframe it in terms that resonate better with their priorities.

Sometimes you get there. You understand the objection, you address it, and the answer changes from “no” to “yes, if we do it this way” or “yes, next quarter.” That’s a win, and it happened because you listened and adapted rather than just pushing harder with the same approach.

Sometimes there are business constraints you’re not aware of. Customer commitments that shape priorities. Strategic initiatives that haven’t been announced yet. Budget realities that aren’t your problem to solve.

If they have context that changes the risk calculation, that’s legitimate. Your job is to make sure they understand the security implications; their job is to make the decision in the broader context they’re managing.

When it’s acceptable risk: Document it clearly. Make sure the decision-maker understands what they’re accepting and what the potential consequences are. Then move on.

You don’t have to agree. But if they’re accountable for the decision and they’re making it with clear understanding of the risk, that’s their call to make.

At that point, you document the final decision in your risk register—including what you tried, what their reasoning was, and the fact that this is a deliberate acceptance of known risk.

It’ll feel wrong sometimes. You’ll see risks that make you uncomfortable. But if you can’t let go of decisions that have been made by people with the authority to make them, you’ll be miserable.

Whether you can live with that outcome is a personal decision about whether this organization’s risk tolerance aligns with yours. (If you haven’t read Week 2’s sections on understanding and calibrating risk tolerance, go back and read those now—this is where that concept becomes very real in practice.)

When it’s genuinely wrong: Escalate carefully. Bring data. Bring business impact. Bring regulatory implications if they exist.

Don’t make it personal. Don’t make it emotional. Make it about the risk and the consequences and why this particular decision creates exposure the organization shouldn’t accept.

And understand that the decision might still not change. That’s not you “losing.” That’s the organization choosing a level of risk that you might not be comfortable with—and that’s their right. It’s not your business that you own. You’ve done your job by clearly articulating the risk and the potential consequences.

This is where calibrating your risk tolerance to organizational reality becomes essential. (If you haven’t read Week 2’s sections on understanding and calibrating risk tolerance, go back and read those now—this becomes critically important when you’re facing these decisions in practice.)

Most of the time, with experience and context, you’ll find you can adapt. You’ll learn to distinguish between risks that genuinely keep you up at night and risks that feel uncomfortable but are actually reasonable business decisions given the organization’s constraints. That calibration is part of professional growth.

Sometimes there are genuine misalignments—organizations that are reckless in ways that cross ethical or professional lines. But that’s rare. More often, it’s about learning to work effectively within an organization’s actual risk appetite rather than chasing the theoretical perfect state you might prefer. (Remember Week 2: Fort Knox isn’t the goal. Perfect security that nobody uses, that creates so much friction people work around it, that consumes resources needed elsewhere—that’s not security, it’s security theater that makes things worse. If you’re struggling with this concept, go back and read that entire post.)

The Organizational Structure Problem

Here’s the uncomfortable truth: if you’re a team of one or two reporting through IT, there’s a ceiling on what you can accomplish.

You can build solid foundations. You can prevent a lot of common problems. You can mature processes incrementally. But you can’t transform the security posture of an organization from that position.

Security as a function reporting through IT signals something about organizational priorities. It says security is an operational concern that IT manages, not a strategic concern that gets executive attention.

That might be appropriate for some organizations. Small companies where IT and security overlap significantly. Mature environments where security is already in good shape and just needs maintenance. Non-regulated industries where the risk profile is genuinely lower.

But for a lot of organizations, especially as they grow, that structure becomes a constraint. Security needs input where business decisions get made—not necessarily a C-level executive role, but a position where you’re consulted and brought in early to planning rather than being the afterthought or the checkbox item. It needs the ability to influence architecture at the design stage, not review it after implementation is done.

(I’ve written about this concept more fully in Security Third: Why “Security First” Makes Organizations Less Secure—the goal isn’t to put security above everything else, but to make security an everyday consideration woven into how the organization works.)

Your job in the current structure is to do good work, build credibility, and position yourself (or your successor, or the function) for that evolution when it comes.

Sometimes the transition happens because of growth—the organization reaches a size where security reporting through IT doesn’t make sense anymore. Sometimes it happens because of an incident that makes leadership realize security needs more attention. Sometimes it happens because of regulatory pressure or customer requirements.

If you’re doing your job well, you’ll help accelerate that evolution by demonstrating the value of security as a function and building the case for why it needs different organizational positioning.

Recognizing Challenges and Finding Paths Forward

Some organizational dynamics are challenging but workable. Some are warning signs that need attention. Here’s what to watch for and what you can do about it.

Every security proposal gets killed on cost without real discussion of risk. If the answer is always “too expensive” without actually weighing the cost against the risk, you’re not having real conversations about security.

What you can do: Start quantifying risk in business terms. Not “we need this security tool,” but “here’s what it costs if this risk materializes, here’s the likelihood, here’s what mitigation costs.” Make it a business decision, not a security decree.

Partner with finance if they exist—they speak the language leadership understands, and they can help you establish actual cost figures for your organization. Try this exercise: work with finance to determine what dollar figure in fines, lawsuits, settlements, and remediation costs would make the board, CEO, or owner say “turn off the lights and go home, we’re done.” Then use resources like the Cost of a Data Breach Report to show what incidents in your industry actually cost. It’s not about being dramatic—it’s about quantified risk metrics.

This is hard work. Honestly, it’s complex enough that I might write about it separately in the future, because doing it well requires navigating a lot of variables and avoiding arbitrary numbers that don’t actually reflect your organization’s reality. But even an imperfect attempt at quantification is better than “this seems important” when you’re trying to justify security spending.

You’re excluded from architecture decisions until implementation is done. If security review happens at the end, when changing anything is expensive and disruptive, you’re set up to either rubber-stamp bad decisions or be the bad guy who delays projects.

What you can do: Insert yourself earlier, even informally. Build relationships with architects and senior engineers. Offer to review designs before implementation starts—position it as “I can help you avoid expensive changes later” not “I need to approve this.”

Ask project managers or business owners if you can sit in on planning meetings—frame it as learning about upcoming initiatives so you can be more helpful. If there’s a regular architecture review or project kickoff process, work with whoever runs those meetings to get security included as standard practice. Eventually people will start including you because it’s easier than retrofitting security afterward.

Leadership treats security purely as a compliance checkbox. If the only security work that gets prioritized is what’s required for audit, the organization doesn’t actually care about security—they care about compliance theater.

What you can do: Use compliance as your lever, but be strategic about it. If MFA is “nice to have” for security but “required for SOC 2,” frame it as compliance. It’s not ideal, but it gets things done.

But go further: monitor upcoming regulatory changes. Follow requests for comment on new regulations in your industry. Track proposed updates to audit frameworks. When you see something coming, bring it to leadership early: “This isn’t required yet, but it’s proposed for next year. If we implement now, we’re ahead of the mandate and we avoid a scramble when it becomes required.”

You’re still using compliance as the hook, but you’re positioning security as forward-thinking business enablement rather than reactive checkbox completion. And sometimes demonstrating that kind of strategic awareness opens doors for broader security initiatives that aren’t tied to specific compliance requirements.

(We’ll dig deeper into the compliance-versus-security tension in Week 9, including how to navigate organizations that treat compliance as the definition of security. For now, just understand that compliance can be a useful forcing function even when it’s not the same as actual security.)

You’re expected to rubber-stamp decisions that are already made. If your opinion is requested but not actually valued, if you’re there to provide cover rather than actually influence outcomes, that’s not a real security role.

What you can do: Stop rubber-stamping, but don’t become a blocker either. When presented with a done deal, respond with: “OK, you can proceed. I’ll work on the formal risk assessment and get that to you—it might take me a few days to review this properly and understand all the implications, I might need more insight from the team. But you’re not blocked waiting on me.”

Then deliver an actual assessment. Document the risks you see, your recommendations, what controls might mitigate the concerns. Even though the decision is already made, you’re establishing a record and demonstrating that security review means something.

Over time, people start to realize they’d rather have those conversations up front than get a risk assessment afterward that highlights everything they should have done differently. You’re not changing the immediate decision, but you’re creating incentive for earlier involvement next time.

Nobody wants to hear about risks that don’t have cheap, easy solutions. Security work involves hard trade-offs. If leadership only wants to address risks that are trivial to fix, they’re not serious about managing actual risk.

What you can do: Bring options, not just problems. “Here’s the risk. Here’s the ideal solution. Here’s what we could do with half the budget. Here’s what we could do with no budget but more time. Here’s what happens if we do nothing.”

And remember: the “ideal solution” isn’t always Fort Knox-level security. (Go back to Week 2 if you need a reminder—perfection is often anti-security.) Sometimes the ideal solution is the one that actually gets implemented and used, even if it’s not theoretically perfect. Make it easier for them to say yes to something realistic rather than forcing them to choose between perfect and nothing.

Some of these dynamics shift with patience and credibility-building. If you demonstrate value over time, if you build relationships, if you show that you’re helping solve problems rather than just identifying them, organizational culture can evolve.

But be honest with yourself: are you making progress, or are you just spinning your wheels? If you’ve been trying these approaches for a year or more and nothing is changing, that tells you something about whether the organization is actually ready to invest in security.

Building From Where You Are

If the situation is workable—not ideal, but workable—here’s how to make progress:

Start with foundational hygiene. Asset inventory, patch management, MFA, basic logging. Unglamorous work, but essential—and hard to argue against. These are things that benefit IT broadly, not just security.

Build relationships across IT. The network team, the sysadmins, the database folks, the developers, the helpdesk staff who see phishing attempts first. They’re your early warning system and your implementation partners. You need them on your side.

Invest in your business acumen. Understand how your organization makes money. What the critical business processes are. Who the key stakeholders are. What the competitive pressures and strategic priorities look like.

Security people who understand the business get taken seriously. Security people who only understand security get sidelined.

Find executive sponsors. Maybe it’s not your direct boss, but there’s someone in leadership who gets it. The CFO who’s concerned about financial risk. The COO who’s worried about operational disruption. The General Counsel who understands regulatory exposure.

Build relationships with people who have organizational authority and who understand why security matters. They can be allies when you need support for initiatives your direct chain of command doesn’t prioritize.

Know when to move forward. You won’t get every resource you ask for. You won’t address every risk you identify. Leadership will make decisions you disagree with.

Document your position in your risk register. The risk, your recommendation, the decision not to address it, who made that decision, and when. Make sure leadership understands what they’re accepting. Then focus on the things you can influence. Continuing to fight decisions that have been made just burns credibility and energy.

Position for growth. Whether that’s security eventually getting its own reporting line, or you moving to an organization with more mature security structure, or the function evolving as the company grows—organizations and roles change over time.

Do good work. Build skills. Develop organizational literacy and political awareness. These are valuable regardless of where your career goes next.

And here’s something worth remembering: there will be challenging days, weeks, even months in security work. But there are also those days that make being in security entirely worth it—when you prevent something bad from happening, when leadership finally understands what you’ve been saying, when a process you built actually works in a crisis. Those days erase a lot of the troubling times. They’re worth sticking around for.

The Long Game

This is not a quick fix situation. Building security while reporting through non-security leadership takes time, patience, political skill, and the ability to accept imperfect progress.

You’re playing a long game. Incremental wins. Relationship building. Demonstrating value. Building credibility so that when you need support, you have it.

Some people find this frustrating. They want to come in, fix everything, build the perfect security program. That’s not realistic in this structure.

Other people find it satisfying in its own way. Taking an organization from “security is an afterthought” to “we have solid foundations and we’re continuously improving”—that’s real accomplishment, even if it’s not perfect.

Know which type of situation you’re in. Know what’s actually possible given your organizational constraints. And decide whether that’s acceptable to you or whether you need to be somewhere with different structure.

There’s no shame in concluding that a particular organizational structure doesn’t work for you. But give it a fair chance first. A lot of good security work gets done by people who don’t have perfect organizational positioning but who figure out how to operate effectively anyway.

Practical Takeaways

Understand the fundamental tension between IT delivery focus and security risk focus. It’s structural, not personal.

Your job isn’t to say no—it’s to articulate risk, provide options, and help leadership make informed decisions.

Translate technical risk into business impact. Speak in terms leadership actually cares about: revenue, compliance, operational stability, customer trust.

Build credibility through small wins before asking for major resources. Prove you understand the business.

Document risks and decisions in your risk register. Not for CYA, but to create a factual record of organizational risk acceptance.

Align security work with IT’s goals where possible. Be an enabler, not just a blocker.

Don’t let IT speak for security without consulting you first. Make yourself available and be clear about your actual positions.

Bring options, not just problems. Multiple approaches at different cost/effort levels make it easier for leadership to say yes to something.

Understand why decisions go against you before deciding how to respond. Context matters—budget, resources, competing priorities, or clarity of presentation.

Build relationships across IT and with executive sponsors outside your direct chain.

Monitor upcoming regulatory changes proactively. Position security as forward-thinking business enablement, not reactive compliance.

Know when to move forward. Document decisions, then focus energy on things you can influence.

Accept that there’s a ceiling to what you can accomplish in this structure, but work toward organizational evolution.

There will be challenging times, but also moments that make security work entirely worthwhile. Those days are worth sticking around for.

Podcast: Download (Duration: 25:48 — 13.9MB) | Embed

Subscribe to the Cultivating Security Podcast Spotify | Pandora | RSS | More