There’s a part of IT security that rarely gets discussed in technical training. You can have the right control, good evidence, a sensible implementation plan and a reasonable business case, and still not get the decision made.
The problem isn’t always technical. Security decisions are made inside organisations, and organisations have competing priorities, budgets, personalities, ownership questions, and people who can quietly stop something from happening without ever formally saying no.
You can leave a meeting with everyone agreeing with the proposal. Then nothing happens.
The project gets pushed back. Someone wants more information. Another department raises a concern. The budget disappears. The person who supported it moves on to something else. Six months later, the security team is still raising the same risk.
This is where the politics of IT security starts to matter.
The technically correct answer isn’t always the decision that gets made
Security people naturally think in terms of risk. If a control reduces a known risk and is technically achievable, the answer seems obvious: implement it.
The business may see the same proposal very differently. The security team sees the risk of compromise. The business sees the cost of implementation, user disruption, project delays, support requirements, and the possibility that the change will break something important.
Neither side is necessarily wrong. What’s often missing is clarity about who owns the decision, and that causes more problems than it should.
Why good security decisions get blocked
There are a few recurring reasons.
The risk doesn’t feel real
Preventative security work is hard to sell because success usually looks like nothing happening. Spend money on a firewall upgrade and nothing goes wrong, and it can look like an unnecessary expense. Implement MFA and nobody gets compromised, and the value is hard to see. The avoided incident never appears in the monthly management report, which makes immediate costs much easier to see than future benefits.
The pain is immediate
A security control creates real work. Users change behaviour, applications need testing, service accounts need attention, exceptions need documenting, and support teams need to understand the change. The benefit may be months or years away, but the disruption is today. That imbalance makes security proposals especially vulnerable when an organisation is already busy.
Ownership is unclear
A security team can identify a risk without having the authority to accept it on the organisation’s behalf. IT might own the technical control, while a business manager owns the process being protected. Finance owns the budget, operations owns the affected users, and an executive may ultimately own the business risk. If nobody is clear about who makes the decision, the proposal sits in limbo.
The politics nobody puts in the security architecture diagram
Every organisation has an informal layer of decision-making. Some people have a formal approval role. Others have influence because of their position, their relationships, their knowledge of a particular system, or their ability to make an implementation difficult.
This creates the informal veto. It usually sounds reasonable:
- “We should probably get Operations comfortable with this first.”
- “Let’s wait until after the current project.”
- “I don’t think the users will accept that.”
- “Can you prove this is actually necessary?”
- “Let’s put it on the roadmap.”
None of those statements is unreasonable on its own. The problem is when they become a permanent way of saying no without ever saying no.
The “yes in the meeting” problem
This is one of the more frustrating situations. Everyone agrees that MFA, better logging, privileged access controls or improved patching is a good idea. The meeting ends positively. Then the actions don’t happen, and because nobody explicitly rejected the proposal, there’s no decision to challenge. The project simply loses momentum.
This is where security professionals need to stop treating agreement as approval. A verbal “yes” isn’t the same as an owner, a budget, a date and an agreed implementation plan. If the organisation genuinely wants the control, those things need to exist, so leave every important meeting with them written down.
Sometimes the security team is the problem
It’s easy to write about blocked security projects and make the business look unreasonable. That would miss half the story.
A security recommendation can be technically correct but operationally poor. A control might demand a large amount of manual work when a less disruptive control would reduce most of the same risk. Security might push a major change straight after another large project has used up the organisation’s capacity. Sometimes security asks for the perfect control when a good one could be implemented now.
There’s also a tendency in security to treat every exception as a failure. That isn’t realistic. Organisations have legacy systems, operational constraints, applications that can’t be changed immediately, and users who need access for legitimate reasons.
The goal isn’t to eliminate every exception. It’s to understand the risk, reduce it where practical, and make sure someone with the right authority understands what remains. That requires security people to understand the business as well as the technology.
A worked example: getting MFA approved
MFA is a good example because the technical recommendation is straightforward, but the organisational decision can be much harder.
Consider an organisation where 84 users don’t have MFA registered. “We need to turn on MFA” is a statement. This is a proposal:
- Confirm the current MFA registration status.
- Pilot MFA with a small group.
- Resolve application and user issues during the pilot.
- Roll out to the remaining users in stages.
- Track exceptions and deal with them individually, rather than delaying the whole project.
Presented as a controlled change, it gives people something they can actually approve.
Use data to make the discussion less political
Before making the proposal, collect real data rather than relying on assumptions. In Microsoft Entra, the authentication methods registration report shows whether each user is registered for and capable of using MFA (Microsoft Learn: Get-MgReportAuthenticationMethodUserRegistrationDetail):
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
Select-Object UserPrincipalName, IsMfaRegistered, IsMfaCapableNow, instead of saying “we have an MFA problem,” you can say exactly how many users are registered, how many are capable, and where the gaps are. Check licensing before building the business case, because some Entra security controls need Microsoft Entra ID P1 or P2.
The same approach works for any proposal. How many users aren’t registered? How many privileged accounts are affected? Which systems can’t support the control? What exceptions are needed? For identity risk, Microsoft Entra ID Protection has dedicated reports for risky users, risky sign-ins and risk detections (Microsoft Learn: ID Protection risk reports). Outside Microsoft, a vulnerability scan shows exposure, a penetration test demonstrates impact, and an audit finding identifies a gap.
The point of the evidence isn’t to frighten people into agreeing. It’s to make the decision better informed. The more specific the evidence, the harder it is for the discussion to stay theoretical.
Timing and external pressure matter
A technically good proposal can fail simply because the organisation isn’t ready to act on it. If a major project is about to start, another large change will be a hard sell. If the organisation has just had a near miss, the same proposal may get a completely different response. Good security leadership includes recognising when the organisation can absorb a change.
External events often change the conversation too. A recent incident, audit finding, penetration test, insurance requirement, customer requirement or board discussion can make an abstract risk concrete.
In Australia, the ASD Essential Eight provides a useful external reference point. ASD recommends implementing it using a risk-based approach, minimising exceptions and their scope, and documenting and approving any exceptions (ASD: Essential Eight maturity model).
That doesn’t mean “the Essential Eight says so” should replace thinking. It gives you another way to frame the discussion. Instead of the security team being the only voice asking for a control, you can show how the change relates to an established framework, a customer requirement, an audit expectation or a contractual obligation.
Get stakeholders involved before the approval meeting
One of the easiest mistakes is waiting until the formal meeting to discover the objections. If operations, finance, HR or another technical team will be affected, talk to them beforehand. You don’t need everyone to agree with you. You need to understand what they’ll object to.
That gives you the chance to change the implementation without changing the security objective. For example, an application owner might not object to MFA itself. They might object to deploying it to every user at once because of one legacy application. That’s useful information, and it points to a pilot, an exception process or a staged rollout.
The security objective stays intact while the path to it changes. That’s far more productive than discovering the objection in the approval meeting and treating it as resistance.
When you still can’t get approval
Sometimes you’ve done everything well. The risk is documented, the solution is understood, the stakeholders have been consulted and the implementation is practical. The organisation still decides not to proceed.
That’s where formal risk acceptance matters. If a business chooses not to implement a recommended control, the decision shouldn’t disappear into meeting minutes. The remaining risk needs an owner with the appropriate authority, a documented rationale, a review date, and enough information to understand the consequences. ASD makes the same point about Essential Eight exceptions: they should be documented and approved.
The security team should not become the permanent owner of risks it doesn’t have the authority to accept.
This isn’t about covering yourself, although it does make ownership clear for everyone. It also changes the conversation. “IT keeps asking us to fix this” becomes “we understand the risk, we’ve considered the available controls, and the appropriate business owner has accepted the residual risk until the agreed review date.” That’s a management decision, not an unresolved technical argument.
When the block is actually reasonable
There will also be times when the answer should be no. A recommendation might create more operational risk than it removes. It might interfere with a critical process, introduce an unacceptable dependency, cost far more than the risk warrants, or simply be the wrong control.
The answer shouldn’t automatically be “security wins.” The right question is whether the organisation understands the risk and has made a deliberate decision about how to treat it. That might mean implementing the control, reducing its scope, choosing a different control, or accepting the remaining risk for now.
The dangerous outcome isn’t saying no. It’s saying no without understanding what’s being accepted.
What actually works
After dealing with enough blocked security initiatives, the job becomes less about arguing and more about improving the quality of the decision. This is how I approach a significant proposal:
- Define the risk. Explain what can happen, who is affected and the realistic business impact.
- Collect evidence. Use real configuration, logs, reports, vulnerability data or audit findings wherever possible.
- Understand the objections. Cost, users, compatibility, timing and workload are different problems that need different solutions.
- Offer a practical path. A pilot, staged rollout, compensating control or limited scope can make a proposal achievable without abandoning the objective.
- Involve the right people early. Don’t wait for the approval meeting to find out a key stakeholder objects.
- Be prepared to change the implementation. The security objective may be right even when your original plan isn’t.
- If the answer is still no, document the residual risk. Make sure the right owner understands what remains, why, and when it will be reviewed.
Security is partly technology and partly decision-making
The technical side of security is usually the easier part. You can demonstrate the vulnerability, show the configuration, produce the logs and build the control.
Getting an organisation to change is different. You need to understand who owns the decision, who will be affected, who can influence the outcome, and what evidence will make the risk meaningful to them. You also need enough humility to recognise when the security team’s preferred solution isn’t the right answer.
Good security people don’t just know how to configure the control. They know when to push, when to listen, when to compromise on implementation, and when to insist that a decision is formally owned. Most importantly, they don’t let security become an argument that never ends.
The hardest part of IT security is often not knowing what should be done. It’s getting an organisation to make a deliberate decision about doing it.
From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.