Security has spent a long time as the department of no, and it earned the reputation honestly. The traditional model is a gate at the end of a process, staffed by people who were not in the room for the decisions being reviewed, holding a checklist written for a different system.
Four positions, and what each one costs to hold.
1. Embedded guardrails over gatekeeper sign-offs
A gate at the end catches problems at the most expensive moment. Every finding in a pre-launch penetration test was a decision made months earlier, when it was cheap to change and structural now.
The alternative is to put the security decision where the engineering decision is made: a short threat modelling session at design time, secure patterns that are also the easiest path, and automated checks in the pipeline.
What it costs: you have to accept that some things get through. A guardrail tuned tight enough to catch everything gets disabled. Guardrails work because they are tolerable.
2. Continuous assurance over point-in-time audits
An annual penetration test proves the system was secure on one day, against the techniques known on that day, in the configuration it had that day. For an organisation deploying weekly, that leaves fifty-one weeks unexamined.
Continuous assurance means scanning constantly, testing periodically, monitoring configuration for drift, and - this is the part usually missing - tracking findings as a live backlog with owners rather than as a report.
What it costs: the finding count goes up, permanently. That is what it looks like when you start seeing what was already there.
3. Risk-based context over checkbox compliance
A control framework does not know which of your systems processes payments and which serves the internal lunch menu. Applied uniformly it produces enormous work with no relationship to risk, and it crowds out the things that mattered.
Risk-based means arguing for the level of control each system needs, and writing down the argument. It is more defensible to an auditor than uniform application, because it demonstrates that someone thought about it.
What it costs: you have to make and record judgements, which is harder than completing a checklist and considerably harder to hide behind.
4. Shared responsibility over siloed blame
When security owns security outcomes exclusively, engineering optimises for shipping and security optimises for blocking, and both are behaving rationally.
Shared responsibility means the team that builds a thing owns its security posture, and the security function owns enabling them: the patterns, the tooling, the fast answer, and the escalation when something genuinely needs stopping.
What it costs: security has to give up control to gain influence, and that only works if the enabling half is genuinely good. Shared responsibility announced without the tooling to support it is just blame redistribution.
The honest limitation
None of this replaces governance. Somebody still has to own the risk register, accept residual risk by name, and answer to a board or a regulator. Agile delivery changes how the work gets done. It does not remove the requirement for someone to be accountable for it - which is the argument for a named security leader rather than against one.