Nearly half (48%) of UK security leaders surveyed have signed off on a release they were not fully confident was secure.
That is the finding we keep returning to, because it is not a finding about carelessness. These are experienced professionals running security functions in organisations of 1,000 people or more. They did not approve a release they doubted because they stopped caring. They did it because the moment arrived, the release was ready, the business was waiting, and the information in front of them did not settle the question either way.
Almost every other number in this research explains how they got there.
53%* say security findings are frequently out of date by the time they reach the people who need to act on them. Only 36% strongly agree they have visibility into which specific software changes introduced risk after a security incident. 78%* say their organisation has mandated AI-assisted development, while only 38% strongly agree the organisation is prepared for the volume of AI-generated code now entering the environment.
Put those together and the sign-off gap stops looking like a discipline problem. It looks like the predictable output of a security operating model that was designed for a slower rate of change, now running at a rate of change nobody in it chose.
62%* of security leaders say security risk in their organisation is moving from a latent problem to an immediate one. That is the sentence this report is really about.
Security leaders are not short of testing. They are not short of findings, tools, or dashboards. They are short of a decision they can defend: a clear, current, contextual answer to whether a specific software change matters, what response it justifies, and what evidence exists afterwards to show that the right thing happened.
The gap in the assurance model is not detection. It is the decision that sits between a change being made and a security response being chosen. Under a quarterly release cadence, that decision could be absorbed by review meetings, change boards and scheduled testing. At the rate software now changes, and with AI-assisted development mandated in more than two thirds of these organisations, that absorption capacity is gone. The decision still has to be made, hundreds or thousands of times a week. So it gets made informally, late, or not at all, and someone signs off anyway.
78%* of organisations have mandated AI-assisted development.
Against that:
Only 40% of security leaders strongly agree their security team has received adequate tools, budget and resources to support agentic AI software change.
Only 38% strongly agree their organisation is prepared for the volume of AI-generated code entering their environment.
53%* of security leaders say security findings in their organisation are frequently out of date by the time they reach the people who need to act on them.
Asked what concerns them about their organisation's current software change management processes, leaders pointed at the same disconnection from several directions:
36% said security testing results are not connected to the specific change that introduced the risk.
31% said security testing is disconnected from the business context of the change being made.
28% said security testing cannot keep pace with software change.
28% said tickets lack the detail and context security teams need to act on
Only 36% of security leaders strongly agree they have visibility into which specific software changes in their organisation introduced risk after a security incident.
Among organisations that have experienced a security incident in the past three years, the reported causes were spread widely (all figures below describe that subset, not the full sample):
29% a third-party dependency or open source component
29% a change made outside the standard development process: shadow IT, a hotfix, an emergency release
27% a flaw in third-party software
27% a misconfiguration in cloud infrastructure or a deployment environment
27% a bug that had been present for over 30 days before discovery
26% a weakness introduced by AI-generated code
26% chained vulnerabilities
25% a change that was not reviewed
We asked what the biggest barriers are to producing evidence of which software changes over the past 12 months have been security tested.
41% said the volume of change is too high
36% said testing happens too late in the release cycle
36% said reporting does not connect to individual changes
35% cited the diligence of the humans inputting information
30% said there is no clear ownership of the review process
Separately, 18% named the absence of a continuous evidence trail for auditors or customers as a concern about their change management process.
32% of security leaders said they believe security is seen as a blocker to development velocity.
31% said security testing is disconnected from the business context of the change being made.
30% said it is difficult to prioritise findings because there are too many vulnerabilities and no clarity on what to fix first.
29% said the business perceives it as too costly to test every software change.
62%* of security leaders say security risk in their organisation is moving from a latent problem to an immediate one.
Every cluster in this research points at the same missing layer.
Testing exists. Scanning exists. Change management exists. Governance exists. What is missing is the connective decision between a change being made and a security response being chosen: the point at which someone establishes whether this change matters, what could go wrong, what response is proportionate, and where the answer gets recorded.
In most of these organisations that decision is not a system. It is a queue, a meeting, a policy document and a judgement call made under time pressure by someone who does not have the context in front of them. It works well enough at low volume. At mandated AI-assisted development velocity, it produces exactly what the research describes: late findings, untraceable incidents, reconstructed evidence, and 48%* signing off anyway.
Cytix is the security decision layer for a world where software development never stops. It sits between the change and the security response, and it runs the same four questions against every change it sees:
Does it matter?
What could go wrong?
What is a proportionate security response?
How does all of that get reported back to the change?
A developer opens a ticket and raises a pull request altering how session tokens are validated in a customer-facing application. Some of the code was AI-assisted. The ticket description is two lines long, which is normal.
Cytix reads the change against what it knows: the affected asset, the environment it runs in, prior findings on that component, repository signal, documentation and workflow metadata. The two-line ticket is not the input; it is the pointer to the input.
Cytix determines whether the change matters, whether more context is needed before that can be answered, what could plausibly go wrong, and what response the change justifies against the organisation's own policy and thresholds. On this change, the answer is that authentication logic in a customer-facing path warrants attention. On the majority of changes an organisation makes, the honest answer is that it does not, and saying so is as valuable as escalating.
Depending on the qualification, the response may be more context, a human review, an updated threat model, a design change, a specific validation or penetration test, a remediation item, or an accepted risk recorded as such. Human expertise enters where context, business logic or assurance genuinely changes the answer, not as a rubber stamp and not as manual labour. Cytix routes into the ticketing and workflow systems teams already use.
The decision, the rationale, the action taken and the outcome stay attached to the change that caused them. That is the thread the 36% in Finding 2 do not currently have, and the thread that makes the evidence in Finding 3 a by-product of the work rather than a project undertaken later.
Whether or not Cytix is ever part of the answer, this research suggests five questions worth putting to your own function this quarter.
When a developer asks whether a change is risky, how long does it take to get them an answer?
If a regulator or a major customer asked how you decide which changes get scrutiny, how comfortable is that answer?
After your last incident, how long did it take to identify the change that introduced the risk? And was that identification a query or an investigation?
How much of your evidence depends on someone filling in a form carefully? 35% of your peers named that as a barrier.
What proportion of the changes you review turn out not to have needed security attention?
48%* have signed off on a release they were not fully confident was secure. 53%* say findings arrive out of date. Only 36% strongly agree they can see which change introduced risk after an incident. 62%* say the risk has stopped being latent.
None of those numbers describe a profession doing its job badly. They describe a security operating model built for a rate of change that no longer exists, being asked to hold a line at a velocity the business has now mandated. More testing does not close that gap, because the gap is not in the testing. It is in the decision before it, and the evidence after it.
Software change is the unit that matters. Understanding which changes matter is the work. Everything else, including the testing, is what happens once that question has been answered.
Security understood.
*‘Strongly agree’ and ‘Somewhat agree’ responses combined.