eISF for NHS Trusts: Electronic Investigator Site File Requirements

An electronic investigator site file (eISF) is the site-held repository of essential records for a clinical trial, kept in a validated computerised system rather than a lever-arch binder. ICH-GCP E6(R3) names the file itself at Appendix C.2.3: the repository held by the investigator or institution “may also be referred to as the investigator site file (ISF)”. For an NHS trust the requirements on that system come from four separate places at once, and only one of them is answered by storage.

Most eISF specifications written inside a trust describe storage: folders, permissions, a search box, somewhere to put a signed consent form. The four authorities that will later examine the system ask for something else. The MHRA asks whether a record is still complete and legible in twenty-five years. The sponsor asks whether access matches the delegation log. NHS information governance asks whether the supplier’s assurance is published and in date. The trust’s own R&D office asks whether every study files the same way. A specification that names only storage answers one of those four examinations.

This guide works through what those four owners require, grouped into the four things a trust has to specify: retention, certified copies, access control and NHS supplier assurance. Each group carries the provision behind it and the evidence it produces, and the guide closes with how to write the whole set into a single specification.

What Does an eISF Have to Satisfy in an NHS Trust?

Four bodies specify the same system, each under a different instrument, each asking for a different kind of proof. The table below sets out who asks, what they ask for, and the artefact that answers them.

The four sets overlap in places and conflict nowhere. They fail together in one specific way: a system chosen against one of them alone satisfies that one and leaves the other three to be answered by hand, later, under time pressure.

The fourth owner in that table, the trust itself, sets a governance duty rather than a system requirement, and it is the subject of a separate guide on governing site files across a trust’s studies. The sections below cover the three external owners and the four system requirements that follow from them.

The Point Where a Storage Specification Runs Out

Consider a trust that moves eleven studies from paper site files into a document platform bought on price and search speed. The migration goes well. Every study has a folder tree, every record is indexed, and the R&D office reports the project closed. Eight months later a sponsor audit arrives and asks five questions the platform was never specified to answer.

• The consent forms were scanned and the paper shredded. The auditor asks for the validation record for the scanning process and the documented check that each output is a true copy. No such record exists, so the certified copy status of every scanned consent form is open.
• A research nurse left in March. Her account is still active because deactivation runs through the trust’s general leaver process rather than the study’s delegation of authority log. The access list and the delegation log disagree.
• Two studies filed the protocol under different folder names. Reconciliation against the sponsor’s Trial Master File becomes a manual comparison rather than a structural check.
• The retention field says five years. Two of the eleven studies were submitted for approval on or after 28 April 2026 and carry a twenty-five year duty. The system holds one setting for all of them.
• The supplier’s DSPT publication lapsed in July. Nobody checked, because the contract recorded the claim at signature and nothing re-checks it annually.

Every one of those five is a specification gap, not a failure of the people using the system.

Requirement One: Records That Outlive the Study Team

Regulation 31A of the Clinical Trials Regulations sets the statutory retention duty, and SI 2025/538 changed it on 28 April 2026. The amended regulation 31A(7) requires the sponsor and the chief investigator to keep the documents in the trial master file, including documents held in electronic form, for at least twenty-five years from the day after the trial concludes, and to keep them readily available to the licensing authority, complete and legible throughout. Regulation 31A(9) requires named individuals to be appointed for archiving, with access restricted to them.

The twenty-five year duty applies to trials whose application was submitted on or after 28 April 2026. MHRA’s transitional arrangements guidance states that trials submitted before that date keep the five year rule for the trial master file. A trust running a mixed portfolio therefore holds two retention populations in one system, and the system has to know which study belongs to which. The applicable period is worth confirming with the sponsor study by study rather than set once for a whole tenancy.

MHRA’s guidance on archiving and retention of clinical trial records, updated on 28 April 2026, puts the site file inside that duty in terms: “Retention of the essential documents within the TMF (Trial Master File) (including the investigator site file) and the medical files of trial participants is a legal requirement as described in Regulation 31A of the amended Clinical Trials Regulations.” The same page states that the sponsor, the investigator and any delegated service providers must ensure those documents are retained for at least 25 years. It adds that the named individual should have oversight of electronic records as well as paper ones, that migration to new formats should be validated and documented, and that documents must not be destroyed before the end of the retention period. Four requirements follow for the system itself.

• The retention clock is set per study rather than per tenancy, which allows one trust to hold five year and twenty-five year populations without a manual register.
• Deletion is blocked until the clock expires, so an ordinary user action cannot destroy a record early.
• Format migration is recorded as an event against the record, which preserves the readability chain across a system upgrade or a supplier change.
• Archive access is restricted to named individuals, which satisfies regulation 31A(9) in the system itself.

The statutory duty in regulation 31A names the sponsor and the chief investigator. A trust taking part as a participating site, holding neither role, reaches the same obligation through its agreement with the sponsor and through the investigator duties in ICH-GCP E6(R3). The practical effect on the system is identical, and the route matters when a trust negotiates who pays for twenty-five years of storage.

ICH-GCP E6(R3) section 2.12.12 puts the same duty on the investigator in different words. The investigator or institution retains the essential records for the required period or until the sponsor says they are no longer needed, whichever is longer, and takes measures to ensure availability, accessibility and readability while preventing unauthorised access and premature destruction. Section 2.12.13 requires the investigator to tell the sponsor who is responsible for maintaining those records during the retention period, including after a site closes.

Also Read: NHS Clinical Research Software and ICH-GCP E6(R3): What the New UK CTR Requires

Requirement Two: Copies That Stand as the Record

The move from a paper site file to an electronic one creates a copy of every existing record. The regulatory question is whether that copy is the record or a convenience. E6(R3) defines a certified copy as a copy of the original record verified, by a dated signature or by generation through a validated process, to hold the same information as the original including relevant metadata. Appendix C.2.9 states that a copy used to permanently replace an original record should meet those requirements.

The MHRA GXP Data Integrity Guidance says the same thing operationally. Section 6.17 permits paper data to be retained by using a validated scanning process where a documented process ensures the outcome is a true copy, and asks organisations to consider the risk associated with destroying original records. Section 6.17.1 adds a rule that catches most trusts mid-migration: references between physical and electronic records must be maintained in a hybrid file so that full verification of events stays possible throughout the retention period.

Three practical rules follow for a trust planning a migration.

• Validate the scanning route before the first box is opened. The validation record is what converts a scan into a certified copy, and it has to exist before the copies are made rather than after.
• Keep the hybrid map for as long as the file is hybrid. A study part-migrated in March and finished in September has records in two places, and the cross-reference is the only thing that lets an inspector reconstruct the sequence.
• Hold originals where the party who generated them holds them. E6(R3) Appendix C.2.7 states that original records should generally be retained by the responsible party who generated them, which keeps wet-ink site originals at the site.

One clause deserves separate attention. E6(R3) Appendix C.2.8 addresses records the investigator reaches through a sponsor-provided portal, such as safety reports, and states that these records need to be retained by the investigator or institution at the end of the trial. A site file that exists only as a view into the sponsor’s system leaves the site with nothing to retain once access ends.

Requirement Three: Access That Matches the Delegation Log

Access control in an eISF carries a regulatory meaning beyond information security. E6(R3) section 4.3.8 requires access controls that limit system access to authorised users and ensure attributability to an individual, permissions revoked when they are no longer needed, a process for periodic review of roles and permissions, and documented records of authorised users including the time each permission was granted. Section 3.16.1 puts a matching duty on the sponsor: access permissions granted to investigator site staff should be in accordance with delegations by the investigator, and visible to the investigator.

That single sentence sets the design of the whole permission model. The delegation log is the authority, and the user list is its consequence.

The inspector row reflects published MHRA expectations. The MHRA Inspectorate has set these out in its guidance on hosting a GCP inspection, stating that direct access will be required to all systems that make up the trial master file, that inspector access should be read-only, and that it should not be otherwise limited, including access to audit trails. E6(R3) supports this from the other side: section 2.12.14 requires the investigator to make all requested trial-related records available for direct access on request from a monitor, auditor, ethics committee or regulatory authority, and the glossary confirms direct access may be performed on site or remotely.

Also Read: CTMS for NHS R&D: Choosing an Inspection-Ready Platform

Requirement Four: NHS Assurance Before the First Record Lands

An eISF holds personal data about trial participants inside an NHS organisation, which brings a separate assurance stack into the specification. Three instruments carry most of it, and each is verifiable against an independent register rather than a vendor statement.

• The Data Security and Protection Toolkit. The DSPT applies to all organisations with access to NHS patient information, and an organisation must currently publish at least one assessment by 30 June each year. NHS trusts, integrated care boards, commissioning support units and DHSC arm’s length bodies moved to an assessment aligned to the NCSC Cyber Assessment Framework in September 2024. IT suppliers complete the toolkit under the National Data Guardian standards route.
• Cyber Essentials. The NCSC describes Cyber Essentials as the minimum standard of cyber security recommended by government, delivered through IASME as its official delivery partner. Cyber Essentials Plus assesses the same five technical controls and adds independent technical testing.
• DTAC. The Digital Technology Assessment Criteria published by NHS England assess clinical safety, data protection, technical security, interoperability and usability. A supplier is asked to evidence its DSPT status, a current Cyber Essentials certificate, a data protection impact assessment and independent penetration testing. The purchasing organisation applies the criteria, so a trust should confirm the current version and its own scoring thresholds before writing them into a specification.

Data protection roles cause more confusion in R&D offices than any other part of this group. The HRA’s study-wide governance criteria on information governance set out the position that applies in most studies. The sponsor is normally the data controller for data processing in a research study and decides how the data is stored and for how long. The participating care organisation is normally the sponsor’s data processor for that study, and holds separate controllership for the processing it does for its own purposes outside the research. The HRA also states that DPIAs for research processing are the sponsor’s responsibility, and that research sites should not need to carry out a study specific DPIA.

That position covers the study. The eISF platform is a separate matter, because it is an information asset the trust is deploying across its portfolio. A system-level data protection impact assessment covering that deployment remains the trust’s own responsibility, and it is the assessment a DTAC review expects to see. The two are different documents and a trust needs both.

The HRA adds one further position that bears directly on a cloud-hosted site file. Personal data in NHS research should ideally be processed only within NHS systems, and a sponsor whose study requires personal data to leave NHS systems should be able to justify that and explain how the data will be kept secure. A site file carries identifiable data in several places, including signed consent forms and the subject enrolment and identification logs. The specification should name which record types may hold participant identifiers and set the hosting, access and encryption conditions that apply to those types, rather than leaving the question to an assumption at go-live.

What Belongs in the Site File, and What Sits Next to It?

UK guidance on site file content is thinner than most teams expect. The NIHR publishes suggested investigator site file contents, a twenty-three section list issued in 2019 and framed as a suggestion rather than a standard, and it does not address electronic storage. The authoritative description of content now sits in E6(R3) Appendix C, which is also where the ISF acquires its formal definition. Structure is a separate question from content, and the DIA TMF Reference Model answers it.

• Content comes from E6(R3) Appendix C and the study protocol, which together define the working set for a given study. A practical version is set out in the ISF essential documents checklist.
• Structure comes from the DIA TMF Reference Model, which lets a monitor reconcile the site file against the sponsor’s file zone by zone instead of comparing folder names. The zones that live at the site are mapped in TMF Reference Model and the investigator site file.
• Pharmacy records belong in a separate electronic pharmacy site file, held under pharmacy control with its own access model and its own accountability chain. The boundary between the two files is covered in why the ePSF and the eISF stay separate.
• Study state lives in a clinical trial management system. Delegation currency, visit windows, milestones and recruitment are conduct records rather than filed documents.
• Consistency across studies is an R&D office duty, because a standard that each study team applies for itself produces eleven standards. That duty is covered in NHS R&D: governing site files across a trust’s studies.

How Should a Trust Write the Specification?

The four requirement groups convert into a specification a procurement team can score. Each line below states a requirement and the evidence a supplier produces against it, which keeps the evaluation on documents.

• Retention is set per study. Ask to see two studies in one tenancy carrying different retention clocks, and the deletion attempt that the system refuses.
• The audit trail cannot be switched off. Ask which roles can alter or disable it, and read the answer against E6(R3) section 4.2.2, which requires audit trails, reports and logs to stay enabled.
• Certified copy status is recorded on the record. Ask how the system marks a scanned original, who verified it, and on what date.
• Permissions derive from the delegation log. Ask to see a delegation end date closing a user’s access, rather than an administrator doing it by hand.
• A read-only inspector role exists. Ask to see it, including its view of the audit trail, and confirm it can be granted without a licence purchase.
• Validation evidence is available to the trust. E6(R3) section 4.3.4 requires a risk-based approach to validation and expects the responsible party to ensure systems are validated as fit for purpose, including those developed by other parties.
• Assurance is checkable against a register. Verify DSPT status on the toolkit database and the Cyber Essentials certificate on the IASME database, with the expiry date recorded in the contract.
• Exit produces a readable file. Ask what the trust receives at the end of the contract, in what format, and how its readability is preserved for the remainder of the retention period. A move between site file systems is planned in two workstreams, covered in Florence eISF alternatives.

Also Read: Clinical Trial Management Software for NHS Trusts: 2026 Buyer’s Guide

What Are the Risks of Specifying Storage Alone?

A document platform bought against a storage specification creates four exposures that surface at different points in the study lifecycle.

• Retention exposure. A single tenancy-wide retention setting leaves the trust holding twenty-five year studies under a five year rule, and the gap appears only when a record is needed and gone.
• Copy exposure. Scanned originals with no validation record and no certification marker leave the certified copy status of the whole migrated set open to challenge.
• Access exposure. A user list maintained separately from the delegation log produces periods where a person held system access without a current delegation, which is visible in the audit trail and difficult to explain afterwards.
• Assurance exposure. A supplier whose DSPT publication or Cyber Essentials certificate lapses mid-contract puts the trust’s own information governance position at risk, with no automatic warning.

The system does not fail on the day it is chosen. It fails on the day someone asks it a question it was never specified to answer.

How Does AQ eISF Meet an NHS Trust’s Requirements?

The AQ eISF holds the investigator site file inside the same governed record as the rest of the study. That design lets a trust answer the four requirement groups from one system instead of assembling four separate processes around a document store.

• Permissions derive from Digital DoA delegation entries and their effective dates, which keeps the access list and the delegation log in agreement without an administrator reconciling them.
• Retention is configured per study, which allows a trust to run pre-2026 and post-2026 populations in one tenancy under their correct statutory clocks.
• Every action writes an attributable, time-stamped audit entry that cannot be disabled in normal use, which gives an inspector the read-only view of the record and its history in one place.
• The site file is structured on the DIA TMF Reference Model, which lets a monitor reconcile it against the sponsor’s eTMF zone by zone.
• Deviations raised against a site file record route into CAPA and the QMS, which keeps the finding, the root cause and the corrective action attached to the study they came from.
• AQ holds Cyber Essentials certification, completes the Data Security and Protection Toolkit, and is available through G-Cloud, which gives an NHS R&D office the assurance artefacts its procurement route asks for.

Book a live demo to see how the AQ eISF handles per-study retention, delegation-driven access and inspector read-only review inside a single study record.