Cyber security review as a delivery milestone
Booking the penetration test is the easy half. The milestone worth planning is the remediation window, with owners, severity definitions and a retest slot agreed before the report exists.
Public sector3 min read
The shape of this failure is predictable enough to draw in advance. A penetration test report arrives eleven working days before go-live. Fourteen findings, four of them architectural. The test had been in the plan for months. What had never been in the plan was who would fix what it found, in which order, and by when.
Security review sits inside each of our delivery cycles rather than in a phase before release, and the reason is closer to scheduling than to ideology. A finding about a session token is an afternoon's work. A finding about the authorisation model cannot be fixed at all in the time remaining at the end of a programme.
The remediation window is the milestone
Booking an assessor is the small half of the job. The line that belongs in the plan is the remediation window: a block of engineering capacity after the report, sized on the assumption that the report will contain something serious, with the retest already booked against the same assessor. Retest slots go quickly and assessors are booked out for weeks. Reserve both at the same time, from the same conversation.
Sizing that window is guesswork, and guessing is still better than the alternative. Two weeks of two engineers for a system of moderate size is a reasonable opening position. If the report comes back clean, that capacity gets absorbed by the release. Nobody has ever complained about the fortnight they did not need.
An ugly early test beats a polished late one
The findings that hurt are structural: how authorisation is enforced, how keys are handled, how tenancy is separated, how audit events are written. All of those are decided in the first weeks and are close to immovable in the last. An informal assessment against a partial system in month two, producing a report nobody would show a steering committee, is worth more than an immaculate one in month nine.
We would far rather be told the authorisation model is wrong while it is still four hundred lines of code and one integration. The same finding at the end of a public sector programme means a go-live date moving, and go-live dates in that world are attached to legislation, budget years and public commitments.
Severity is negotiated before the report exists
A week can vanish into an argument about whether an issue is high or medium, and that week comes directly out of the remediation window. Settle it at the point of engagement: the severity definitions, what counts as a fix, what counts as a compensating control, and who holds the authority to accept a risk rather than fix it.
That last one matters most in government work, where the person able to accept a risk is often outside the programme entirely and their calendar is not ours. Find out who they are and how much notice they need in month one, because discovering it in the final fortnight converts a manageable finding into a schedule problem.
Give the assessor something real to test
A test run against an unstable staging environment produces a report about the staging environment. Give the assessor a stable build, credentials for every role including the privileged ones, the architecture and data flow documentation, and a named engineer who answers questions inside the day.
Teams sometimes withhold access on the theory that a black-box test is more honest. It is mostly just slower. An assessor spending three days mapping what a diagram would have shown in twenty minutes is three days of paid effort not spent on business logic and authorisation, which is where the findings worth having actually live.
The pipeline should make most of it dull
Dependency scanning, static analysis and secret detection belong in the build, where they break a pipeline in the first cycle instead of appearing in a report in month nine. Automating them is what frees the assessor's time for the parts no scanner reaches, and it means the report contains fewer items the team could have found for themselves, which does something useful to the credibility of the ones that remain.
A security review that surprises the programme has failed as a piece of planning, whatever it happens to find. The report should confirm most of what the team already suspected, in a form the reviewing authority will accept, on a date everybody agreed to months earlier.
More on public sector
All writingApril 2026
The engineering behind a border control system
Availability, offline operation, biometric thresholds and the audit trail, seen from the officer's booth at three in the morning rather than from the tender document.
September 2025
DevSecOps when security review is a gate, not a step
In government programmes the security function sits outside delivery and can stop a release. The pipeline's job is to make the assessment cheap, repeatable and dull.
February 2022
Procurement is a design constraint, not paperwork
In public sector delivery, a third of the architecture is already written into the tender schedules. Reading them as legal formality is how programmes acquire expensive late changes.
Talk to our engineering team
Tell us what you need built, modernised or maintained. We will tell you whether we are the right firm for it and what it costs.