Why security change stalls¶

Security programmes stall for recognisable reasons. ChangeShop surfaces them quickly because the same patterns that derail change in organisations show up in the workshop room within an hour.

The assumption of rational compliance¶

Most security efforts assume that problems are technical, solutions are deployable, and organisations are rational actors. Contact with reality is brisk.

People do not comply with security policies because the policies are correct. They comply when the policies are easier than the alternatives, when the consequences of non-compliance are real, and when they trust the people asking them to change their behaviour. None of these conditions is created by a policy document.

What resistance looks like in practice¶

ChangeShop identifies patterns that appear reliably when change encounters a system that is not ready for it.

Deflection: “that is not my team’s area.” This is sometimes accurate and sometimes a way of avoiding a conversation about ownership that nobody wants to have.

Over-analysis: producing more data, more modelling, more architecture diagrams as a way of deferring decision. This is stalling disguised as rigour.

Premature solutions: proposing specific fixes before the problem is properly understood. This is avoidance of the real issue, which may be uncomfortable to name directly.

Status protection: “this approach has always worked for us.” This is the system defending the current state against a threat to its stability.

Resistance as a map, not an obstacle¶

The ChangeShop insight is that resistance is not obstruction to be overcome. It is information about the system.

“We do not have time for this” describes a capacity mismatch between the security requirement and the operational reality. Overriding it produces nominal compliance and actual evasion.

“This breaks our workflow” describes a design failure in the control or the rollout approach. Overriding it produces workarounds that may be worse than the original gap.

“We already tried that” describes a trust deficit. Something similar was proposed before, nothing changed, and the team learned not to invest effort in this category of initiative. Overriding it produces cynicism.

Each of these is a map of the system. Ignore it, and you design interventions that will be quietly dismantled.

The homeostatic trap¶

Organisations resist change to remain stable. This is not a pathology. It is how systems maintain themselves. The security team that arrives with a mandate to improve things is, from the organisation’s perspective, a destabilising force. The immune response is not personal.

The trap is treating the resistance as the problem. The resistance is the symptom. The actual question is: what conditions would have to change for this organisation to be able to absorb this improvement without treating it as a threat?

That is a different question from “how do we get them to comply,” and it produces different, more durable answers.