Information Governance
- Eleanor Davill (Unlicensed)
- Chloe Gibson
- Michael France
ID | S30 |
|---|---|
Version | 5.0.1 |
Type | Overarching Standard |
Status | Effective |
Effective Date | Jul 1, 2025 |
Contracting Vehicle(s) |
- 1 Introduction
- 2 Baseline Assurance Standard Requirements
- 2.1 Authentication
- 2.2 Role-based Access Control
- 2.3 Legitimate Relationships
- 2.4 Information Sharing across Organisations for Direct Care
- 2.5 Additional Privacy Controls
- 2.6 Provenance
- 2.7 Data Suppression & Removal
- 2.8 Audit
- 2.9 Notifications
- 2.10 Data Subject Access Requests
- 2.11 UK General Data Protection Regulation (UK GDPR)
- 2.12 Information Security
- 3 Further Requirements
- 3.1 Authentication
- 3.2 Role-based Access Control
- 3.3 Legitimate Relationships
- 3.4 Information Sharing across Organisations for Direct Care
- 3.5 Workstation Access Controls
- 3.6 Data Labelling
- 3.7 Provenance
- 3.8 Data Suppression & Removal
- 3.9 Audit
- 3.10 Notifications
- 3.11 Notification mechanism
- 3.12 Mandate recording of Privacy Officer
- 3.13 Information Security
- 4 Onboarding Supporting Information
- 5 Roadmap
Introduction
Supports the controls needed to ensure that Special Category Data is kept confidential, is accurate and is available to authorised users when required.
The Information Governance Standard defines the controls that are needed to ensure that the significant quantities of sensitive Personal Data processed by systems are kept confidential, are available to authorised users when required, and are accurate.
Information Governance is a key aspect of the Authority’s requirements for systems, reflecting for example the public commitments made under the Care Record Guarantee and the NHS Confidentiality Code of Practice.
Systems under the Capabilities and Standards Model process considerable amounts of sensitive, personally identifiable information, and this Standard intends to provide controls over the processing and use of that data.
See also Guide to GDPR - key definitions, for definitions of Personal and Special Category Data.
The Information Governance Standard includes:
Authentication - National Authentication (as per Authentication and authorisation section of Interoperability Standard) and local authentication
Role-based Access Control (RBAC) - For authorising access to system functions and data
Legitimate Relationships - Management of legitimate access to Active and Inactive Patient/Service User records and access to information from other organisations for Active Patients/Service Users
Information Sharing across Organisations for Direct Care - Data Sharing, testing of the application and best practice monitoring
Additional Privacy Controls - For restricting access to Personal and Special Category Data
Workstation Access Controls - Minimising the risk that information may be viewed and accessed on unattended workstations
Data Labelling - Outputs from the system are properly marked to reflect their sensitivity
Provenance - The source of all clinical data is appropriately recorded and accessible
Data Suppression & Removal - The accuracy of the Patient/Service User record is maintained
Audit - All system actions are recorded, and accessible, providing an important control against the misuse of systems
Notifications - Alerting mechanism for the designated Privacy Officer
Information Security - Storage, testing, communications and network access controls
Data Subject Access Requests (DSARs) - Support responding to Data Subject Access Requests, providing data where required
General Data Protection Regulation (GDPR) - Adherence to the regulation and support related processes
Baseline Assurance Standard Requirements
The Baseline Assurance Standard (BAS) provides a quicker risk-based assurance approach for Solutions; balancing safety against efficiency by combining a minimum set of essential Requirements from the DSIC Overarching Standards. Completing the BAS is the first step to achieving full assurance with the Overarching Standards allowing Supplier Solutions to be published on the Buying Catalogue. Upon meeting this Standard, Solutions are required to meet all the remaining Overarching Standards subject to the timelines laid out by the Authority.
All Baseline Assurance Requirements can be found here. Each Solution will be assigned a category of A, B or C that determines the level of assurance applied to that Solution. See the relevant category column to understand the assurance required for each Requirement. For information on Solution Categories see Solution Categories for Assurance in DSIC.
The following table of Requirements are the Requirements in the Baseline Assurance Standard related to Information Governance.
Applicable Contracting Vehicle(s) | ID | Requirement | Level | Category A | Category B | Category C |
|---|---|---|---|---|---|---|
Authentication | ||||||
All | GP-IG-2.1-3B | Authentication - General standards Any access to Personal or Special Category Data within Solutions will be subject to authentication at least to standards described in GP-IG-2.2-1. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-2.1-4 | Authentication - NHS authentication with no additional authentication Solutions shall ensure that, where NHS authentication (as per Authentication and authorisation section of Interoperability Standard) is used, those users are able to carry out all Solution activities (subject to their access rights) without the need for any additional authentication. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-2.1-10 | Authentication - Local Users not using NHS authentication (see GP-IG-2.1-4) can only use local authentication and will not therefore be allowed access to Solution functions for which NHS authentication is required. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-2.1-13 | Enable user role and organisation validation The application shall make it possible – by clearly and continually displaying the user’s name, role and organisation – for users to validate the role and organisation relevant to the access they are being granted so as not to be able to claim ignorance of that role or organisation, or otherwise justify a lack of awareness of the significance of their actions. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-2.1-14 | Audit authentication activity All activities associated with requirements in this section will be recorded in the Solution Audit Trail. Such Audit Trail entries can also include End User device (or Solution) identification information. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-2.2-2 | Local authentication - unique user identity and password Any local authentication will be based on a unique user identity which is then authenticated at least through the use of a password. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-2.2-3 | Local authentication - password strength and management Local authentication will satisfy the password strength and password management guidance set out in Meeting the Digital Service Standard and Password Guidance. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-2.2-4 | Password storage Where passwords are stored in Solution databases, they will be stored salted and hashed, using algorithms and strengths recommended in NIST Cryptography Standards. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-2.2-5 | User access and password Audit Trail Successful login, unsuccessful login attempts, logouts and password changes will be recorded in the Solution Audit Trail. Data to be included in such an Audit Trail entry: Successful login, logout:
Unsuccessful login:
Password changes:
Such Audit Trail entries to also include End User device (or Solution) identification information. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-2.2-6 | New user - password creation New users will be assigned, or will be required to enter, a password matching password-strength requirements in GP-IG-2.2-3. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-2.2-7 | New user - define own password on first use If initial password is assigned, the new user will be required to set a password that meets the password-strength requirements in GP-IG-2.2-3, upon first use of the Solution. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-2.2-8 | Password reset Password reset facilities are provided; the Solution will store additional information associated with each user so as to allow newly-generated passwords to be provided securely to devices previously known to be associated with the user (such as mobile number or NHSmail email address). Any such newly-generated passwords cannot be made visible to Solution-administration staff, and following first use of such passwords, the user will be required to set their own password. | MUST | Self-certification | Self-certification | Self-certification |
Role-based Access Control | ||||||
All | GP-IG-3-2 | Role-based access control The Solution will have Role-based access control to authorise users’ access to the Solution functions and data. For NHS authentication requirements see Authentication and authorisation section of Interoperability Standard. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-3-7 | Updates to Job Role to Baseline Activities The Solution will have a process for incorporating updates to the nationally-defined mapping from Job Role to Baseline Activities as published by the Authority. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-3-8 | Local Role-based access control Where the Solution supports users who do not use NHS authentication, the Solution shall implement local Role-based access controls which support the allocation of access rights. These are in line with the nationally-defined job roles and activities taken from the latest National RBAC Database. Local RBAC mechanisms will need to:
Access controls to include the ability to segregate access to the following functions:
| MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-3-9 | Local authentication - local access rights Where Solutions provide local authentication (see GP-IG-2.2-1) that can be used by users who are enabled to use NHS authentication, any local access rights to automatically reflect the access rights associated with the user as defined on Spine, i.e. without any manual update mechanism being required and no increased access rights can be locally associated with the local based authentication. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-3-12A | Role-profile and Organisation Context matching The Solution will ensure that the Organisation Context of the Solution matches the selected role-profile. Where the Solution supports a single organisation, that organisation to match the organisation from the selected role-profile for any user access to proceed. Where a particular Solution supports multiple organisations, the Solution shall set the Organisational Context to that of the selected role-profile (and thus influencing the control as to what Personal Data the user has access to). | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-3-13 | Provide local Solution functions to RBAC mappings Suppliers will provide details of the mapping of their local Solution functions to activities from the National RBAC Database. This is to support the Registration Authority (RA) process (to ensure that RAs have information to enable them to correctly define positions and allocate users to such positions, or by allocating users individual User role-profiles containing appropriate job roles and any additional activities) and also to support the compliance process. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-3-17 | Activities restricted to logged in user role The Solution can only support the activities associated with the role that the user has logged in under. The Solution will not combine activities from multiple roles for the purposes of controlling a user’s access to the Solution. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-3-19 | Specific professional status The Solution will support the notion of specific professional status for users, to support areas of functionality where there can be, for example, statutory reasons to restrict such functionality to certain professional groups (for example where fit notes can only be issued by GPs). | MUST | Self-certification | Self-certification | Self-certification |
Legitimate Relationships | ||||||
All | GP-IG-4-3 | Access to the records of non-active Patients/Service Users Access to the records of non-active Patients/Service Users can be provided within a grace-period following inactivation (such a period to be configurable per organisation, default 4 weeks):
| MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-4-4 | Reactivate Patient/Service User record - alert The act of making a Patient/Service User record active (from an inactivated or archived state), when carried out without a formal Patient/Service User re-registration, will generate an alert to the user designated as the organisation’s Privacy Officer (see Notifications). | MUST | Self-certification | Self-certification | Self-certification |
Information Sharing across Organisations for Direct Care | ||||||
“safe and appropriate sharing in the interests of the individual’s direct care should be the rule, not the exception”
There are different ways in which information is commonly shared across organisations; for example:
The requirements in this section are intended to recognise that:
| ||||||
All | GP-IG-5-1 | Data sharing - recording Patient/Service User expressed preferences Solutions will provide the capability to record a Patient/Service User’s expressed preferences as to how clinical information about them, can be accessed from other care settings, for their direct care. Where Solutions are directly used in other care settings, it is expected that such preferences can be managed at the level of individual operational units or settings in which Patients/Service Users would reasonably expect their information to be shared without hindrance, in order to support their direct care. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-5-2 | Organisational change - Patient/Service User preferences carried forward Organisational structures change over time, for example as Practices merge or split. In such circumstances, every Patient/Service User’s expressed preferences will be carried forward into the new organisational structure, on the basis that Patients/Service Users have been made aware of the implications of any such proposed change, prior to it taking place, and that Patients/Service Users had the opportunity to amend their expressed preference. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-5-3 | Practice controlled information sharing The Practice is to have control as to whether information sharing (access to information from other care settings) for any Patient is enabled, so as to align with Confidentiality: Good Practice in handling Patient information. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-5-4 | Respect recorded preferences The Solution will respect any such recorded preferences, having effect on the sharing of information that might otherwise be technically possible. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-5-5 | Preferences for sharing data into the Organisation from other care settings If the Solution also supports access to information from other care settings, then it will need to also support the recording (and respect of) expressed preferences whether information about them from specific other organisations can be viewed from within the Organisation. It is not necessary that an explicit consent to such sharing be recorded within the Solution prior to any such sharing taking place, other than the exception condition described in requirement GP-IG-5-6A. | SHOULD | Self-certification | Self-certification | Self-certification |
All | GP-IG-5-6A | PDS - express dissent setting Some Patients/Service Users have an “express dissent” setting (value 2) on the consent-to-share flag held nationally on PDS, to be interpreted that the Patient/Service User has previously expressed concern about potential information sharing for their direct care across different care settings. For such Patients/Service Users, making their Personal Data available to other care settings will need to be on an “opt-in” basis, rather than the default “opt-out”. Therefore, in that situation, Solutions will have to prevent any access to information from other care settings, unless the Patient/Service User has explicitly consented to such sharing in the local Solution through facilities provided in requirement GP-IG-5-5. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-5-6B | Information sharing prompt In circumstances where both (i) the Patient/Service User has an ”express dissent” (value 2) setting nationally, and (ii) the Solution has not recorded any expressed decisions from the Patient/Service User, the Solution will prompt the Clinician as part of an encounter with the Patient/Service User, to provide an opportunity to confirm the Patient/Service User’s intentions through the facilities described in requirement GP-IG-5-5. | MUST | Self-certification | Self-certification | Self-certification |
Additional Privacy Controls | ||||||
All | GP-IG-17-1 | Access to whole Records It will be possible to:
| MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-17-2 | Access to individual parts of records It will not be possible, over and above the use of RBAC in general:
| MUST | Self-certification | Self-certification | Self-certification |
Provenance | ||||||
All | GP-IG-10-1 | Record provenance details for all Personal and Special Category Data The Solution will record the following provenance details of all Personal and Special Category Data recorded within the Solution:
The Solution will also make access to this information available to users. Whilst some details (such as name, role) associated with individual users are likely to change over time, the display of user information will reflect the state of such information as it was at the time of the associated event (such as data entry). | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-10-2 | Record provenance details of information shared across Organisations The Solution will record provenance details of information being sent, together with provenance details of information that might be entered into the Solution, based on incoming information. For example, a document from a separate, sending Organisation can be sent into the receiving Organisation, and some summarisation activity can then take place within the receiving Organisation. The Solution to record:
| MUST | Self-certification | Self-certification | Self-certification |
Data Suppression & Removal | ||||||
All | GP-IG-11-1 | Prevent removal of Personal Data Other than in the specific circumstances described in subsequent requirements in this section, the Solution will NOT allow any user to remove Personal Data, for example from the electronic Patient/Service User record (whether that be a “logical delete/soft delete” causing information to be hidden from view, or a “physical delete/hard delete” causing information to be physically deleted from the clinical data repository). | MUST | Self-certification | Self-certification | N/A |
All | GP-IG-11-3 | Logical deletion The Solution will provide the ability for users to “logically delete” entries in a record, i.e. resulting in the underlying data being marked in such a way that it is no longer visible to any user of the record. The requirements associated with this functionality vary, according to whether the information being deleted has been able to be viewed by other users (or accessible by Solution processes). If such data has not been viewable (for example where a user discovers during the recording of a Consultation that they are entering data in the record of a different Patient/Service User, or where the user recognises they have made an error):
Alternatively, where data is being logically deleted that has previously existed in the record, and has been accessible to other users (for example where a Patient/Service User feels that information in the record is damaging, that an annotation is not sufficient, and requests that information from the record is deleted; note that this is most likely to be true where information has been previously entered into the record in error):
| MUST | Self-certification | Self-certification | N/A |
All | GP-IG-11-4 | Physical deletion The Solution will support the physical deletion of records or parts of records in response to court orders or other legislative circumstances. This functionality will NOT be made available to normal users of the Solution, and local Solution administrators will NOT be able to grant access to such functionality to normal users. Such physical deletions are expected to be rare – the functionality described in requirement GP-IG-11-3 is expected to satisfy the great majority of scenarios. Therefore, physical deletion shall be initiated through a Supplier’s service desk facilities, but shall only be carried out in response to a specifically authenticated and validated request from an organisation’s Caldicott Guardian or Privacy Officer, co-signed by a senior Clinical representative. Such requests shall be audited and retained by the Supplier. In such circumstances it will NOT be possible for any user, or back-office process, to reconstitute the state of the record to that prior to any such physical deletion. This functionality will NOT modify the Solution Audit Trail, other than is necessary to support this requirement. The fact of a physical deletion (without referring to data content) will be recorded in the Solution Audit Trail but such entries will NOT be visible to normal users of the Solution. | MUST | Self-certification | Self-certification | N/A |
There are several related mechanisms defined in requirements, which are compared in the following table:
Name | ID | Level | Typically initiated by | Actioned by | Reversible? | Visible marker of use? | Example/use case |
|---|---|---|---|---|---|---|---|
GP-IG-11-3 | MUST | User (during data entry) User or Patient for previously-committed data | User | Yes, by back-office | Yes, for previously-committed data | i) Clinician discovered error during data entry ii) Patient wishes damaging information to be hidden from all future users; Clinician agrees that this will not impact future case | |
GP-IG-11-4 | MUST | Patient | Back-office | No | No | Patient wishes damaging information to be hidden from all future users; court so orders.
|
Applicable Contracting Vehicle(s) | ID | Requirement | Level | Category A | Category B | Category C |
|---|---|---|---|---|---|---|
Audit | ||||||
All | GP-IG-12-1 | Audit trails Solutions to provide Audit Trails, sufficient to support the following purposes:
Application level Audit Trails to be subject to the same level of controls as the electronic Patient/Service User record. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-12-2B | Include all information about exchanges with external Solutions and organisations in Audit Trails The Solution shall ensure that Audit Trails are kept which record information about all information exchanges with external Solutions and organisations, including but not limited to:
Such Audit Trails shall provide a security record for use in analysing breaches of security and policy that might be used as evidence for use in disputes. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-12-3 | Viewing Patient/Service User record as per previous date A means of viewing or reconstructing any individual Patient/Service User record as it was on any previous date will be supported, taking into account the requirements stated in GP-IG-11-4. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-12-4 | View/filter/sort Audit Trails The Solution shall provide facilities to allow authorised users (e.g. a Caldicott Guardian or Privacy Officer) to view Audit Trails. Such facilities to include the ability to display, filter and sort parts of the Audit Trail based on at least the following parameters (both individually and in combination):
Whilst some details (such as name, role) associated with individual users are likely to change over time, the display of user information to reflect the state of such information as it was at the time of the associated event (such as data entry). | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-12-5 | Audit Trail minimum information The Audit Trail records provided for GP-IG-12-1 and GP-IG-12-2B shall include the following minimum information:
Audit Trail records to include details of the End User device (or Solution) involved in the recorded activity. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-12-7 | Deleting Audit Trails The Solution shall ensure that records in the Audit Trail can only be deleted by a privileged user under specific conditions; such as court orders. Note that such deletions are expected to be very rare, and it is important that access to such functionality will be stringently controlled. It will not be possible for any local user to have such rights as a matter of course, and it will not be possible for any local administrator to be able to grant such rights to any local user. Any attempts to manually update or add to the Audit Trail to be prevented as far as is practicable, to ensure the integrity of the Audit Trail, and protect against attempts to tamper. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-12-8 | Audit Trails enabled at all times All Audit Trails shall be enabled at all times and there shall be no means for users, or any other individuals, to disable any Audit Trail. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-12-9 | Audit Trails included in routine Solution backup All Audit Trails shall be included as part of the routine Solution backup. This shall include:
| MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-12-10 | Audit retention The Audit Trail can be moved to archive storage as required for efficient Solution operation. This shall be retained in accordance with the audit retention policy; as specified in Records Management Code of Practice for Health and Social Care 2021 (or later) to allow access as specified above in requirement GP-IG-12-4. Where audit data has been previously archived, it will be made clear in audit viewing tools or other arrangements that some audit data might not be immediately available, but that it can be retrieved (with an indication of steps to take to make such archived data visible). | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-12-11 | Audit trail copies Copies of the Audit Trail to support the following:
| MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-12-13 | Link archived records to Audit Trail In a Solution where any Patient/Service User records are archived (made inaccessible to normal Solution access) then a link will be maintained between the archived records and the Audit Trail, to ensure that the audit records associated with archived records remain accessible. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-17-3 | Timestamp format The timestamps in Audit Trail entries shall be stored in UTC, to the nearest millisecond. When displaying audit entries to authorised users, they shall be displayed by default in local time (with clear indication how this will differ from UTC). | MUST | Self-certification | Self-certification | Self-certification |
Notifications | ||||||
All | GP-IG-13-1 | Inform user notification will be generated There are a number of requirements elsewhere in this document (which reference this Notifications section) where it is appropriate for specific actions to be permitted, but a notification to a Privacy Officer will be raised to ensure appropriate governance of actions can be maintained. In such circumstances, the Solution shall ensure that the user is made aware that a notification will be raised, and is provided with the ability to enter a reason for their action. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-13-2A | Notification content In such circumstances, a notification containing the following information will be made available to the individual within the organisation designated as Privacy Officer:
| MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-13-3 | Levels of notifications The mechanism shall support at least two levels: notifications (warnings) and full alerts. Notifications are for occasions when there is a legitimate, but unusual, activity taking place (such as the access to a record of a newly-archived Patient/Service User) whereas alerts are for exceptional conditions (such as accessing record of Patient/Service User that has been deducted for some time). | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-13-4 | Privacy Officer requirements The Solution will allow the designated Privacy Officer to:
| MUST | Self-certification | Self-certification | Self-certification |
Data Subject Access Requests | ||||||
All | GP-IG-15.8 | Support Response to Subject Access Requests The Supplier shall ensure that the Solution supports responding to Data Subject Access Requests (e.g. by providing the required data) in accordance with the ICO GDPR guidance regarding a data subject’s right to access. Any historical Personal Data, that can be linked to the current active record (for example as a result of a GP2GP transfer) although not normally available to Solution users, falls within the scope of a Data Subject Access Request. See right to rectification / erasure guidance. | MUST | Self-certification | Self-certification | Self-certification |
UK General Data Protection Regulation (UK GDPR) | ||||||
All | GP-IG-16-1 | UK General Data Protection Regulation (UK GDPR) Suppliers to ensure that Solutions processing (including storage of) Personal or Special Category Data adhere to UK General Data Protection Regulation (UK GDPR). See General Data Protection Regulation guidance and ICO - Guide to the General Data Protection Regulation (UK GDPR) for further guidance. | MUST | Self-certification | Self-certification | Self-certification |
Information Security | ||||||
All | GP-IG-14.2-2 | Protection from Unauthorised Access - Solution's databases and/or files The Solution shall ensure that all Personal and Special Category Data, and audit logs, are protected from unauthorised access and modification when stored within the Solution's databases and/or files. This applies wherever such data is being processed or stored. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-14.2-3 | Protection from Loss or Theft While being processed, stored, and in backup and archive storage, all Personal Data and sensitive Personal Data and audit logs shall be physically protected from loss or theft in line with Records Management Code of Practice for Health and Social Care 2021 (or later). | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-14.2-4 | Personal Data and Sensitive Personal Data - retention policy Personal Data and sensitive Personal Data and audit logs shall be retained in line with Records Management Code of Practice for Health and Social Care 2021 (or later). | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-14.2-5 | Data Storage - Location The location of physical storage of Personal or Sensitive Personal Data shall abide by published Health and Social Care Cloud Security - Good Practice Guide and described in the Records Management Code of Practice for Health and Social Care 2021 (or later) or as subsequently amended. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-14.2-7 | Data - secure deletion When no longer required to support services, all media and any infrastructure components that have stored data shall be subject to secure deletion to standards described in NIST Guidelines for Media Sanitization. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-14.3-1 | Limit Personal Data Transferred to Portable Media The Supplier shall demonstrate that it has limited any Personal Data transferred to portable media to the minimum required. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-18-5 | Encrypt Portable Media Where devices or services offered by the Supplier result in the transfer of any Personal Data on any portable media, such media shall be encrypted. The level of encryption used shall conform to the NIST Cryptography Standards to ensure only approved algorithms are used. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-18-6 | Data Transfer - encryption Where devices or services offered by the Supplier result in the transfer of any Personal Data outside the local physical or virtual network, including transfers across network boundaries within a single local network or exporting data to removable data, encryption shall be used. The level of encryption used shall conform to the NIST Cryptography Standards to ensure only approved algorithms are used. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-14.3-4 | Audit - encryption, decryption, transport, storage and destruction of data The encryption, decryption, transport, storage and destruction of data which is physically transferred shall be auditable with the media logged and tracked to ensure all instances are accounted for. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-14.3-5 | Encryption Accredited to FIPS 140-2 The Supplier shall ensure that the encryption product used is accredited to FIPS 140-2. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-18-7 | Encryption Keys - strength and complexity The Supplier shall ensure that the encryption key for each archive is of an appropriate strength conforming to NIST Cryptography Standards to ensure only approved algorithms are used. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-14.3-7 | Encryption Keys - Provide to Data Controller for Encryption Operations Where encryption keys are generated by the Solution automatically for transfer of data by portable media, the Solution shall provide the encryption key to the Data Controller for each encryption operation. In such circumstances, cryptographic keys will not be generated by the use of an algorithm or other shared secret that solely combines known or accessible environmental or other context-specific information, without the inclusion of unique, context specific secret information as provided by the user or Supplier. Such encryption keys shall be generated using existing libraries. Context specific, secret information to be controlled and managed in line with key management good practice principles (i.e. with audited access controls in place). | MUST | Self-certification | Self-certification | N/A |
All | GP-IG-14.3-8 | Encryption Keys - secure storage The Supplier shall ensure that any encryption keys generated by the Solution are stored securely to enable data recovery in the event of key loss or corruption by the Data Controller. Encryption keys are to be stored separately from the data they protect. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-14.3-9 | Encryption Keys - unique per data archive The Supplier shall ensure that the encryption key for each archive is unique to that data archive. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-14.3-10 | Encryption Keys - separate communication mechanism Where the Supplier Solution provides a mechanism for sending encryption keys to a recipient, either electronic or manually, there are processes in place to ensure that the encryption keys are sent following a separate communication mechanism to the encrypted data or posted separately from the encrypted media. | MUST | Self-certification | Self-certification | N/A |
All | GP-IG-14.3-11 | Transfer of Personal Data - Portable Media Where a service offered by the Supplier requires the transfer of Personal Data by portable media the media shall be encrypted to the level required by the NIST Cryptography Standards and transported in a secure manner. The transfer of Personal Data shall also be conducted using Secure Courier services following NIST Cryptography Standards. | MUST | Self-certification | Self-certification | N/A |
All | GP-IG-14.3-12 | Transfer of Personal Data - Electronic Means Where a service offered by the Supplier requires the transmission of Personal Data by electronic means, the data shall be transmitted in an encrypted form to the level required by the NIST Cryptography Standards. This encrypted data can be transmitted via a secure email service such as NHS Mail or over an approved network such as HSCN. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-14.3-13 | Protect Personal Data - un-trusted networks The Solution shall protect the confidentiality and integrity of Personal Data in transit across un-trusted networks, including (but not limited to):
| MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-14.4-2 | Connections to Remote Servers and Applications - authenticated The Supplier shall ensure that all connections to remote servers and applications are authenticated. This requirement includes connections via the Internet. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-14.4-3 | Access to Diagnostic Ports - securely controlled The Supplier shall ensure that access to diagnostic ports for network and server components is securely controlled. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-14.4-4 | Segregate Networks and Servers The Supplier shall segregate the networks and servers that support services under these contractual arrangements from deployments relating to other, unrelated services. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-16-4 | ISO/IEC 27001 Accreditation Provide either a: Valid ISO 27001 Certificate from a UKAS-registered accreditation organisation, or IAF registered accreditation organisation in exceptional circumstances. or Implementation plan to achieve ISO 27001 Certification from a UKAS-registered accreditation organisation, or IAF registered accreditation organisation in exceptional circumstances. | Must
| Self-certification with Supporting Evidence Supporting evidence to include one of the following:
| Self-certification with Supporting Evidence Supporting evidence to include one of the following:
| Self-certification with Supporting Evidence Supporting evidence to include one of the following:
|
All | GP-IG-18-1 | DSP Toolkit Suppliers to complete the Data Security and Protection Toolkit online self-assessment to provide assurance that they are practising good data security and that Personal Data is handled correctly. | MUST | Self-certification with Supporting Evidence Supporting evidence to include:
| Self-certification with Supporting Evidence Supporting evidence to include:
| Self-certification with Supporting Evidence Supporting evidence to include:
|
| GP-IG-18-8 | National Data Guardian Security Standards The Supplier shall ensure they comply with the National Data Guardian's Data 10 Security Standards. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-18-2 | Antivirus and Malware The Supplier shall ensure that Anti-malware software is deployed on all appropriate endpoints and kept up to date. Where it is deemed inappropriate other protections must be in place to mitigate the risk of malware affecting the operation of the system, such as increased auditing and the use of Intrusion Detection Systems (IDS) and/or Intrusion Prevention Systems (IPS). See Guide to Malware Incident Prevention and Handling for Desktops and Laptops for further guidance. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-18-3 | Application Security The Supplier will ensure that applications are appropriately protected using industry standard techniques, such as controlled access to standard ports and APIs, applying Least Privilege, accepting only encrypted connections, input validation, and fail-safe defaults. The Supplier will be aware of common specific application vulnerabilities and will ensure all appropriate mitigations are incorporated in their architecture. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-18-4 | Patch Management The Supplier shall ensure that vendor patches are applied as soon as reasonably possible. Where a 3rd party (such as a hosting company) is responsible for patching the Supplier shall ensure that they are subscribed to receive all patches in a timely manner. See Guide to Enterprise Patch Management Technologies for further guidance. | MUST | Self-certification | Self-certification | Self-certification |
All | GP-IG-18-9 | Penetration Testing Penetration testing will be completed by a 3rd party CHECK / CREST accredited organisation before go-live and annually thereafter. An action plan must be in place to mitigate any vulnerabilities identified in an appropriate timeframe. | MUST | Full Assessment Supporting evidence to include:
Ongoing Compliance:
| Full Assessment Supporting evidence to include:
Ongoing Compliance:
| Full Assessment Supporting evidence to include:
Ongoing Compliance:
|