In this article
About this research
Research conducted on behalf of Cytix by Opinion Matters between 28.07.2026 and 03.08.2026. Sample: 250 UK IT security leaders (aged 25+), including CISOs, Heads and Directors of IT Security, VPs of IT and Information Security, Directors of Application Security and Product Security, Heads of AppSec, AppSec Leads and Heads of IT Security Engineering. All work in organisations employing 1,000 or more people with an in-house software development team. Opinion Matters abides by and employs members of the Market Research Society and follows the MRS code of conduct and ESOMAR principles. Opinion Matters is also a member of the British Polling Council.
Initial take
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.
What we think this research shows
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.
Why now: the mandate arrived before the resources
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.
What we take from it
The interesting thing here is not that AI-generated code is uniquely dangerous. It is that the volume decision was taken at board level and the assurance decision was not. Development velocity was mandated as a strategic priority; the security function's ability to qualify what that velocity produces was left roughly where it was. Despite this, we would still resist framing any of this as an AI security problem. AI-assisted development is pressure on software change. The unit that has to be understood is still the change itself: the ticket, the pull request, the diff, the release. What has altered is how many of them there are, and how few of them a human has read.
Finding 1: Findings arrive too late to be useful
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
What we take from it
A finding that arrives late is not a weaker version of a finding that arrives on time. It is a different object. By the time a stale finding reaches an engineer, the code has moved, the context has gone, and the work of reconstructing why the change was made in the first place falls to whoever is holding the ticket. That is the tax nobody budgets for. It is also why security findings and business priorities so often look like they are describing two different companies. The 36% figure is the one we would put in front of an audit committee. If test results are not connected to the change that caused the risk, then the organisation cannot answer a simple question in either direction: what did this change introduce, and what have we done about it?
Finding 2: After an incident, most cannot point to the change
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
What we take from it
Two things stand out. The first is that the causes are almost evenly distributed, which tells you there is no single control to buy your way out of. The second is more uncomfortable: the two highest causes, third-party components and changes made outside the standard process, are both cases where the organisation's normal review path was never in play. That is the same problem the 36% visibility figure describes, arriving from the other end. If a change can enter production without passing through the process that would have qualified it, then after an incident there is no record to trace back to. The forensic work becomes archaeology: tickets, Slack threads, commit history, someone's memory of a Friday afternoon. An emergency change is not a governance failure. It is a legitimate operational necessity that most change processes handle badly, forcing a choice between shipping the fix now and keeping the evidence trail intact. Most organisations quietly choose the fix. They are right to. The process should not have made them choose.
Finding 3: Evidence is a reconstruction job
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.
What we take from it
Read the top three together and they describe a single mechanism. Volume outruns the process; the process runs late; the output is not attached to individual changes. Each one alone is survivable. In combination they mean that evidence is not a by-product of the work, it is a separate project undertaken after the fact, usually under deadline. The 35% figure deserves particular attention, because it is the one nobody wants in writing: a third of security leaders say the reliability of their evidence depends on how carefully individuals filled in forms. That is not a criticism of those people. It is a description of a control that exists only in someone's conscientiousness on a busy day.
Finding 4: Security are still viewed with friction
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.
What we take from it
These four numbers are usually treated as a culture problem to be solved with better relationships. We think they are an information problem wearing a culture problem's clothes. Security is experienced as a blocker when it applies the same scrutiny to a copy change and a change to an authentication flow, because from the outside that looks like indiscriminate friction rather than proportionate care. The 29% is the same point expressed as money: if every change is treated as equally deserving of testing, then testing every change is indeed too expensive, and the business is right to say so. The way out is not for security to test less or to care less. It is for security to be able to show, change by change, why this one warranted attention and that one did not. Proportion is what turns a blocker into a filter. Only the right things get passed through.
Finding 5: The problem has stopped being theoretical
62%* of security leaders say security risk in their organisation is moving from a latent problem to an immediate one.
What we take from it
This is a strong majority saying, in effect, that the buffer has gone. Software risk used to behave like a slow accumulation: something you managed over quarters, with the reasonable expectation that today's unreviewed change would probably not become this week's incident. 62% say that’s no longer the case. Combined with the 48%* who have signed off on a release they were not fully confident about, and the 36% who cannot trace which change introduced risk after an incident, the picture is of leaders carrying immediate risk with a delayed information supply. Moreover, it is not solved by more findings arriving faster. It is solved by knowing which changes matter, in time to do something proportionate about them, with a record that survives afterwards.
What the findings share
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.
How Cytix approaches this
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?
The workflow
A change appears
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.
Context is assembled
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.
Security relevance is qualified
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.
The right response is routed
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.
Evidence is retained
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.
What this means for security leaders
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 the honest answer is measured in days, your findings are already arriving into a different codebase than the one they describe.
If a regulator or a major customer asked how you decide which changes get scrutiny, how comfortable is that answer? Not whether you have a policy. Whether the policy describes what actually happens.
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. It is worth knowing your own exposure to it.
What proportion of the changes you review turn out not to have needed security attention? If you cannot answer that, you cannot yet demonstrate that your scrutiny is proportionate, which is the argument that turns security from a blocker into a filter.
Where this leaves us
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%1 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.
Close the assurance gap
Don't let AI assisted development cloud your view of what's secure. Know exactly what changes matter, as they're made.
*‘Strongly agree’ and ‘Somewhat agree’ responses combined
This article is an exclusive
Unlock the full article by submitting the form. Get instant access to all premium resources available only to registered users.
