Security is cheapest and most effective when it is treated as a design input, not a gate at the end of delivery. The decisions that determine how exposed a platform will be — identity, data boundaries, integration contracts, tenancy, logging — are made in the first weeks of a programme, long before a penetration test is scheduled.
The pattern that creates late surprises
In most programmes, security enters through assurance: a review, a test, a questionnaire from a client or regulator. By then the architecture has hardened, the integration surface is fixed and the delivery schedule has no room. Findings that are conceptually simple — a service holding more data than it needs, an identity model that cannot express least privilege — become expensive because the fix touches design rather than configuration.
The result is a trade-off nobody chose deliberately: accept residual risk to protect the date, or delay the date to unpick a decision made months earlier with incomplete information.
What changes when security joins the design table
Bringing security into design does not mean adding a review board. It means naming, at the point each architecture decision is taken, what the decision assumes about trust, what data crosses which boundary, and who will hold the resulting risk in operation.
That work is cheap. A threat model on a whiteboard, an explicit data classification per interface, and a written statement of who can do what in each environment will usually surface the issues that would otherwise appear in an assurance report — while they are still one conversation away from being resolved.
Three practical moves
First, make the identity and access model a first-class design artefact with a named owner, not an implementation detail left to whoever builds the first service.
Second, write down the data boundaries. If a component holds personal, financial or regulated data, that fact should be visible in the architecture, not discovered during a review.
Third, agree the evidence you will produce as you build — logs, change records, test results — so assurance later is a matter of collecting what exists rather than reconstructing history.