Different risks, the same queue

Two changes land in the same release. One's a wording tweak to an internal help page. The other changes authorisation logic. Both go into the security queue and wait for the same specialist, even though one of them probably doesn't need any more security work at all.

Sound familiar? That first look is where a lot of the waiting actually starts. In our research with 250 UK security leaders, 32% said security is seen as a blocker to development velocity, and 28% said tickets don't carry the context security teams need. So it's worth asking a fairly simple question: how does your team decide which changes need specialist review?

In this post, we'll walk through five practical steps to help you answer it, and then show you how to trial the approach on a single service before rolling it out more widely.

Why this matters more now

AI-assisted development is adding to the pile. More changes coming in means more changes to qualify. You might still need extra review capacity, of course, but it's worth starting with what's using up the capacity you've already got: how many changes arrive, how many really need a specialist, and how reliably your current process tells them apart.

The good news is that you can cut a lot of avoidable waiting by deciding which changes need specialist review earlier. That means agreeing the criteria, pulling together the context each decision needs, naming who owns exceptions and keeping a record of why each change went the way it did. Testing then follows wherever the assessment says it's needed.

Research conducted by Opinion Matters on behalf of Cytix among 250 UK IT security leaders at organisations with 1,000+ employees and an in-house development team, 28/07/2026 to 03/08/2026.

Step 1: Check the change, not the ticket

A security review usually starts with a ticket. The trouble is, the information you need to assess usually sits somewhere else. So it pays to gather those inputs before the decision is made.

Our guide to agentic AppSec in practice sets out the sources worth reading together: ticket descriptions and comments, pull request discussions, code diffs and linked architecture records. Put them side by side and it’s much easier to spot where a change doesn’t match the description.

Going back to our help page update, this would mean checking the implementation before choosing the lighter path. Let's say the diff confirms it's a wording-only edit to static content, with nothing touching templates, scripts, permissions or deployment configuration. The relevant checks pass, and you know which service and environment it affects. So that one can take the lighter path.

But if the ticket says 'wording update' and the pull request also changes executable behaviour, that mismatch needs dealing with first. Whilst the ticket title sounds reassuring, it can't settle the question on its own.

Step 2: Let policy set the route

Once you understand the change, your organisation's policy should determine the response. For example, a policy might allow verified content-only changes to go ahead without additional specialist security review, while keeping peer review, testing and release controls in place. Changes affecting access decisions, on the other hand, might require a trained reviewer or focused validation.

Established guidance supports this. NIST's Secure Software Development Framework suggests defining criteria for security checks and selecting review or analysis methods according to organisational policy. DORA's guidance on streamlining change approval names 'treating all changes equally' as a pitfall and suggests measuring what percentage of low, medium, and high-risk changes need manual approval. Neither prescribes thresholds. Those need to reflect your own systems, obligations, and risk appetite.

So now our two changes take different paths, and anyone can see why. The help page update meets the agreed conditions and continues through the normal release process. The authorisation change receives closer assessment of the affected access rules, the relevant threats and the test evidence. If information is missing, the next step is to request clarification. If a plausible risk needs validating, it might be a targeted test. Either way, the outcome is a decision tied to the change, with the work needed to support it clearly identified.

Step 3: Define what qualifies for lighter review

It’s tempting to assume a small diff means low risk, but this isn’t always the case. A one-line edit to an access rule can change who reaches sensitive data, while a large change may follow an established pattern with controls everyone understands.

So define eligibility by what the change actually affects from a security point of view: exposure, privileges, sensitive data, dependencies and trust boundaries, as they apply to the system. It’s also worth deciding up front whether the assessment covers risk introduced by the change, the existing risk in the component it touches, or both, and factoring in the surrounding environment and previous findings. Passing automated checks does count as evidence, but only within what those checks cover. They won’t tell you much about business logic or intended behaviour.

When information is missing or conflicting, that should trigger clarification or a human review. And if AI is helping with the assessment, be clear about the evidence it can use, how much uncertainty should trigger escalation, and who can override its recommendation.

Our AppSec guide recommends running the assessment in parallel with your existing process to begin with. We’d add one step: look closely at the cases where the two disagree, and sample both the changes that qualified for lighter review and those that escalated. That will show you whether the process is picking up the differences that matter before your release depends on it.

Step 4: Record the reason for every decision

In our research, 36% of security leaders said their reporting doesn’t connect to individual changes. And a 'review complete' status doesn’t really tell us much. Did a specialist look at the access logic? Did a test validate a risk? Or did the change simply meet criteria you’d agreed to in advance?

Each decision should leave a record of the scope that was assessed, the context considered, the policy that applied, the rationale, the accountable owner and any action needed. That way engineering, security and anyone checking assurance later can all understand what happened.

That also goes for decisions not to review. For the help page update, you'd record which revision was assessed and why it met the eligibility conditions. If a later commit changes the basis for that decision, the affected scope needs reassessing, so agree how that will work before you start relying on the lighter path. Keep sensitive technical detail under the right access and retention rules, and keep records focused on what was assessed and why, rather than everything that was looked at.

Step 5: Measure the wait security can influence

DORA defines change lead time as 'the amount of time it takes for a change to go from committed to version control to deployed in production'. Security review can start before that clock does, and some of it runs alongside other delivery work. So faster review only shortens lead time where it's removing a constraint on deployment, and it's worth being precise about that when you report impact.

To get a clear picture, record when each change is submitted, when it's first assessed, when information is requested and when the final decision lands. Then split out queue time, active assessment and time spent waiting for information. Look at the typical waits as well as the longest ones.

Then pair those timings with a few quality measures: sampled classification errors, overrides, how complete the evidence is, and any security issues later traced back to changes. That's how you show the decisions are holding up as they get quicker. Delivery failure measures add useful context, but they can't show that a change didn't introduce a security weakness, so treat improvement as something you demonstrate over time.

Putting it into practice: Start with one service

You don’t need to change everything at once. Pick a service where the change history, owners and review records are accessible. Then sit down with engineering and go through recent work together: where did changes wait, what information was missing, and which assessments needed specialist expertise?

From there, agree a narrow set of eligibility conditions and a named exception owner, then trial the routing with human oversight. Keep a baseline so that changes in workload or release practice are visible when you assess the results. Once the team can explain both the effect on waiting time and the quality of the decisions, you’re in a good place to expand. Just bear in mind that some services will need different thresholds or extra controls.

How Cytix helps

Cytix applies this approach to the software change itself. Automatic change approvals pulls together the context for each change, assesses its security relevance and checks it against your own approval policy and risk thresholds. Where a change clearly meets your policy, it can proceed without manual sign-off. Anything else goes to a person, and every decision keeps its rationale.

When you evaluate it, follow a single change all the way through: what information was considered, which policy applied, why it proceeded or needed closer attention, and what record remained. Include a change with insufficient context, and see exactly where a person steps in. Any effect on lead time should be measured in your own delivery process.

Join our newsletter

Receive the latest advancements, playbooks, and industry insights in software change security understanding.

Frequently Asked Questions