We still hear it far too often: security blocks projects.
It is a convenient sentence. It gives everyone a clear culprit, easy to identify, often outside the project team.
The project moves forward, then “security” shows up.
It asks questions.
It requests fixes.
It refuses a production deployment.
It asks for additional analysis.
The quick conclusion: security slows everyone down.
Except that, in many cases, this is not exactly what is happening.
What really blocks projects is not security.
It is ambiguity.
Ambiguity in the rules.
Ambiguity in responsibilities.
Ambiguity in validation criteria.
Ambiguity in timelines.
Ambiguity in exceptions.
Ambiguity in the acceptable level of risk.
And when everything is ambiguous, security mechanically becomes the moment when the problem appears.
Not necessarily the moment when it was created.
The false problem: “security blocks”
Saying that security blocks projects often means confusing the cause with the symptom.
Yes, a security team can block a deployment.
Yes, it can request fixes.
Yes, it can reject an architecture or a public exposure.
Yes, it can slow down a production release.
But the real question is rarely:
“Why is security blocking this?”
The real question should be:
“Why are we discovering this problem so late?”
Because if a project reaches its final phase with:
- an unplanned Internet exposure
- poorly identified sensitive data
- no threat model
- secrets stored all over the place
- undocumented architecture
- overly broad IAM permissions
- no monitoring
- no rollback plan
- no compliance validation
- unmanaged critical dependencies
then the problem is not that security “blocks”. The problem is that the project moved forward for weeks or months without clear guardrails.
And at the end, someone discovers that the risk is too high.
Ambiguity creates organizational debt
We often talk about technical debt.
We also talk about security debt.
But there is another, much more insidious kind of debt: organizational debt.
It appears when rules exist somewhere, but nobody really knows:
- where to find them
- who they apply to
- whether they are mandatory
- how to interpret them
- who can grant an exception
- how long a validation takes
- when security should be contacted
- what is blocking and what is not
As a result, everyone moves forward with their own interpretation.
Product teams think they are compliant.
Technical teams think they did things “as usual”.
Security teams think the rules are known.
Management thinks the topic is under control.
And everyone discovers too late that this was not the case.
This is not a problem of bad intent.
It is an organizational problem.
Unclear rules produce unclear decisions
A security rule that is not clear is often worse than no rule at all.
Because it creates the illusion of a framework.
Take a classic example:
“Access must be secured.”
Very well. But what does that mean?
- Mandatory MFA?
- Mandatory SSO?
- No local accounts?
- No shared accounts?
- Secret rotation?
- Conditional access?
- Bastion host?
- VPN?
- Just-in-time access?
- Periodic reviews?
Another example:
“Sensitive data must be protected.”
Again, very well. But which data?
- Personal data?
- Customer data?
- Financial data?
- Internal data?
- Contractual data?
- Technical data?
- Application logs?
And what does “protected” mean?
- Encryption at rest?
- Encryption in transit?
- Tokenization?
- Access restriction?
- Audit trail?
- DLP?
- Limited retention period?
- Isolated environment?
When a rule can be interpreted in ten different ways, it should surprise no one when ten teams apply it differently.
A well-written rule should leave no room for interpretation.
It should allow a team to understand what is expected, what is recommended, what is mandatory, and what is forbidden.
Otherwise, the day security makes a decision, that decision feels arbitrary.
Not necessarily because it is.
But because the framework was never made explicit.
An opaque process feels like a wall
Another very common issue: the security validation process exists, but it is opaque.
Teams know they need to “check with security”.
But they do not really know:
- when to do it
- through which channel
- with which information
- within what timeframe
- with what level of detail
- based on which decision criteria
- with what consequences if something is rejected
In this context, security feels like a black box.
A request is sent.
People wait.
Questions come back.
People answer.
They wait again.
Then sometimes they receive a negative opinion, a list of required fixes, or a request for additional analysis.
Even when the decision is justified, the experience is bad.
And when the experience is bad, teams bypass it.
Not necessarily out of malice, but more often out of exhaustion.
They learn that “going through security” is slow, uncertain, and painful.
So they try to avoid it until the very last moment.
Then security arrives late and blocks. Everyone confirms their initial bias, and this creates an endless toxic loop.
The absence of SLAs destroys trust
One often underestimated point: response times.
A project team can handle a security constraint.
It can handle a technical fix.
It can handle a mandatory validation.
What it handles much less well is uncertainty.
If a team does not know whether security will respond in two days, two weeks, or never, it cannot plan properly.
And when it cannot plan, it takes shortcuts.
A security process without an SLA naturally creates frustration.
There is no need for an ultra-complex SLA.
But a few commitments need to be clear at a minimum:
- acknowledgment within X days
- first response within X days
- target timeline depending on the type of request
- accepted urgency level
- escalation criteria
- responsibilities on the project side
- responsibilities on the security side
Security does not need to promise the impossible.
Above all, it needs to avoid radio silence.
Because from a project team’s perspective, a lack of response is already a form of blocking.
A few signs that your security is too ambiguous
Some symptoms are fairly easy to recognize.
If you regularly hear:
“We did not know we had to contact you.”
“We are only discovering the rules now.”
“Security said no, but we do not know what to do.”
“We will go to production and regularize it later.”
Then the problem is probably not only cultural.
There is probably an issue with clarity, process, or capacity.
And it needs to be treated as such.
Ambiguity sometimes suits everyone
We also need to be honest: ambiguity does not always exist by accident.
Sometimes, it is convenient.
It suits teams that want to move forward without constraints.
It suits managers who do not want to arbitrate.
It suits organizations that prefer to avoid difficult decisions.
It can even suit security teams, which can keep a comfortable margin of interpretation.
But that comfort is temporary.
Ambiguity always ends up being expensive.
It costs delays.
It costs frustration.
It costs escalations.
It costs bypasses.
It costs technical debt.
It costs risk exposure.
And sometimes, it costs an incident.
Clarity requires effort upfront.
But it avoids a lot of chaos later.
Conclusion
Security does not block projects by nature.
What blocks projects is often the accumulated ambiguity around security:
- imprecise rules
- opaque processes
- lack of SLAs
- unknown criteria
- poorly defined responsibilities
- poorly framed exceptions
- arbitrations that are never owned
Effective security is not soft security.
It is clear security.
It knows how to state what is expected, what is mandatory, what is acceptable, and what is not.
And above all, it avoids turning every validation into a last-minute surprise.
Because in the end, project teams can live with constraints.
What they tolerate much less is discovering the rules when the game is almost over.
Security does not block projects.
Ambiguity does.
In a future article, I will come back to a directly related point: why security that is consulted too late almost always becomes brutal, even when it is right.
