Security assurance on major transformation programmes: where it usually goes wrong

James Bruckel·CEO, Wuluf

The most difficult security assurance issue on a transformation programme is often a timing issue. The programme has chosen its suppliers, agreed a design and committed to a delivery date. Then assurance asks for evidence that a critical control will work. If that evidence is missing, the choice is suddenly between changing a plan that has gathered momentum and accepting a risk nobody intended to take.

That is a poor position for the delivery team and the security team. Earlier assurance would not have guaranteed a perfect design. It would have given the programme more time to test an assumption, change a requirement or fund the work needed to make the control real.

Major programmes already have plans, governance and approval points. Security assurance should use them. The useful question is what a security review needs to establish before each decision becomes expensive to reverse.

I would ask the executive board, the IT leadership team and the programme office whether security is part of their normal governance. If they can name the security people, know them and speak to them regularly, that is a useful sign. Hesitation or a referral to somebody several steps away suggests security may be brought in late unless the programme has very strong review points. I see the cost of that delay too often, including in decisions made while the work is still only a concept.

Assurance gets planned around the final approval

Many programmes know they will need a security review before a service goes live. They put the review on the plan and assume the team can assemble the evidence when the date approaches. The difficulty is that a review can only tell you what the evidence supports. It cannot create missing controls or recover months of supplier negotiation.

Consider a service that depends on a supplier to provide audit records, access controls and a route for incident reporting. If the contract and design have already been agreed before anyone checks how those controls will work, the final review may reveal a gap that the delivery team cannot fix alone. The example is illustrative, but the decision it exposes is familiar. The programme needs to know what it is buying and how it will verify it before it commits.

For projects on the Government Major Projects Portfolio, an assurance and approvals plan is required to coordinate reviews and approval points across the life of the programme. Security teams need to connect their work to that plan where it applies, and programmes outside that regime can use the same principle. Put the security question beside the decision it is meant to inform.

UK Government Secure by Design guidance calls for security to be considered early and throughout delivery. In practice, early contact gives the team time to challenge an assumption before it becomes a contract, a build decision or a date in the programme plan. A review at the end still has a purpose, but it cannot recover every opportunity lost at the start.

The wrong evidence arrives at the right meeting

A pack can contain policies, diagrams, certifications and test reports without answering the question in front of the decision maker. A supplier certificate may say something about the supplier's management system. It does not, by itself, show that the programme has configured its service correctly or decided who responds to an alert.

The National Cyber Security Centre makes this distinction in its assurance guidance. Confidence comes from how a control has been chosen, implemented and operated, as well as from any external assessment. A snapshot also has limits as the service changes. The programme therefore needs to decide what claim each piece of evidence supports and what remains to be checked in its own environment.

If the review asks whether privileged access is controlled, a generic access policy is only a starting point. Someone should be able to show which roles can use that access, who approves it, how it is removed and what records exist. That is the sort of evidence that can change a design or an operating decision while there is still time.

Suppliers are assumed to own more than they agreed to deliver

Transformation programmes cross organisational boundaries. The prime, cloud provider, software vendor, internal operations team and future service owner may each hold part of a security control. The gap often sits between them.

A supplier may have a strong security record and still provide a service that depends on the client to configure logging, manage identities or monitor alerts. If the programme has not identified those responsibilities, the assurance team will find statements such as the supplier is responsible or IT will handle it. Neither tells the reader who will do the work, what access they need or how the programme will verify completion.

The NCSC advises organisations to assess supplier controls during selection, put necessary requirements into the contract and monitor them during delivery. Those steps have different deadlines. An assurance requirement discovered after contract award can become a commercial change, a delivery delay or a risk the client has to carry.

The risk reaches somebody who cannot change it

A security specialist can explain why the evidence is weak and recommend a treatment. They may have no authority over the programme budget, the supplier contract or the delivery date. Assigning the risk to security because it is a security risk does not give that team any of those powers.

The programme needs to name the person who can decide what happens next. Can the design be changed? Is extra funding available? Will the service be delayed? If a residual risk is to be accepted, who has the authority and the information to make that choice? Security should give that person an honest view of the facts and the available options.

Most programmes I have worked with have had a senior responsible owner, often with the right budget and authority. The delay can come below that level. I encourage clients to agree in advance what operational teams may decide within boundaries set by that owner. They can then carry out anticipated tests or fixes without waiting for the next senior meeting. Material changes and acceptance of significant risk still go back to the person with authority. The senior responsible owner gets assurance that the team has stayed within the limits they agreed.

When no one can answer, an issue can sit in the register while work continues around it. By the next review, the practical options may have narrowed again. That is why assurance needs a route into programme decisions, not just a place on the reporting calendar.

What to do when assurance is already late

A late review is still worth doing. It should be clear about what has been demonstrated, what remains untested and what can realistically change before the next commitment. That may require a targeted test, a supplier clarification, a design adjustment or a decision to hold a transition point.

The first response should be to separate immediate blockers from work that can be controlled during operation. This is a judgement about the service and its risks, not a way of relabelling every unresolved issue as an action for later. Record who owns each action, what evidence will show it is complete and who will decide whether the service can proceed.

The programme should also ask why the issue surfaced at that point. Was the security requirement absent from the procurement? Did an assumption about a supplier go untested? Did an earlier review raise the issue without getting a decision? That answer matters to the next phase of delivery, not just to a lessons learned document.

The handover leaves nobody checking the control

A transformation programme may finish when the new service is accepted. The security risk continues while the service is used. A control that passed a test during delivery can weaken after a configuration change, a new supplier connection or a change in who has access. The operational team needs to know what was tested, what was left open and how it will keep checking the controls that matter.

I have seen a clean new system land on an older environment with serious technical debt. The project team may have followed good practice within its own boundary, yet the infrastructure it depends on weakens the result. If nobody assessed that dependency early, the programme may have missed the chance to change the environment or design compensating controls before deployment.

Security operations centre monitoring is another. I have seen services deployed before the monitoring team had developed its playbooks or worked out which logs and alerts it needed. Building that capability alongside the service gives the team time to understand normal behaviour and think through how the service could be misused. Waiting until after release wastes a useful period when the new service can be observed with fewer changes and less ordinary user activity around it.

This is another handoff assurance should examine before transition. Who receives the records and the outstanding risks? Who owns monitoring, patching, access reviews and incident response? Which supplier obligations continue after the project team has left? If the answer is a future operating model that nobody has staffed or funded, the programme has not finished the security work by handing over a folder.

NCSC guidance treats assurance as something to maintain through the life of the service. For a programme, that means the final review should give the service owner a usable starting point. It should tell them where the evidence is strong, what assumptions it rests on and what changes would require another look.

Make assurance part of the delivery conversation

A workable approach starts with a small number of decisions. What is the programme changing? Which services and information matter most? Where will a supplier or design choice be hard to reverse? What evidence would the decision maker need at those points?

Security can then plan its reviews, tests and supplier questions around those choices. The work still has to adapt as the programme learns more. A new integration, supplier or use of data may change the risk. Assurance should make that change visible and bring the right people together while they still have options.

That requires a named route into the programme team and clear authority for routine decisions. Security should see changes to scope and design early enough to respond. The programme should know who can obtain a supplier answer, who can fund a test within agreed limits and who will bring a material issue to the senior responsible owner. A review date without those working relationships offers limited help.

The aim is to make the delivery decision better. If security assurance has done its job, the programme can explain the control it expects, show evidence of what is working, identify what is unresolved and name the person who can act. A green report without those answers offers little comfort.