Security designed in, not bolted on

Most organisations treat security as the last phase of a technology project. The ones that regret it most are the ones that discovered the cost ratio after the breach.

The typical pattern is familiar. A system is built. A penetration test is commissioned near the end of the project. Findings come back. Some are fixed, some are deferred, some are accepted as residual risk. The system launches. The organisation has a product and a backlog of security debt it intends to address next quarter.

This is not malice. It is sequence. When security arrives at the end of a project, it arrives as a constraint on something that is already designed. The architecture is fixed. Changing it is expensive. Findings that require structural remediation get deferred. The system that launches is not the system that was tested. It is the system that was tested, with the expensive findings left in.

What 'designed in' actually means

Security designed in is not a checklist applied at the end of the build phase. It is a set of structural decisions made before the architecture is drawn: how identity and access are managed from the first user onward, how data is classified and who can reach it, how the system will be monitored once it is live, and what the response looks like when something fails.

These are not security questions. They are architecture questions with security consequences. A system built without them does not have security missing from it. It has security built around a structure that was never designed to be secured. The difference matters because one is maintainable and the other is a perpetual retrofit.

The three moments that determine security posture

The first is the architecture decision. Before any code is written, the structural choices (cloud provider, access model, data classification, API surface, third-party dependencies) determine the attack surface. A system designed with a minimal, well-understood attack surface is not easier to secure. It is already secure by design. These decisions, made in the first weeks of a project, are the most consequential security decisions the organisation will make.

The second is the build phase. Zero Trust access controls, secure CI/CD pipelines, secret management, dependency scanning, and container security are build decisions, not security additions. A development team operating without them is not building a system that will need security. It is building a system that already has security debt, compounding with every sprint.

The third is the operational model. A system that launches without defined incident response, without log aggregation and analysis, without a Security Operations Centre or a defined alternative, does not become insecure at the moment of breach. It was insecure from the moment it went live. The breach is not the event. It is the evidence.

A breach does not create a security problem. It reveals one that already existed.

Three moments that determine security posture

Architecture

Structural choices made before a line of code (access model, data classification, API surface) determine the attack surface. These are the most consequential security decisions the organisation will make.

Build

Zero Trust access controls, secure CI/CD pipelines, secret management, and dependency scanning are build decisions. A team operating without them accumulates security debt with every sprint.

Operations

A system that launches without incident response, log aggregation, and threat monitoring is insecure from go-live. The breach is not the event. It is the evidence of a condition that already existed.

Perimeter model

A defended outer boundary. Everything inside is trusted by default.

A compromised internal account has unrestricted lateral access across the system.

Perimeter breaches are not detected until the damage is already done.

Trust once. Risk permanently.

Zero Trust

No actor, internal or external, is trusted by default.

Every access request is verified. Every session is authenticated. Every transfer is logged.

Compromise of one account does not grant lateral access to the rest of the system.

Verify continuously. Contain automatically.

Zero Trust as an architectural starting point

Zero Trust is not a product. It is a design principle: the assumption that no actor, whether inside or outside the network perimeter, can be trusted by default. Every access request is verified. Every session is authenticated. Every data transfer is logged. The perimeter is not the boundary. The identity is.

In practice this means designing identity and access management before designing features. It means treating internal network traffic as untrusted. It means requiring the same verification from a logged-in administrator as from an anonymous external request, because the administrator account may be compromised and the architecture should not assume otherwise. Organisations that implement Zero Trust as a retrofit discover that the assumption of internal trust is woven through every layer of what they built.

Compliance as architecture, not documentation

ISO 27001, GDPR, PCI DSS, and NIST are not certification exercises. They are frameworks that describe what a secure, governable system looks like at the architectural and policy level. Organisations that treat compliance as a documentation project, assembling evidence after the fact, spend significantly more time and money than organisations that design to meet the frameworks from the outset. The frameworks do not ask for evidence that a secure system exists. They describe what one looks like. Design to them, and the evidence exists by default.

The audit is straightforward when the architecture was designed to pass it. It is expensive, and sometimes impossible without redesign, when the audit reveals that the architecture cannot satisfy the framework's structural requirements. Compliance failures that require architectural remediation are among the most costly outcomes in institutional technology.

What this costs to get right, and what it costs to get wrong

Security designed in from the start adds cost at the architecture phase. It changes design decisions. It requires security input before the build team wants to receive it. It introduces questions (about data classification, access boundaries, and operational monitoring) that slow the first sprint while the answers are found.

Security retrofitted after the build adds cost at the worst possible moment: when the system is live, when the organisation is dependent on it, and when any change to the architecture risks breaking the things that are working. The total cost of a security retrofit (architectural redesign, penetration testing, remediation, compliance review, and operational reconfiguration) is typically several multiples of what security design-in would have cost at the outset.

The organisations that understand this ratio most clearly are the ones that discovered it after a breach. The cost of the breach (incident response, forensic investigation, regulatory notification, reputational damage, and system remediation) is not a security cost. It is the cost of the decision, made months or years earlier, to treat security as the last phase of a build rather than the first.

←All insights

If this resonates with a challenge you are navigating, we are happy to talk through it.

Start a conversation