Does Trusted Research Expect Penetration Testing? What UKRI Terms Ask of Universities

Does Trusted Research Expect Penetration Testing? What UKRI Terms Ask of Universities

By EJN Labs · 28 Aug 2026 · 8 min read

UKRI funding terms do not impose a blanket penetration testing requirement. Trusted Research guidance from NPSA and the NCSC expects proportionate security for sensitive research, and individual grants or collaboration contracts can require testing evidence directly. Most universities evidence this with a scoped test of 4 to 6 days, typically £4,400 to £8,400, covering the systems that hold the research data.

UKRI and Trusted Research penetration testing: what is actually expected

The honest position on UKRI and Trusted Research penetration testing is that neither is a certification scheme with a testing clause you can point to. UKRI sets funding terms that require grant holders to protect the data, assets and outputs of funded work. Trusted Research is guidance, produced by NPSA and the NCSC, on protecting sensitive research from theft, misuse and hostile state interference. Between them they create a clear expectation of proportionate technical security, and for sensitive projects that expectation frequently lands as a request for testing evidence, from UKRI assurance processes, a collaborating partner, or a contract layered on top of the grant.

Why this matters for universities and research organisations

UK research is a stated target for state-linked threat actors, and the NCSC has repeatedly warned the higher education sector about exactly that risk. One compromised research group can expose pre-publication results, sensitive intellectual property, export-controlled material or participant data.

Research environments are also structurally hard to defend, combining federated identity, long-lived external collaborations, shared high performance computing and a culture of openness that predates most security controls.

A security failure on a sensitive project can put future funding at risk, breach collaboration agreements and trigger export control problems. Increasingly, due diligence questionnaires from partners ask directly whether the systems holding project data have been independently tested. Universities that can answer with a recent report from a CREST-accredited firm close those questions quickly; those that cannot negotiate security schedules from a weak position.

The regulatory and contractual drivers behind the expectation

Three layers create the pressure.

  • UKRI funding terms. Grant conditions require institutions to safeguard the data and assets of funded work. UKRI does not name penetration testing in its standard terms, but specific calls, particularly those touching national security or sensitive technologies, can attach security conditions. Where a grant or contract requires security assurance, meeting it is mandatory.
  • Trusted Research guidance. NPSA and NCSC guidance asks institutions to weigh each project’s sensitivity, vet collaborators, and apply proportionate protective measures to the systems and data involved. It is guidance rather than law, but it is the benchmark UKRI, government departments and industrial partners use to judge whether an institution took reasonable care.
  • Contracts layered on the research. Collaboration agreements, government contracts and commercial research agreements often contain their own security schedules. This is where explicit testing requirements most commonly appear, often as annual independent security testing with defined remediation timescales.

So the accurate answer is: Trusted Research expects proportionate security evidence, and penetration testing is the strongest form of that evidence for technical controls. It becomes strictly mandatory when a grant condition or contract says so, increasingly common for sensitive projects.

What to test in a research environment

Scope should follow the data, not the org chart. We start by asking which projects carry sensitivity, where that data lives, and who can reach it.

Research data platforms and storage

Secure research environments, data safe havens and cloud storage holding project datasets. Misconfigured sharing, weak segregation between projects and stale access are the most common findings. Where the estate runs on AWS, Azure or GCP, a cloud penetration test against the configuration and identity model is usually the highest-value exercise.

External-facing systems and remote access

VPN concentrators, remote desktop gateways and anything reachable from the internet. University perimeters are broad, and forgotten departmental servers are a recurring entry point. An external infrastructure penetration test establishes what an attacker sees before they need credentials.

Identity and federated access

Single sign-on, multi-factor coverage, and the leaver process for researchers, visiting academics and external collaborators. Trusted Research puts heavy emphasis on knowing who has access; testing proves whether the technical controls match the policy.

Research applications and APIs

Custom portals, data collection tools and integrations are often built under deadline pressure and rarely see security review. API penetration testing catches authorisation flaws that expose one project’s data to another project’s users.

How an engagement runs

An engagement runs through five stages: scoping, rules of engagement, testing, reporting and retesting. It starts with a short call to map sensitive projects and systems, and it ends with an updated report, re-verified fixes included, that you can hand to a funder or partner.

Scoping also captures constraints, such as instruments that must not be scanned. Rules of engagement set written authorisation, named contacts and agreed test windows. UK-based testers then work through the agreed scope, from external reconnaissance to authenticated testing of platforms and cloud configuration. The report ranks findings by real-world risk to the research data, pairs each with a concrete fix, and includes an executive summary written for a research office or funder audience.

If you are preparing internally first, our penetration testing checklist covers what to have ready before testers start.

What it costs and how scope drives the price

Penetration testing in the UK is priced by effort. Day rates at CREST-accredited firms run from £1,100 to £1,400, with day counts driven by scope: how many systems, how many user roles, how complex the cloud estate. Typical ranges look like this.

EngagementTypical effortTypical cost
External infrastructure test3 to 5 days£3,300 to £7,000
Research portal or web application4 to 6 days£4,400 to £8,400
Cloud research environment review5 to 8 days£5,500 to £11,200
Combined estate for a sensitive programme8 to 12 days£8,800 to £16,800

These are typical UK ranges rather than quotes; the exact figure depends on your scope. A focused test on one sensitive project’s systems is far cheaper than a whole-institution exercise, and is usually what the evidence question requires. For a full breakdown, see our guide to penetration testing cost in the UK.

How EJN Labs approaches testing for research organisations

EJN Labs is a CREST-accredited UK penetration testing firm, and we hold Cyber Essentials Plus and ISO 27001 ourselves, so we understand the assurance side of the table as well as the testing side. When we scope a research environment, we map the estate around the sensitive data first: which projects are in scope, whether the data sits in an on-premises safe haven or a cloud tenancy, how external collaborators authenticate, and which systems a funder will actually ask about. That mapping usually cuts day counts, because it removes systems carrying no sensitive data from scope.

All testing is delivered by UK-based testers, which matters where export control or nationality requirements restrict who may access project data. Reports are written to be handed on: an executive summary for UKRI or a partner, and technical detail your IT team can act on. Our CREST penetration testing page explains the methodology and the evidential weight accreditation gives the report.

Frequently Asked Questions

Does UKRI require penetration testing for all funded projects?

No. UKRI’s standard funding terms require institutions to protect the data and assets of funded work, but they do not name penetration testing as a universal condition. Specific grants, calls and contracts can attach security conditions that do require testing evidence.

Conditions like that appear particularly on sensitive technologies and national security themes, and where one exists it is mandatory. Elsewhere, testing is how institutions evidence proportionate care.

What does Trusted Research actually ask universities to do?

Trusted Research asks institutions to assess the sensitivity of each project, carry out due diligence on collaborators, control who can access research data, and apply proportionate protective security to the systems involved. It is NPSA and NCSC guidance rather than legislation.

The guidance prescribes no specific technical tests, but independent testing is the clearest way to prove those protective measures actually work.

What does a penetration test for a university research environment cost?

Expect £1,100 to £1,400 per day at a CREST-accredited UK firm. An external infrastructure test typically takes 3 to 5 days, so £3,300 to £7,000. A research portal or web application usually needs 4 to 6 days, £4,400 to £8,400.

A cloud research environment review runs 5 to 8 days, £5,500 to £11,200. Exact pricing depends on scope, so request a quote against your actual estate.

Which systems should a university include in scope?

Include the platforms that store project datasets, the external-facing systems that provide remote access to them, the identity systems that control who gets in, and any custom applications or APIs built for the project. The rule is simple: follow the sensitive data.

Instruments and general teaching systems can usually stay out of scope, unless they share networks or credentials with the research environment.

Who should own the testing evidence, the institution or the research group?

The institution should own testing evidence centrally, usually through the CISO or research office, even when a single project triggered the requirement. Central ownership means one report can answer questions from multiple funders and partners, and remediation is tracked properly.

It also means the next sensitive grant application can cite existing evidence rather than starting from zero. Research groups should feed scope into the engagement, not run procurement alone.

Turn Trusted Research expectations into evidence

If a grant condition, a collaboration partner or your own Trusted Research review is asking for security assurance, a scoped test of the systems holding the sensitive data is the fastest way to produce it. Get a CREST penetration testing quote and have the evidence ready before the next due diligence questionnaire arrives.

Leave a Reply

Your email address will not be published. Required fields are marked *