By EJN Labs · 10 Aug 2026 · 8 min read
The Service Standard does not name penetration testing in any of its 14 points, but government digital services are expected to show security testing evidence at service assessments, and GOV.UK Service Manual guidance recommends penetration testing before a service handles real user data. A CREST-accredited test is the accepted way to meet that expectation. A typical single-service test runs 4 to 6 days, around £4,400 to £8,400.
What the Service Standard says about penetration testing
The Service Standard never uses the words “penetration test”. Owned by the Central Digital and Data Office, it is a set of 14 points describing how government digital services should be designed and run, mandatory in practice for central government transactional services and widely adopted by other public bodies.
It is one of the most common questions we hear from public sector service teams preparing for an assessment, which is why it is worth being clear about what the standard actually contains.
The security requirement sits in point 9: create a secure service which protects users’ privacy. That point is deliberately outcome-based. It prescribes no testing method, frequency or supplier accreditation, but it puts the burden on the service team to show, with evidence, that security has actually been tested rather than assumed.
This is where penetration testing enters the picture. The GOV.UK Service Manual, the practical companion to the Standard, discusses vulnerability and penetration testing as part of securing a service, and assessors routinely ask what independent testing has been carried out, what it found and how findings were fixed. A team arriving at a beta or live assessment with no testing evidence is exposed on point 9, even though no clause literally says “you must buy a pen test”.
Why service assessments make testing evidence unavoidable
Central government services within CDDO’s assurance scope are assessed at the end of alpha, before public beta and before going live, against all 14 points. A not met rating on point 9 blocks progression: a service that fails its beta assessment cannot move to public beta on GOV.UK until the issue is resolved.
The questions assessors ask on point 9 follow a consistent pattern:
- Has the service had independent security testing, and when?
- What was in scope: the web frontend, the APIs, the cloud environment, the integrations?
- What did the testing find, and what is the evidence that findings were remediated and retested?
- How will testing be repeated as the service changes after launch?
None of those questions can be answered convincingly with an automated scan report alone. Scanners find known signatures; they do not test authorisation logic or the way a service trusts data from another government system. That is why a manual penetration test from an independent firm has become the de facto evidence for point 9. Suppliers building services for departments face the same expectation, because the contracting authority carries the assessment risk and passes the evidence requirement down through the contract.
What to test in a government digital service
Most modern government services share a recognisable shape: a citizen-facing frontend built to GOV.UK design patterns, backend APIs, cloud hosting, an identity integration for sign-in, and connections to departmental case management or legacy systems. Scope should follow that architecture, not a generic checklist.
The citizen-facing frontend
The public web application is the largest attack surface. Testing covers input handling across every form step, session and cookie behaviour, access control between journey states, and whether one user can reach another user’s data by manipulating references.
APIs and integrations
Government services are increasingly API-first, and the APIs often trust internal callers more than they should. An API penetration test checks authentication and authorisation on every endpoint, rate limiting, and the handling of data received from other systems, including other departments’ services.
The cloud environment
Misconfigured cloud infrastructure undermines a secure application. A cloud penetration test reviews identity and access management, network segmentation, storage permissions and secrets handling in the accounts that run the service, which is exactly the configuration evidence assessors like to see alongside application findings.
External perimeter and supporting estate
Admin interfaces, staff portals and anything else the service exposes to the internet belong in scope too. An external infrastructure test maps and probes everything reachable from outside, which frequently surfaces forgotten test environments running older copies of the service.
How an engagement runs against an assessment deadline
Service teams almost always come to us with a fixed date: the beta assessment is booked, or the go-live decision is scheduled. A well-run engagement works backwards from that date:
- Scoping. We walk through the architecture with the technical lead, count the user journeys, API endpoints and cloud accounts involved, and agree what will be tested and where. For government services we normally test a pre-production environment that mirrors live, with production data excluded.
- Testing. UK-based testers work through the agreed scope manually, backed by tooling. Critical findings are flagged the day they are found, not held for the report.
- Reporting. Each finding is described with evidence, realistic impact for the service and specific remediation steps, written so the report can be handed to an assessment panel as-is.
- Retesting. Once fixes land, we retest the affected findings and issue an updated report. That closed-loop evidence, found, fixed, verified, is what satisfies point 9 questioning.
Allow at least four to six weeks between booking and your assessment date so there is time to remediate and retest. Our penetration testing checklist covers the preparation steps that make the testing window productive from day one.
What it costs and how scope drives the price
Penetration testing is priced by effort, and effort is driven by scope: the number of user journeys, API endpoints, cloud accounts and integrations. UK day rates for CREST-accredited testing typically run £1,100 to £1,400. Typical ranges for government digital services look like this:
| Scope | Typical effort | Typical UK cost |
|---|---|---|
| Single API or small standalone service | 2 to 3 days | £2,200 to £4,200 |
| Citizen-facing service with frontend and APIs | 4 to 6 days | £4,400 to £8,400 |
| Service plus cloud environment and integrations | 6 to 9 days | £6,600 to £12,600 |
Larger multi-journey services and shared platforms sit above these ranges. Public sector procurement usually needs a fixed price against a defined scope, which is what a proper scoping call produces. For what moves the numbers, see our guide to penetration testing costs in the UK; for an exact figure, use the quote form.
How EJN Labs approaches Service Standard testing
EJN Labs is a UK firm delivering CREST-accredited penetration testing, and we hold ISO 27001, ISO 9001 and Cyber Essentials Plus ourselves, so we understand what it feels like to sit on the audited side of an assurance process. All testing is carried out by UK-based testers, which matters for services handling citizen data with data residency and personnel expectations attached.
When we scope a government digital service we start from the team’s own architecture diagram rather than a generic questionnaire, enumerating journeys, endpoints and trust boundaries and mapping effort to the components that carry the most risk. Retesting is built into the engagement rather than sold as an extra. If you are comparing suppliers, our guide to the best UK penetration testing provider sets out the questions worth asking any firm, including us.
Frequently Asked Questions
Does the Service Standard explicitly require a penetration test?
No. None of the 14 points names penetration testing. Point 9 requires a secure service that protects users’ privacy, and service assessors expect evidence that security has been independently tested, so in practice an independent penetration test is the standard way teams evidence point 9.
GOV.UK Service Manual guidance discusses vulnerability and penetration testing as part of meeting that expectation, which is how the requirement takes hold despite never being written into the standard itself.
What does a penetration test for a government digital service cost?
A government digital service penetration test typically costs £2,200 to £12,600 at UK day rates of £1,100 to £1,400 for CREST-accredited testing. The smallest scope is a single API or standalone service, and the largest adds the cloud environment and integrations to a citizen-facing service.
A single API or small standalone service is usually 2 to 3 days, £2,200 to £4,200. A citizen-facing service with frontend and APIs runs 4 to 6 days, £4,400 to £8,400. Adding the cloud environment and integrations takes it to 6 to 9 days, £6,600 to £12,600.
When in the service lifecycle should we test?
Test before your public beta assessment, because that is the point at which real users and real data arrive. Book four to six weeks ahead of the assessment so there is time to fix and retest findings, then test again after go-live whenever the service changes significantly and at least annually.
Say so in your assessment as well, because assessors ask how testing will continue once the service is live.
Do suppliers building services for government need their own testing?
Usually yes. The contracting authority owns the assessment outcome, so contracts commonly require the supplier to arrange or support independent security testing of what they build. Commissioning testing yourself, and arriving with a clean retested report, removes a procurement risk for your customer.
It also stops last-minute testing being forced into the delivery schedule.
Is a vulnerability scan enough to pass point 9?
Rarely on its own. Scanning cannot test authorisation logic, business logic flaws or the trust relationships between a service and the systems it integrates with. Panels generally want manual, independent testing evidence for a service handling citizen data, with findings remediated and verified by retest.
Scanning still has a place as continuous hygiene, and assessors like to see it running alongside the manual work.
Get assessment-ready testing evidence for your service
If your service has an assessment on the calendar, the strongest position is a completed test, remediated findings and a retest report before the panel convenes. Request a penetration testing quote and we will return a fixed price against a defined scope, usually within one working day.
Leave a Reply