1. What good IG looks like and how to evidence it in IRAS guidance

Contents

Who this section is for

Recording research activities for DSPT purposes - how sponsor IG information is used by participating NHS/HSC organisations

How to use this section

IG Annex

Detailed Guidance by IG Topic

• Data minimisation and purpose limitation
• Security
• Lawfulness
• Transparency and rights
• International transfers
• Accountability
• Processors
• Privacy and electronic communications regulations (PECR) Compliance
• Confidentiality and common law duty of confidentiality
• AI/ML Systems

At a glance checklist

This section relates to the IG areas that form part of the study-wide review under section 5.1 of the UK Study-Wide Governance Criteria that is used to assess sponsor-level arrangements evidenced through the IRAS submission in the following key areas:

• governance roles and accountability, including clarity of controller and processor responsibilities and oversight mechanisms
• confidentiality and data protection considerations, including legal bases, the common law duty of confidentiality, and data minimisation
• data flows and access controls, including how data are collected, transferred, stored, linked, and accessed within and across organisations
• security safeguards, including technical and organisational protections applied to systems used in the study
• plans for data sharing or linkage, including onward access, retention, and arrangements at study close-down

Section 5.1 does not assess matters that depend on local operational systems, such as network-specific cyber controls, local staff access provisioning, or organisation-specific training compliance. These remain the responsibility of NHS/HSC organisations to consider locally, in accordance with HRA and other guidance provided elsewhere.

Recording research activities for DSPT purposes - how sponsor IG information is used by participating NHS/HSC organisations

Local responsibilities

NHS organisations are required under the DSPT to maintain records of information assets, data flows, and processing activities, including for research. For studies approved through study-wide review, participating NHS organisations will normally meet these requirements by recording their local research information asset and associated data flows at an appropriate level, and by drawing-on sponsor-provided IG documentation made available to participating organisations (such as the IRAS submission; a Processor Matrix or equivalent summary identifying relevant third party processing where used; how the sponsor assures those processors; and references to system-level DPIA) within an IG Annex, rather than duplicating sponsor assurance.

Sponsor responsibilities/National level responsibilities

Sponsors are responsible for putting appropriate IG and security arrangements in place for the systems and processes used in a study. This includes completing and maintaining any system-level DPIAs or equivalent organisational assessments needed to meet UK GDPR and confidentiality requirements.

As part of the IRAS submission, sponsors should provide clear, documented assurance about these arrangements, including confirmation that relevant DPIAs and contractual safeguards are in place. Those assurances should be made available to participating NHS/HSC organisations (for example through the IRAS application and a supporting IG Annex).

Where sponsor-level IG arrangements are clarified or materially change, sponsors should ensure those changes are captured through the appropriate IRAS submission or amendment, and reflected in updated information shared with participating organisations. Participating organisations should be able to rely on this sponsor-provided information as documented evidence for their own local records (for example, Information Asset and Flow Registers maintained for DSPT purposes).

NHS/HSC organisations should therefore be prepared to rely on assurance that has been reviewed nationally, and to accept that information in the format provided by the sponsor, rather than repeating sponsor DPIAs, creating additional local forms, or requesting repeat security or IG questionnaires. This approach is intended to avoid unnecessary delay and duplication in multi-centre studies and to support the principle of “assure once, rely many times”.

How to use this section

This section aligns and builds on the guidance in Section 5.1 in covering the ten core IG topics that study-wide reviewers expect to see addressed in an IRAS submission. Each topic is presented under three headings:

• ‘what good looks like’ – the standards that study-wide reviewers expect to see met
• ‘evidence in IRAS submission’ – the specific information sponsors should provide to demonstrate compliance
• ‘tip’ – practical suggestions to help sponsors avoid common pitfalls or ambiguities

This structure is designed to balance expectations, evidence, and practical advice, and can be used in different ways:

• sponsors can use it as a checklist to guide study design and ensure IRAS submissions are structured proportionately and consistently
• participating organisations can use it to understand what reassurance they should take from the study-wide review of the IRAS submission

In turn, clearer and more consistent sponsor submissions will help study-wide reviewers, allowing them to focus on assessing the essentials rather than resolving gaps or ambiguities.

This section underpins the principle that assurance should be provided once, at sponsor level, and relied upon by others involved in study set-up and delivery. Study-wide reviewers confirm compliance with core IG standards nationally, while participating NHS/HSC organisations use that evidence to support their own DSPT, or equivalent, requirements and to check only those elements that relate to local implementation or integration. This alignment avoids duplication and ensures that both sponsors and participating NHS/HSC organisations are working to the same national benchmarks.

Instead of local teams requesting additional documentation (for example, local cyber or cloud-risk forms), sponsors should confirm whether equivalent national assurance has already been provided, or otherwise provide additional evidence or information where local checks are necessary. Where assurance already exists, it should be accepted locally without further local re-validation. Where additional local checks are required, these should usually be conducted using information in the format provided by the sponsor, avoiding the use of local forms.

To support this ‘assure once, rely many times’ approach in practice, sponsors are encouraged to bring together key IG assurances for participating organisations in a single, clear document (referred to in this Guide as an ‘IG Annex’).

IG Annex

An IG Annex is not a prescribed template, but a practical way of bringing together sponsor-level IG information already reviewed study-wide (such as confirmation that appropriate processor arrangements and system-level DPIAs are in place), alongside concise participating organisation-relevant summaries (for example, a Processor Matrix or equivalent overview of third-party processing and assurance routes) to support local assurance where needed. Use of an IG Annex or Processor Matrix should be proportionate and appropriate for the study and can be determined by the Sponsor.

Where some IG details are not yet known at the point of IRAS submission (for example, the names of individual third-party providers of software or hardware to be used to support research delivery), the IG Annex can be used to set out the sponsor’s expectations, minimum safeguards, and assurance approach, and then updated once details are confirmed. Where IG-related information is clarified or changed following study-wide review or subsequent amendments, the IG Annex should be updated and re-shared with participating NHS/HSC organisations. Where the changes fall within the scope of study-wide review, they should be reflected through the appropriate IRAS submission or amendment, so participating NHS/HSC organisations can continue to rely on current, nationally reviewed assurances without duplication, and focus only on matters that cannot be addressed through study-wide review and therefore require local consideration and documentation.

Detailed Guidance by IG Topic

Data Minimisation and Purpose Limitation

What good looks like:

• every dataset is explicitly and demonstrably linked to study objectives
• the study design process includes a documented review to ensure each data item collected is necessary for the purpose, with non-essential fields excluded
• retention periods are clearly defined, proportionate, and documented (for example, in years or by regulatory trigger)

Evidence in IRAS submission:

• describe the process undertaken to review the dataset and explain how the final data items were judged necessary and proportionate to the study objectives
• provide a concise justification of the main categories of data (for example, demographic, clinical, laboratory) and show how each supports the study’s purpose or endpoints
• explain the planned retention period and how this was determined to be proportionate, for example by referencing regulatory or scientific requirements that trigger deletion or archival.
• describe how and where evidence of secure destruction or archival will be recorded and made available to participating NHS/HSC organisations or DSPT auditors on request

Tip:

• summarise categories of data with clear reasoning, rather than commenting on each individual case report form (CRF) item
• avoid catch-all phrases such as “just in case” or “for completeness”
• show how retention decisions align with UK GDPR Articles 5(1)(c), 5(1)(e), and 89

Security

What good looks like:

• security measures are built into the study design and day-to-day operations, ensuring that data are protected at every stage of the study lifecycle
• security controls are implemented and maintained (for example, encrypted storage, access restrictions, audit logs)
• where relevant, recognised assurance frameworks (for example, DSPT, ISO 27001 or other national or internationally recognised frameworks such as NIST Cybersecurity Framework and NHS/HSC requirements (such as DTAC for digital tools or DCB 0129/0160 clinical safety standards) are applied in practice - these should normally remove the need for additional local cyber or cloud-risk assessments, unless integration with local IT introduces new risks
• safeguards apply across the data lifecycle, including collection, storage, transfer, and secure deletion
• where processing takes place outside of usual NHS/HSC systems, the sponsor ensures that additional systems are assessed for their security controls, the degree of identifiability of the data processed, and the safeguards applied to achieve equivalent protection to NHS standards

Evidence in IRAS submission:

• describe the technical and organisational measures in place, specifically referencing use of recognised standards, and covering third-party systems
• show how suppliers and third-party systems are managed and describe proportionate safeguards (for example, penetration testing, incident response, audit logging)
• clarify where sponsor-required systems will be used instead of, or alongside, NHS/HSC systems, and demonstrate how security is assured for those additional environments - for example, by referencing DSPT, DTAC, ISO 27001 or any other equivalent national or international certifications such as the NIST Cybersecurity Framework
• where the study involves sponsor-supplied devices, describe how device-management and security controls are applied. Where devices are used by NHS/HSC staff or connect to non-public NHS/HSC systems, these should comply with NHS/HSC Mobile Device Management (MDM) policies. Compatibility with local MDM arrangements and other local operational policies should be discussed early with participating organisations (for example during site feasibility or site selection discussions), rather than being reassessed through study-wide IG review. While MDM policies are implemented locally, they are typically used to meet national baseline security expectations (for example, through DSPT), and sponsors are not expected to replicate or design studies to suit individual local policies
• explain how data transfer mechanisms are consistent with NHS and data-protection standards
• explain how incident-reporting routes are managed between sponsor, supplier, and participating organisation (for example, who notifies whom of any security breaches or service downtime)

Tip:

• give clear examples of safeguards (for example, encryption, access management, audit logs) rather than generic statements like “data will be secure”
• where new or non-standard tools are being introduced (for example, apps, wearables, e-Consent systems), note briefly how they have been reviewed for IG and security risks and reference any relevant assurance frameworks
• focus detail on sponsor-mandated or third-party systems; additional assurance is not needed for standard NHS/HSC environments that already meet baseline security requirements
• where penetration testing or other security testing is cited, specify the frequency (for example, annually or after major system updates) and confirm where results are documented or available for DSPT audit

Lawfulness

What good looks like:

• lawful bases under UK GDPR Article 6 and special category conditions under Article 9 are explicitly determined and justified
• roles of sponsor, participating organisations (including any proposed “hub and spoke arrangements”), participant identification centres (PICs) and third parties are clearly defined in relation to collection, use and transfer of data (controller, processor, sub-processor and any joint controller arrangements)
• interaction with the common law duty of confidentiality is understood, including checking whether additional support (for example, section 251 support, in England and Wales) is required
• any intended secondary use of data from, or contribution of data to, a research database is considered and justified
• involve relevant patients, carers or members of the public to ensure participants would not be surprised about the way their data is used

Evidence in IRAS submission:

• describe both UK GDPR and common law bases and conditions precisely – demonstrate the distinction between personal data under UK GDPR and confidential patient information under common law
• define roles/responsibilities in relation to data clearly
• describe how any confidentiality obligations are met and whether section 251 support, or devolved nation equivalent, is needed
• reference the sponsor’s appropriate system-level DPIA/s already in place. Only where the study departs from those established processes (for example, new technology or unassessed high risks) should a study-specific DPIA be completed by the sponsor, in line with HRA and MHRA guidance developed with the ICO
• describe any known, planned or expected secondary uses of data at the time of submission and any relevant governance arrangements that would apply

Tip:

• avoid vague wording such as “UK GDPR compliant” – study-wide reviewers expect specific articulation of lawful bases and roles
• address both GDPR data protection and common law confidentiality requirements together
• flag early where a CAG (or devolved-nation equivalent) application may be needed

Transparency and rights

What good looks like:

• participants are given clear, layered information that explains how their data will be used, their rights, and withdrawal options
• materials align with HRA transparency templates and are accessible to diverse audiences, including layered use of organisation-level transparency material by both the sponsor and the participating organisation
• data subject rights (access, rectification, erasure, restriction, objection) are considered, noting the limits under the research exemption (DPA 2018 Sch.2 para.27)

Evidence in IRAS submission:

• submit participant materials for review, showing alignment with HRA transparency templates
• where templates have been adapted, provide evidence of testing or input with relevant patients and members of the public (see Public Involvement)
• ensure information on rights is communicated within participant materials and explain where research exemptions apply, with reference to safeguards under Article 89 UK GDPR
• do not submit DPIAs with the application - reviewers will not normally expect to see them. Sponsors should reference an existing system-level DPIA or, if the study introduces new or higher risks not already covered, reference a study-specific DPIA and describe the additional measures (see HRA and MHRA guidance developed with the ICO)

Tip:

• use the GDPR transparency wording for all sponsors wherever possible to ensure consistency and clarity
• be upfront about rights: use of HRA GDPR transparency wording as provided will usually be sufficient. Any study-specific explanation should be included only as supplementary text in the participant information sheet (PIS) where necessary to describe how rights operate in practice in the study (for example, where data are collected via an app or digital tool), and should not re-word or expand on the rights themselves. Where any rights are limited under the research exemption, this should be clearly stated in the PIS with reference to the safeguards in place
• evidence patient and public involvement wherever possible as a matter of good practice (see public involvement guidance for researchers)

International Transfers

What good looks like:

• all data transfers are minimised and secured
• any international transfers of personal data are identified, justified, and supported by appropriate safeguards

Evidence in IRAS submission:

• provide assurance that secure transfer methods are in place
• if personal data will be transferred outside the UK, explain why this is necessary in line with the principle of data minimisation, and set out the safeguards in place (for example, adequacy decision, an International Data Transfer Agreement (IDTA) and Transfer Risk Assessment (TRA)). This is particularly important where the exporting organisation is an NHS/HSC organisation, which is required to justify the transfer clearly and evidence compliance
• sponsors should confirm whether any international transfers are already covered by the relevant system-level DPIA, and only complete a study-specific DPIA if new or unassessed risks are introduced

Tip:

• if no international transfers of personal data are required, state this clearly - it quickly reassures study-wide reviewers and avoids unnecessary queries. Where data is being transferred internationally, but the sponsor considers that this is not personal data to the recipient, clearly set out the safeguards that make this data not identifiable
• confirm whether cloud hosting or other suppliers involve international transfers of personal data, even if not obvious (for example, use of US-based providers)
• make clear who is responsible for carrying out any international transfer (for example, Sponsor, contract research organisation (CRO), or NHS/HSC organisation) to ensure responsibilities and safeguards are consistent with contractual arrangements

Accountability

What good looks like:

• sponsor-level governance structures are established, with sponsor IG oversight, sponsor Data Protection officer (DPO) involvement, monitoring, and audit plans
• the accountability principle under Article 5(2) UK GDPR is explicitly acknowledged - sponsors must be able to demonstrate compliance, not just assert it
• a named role (for example, the Chief Investigator, sponsor IG lead, or equivalent) is identified as responsible for IG in the study
• where IG activities are delegated (for example to a Contract Research Organisation (CRO) or other third party), the delegation is clearly documented, responsibilities are defined, and the sponsor retains overall accountability for compliance

Evidence in IRAS submission:

• describe the sponsor IG governance, monitoring, training, and oversight arrangements in place
• show how compliance will be evidenced in practice (for example, through audit), not just described in principle

Tip:

• avoid generic assurances - describe the governance arrangements that will apply in practice, which may include reference to mechanisms such as governance sign-off processes, audit trails, or training logs
• be clear who is responsible for maintaining oversight and reporting IG issues during the study
• if IG activities are delegated (for example to a CRO), explain how this works in practice for the study – what the CRO does day-to-day, what the sponsor checks or signs off, and how issues are escalated

Processors

What good looks like:

• in line with the expectations set out in Sections 5.1.1.6 and 5.1.8.3 of the UK Study-Wide Governance Criteria, sponsors should describe IG roles, processing activities, and safeguards based on what is known at the point of IRAS submission. Where specific details (such as named software, hardware, or third-party suppliers) are confirmed after submission, these should be documented in information provided to site (in an IG Annex, for example), where they materially affect the IG assurances relied upon by participating NHS/HSC organisations. Where there is such material affect, amendment submission for central review is likely to be needed as well. Updates are not expected for routine or administrative changes, and should be proportionate, focusing only on changes that alter the risk profile or basis on which study-wide assurance was given
• there is clear documentation by the sponsor-as-controller of all processors, in line with Sections 5.1.1.6 and 5.1.8.3 of the UK Study-Wide Governance Criteria, describing processing roles, activities and safeguards based on what is known at the point of the IRAS submission. This may be presented in a Processor Matrix or equivalent overview of third-party processing and assurance routes, as a structured and proportionate overview identifying the software, websites, devices or digital tools used in the study that involve third party processing. Where processors are known, the Matrix should identify each supplier, their role and purpose, the type of data processed and whether any identifiable data will be processed, together with confirmation that appropriate safeguards and contractual arrangements are in place, or reference to a relevant sponsor system-level DPIA or equivalent organisational assurance covering those suppliers and processing activities. Where specific details (such as named suppliers or tools) are not yet confirmed, the Matrix should clearly describe the expected processing activities, types of data involved, and the minimum data protection and security safeguards the sponsor will require once details are finalised, rather than deferring this to a local resolution. This demonstrates due diligence, clear accountability at sponsor level, and supports participating organisations to rely on national assurance without re-checking supplier arrangements locally. Detailed vendor assurance documentation should be managed through the sponsor’s organisational or QMS processes and does not normally need to be reproduced at study level.

Evidence in IRAS submission:

• provide assurance that all third-party tools and suppliers have been, or will be, identified, reviewed, and covered by appropriate contracts
• include a description of all processor arrangements (for example, using a Processor Matrix or equivalent summary) in the application , setting out known processors where available and, where not yet confirmed, the expected processing activities and minimum IG, security and contractual requirements they will be required to meet and confirm this information will be provided to participating organisations

Tip:

• be transparent: name processors directly rather than using generic terms like “external providers”

Privacy and electronic communications regulations (PECR) compliance

What good looks like:

• electronic participant communications are reviewed at an appropriate level (such as by the sponsor or a delegated study team) to ensure they are limited to factual information about study participation (for example, invitations, alerts and reminders) and not promotional or marketing in nature
• Relevant patient, carer and public input determines the information that participants need

Evidence in IRAS submission:

• describe the intended purpose of each type of participant communication and confirm that they have been reviewed against PECR requirements through a proportionate PECR check rather than detailed content approval. This enables the REC to form an opinion on whether Regulation 22 on direct marketing applies

Tip:

• keep a brief, proportionate record of your PECR consideration and ensure that participant communications remain factual, neutral, and free from any promotional content
• state clearly that PECR Regulation 22 has been considered, with a simple confirmation such as: “We have confirmed this is not direct marketing under PECR Regulation 22”
• highlight any patient and public involvement in shaping participant communications, as this can support REC assurance that materials are proportionate, appropriately informative and non-promotional

Confidentiality and common law duty of confidentiality

What does good look like

• it is clear that the common law duty of confidentiality is met
• where common law consent is not available for pre-consent disclosure of identifiable confidential patient information (CPI) beyond those directly involved in providing, supporting or advising on the patient’s care, section 251 support in England and Wales (or devolved-nation equivalent) is in place (see the HRA’s 2025 report, Using health information to let patients know about research options – legal, policy and ethical issues)
• the Caldicott Principles are applied in study design and oversight
• where special category data is processed, an Appropriate Policy Document (APD) is maintained as required under the DPA 2018
• where confidential patient information is being used without consent and section 251 support is in place, it is made clear whether the National Data Opt-Out (NDOO) applies (England only) and, if so, how it will be applied at source in line with HRA guidance

Evidence in IRAS submission:

• describe how confidentiality requirements have been considered and addressed
• provide clear information on any access to CPI by sponsor staff or other research staff from outside of the participating organisation - including whether consent for such access will be obtained in advance and, if so, how, as well as clear direction to participating organisations on how local arrangements for local staff access to CPI maintain the duty of confidentiality - and describe how all such access is being ensured to align with the HRA’s 2025 report, “Using health information to let patients know about research options – legal, policy and ethical issues”
• confirm if statutory or equivalent support (for example, CAG section 251 support in England and Wales) is needed and, if so, provide assurance that will be secured before CPI is disclosed beyond those directly involved in providing, supporting or advising on the patient’s care

explain how the NDOO will be implemented, if applicable

Tip:

• distinguish clearly between UK GDPR lawful bases and common law duty of confidentiality - they are separate requirements

AI/ML Systems

What good looks like:

• Artificial Intelligence and machine learning (AI/ML) systems are considered in terms of transparency (how outputs are generated), fairness (bias mitigation), and oversight (human review)
• data minimisation principles are applied throughout development, training and analysis
• if personal data is used to train the AI/ML system, sponsors should consider why this is necessary. It should not be assumed that safeguards for analysing study data automatically cover training. The use of personal data for training needs its own clear justification
• the need for the sponsor to create study-specific DPIAs for AI/ML is carefully considered. DPIAs for AI/ML are normally addressed at system level; study-specific DPIAs should only be required where new or higher risks cannot be mitigated through those existing assessments and design safeguards

Evidence in IRAS submission:

• explain how the AI/ML system for use in the study meets the principles of transparency, fairness, and oversight (for example, through referring to documentation of model logic, human-in-the-loop processes, bias-testing reports)
• provide assurance that data minimisation has been applied in system design, training, and analysis, with a clear rationale for any data used
• if training datasets include personal data, justify their use explicitly and describe safeguards (for example, pseudonymisation, access controls)
• describe how AI/ML systems will be monitored during the study (for example, referring to audit logs, performance checks, bias monitoring) and how issues will be addressed
• reference the sponsor’s relevant system-level DPIA covering the AI/ML aspects (in line with HRA and MHRA guidance developed with the ICO), showing how risks are mitigated at the design stage. Where a study departs from those established assessments (for example, new technology or previously unassessed risks), provide the rationale for a study-specific DPIA and summarise its findings (for example, using a data flow map, model description, or bias-testing outputs). In line with current expectations, note that this only applies if the study introduces new or changed risks beyond those already addressed at system level. Routine study-level use of an already assessed system would not normally require a new or additional DPIA

Tip:

• reassure study-wide reviewers that AI/ML outputs will remain explainable to participants and subject to human oversight, not left to ‘black box’ automation
• avoid unnecessary complexity or lack of clarity. Models should be explainable (including their limits) to study-wide reviewers, participating organisations, and participants in plain language
• acknowledge potential risks of harm (for example, inaccurate outputs, bias or participant misunderstanding) and explain how these will be mitigated, ideally through safeguards set out in the system-level DPIA