" . . you can't bolt on what should have been built in . ."
‘Security by Design’ has become one of those phrases that appears everywhere. It’s written into strategy documents, referenced in meetings, and positioned as a non-negotiable in modern technology delivery. And rightly so.
The idea is simple. If security is considered from the outset (woven into architecture, identity, and system design) it becomes part of the foundation rather than an afterthought. Done properly, it reduces risk, avoids rework, and creates systems that are far easier to scale and maintain.
Yet despite this, the reality across many organisationstells a different story.
Security by Design doesn’t often fail because the principle is flawed. It fails because of when it’s applied.
More often than not, architecture enters the conversation just a little too late.
By the time architects and security leads are engaged, delivery has already begun. Engineering teams are building, timelines are in motion, and key design decisions (some explicit, others accidental) have already been made. At that stage, security is no longer being designed into the system. It’s being negotiated around it.
And that’s where the shift happens . .
What should have been a structured approach to identity, access, and trust boundaries becomes something far more reactive. Controls are introduced, but they are layered rather than embedded. Gaps are identified, but they are worked around rather than resolved at source. Security starts to feel less like an enabler and more like an interruption.
From the perspective of delivery teams, this is often where frustration begins to surface. Not because security is unnecessary, but because it arrives in a way that disrupts rather than supports. Decisions that once felt straightforward suddenly become constrained. Timelines stretch. Complexity increases.
The irony is that this outcome is rarely tracked in any meaningful way.
Organisations are good at measuring delivery milestones, budgets, and even incidents. What they tend not to measure is the cost of retrofitting.
The hours spent revisiting decisions. The architectural compromises made under pressure. The long-term impact of systems that were never quite structured in the right way to begin with.
Over time, these small inefficiencies accumulate. What began as a fast-moving delivery becomes something much harder to change, more expensive to maintain, and increasingly exposed to risk.
From a market perspective, this pattern is not surprising.
Architecture is still too often positioned as a governance function rather than a design authority. Something that validates decisions rather than shapes them. At the same time, organisations are under constant pressure to accelerate - whether that’s cloud adoption, digital transformation, or the integration of new technologies.
Speed becomes the priority.
And in that environment, architecture is frequently invited in once momentum has already built.
Those organisations that manage to avoid this, tend to approach things differently;
- Architecture is not treated as a checkpoint. It is part of the initial thinking.
- Identity models are defined before access is granted.
- Trust boundaries are considered before systems are connected.
- Security is not something that is added later .. it is part of how the system is conceived.
In those environments, security rarely becomes a blocker. It moves with delivery because it was designed to.
There is also a talent dimension to this that cannot be ignored. Many organisations have strong engineers and capable security teams . . but fewer individuals who can operate across the intersection of business intent, architecture, and security strategy. Without that connective layer, decisions are made in isolation, and alignment becomes something that is attempted after the fact. And that is often too late.
Ultimately, Security by Design is not a technical challenge - it's is a timing problem.
If architecture is brought in after delivery has started, the opportunity to design has already passed. What follows is adjustment, compromise, and in many cases . . unnecessary complexity!
