When Security Becomes the Bottleneck

Security creates the most value when it manages risk without unnecessarily slowing the business.

When Security Becomes the Bottleneck
What if your security program is creating risk instead of reducing it?
Not because your controls are ineffective. Not because your security team isn't doing its job. But because the organization has become so dependent on security reviews, approvals, assessments, and exceptions that getting business done requires navigating security instead of working with it.

At some point, a security control can stop being a safeguard and start becoming a bottleneck. The question isn't whether security should create friction. The question is whether the friction is worth the risk reduction it provides.

Not All Friction Is Bad

Some security controls are supposed to create friction. MFA adds that extra step we all love. Privileged access controls add restrictions. VRA’s are time consuming. Change management introduces review. Segregation of duties prevents someone from completing certain activities alone.

Those controls exist because unrestricted convenience can create unacceptable risk.

The objective, therefore, isn't: “Make security invisible.”

It is: “Make necessary security friction intentional.”

This distinction matters.
A security program should create enough friction to manage meaningful risk, but not so much friction that the organization begins treating security as an obstacle to overcome.

How Security Becomes the Bottleneck

Security bottlenecks rarely appear because someone deliberately decided:

“Let's make the business slower.”

They usually develop incrementally. A new control is added. Then another requirement is added. A review process is introduced. Then another approval is added.

A security team becomes the default reviewer for anything involving technology. Eventually, the security function becomes involved in decisions that may have little meaningful security risk associated with them.

The process may still look reasonable when viewed one step at a time.

The problem becomes visible when you look at the entire workflow.

For example:

Business request → IT review → Security review → GRC review → Privacy review → Legal review → Procurement → Executive approval

Every step in this progression has a legitimate purpose. But if the organization cannot explain what risk each step manages, the process may have evolved beyond what is actually necessary.

The result is what I would call security process debt.

The organization has accumulated layers of security-related activity without periodically evaluating whether those layers still provide proportional value.

The Security Bottleneck Has a Cost

Security teams understandably focus on the risks created when controls are missing.

We should also consider the risks created when security processes become unnecessarily restrictive.

Excessive friction can lead to:

• Business teams circumventing approved processes

• Employees adopting unsanctioned applications

• Shadow IT

• Delayed projects and product releases

• Security teams becoming involved in low-value decisions

• Increased operational workload

• Frustration between security and business teams

• Security being viewed as a cost center rather than a business partner

I would say that there is a paradox here to consider.

A security process designed to reduce risk can sometimes create new risk when it becomes so difficult to follow that people work around it.

The control hasn't necessarily failed technically. The operating model has failed behaviorally.

The Principle of Proportionality

One of the most important concepts in mature security leadership is proportionality. Not every decision deserves the same level of security scrutiny.

Consider these two hypothetical requests.

Request A: A business unit wants to purchase a cloud application that will process highly sensitive customer information.

Request B: A team wants to use a low-risk collaboration tool to organize an internal volunteer event.

Treating both requests with the same six-week security assessment process may demonstrate consistency.

It does not necessarily demonstrate maturity.

The first request may warrant extensive security, privacy, legal, and risk review.

The second may not.

A mature security program asks:

“What is the risk associated with this decision, and what level of scrutiny is appropriate for that risk?”

That is very different from:

“What is our standard process?”

Standardization is valuable. Blind standardization is not.

A Practical Security Friction Test

When a security process becomes a source of frustration, I would start with five questions.

1. What risk is this step managing?

Every significant security requirement should have a reason. If nobody can articulate the risk, the requirement deserves examination.

2. What happens if we remove or reduce it?

This is where risk-based thinking becomes useful. Would removing the step create meaningful additional exposure or would it primarily eliminate administrative effort?

3. Can the control be automated?

Human review is valuable for decisions requiring judgment. It is considerably less valuable when people are manually checking information that technology can reliably evaluate.

Automation isn't simply a productivity initiative.

However, It can be a security maturity initiative because it allows human attention to remain focused on higher-risk decisions.

4. Can the process be risk-tiered?

Instead of treating every request identically, establish different paths.

For example:
Low risk → automated or lightweight review
Moderate risk → standard security assessment
High risk → comprehensive multidisciplinary review

The exact tiers will vary by organization. The principle is what matters: Risk should influence the amount of friction.

5. Who actually needs to make the decision?

I believe this is often overlooked.

Security teams can become bottlenecks because they are asked to make decisions that belong to the business.

Security may assess the risk. Security may recommend a course of action. Security may establish minimum requirements. But someone else may own the business decision.

Clarifying decision rights can eliminate an enormous amount of unnecessary delay.

From Gatekeeper to Guardrail

There is a useful mental model here.

A gatekeeper asks:

“Should this be allowed?”

A guardrail asks:

“How can this happen safely within acceptable risk?”

The distinction isn't absolute. There will always be situations where security needs to stop something. A critical vulnerability shouldn't be ignored because a product launch is tomorrow. A serious regulatory obligation shouldn't be dismissed because compliance is inconvenient. A high-risk third party shouldn't be approved simply because the business is in a hurry.

But those situations should be based on risk, not simply on the existence of a security policy.

The guardrail mindset changes the default conversation.

Instead of: “You can't do that.” The conversation becomes: “Here are the conditions under which we can safely do that.”

I would say that is a much more productive relationship between security and the business.

Security Should Not Own Every Decision

There is another subtle problem that can turn security into a bottleneck: security becomes the default decision-maker for risk.

Imagine a business leader wants to deploy a new service.

Security identifies three risks. The security team documents them. The security team recommends mitigation. The business doesn't want to implement all of the recommendations.

Who decides?

If the answer is automatically “security,” the organization has a governance problem. Security should have authority over defined security requirements and controls. Business leaders may ultimately need to decide whether a particular risk is acceptable given the value of the initiative.

That is risk governance. The security team's job is not to eliminate every risk.

It is to help the organization understand risk well enough to make informed decisions about it.

Measure Security Friction

This is where I think security leaders can improve their programs considerably.

We routinely measure things such as:

• Vulnerabilities remediated

• Incidents detected

• Phishing simulations completed

• Access reviews performed

• Security assessments completed

• Controls tested

Those metrics have value, and if you have read my previous articles, you know I believe in routine measurements as baseline metrics. Of course they have to be tied to a business objective.

But what about the friction created by the security program?

Consider measuring:

Time to security approval
Time to onboard a vendor
Time to provision access
Percentage of requests requiring manual intervention
Percentage of reviews escalated to security leadership
Number of business processes bypassing security procedures
Number of security exceptions requested

These aren't simply operational metrics. These metrics tell us whether the security operating model is functioning effectively.

A rising number of exceptions, for example, might not mean that the business has suddenly become less security-conscious. It might mean the process has become unrealistic.

That is a very different diagnosis.

Security isn't about saying No. It's about helping the business say YES ....safely.

The Security Friction Matrix

A simple way to visualize this is to evaluate security processes across two dimensions:

Risk reduction
How much meaningful risk does the process reduce?

Business friction
How much time, complexity, or effort does the process introduce?

This creates four broad categories:

High Risk Reduction / Low Friction

Keep and scale.

These are the controls and processes security should be proud of. They materially reduce risk without imposing unnecessary burden.

High Risk Reduction / High Friction

Optimize.

The control may be necessary, but the organization should look for automation, better workflows, risk-tiering, or clearer decision rights.

Low Risk Reduction / Low Friction

Automate or simplify.

There may be little reason for significant human involvement.

Low Risk Reduction / High Friction

Challenge it.

This is where security organizations should be willing to ask themselves some difficult questions.

Why are we doing this? What risk does it address? Would we design the process this way today? Is the administrative burden greater than the security value?

That last category is where some of the biggest opportunities for improvement may exist.

Mature Security Doesn't Mean Frictionless Security

There is a temptation to interpret this argument as:

“Security should get out of the way.”

I don't believe that is the answer.

Security exists precisely because some things should not be frictionless. The mature approach is different.

Security should make the right things harder and the wrong things even more harder.

But Security should make legitimate business activity as easy as reasonably possible within acceptable risk.

That requires judgment. It requires understanding the business. It requires understanding risk. It requires understanding how people actually work.

It also requires security leaders to periodically examine their own processes with the same skepticism they apply to everyone else's.

So what's the takeaway in all of this?

A security program can fail in two opposite directions.

It can be too weak to manage meaningful risk.

Or it can become so restrictive that the organization begins working around it.

Neither is maturity.

The strongest security programs find the space between those extremes.

They establish clear guardrails.

They tier controls according to risk.

They automate routine decisions.

They reserve human judgment for situations that actually require it.

They establish clear decision rights.

And they measure not only the risk security prevents, but also the friction security creates.

Because security isn't successful when the business can't move.

Security is successful when the business can move confidently within understood and acceptable risk.

That is the difference between being a gatekeeper and being a business enabler.

Contact

Reach out for tailored security solutions.

Email

info@sciconsulting.io

© 2026. All rights reserved.