Security should enable programmes to move faster and be secure.
What is Change Driven Security?
Change Driven Security is the approach we are exploring at CloudPeek: using a programme’s existing security knowledge to assess the security implications of a proposed change against its agreed standards, controls and risk tolerance. The assessment helps identify which changes need security review and gives reviewers the evidence and context to make a decision.
The immediate focus is change assessment. A customer asks for a new integration. Engineering proposes a different component. A request for change introduces new connectivity. What does that mean for the security of the programme, and how much review does it need?
Why can security reviews delay programme delivery?
In recent conversations with people delivering security-sensitive programmes, a recurring problem has been where security fits into the change and delivery process. Changes can reach development before security has had the opportunity to assess them. By the time the security implications become clear, decisions have been made and work may need to be revisited.
In one conversation, a chief engineer described change requests going straight to development, bypassing the security architect. The security team was brought in after the work had been built, when addressing the concerns could mean revisiting decisions already made. They described the resulting back-and-forth as “ping pong”, with developers seeing security as the blocker because it was the last team to touch the work.
The same person described a different approach on a programme they had improved: change requests went past a dedicated security architect, with security input built into the delivery teams. Their question for an initial assessment was practical:
“Does a security architect need to get eyes on or can it go straight to a team?”
There can be several reasons. Security teams may not have enough capacity. The programme may not have allocated enough budget for security support. Delivery teams may not recognise which changes affect the security design. Under pressure to meet a deadline, a review can become something to deal with later.
Whatever starts the problem, the consequences can reach well beyond the security team. Decisions wait, work gets repeated and milestones slip. When payments depend on those milestones, delays affect programme cash flow too.
A separate conversation about cloud migration showed how this problem extends beyond application development. A provider may be ready to move infrastructure into the cloud, while the customer still has security assurance requirements to work through, particularly in government and financial services. The technical migration is only part of what needs to happen before delivery can proceed.
For us, that raises a useful question: can the security implications of the proposed migration be assessed against the customer’s agreed standards, architecture and risk tolerance early enough to inform the delivery plan? Where review is needed, the team should know what requires attention and what evidence to prepare.
One programme delivery professional we spoke to described teams improving their development process and delivering in short sprints, only to find that getting the work approved for live use remained slow. In their experience, faster development was building up work waiting for assurance.
They described a programme launch delayed by several weeks while approvals were lined up across different assurance groups. Each group wanted evidence from the others before signing off. The requirements were known, but coordinating the decisions still held up delivery.
That example spans several assurance disciplines. Our current focus is the security change assessment within that wider process. Improving it needs to make the existing process work better, including making dependencies on other reviewers visible.
From my experience across security operations and engineering, this is something we need to get better at. The people doing the security work need the time and context to make useful decisions early enough to help delivery.
What knowledge does a security change assessment need?
A programme may already have architecture documentation, security requirements, agreed standards and controls, threat models and a documented risk tolerance. Together, these establish how the system is meant to work, the standards it must meet and which risks its owner has agreed to accept.
Our question is whether we can make that knowledge more useful when a change arrives.
CloudPeek is working on an approach that uses this material through our dynamic knowledge layer to assess a proposed change against the programme’s agreed standards, controls and risk tolerance. The assessment should identify the affected risks, applicable requirements and design assumptions, and provide the evidence behind its conclusions.
There are two connected jobs here. First, establish whether the change falls within the programme’s agreed risk tolerance. Second, where security review is required, give the architect a useful starting point: what has changed, where the concerns are and which existing decisions or controls are relevant.
That should help the architect spend their time solving the problem, with less time spent getting reacquainted with the context.
This builds on the organisational knowledge layer we have written about previously: keeping the evidence and reasoning behind decisions available for the next assessment.
How does Change Driven Security relate to Secure by Design?
The MOD’s Secure by Design guidance describes security as an ongoing part of a capability’s lifecycle, with controls proportionate to its context and risks.
Our proposed change assessment process would use the programme’s Secure by Design documentation, threat models and agreed standards when a change arrives. The documented risk owner retains authority over risk tolerance, and the programme’s security working group continues to define its delivery and approval processes.
How can CloudPeek help security architects review changes?
The same programme delivery professional described security reviewers spread across many programmes. A reviewer coming into a programme intermittently has to understand what has been built, what has changed and which decisions have already been made before they can judge what needs attention.
The evidence can be spread across user stories, architecture documents, code repositories, Confluence and SharePoint. They also described lengthy assessments, followed by similar reporting at later stages and for other review groups. In their account, much of the underlying information was repeated.
This gives us a practical question to test: can CloudPeek use the programme’s existing knowledge to prepare a focused assessment of the change, linked back to the relevant evidence and agreed standards?
For an architect, that could mean arriving at a review with the affected controls, outstanding questions and relevant design decisions already identified. For a programme manager, it could mean seeing earlier which changes need security input and what information is needed to move them forward.
Who decides whether a change needs security review?
The documented risk owner owns the programme’s risk tolerance. The programme’s agreed standards and any approved exceptions also need to be documented and available in CloudPeek so that the assessment can follow them. A change falling within risk tolerance still needs to meet the applicable standards or follow the programme’s process for approving an exception.
As I put it during the discussion:
“We don’t define, we follow.”
The process we are exploring has three outcomes:
- Within the agreed risk tolerance: the change can go directly to development or engineering under the programme’s agreed process.
- Outside the agreed risk tolerance: it goes to security review, with the areas of concern and supporting evidence already identified.
- Undetermined: CloudPeek records what it could establish and what evidence is missing, then routes it for security review. Security or programme management can obtain the additional information.
Missing information needs to be visible. An assessment that cannot establish the risk needs to say so and explain what is needed next.
What does a security change assessment look like?
Consider a proposed integration with an existing partner. The partner is already approved to handle the identified data. The connection is encrypted and point-to-point, with no direct internet access. Data access is limited to non-sensitive information.
If those conditions meet the programme’s agreed standards and documented controls, and fall within its risk tolerance, that change could go directly to engineering. CloudPeek would need to show the evidence supporting that route.
Now introduce internet connectivity, or a new piece of software or hardware. That could affect assumptions in the existing design and require security review. The useful output is an explanation of which assumptions or controls may be affected and what needs attention.
Implementation and updates to programme documentation would continue through the standard process defined by the programme’s security working group.
How is CloudPeek testing Change Driven Security?
We are defining the concept and testing prototypes. The backend works as part of CloudPeek’s dynamic knowledge layer, and we want to shape the interface and workflow with people experiencing this problem in a real programme.
We want to start within the processes people already use, prove where the assessment helps and iterate from there. In a pilot, we would agree what to measure with the programme: time spent preparing and reviewing changes, issues identified before implementation, or rework caused by security concerns found late. Those are outcomes to test.
As AI helps teams build software faster, the capacity to assess that work needs attention too. Otherwise we risk moving the queue from development into assurance, with little improvement in how quickly a programme can deliver something usable.
The aim is to make better use of the security expertise a programme has: give routine changes an appropriate route and give architects the context to focus on decisions that need their judgement.
“Security should enable programmes to move faster and be secure.”
We are looking for a pilot partner actively experiencing delays or friction in security change reviews, who wants to test an approach and iterate quickly with us. If that sounds like your programme, we would like to talk.