Why cyber risk is often decided before the security conversation begins
Most cyber security conversations start too late.
By the time a project reaches formal assurance, many of the most important decisions have already been made. Suppliers have been selected. Delivery milestones have been agreed. Commercial pressures are in motion. Architecture choices have hardened into assumptions. Access models, hosting patterns, integrations and support arrangements may already be baked into the shape of the service.
At that point, security can still improve the outcome. It can challenge, refine, test and assure. But it is often working with a narrower set of options than people realise.
The difficult truth is that many security decisions are not labelled as security decisions when they are made. They appear as commercial decisions, delivery decisions, programme decisions, architecture decisions, user experience decisions, supplier management decisions. Each one may look reasonable in isolation. Together, they define how secure, resilient and supportable a system can realistically become.
The early choices that set the limit
A programme does not need to make an obviously poor decision to create security problems later. More often, the issue is a sequence of decisions that each appear practical at the time.
A requirement is written broadly because the team does not want to over-prescribe. A supplier is chosen because its proposal is credible, affordable and deliverable. A key integration is deferred because it would slow the first phase. A manual process is accepted as an interim workaround. A privileged access model is left to be clarified during implementation. A monitoring requirement is assumed to be part of the operational service. A third-party dependency is noted, but not fully explored.
None of these choices are unusual. They are normal features of complex delivery. The problem is that they reduce the space in which security can operate. Later, when assurance teams ask whether risks have been understood and managed, they may be interrogating a design that has already absorbed months of compromise.
Procurement is part of the security architecture
Procurement is often treated as the prelude to delivery. In reality, it shapes delivery. The way a requirement is framed influences the supplier response. The evaluation criteria influence what is rewarded. The contract determines what can be enforced. The commercial model affects whether security activity is treated as integral work or additional effort. The supplier’s assumptions influence the design before the first technical workshop begins.
This is why vague security language causes problems. Phrases such as “appropriate security controls”, “secure solution” or “compliant with relevant standards” may sound sensible, but they leave too much room for interpretation.
Delivery pressure changes the design
Even when security requirements are well written, delivery pressure changes behaviour. A team facing a fixed milestone will usually find a way to keep moving. That may mean accepting a temporary manual step, granting broader access than intended, using an existing collaboration route, postponing a control until a later phase, or carrying a risk that feels manageable in the moment.
Sometimes this is the right decision. Programmes need judgement, not rigid perfection. The issue is whether these decisions remain visible. Temporary exceptions have a habit of becoming permanent. Manual workarounds become part of the operating model. Access arrangements created for speed become normal practice. Assurance evidence is reconstructed after the event. Operational teams inherit decisions they did not make, then have to support them for years.
Assurance should not be archaeology
One of the clearest signs that security has arrived too late is when assurance becomes archaeological.
Teams begin digging through old decisions, trying to reconstruct why something was designed in a particular way. They search for evidence that was never captured. They ask suppliers to explain assumptions from months earlier. They discover that a risk was accepted informally but never owned formally. They find that a control exists, but nobody is quite sure whether it operates as intended.
Good assurance should not have to reverse-engineer the security story. The story should be created as the programme develops. Threat models, risk decisions, architectural choices, test results, access reviews, supplier evidence, vulnerability management records and incident response arrangements should form a coherent line of sight from design through delivery into operation.
The supplier boundary is where assumptions become risk
Many security weaknesses sit at the boundary between organisations.
A programme may have reasonable internal controls, but depend on suppliers, subcontractors, delivery partners, managed service providers, software vendors or external support teams. Each party may manage its own part of the picture. The risk appears in the joins.
Who can access what? Which organisation monitors which activity? How are incidents escalated between parties? Where does responsibility change hands? How is sensitive information shared? What happens when a supplier’s supplier is involved? How are changes communicated across the supply chain?
Security controls often fail because they are badly aligned to the way people need to work. If the approved route is too slow, unclear or impractical, people will find another route. Not because they are careless, but because the work still has to happen.
Usability is not a concession to convenience. In secure delivery, usability is part of control. A process that people can actually follow is more secure than a theoretically stronger process that everyone bypasses.
Security belongs where decisions are made
The lesson is not that every delivery decision needs a security meeting. That would slow programmes down without necessarily improving outcomes. The lesson is that security needs to be present where decisions materially affect risk.
That means earlier involvement in procurement. Clearer risk appetite. Better supplier questioning. More explicit ownership. Evidence generated through delivery, not assembled afterwards. Controls designed around real users and operational constraints. Assurance that tests whether the system works as intended, not just whether the paperwork is complete.
For government, defence and regulated organisations, that shift is no longer optional. The systems being delivered are too interconnected, the supplier ecosystems too complex, and the assurance expectations too high for cyber risk to be dealt with at the edge of the programme.
The security decisions are already being made. The question is whether anyone is recognising them early enough to shape the outcome.
Related Links:
