PSN IT Health Check

Our PSN IT Health Check (ITHC) is a penetration test scoped and reported to satisfy Public Services Network assurance, delivered by a testing team experienced in the PSN Code of Connection (CoCo) submission process.

We work with public sector IT and compliance leads across the UK, including London-based authorities and their delivery partners, to produce evidence that stands up when your connection compliance is reviewed.

If you are working to a submission deadline, we scope, test, report and support retesting so the ITHC clears rather than stalls.

A PSN IT Health Check is an independent penetration test of an organisation's external and internal systems, carried out to identify security vulnerabilities and produce assurance evidence for the PSN Code of Connection. It examines the systems connected to, or relevant to, the PSN environment and reports findings in a form that supports the compliance submission, typically on an annual basis.

The Public Services Network is the government network that lets public sector bodies share services and data securely, and the Code of Connection sets the security conditions for connecting to it. An ITHC is one of the conditions used to demonstrate that the connecting organisation identifies and manages its risks. When the engagement is scoped correctly and delivered by an appropriately accredited team, the resulting report is accepted as PSN compliance evidence.

Is a PSN ITHC Still Required?

The PSN landscape is changing. Government network strategy has moved towards retiring and migrating PSN in favour of internet-first and modern connectivity models, so some organisations are unsure whether they should still be commissioning an ITHC or scoping a different assurance requirement entirely.

The practical answer depends on your current connection obligations. If your organisation still holds or is renewing a PSN connection, the CoCo requirements, including the ITHC, continue to apply for as long as that connection is in scope. If you are mid-migration, the assurance you need may differ from a standard PSN ITHC, and scoping the wrong requirement wastes both budget and lead time.

A useful test is to ask what your connection provider or the body reviewing your compliance is currently asking you to produce, and against which submission date. Before committing, confirm what your specific connection or successor arrangement actually requires.

We run a short scoping conversation to establish whether a PSN ITHC is the correct engagement for your situation or whether your assurance obligation has changed.

What a PSN ITHC Covers: External and Internal Scope

A PSN ITHC is split into external testing and internal testing, mirroring the GOV.UK ITHC scope model. External testing assesses what an attacker can reach from the internet, while internal testing assesses what could be exploited by someone already inside the network, such as a compromised device or an insider. Each gives a different risk picture, and PSN assurance generally expects both to be considered rather than external alone.

Treating these as two separate risk pictures is what stops a submission that looks clean externally from masking exploitable weaknesses inside.

The assets your engagement can include commonly cover:

• Public-facing IP ranges and internet-exposed services
• Web applications and any authenticated portals in scope
• Servers and hosts within the PSN-relevant environment
• Firewalls, routers, switches and other network equipment
• Internal network segments and the systems reachable within them
• Any specific in-scope environments your CoCo submission covers

Scope is defined by your organisation, with our support. GOV.UK places responsibility on the connecting body to determine what is in scope, and our role is to help you draw that boundary accurately so nothing relevant is missed and nothing irrelevant inflates the engagement.

How to Scope Your ITHC

Because the connecting organisation is expected to define its own scope, both the accuracy of your quote and the reliability of your compliance evidence depend on getting this right before enquiry. Preparing the following information means we can quote precisely rather than by assumption:

• The count and detail of external IP addresses and internet-facing hosts
• The count and detail of internal hosts and network devices
• A list of web applications, including whether testing needs authenticated access and how many user roles apply
• The network segments or environments that fall within the PSN connection boundary
• Whether internal testing is required, and how internal access will be provided (on-site or via a testing device)
• Any systems that are sensitive to disruption and need special handling

Common Scoping Mistakes to Avoid

The most common scoping mistakes are under-scoping to save cost, omitting internal assets because external exposure feels more urgent, and giving unclear or estimated IP counts.

A vague count such as roughly a class C range can turn out to be far larger once resolved, which either inflates the engagement mid-flight or leaves assets untested. Each of these can produce a report that does not match what the PSN submission expects, forcing rework close to a deadline.

If you are unsure how to draw the boundary, share what you have and we will help finalise it before testing begins.

The ITHC Delivery Process and Timeline

The engagement follows a clear sequence so you can plan around your deadline and understand where any effort falls on your side:

• Scoping. We confirm assets, IP ranges, applications and internal/external requirements, then agree the testing window and access arrangements.
• Testing. Our team carries out the external and internal testing safely against the agreed scope, coordinating with you on any sensitive systems.
• Reporting. We produce the ITHC report with findings, risk ratings and remediation guidance, structured to support your CoCo submission.
• Debrief. We walk your technical and management stakeholders through the findings and priorities.
• Retest option. Where required, we retest remediated issues to confirm they are resolved.

Testing itself is usually completed within a defined window measured in days rather than weeks, with the exact duration driven by the size of scope. Reporting then adds a short turnaround before you have the finished evidence in hand.

The point most organisations underestimate is lead time. Testing windows have to be booked, and a busy compliance period, such as the run-up to common financial or connection renewal dates, can fill availability quickly.

Live systems are handled with care. Testing is planned around your operational constraints, and any activity with disruption potential is agreed in advance and scheduled sensibly, for example outside core hours where a system is business-critical.

Your ITHC Report and Deliverables

The report is the compliance evidence, so its structure and quality matter as much as the testing behind it. You receive a document written to support a PSN CoCo submission and to be usable by both technical teams and management. It includes:

• An executive summary suitable for non-technical stakeholders
• Detailed findings with supporting evidence for each vulnerability
• Risk ratings that prioritise issues by severity and business impact
• Clear remediation guidance for each finding
• A structure aligned with what a PSN submission expects

Findings are risk-rated rather than dumped as a flat list, which tells you what to fix first and what can wait. Ratings reflect both the severity of the weakness and how exposed or exploitable it is in your specific environment, so a technically serious issue that is well isolated may rank below a moderate one that is directly reachable.

A long, unprioritised list is difficult to act on before a deadline, whereas prioritised findings let you close the highest-risk issues quickly and demonstrate a managed response in your submission.

After Your ITHC: Remediation and Retesting

Finding vulnerabilities does not mean the ITHC has failed. Most reports identify issues, and the assurance process is designed around demonstrating that risks are understood and managed, not that no issues exist. We provide remediation guidance for each finding and remain available to clarify what a fix requires.

If issues are found, this is what typically happens next:

• You review the prioritised findings and remediate the higher-risk issues first
• Where the submission requires confirmation that issues are resolved, we retest the remediated items
• Residual or accepted risks can be documented within your risk management approach for the submission
• Retesting confirms fixes so your evidence reflects the current, corrected state

Whether a retest is needed depends on the severity of what was found and the expectations attached to your connection. Lower-risk findings may be accepted with a documented management position, while higher-risk findings usually need to be fixed and confirmed.

Where RMADS or a documented risk position forms part of your submission, the retest evidence supports it by showing the residual risk after remediation rather than the raw findings.

The key planning point is that remediation and retesting take time, so factor both into your overall deadline rather than assuming the first report is the end of the journey.

What Affects the Scope and Cost of Your ITHC

There is no single fixed price for an ITHC because effort is driven by the size and complexity of what is tested. Understanding the variables lets you anticipate budget and explains why an accurate quote follows a scoping conversation rather than preceding it.

The main cost and scope drivers are:

• Number of external IPs and internet-facing hosts in scope, since each adds testing effort
• Number of internal hosts and network devices to be assessed
• Number of web applications, and whether authenticated testing across multiple roles is required, as authenticated multi-role testing is significantly more involved than an unauthenticated check
• Internal as well as external testing, which adds coverage and often on-site or device-based access
• Network complexity, including segmentation and the number of in-scope environments

As a general rule, a small external-only footprint sits at the lighter end of effort, while a large estate combining external, internal and several authenticated applications sits at the heavier end.

Because these variables move both effort and price, the fastest route to an accurate figure is to prepare your scope information and let us quote against real numbers. For current pricing against your specific scope, request a quote.

Accreditations and Why They Matter for PSN Acceptance

PSN work expects recognised accreditation, and the accreditation held by your testing provider directly affects whether the resulting report is accepted. Our PSN ITHC engagements are delivered under recognised CHECK and CREST accreditation, the recognised standards for this type of government-facing testing.

• CHECK is the NCSC scheme for testing government and public sector systems, and CHECK-status delivery is commonly expected where PSN or public sector assurance is involved.
• CREST demonstrates that testers and the organisation meet an independently assessed standard of competence and process.

In practical terms, accreditation is your answer to the question of whether the report will be accepted. A test delivered by an appropriately accredited team carries recognised weight in the submission process, whereas a generic security assessment from an unaccredited provider risks being rejected as evidence.

The distinction that matters most for PSN is CHECK: it is the NCSC-run scheme specifically aligned with government and public sector testing, so where a submission expects CHECK-status delivery, a CREST credential alone may not satisfy it. Confirming which accreditation your submission requires, and that your provider holds it, before you commit protects you from having to repeat the work.

Why Choose Us for Your PSN ITHC

For a compliance purchase, the right provider is one who understands not just how to test but what the PSN submission actually needs from the report. Our differentiator is familiarity with the CoCo submission process itself, so the deliverable is built to be accepted rather than merely technically thorough.

• PSN CoCo submission familiarity so the report is structured for the evidence you have to provide, not just the vulnerabilities found
• Public sector engagement experience working with IT and compliance leads to hit fixed submission deadlines
• Certified testing team delivering under recognised accreditation for government-facing work
• Process rigour across scoping, safe testing, prioritised reporting and retesting
• UK-based delivery, working with organisations across the country including the London public sector

Because we know how the report is read at the compliance end, we scope and structure it to answer the reviewer's questions the first time, which reduces the back-and-forth that pushes engagements past their deadline. We focus on getting you to an accepted submission with the fewest surprises.

Frequently Asked Questions