Skip to main content

Information technology (IT) security policy

Contents

  1. Introduction
  2. Principles
  3. Scope
  4. Governance roles and responsibilities
  5. Controls
  6. Compliance and reporting requirements
  7. Training implications
  8. Monitoring arrangements
  9. Equality impact assessment screening
  10. Links to any other associated documents

1 Introduction

The information technology (IT) security policy outlines the approach, methodology and responsibilities for preserving the confidentiality, integrity and availability of trust information and data. This is the overarching policy for data security and supported by other technical security, operational security and security management policies (see section 10). It supports the 7 Caldicott principles and the UK general data protection regulation (UK GDPR) as detailed in the information governance (IG) handbook. This policy covers:

  • data security principles
  • governance outlining roles and responsibilities
  • supporting specific information security controls
  • compliance requirements

2 Principles (data security)

The core data security principles are to protect the following information or data asset properties:

Core data security principles
Property Explanation
Confidentiality (C) Protect information or data from breaches, unauthorised disclosures, loss of, or unauthorised viewing
Integrity (I) Retain the integrity of the information or data by not allowing it to be modified
Availability (A) Maintain the availability of the information or data by protecting it from disruption and denial of service attacks

In addition to the core principles of C, I and A, data security also relates to the protection of reputation; reputational loss can occur when any of the C, I or A properties are breached. The aggregation effect, by association or volume of data, can also impact upon the confidentiality property.

For the NHS, the core principles are impacted, and the effect aggregated, when any data breach relates to patient medical data.

3 Scope

This policy applies to all information, information systems, information assets, networks, applications, and locations under the control of the trust.

The policy applies to all users of the trust’s IT systems and services; including, but not limited to employees, contractors, partner organisations and volunteers.

It is essential that the trust maintains proper control and protection of its systems and information. To this end, only equipment and storage devices that have been provided, and or approved by the trust may be used to store or process business information, particularly person identifiable data (PID). This ensures that appropriate protective measures, such as anti-virus software, firewalls and software patches can be maintained.

4 Governance roles and responsibilities

4.1 All staff

Data security and the appropriate protection of information assets is the responsibility of all users and individuals are expected at all times to act in a professional and responsible manner whilst conducting the trust’s business. All staff are responsible for data security and remain accountable for their actions in relation to NHS and other UK government information and information systems. Staff must ensure that they understand their role and responsibilities, and that failure to comply with this policy may result in disciplinary action. This will be reinforced by yearly mandatory data security awareness training.

4.2 Senior information risk owner (SIRO)

The senior information risk owner is allocated lead responsibility for the organisation’s information risks and provides the focus for management of information risk at board level. This role is performed by the director of health informatics.

Operational responsibility for information security must be delegated by the SIRO to the trust’s chief information security officer (CISO).

All information security risks must be managed in accordance with the IG policy and management framework (see section 10 for link).

4.3 Chief information security officer (ISO)

The chief information security officer is responsible for the day to day operational effectiveness of the IT security policy and its associated controls and processes.

The CISO must:

  • lead on the provision of expert advice to the organisation on all matters concerning data security, compliance with policies, setting standards and ensuring best practice
  • provide a central point of contact for data security
  • ensure the operational effectiveness of security controls and processes
  • be accountable to the SIRO and other bodies for data security across the trust
  • monitor potential and actual security breaches with appropriate expert security resource

4.4 Caldicott guardian

The Caldicott guardian is the person with overall responsibility for protecting the confidentiality of personal confidential data (PCD) and for ensuring it is shared appropriately and in a secure manner. This role is performed by the executive medical director.

4.5 Data protection officer (DPO)

The data protection officer is a mandated role and is involved in all issues which relate to the protection of personal data.

The data protection officer must:

  • lead on the provision of expert advice to the organisation on all matters concerning the data protection act, compliance, best practice and setting and maintaining standards
  • provide a central point of contact for the act both internally and with external stakeholders (including the office of the information commissioner)
  • communicate and promote awareness of the act across the trust
  • lead on matters concerning individual’s right to access information held by the trust and the transparency agenda

4.6 Information asset owners (IAO’s)

The information asset owners are senior or responsible individuals involved in running the business area and must be responsible for:

  • understanding what information is held
  • knowing what is added and what is removed
  • understanding how information is moved
  • knowing who has access and why

4.7 Senior responsible owners (SRO’s)

All senior managers, heads of department, information risk owners and directors, defined as senior responsible owners (SROs), are individually responsible for ensuring that this policy and data security principles must be implemented, managed and maintained in their business area. This includes:

  • the appointment of information asset owners (IAO) to be responsible for information assets within their operational or business area
  • awareness of data security risks, threats and possible vulnerabilities within the business area and complying with relevant policies and procedures to monitor and manage such risks
  • supporting personal accountability of users within the business area(s) for data security
  • ensuring that all staff under their management have access to the information required to perform their job function within the boundaries of this policy and associated policies, controls and procedures
  • ensuring that all staff are properly briefed on their security responsibilities and how to fulfil them

5 Controls

The IT security policy and information governance policy and framework have been developed as pinnacle documents which have further policies, controls, standards and guides which enforce and support these policies. See section 10 for links to IG policies.

5.1 Acceptable use

All users of trust equipment and infrastructure will ensure that all activity carried out is appropriate for the business purposes of the trust.

5.1.1 Information systems acceptable use

  • Any individual acting on behalf of the organisation must only access information they are authorised to access relevant to their role.
  • Information systems must not be used for malicious purposes.
  • Information systems must not be used for personal use, for example, storage or transmission of large data volumes such as personal digital images, music or video files or large bulk downloads or uploads.
  • Accessing or attempting to access medical or confidential information concerning themselves, family, friends or any other person without a legitimate purpose and prior authorisation from senior management is strictly forbidden and shall be deemed a disciplinary offence.
  • Use of NHS information systems or data contained therein must not be used for personal gain, to obtain personal advantage or for profit. Any instances of this must be referred to the trust’s counter fraud specialist in line with the counter fraud, bribery and corruption policy (See section 10 for link).

5.1.2 IT Equipment acceptable use

  • Users must lock their device and remove their smart card when left unattended, even for a short period.
  • Unapproved or privately owned software must not be installed on NHS IT equipment.
  • Only authorised personnel shall be allowed to reconfigure or change system settings on the IT equipment.
  • All trust devices must:
    • only be used by the NHS or third party employee that has signed and taken personal responsibility for the laptop
    • be configured with a standard suite of software that includes anti-virus, anti-malware, firewall and remote access software, that aligns to current approved standards
    • if configured according to the specifications above, the laptop or mobile device may be connected to wired or wireless access points
  • Users must not use privately owned or third party owned storage devices for transfers of NHS data.
  • Any device lost or stolen must be reported immediately using the IR1 system.
  • Only authorised IT support personnel shall be allowed to open NHS IT equipment and network equipment cabinets.
  • If devices are located in semi-controlled or public areas, devices must be locked to a fixed point using a physical lock.
  • Portable equipment must never be left unattended in public areas.
  • Portable equipment must never be left in parked cars, unless completely invisible from outside the vehicle and protected from extreme temperatures.

5.1.3 Internet acceptable use

  • Access to the internet is primarily for work or for professional development and training.
  • Users must not attempt to download or install any software or executable files from the Internet without first seeking advice from the IT department.
  • Media streaming may be restricted. Where provided, users must consider the legitimate business requirement for its use and the possible impact that it may have on core business and clinical systems.
  • The IT department will manage and monitor all internet access which can be reported on if required.
  • Please refer to the IG handbook for further guidance, see section 10 for link.

5.1.4 E-Mail acceptable use

  • Email services within the NHS are provided for business purposes. Refer to the IG Handbook for guidance, see section 10 for link.
  • Refer to section 5.7.3 regarding encryption.

5.1.5 Social media acceptable use

Please see the trust’s social media policy and IG handbook for guidance. See section 10 for links.

5.2 Access control

5.2.1 General

  • Access must be granted using the principle of ‘least privilege’. This means that every system and every user of the system should operate using the least set of privileges necessary to complete the job.
  • Each user must be identified by a unique user identity so that users can be linked to and made responsible for their actions.
  • The use of group identities must only be permitted where they are suitable for the work carried out (for example, training accounts or service accounts).
  • Records of user access may be used to provide evidence for security incident investigations.
  • Privileged access will be assigned to a different user ID from the one used for standard user access and must be explicitly authorised.
  • A secure method of remote access must be used if accessing systems from outside of the trust’s premises.

5.2.2 Physical access

  • Physical access must only be granted on the authority of the data or system owner or the IT department.
  • Security measures and controls should be in place to protect physical assets.
  • The data or system owner should retain a log of ‘date, time, name, reason’ for access to their data or system.
  • Any unauthorised access must be reported as a Security Incident via the IR1 system.

5.2.3 Network access

  • All staff and contractors must be given network access in accordance with business access control procedures and requirements for access defined by their roles.
  • All staff and contractors who access trust networks remotely must only be authenticated using the approved remote access authentication mechanism.
  • Diagnostic and configuration ports must only be enabled for specified business reasons.
  • Risk assessment must be conducted by the trust to determine the requirements for the segregation of networks.
  • Segregation of networks must be implemented as determined by the results of the risk assessment.
  • Network administrators must group together information services, users and information systems as appropriate to achieve the required segregation on networks.
  • Network routing controls must be implemented to support the access control policy.

5.2.4 Operating system access

5.2.4.1 User responsibilities
  • All users must have a unique identifier (for example, username and password or smart card) that must not be shared with other users.
  • All users must be required to change their passwords at regular intervals.

5.2.5 System configuration

  • Only authorised personnel must have access to system utilities and access should be revoked when there is no longer a business reason for access.
  • Where there is a business requirement for generic accounts (for example, service accounts), these must only be created following consultation with the trust Security team and following a formal risk assessment.
  • All user devices must be configured to lock automatically after a period of inactivity in order to reduce the risk of unauthorised access.

5.2.6 Information system access

5.2.6.1 User responsibilities
  • All users must ensure that they lock their device whenever they leave their desk to reduce the risk of unauthorised access.
  • Devices must be logged off and shut down at the end of the working day.
  • All users must ensure that their desks are kept clear of any information or removable storage media in order to reduce the risk of unauthorised access.
  • All users must keep their passwords confidential and unique user identities or usernames must not be shared.
  • Passwords must be changed whenever there is an indication of possible system compromise. The user must also inform IT as soon as is possible and log the incident on the IR1 system.
  • Users must inform the system owners of any changes that may affect their need for access, or level of access, to a system.
5.2.6.2 Administration
  • Access to information systems must be granted using a formal user registration process.
  • Managers must review user access rights on a regular basis and after any changes to user roles and responsibilities.
  • Each user of a system must have a unique user identity or username, so that the user can be held accountable for any actions carried out by their allocated user identity.
  • A formal record of all users connected to an NHS system must be maintained, including the necessary approvals.
  • Privilege access management must be controlled through a formal process and only the minimum privileges granted to carry out the role or task.
  • A formal record of all privileges allocated must be maintained.
  • When a user account is no longer required, for example, through staff resignation or a change in duties, IT should be informed immediately.
  • System administrators must ensure that temporary accounts are disabled when no longer required.
  • Unused accounts must be disabled within 60 days and deleted 12 months after being disabled.
  • Removal of accounts must also include the removal of any associated access rights.
5.2.6.3 System configuration
  • For audit purposes, systems must be configured to capture the unique user identity being used.
  • Where technically possible, all standard accounts that are delivered with operating systems must be disabled, deleted or have their default passwords changed on system installation.

5.2.7 Application information access

  • All trust staff and contractors must only be granted access to those application functions required to carry out their roles.
  • All trust staff and contractors must only be granted access to information in applications in accordance with business access requirements and policy.
  • All trust staff and contractors must only have access to sensitive systems if there is a business need to do so and they have successfully completed any additional necessary approval processes.
  • Sensitive systems should be isolated in order to meet the requirements of restricted access to authorised personnel.

5.3 Application security

  • The trust must ensure that applications used by the trust are securely configured and managed as outlined in the secure configuration section.
  • IT managers must ensure that all applications are captured within a software configuration record (SCR), as detailed in the hardware and software controls, to capture and maintain an inventory of all authorised applications. The SCR must be used to manage application configuration, patches, or updates undertaken and must cover:
    • software vendor and item identifier
    • version number and licence details of the software
    • serial number
    • date first installed and date of changes with details of person responsible for change or update. Note: For smartphones where the user controls the update, this process will not be possible. The annual review of the applications on the smartphone should record the latest the build
  • Only applications that are supported by an approved vendor must be procured and used.
  • Full support contracts must be arranged with the application vendor.
  • No modifications should be made to the application without confirmation that the vendor can continue to provide support.
  • Updates, patches and configuration changes issued by the vendor must be implemented as soon as practicable.
  • All devices must be configured so that unauthorised applications cannot be downloaded.
  • Access to application configurations must be restricted to authorised personnel only, for example, least privilege.
  • A full review of applications and licences must be completed at least annually, as part of the regular software reviews. Any anomalies must be reported to the trust’s informatics asset manager.

5.4 Anti-virus and malware

5.4.1 General

Trust systems must run effective anti-virus and anti-malware software.

  • The trust anti-virus and anti-malware software must be configured to detect and remove known viruses and malware.
  • All servers, desktops and laptops must be configured to run only one of the approved products at any time.
  • Anti-virus and anti-malware software must be kept up to date.
  • Anti-virus and anti-malware definition files must be kept up to date.
  • Anti-virus and anti-malware software updates must be deployed across the network automatically following their receipt from the vendor.
  • Virus and malware signature updates must be deployed across the network automatically following their receipt from the vendor.
  • Anti-virus and anti-malware software must be configured for real time scanning and regular scheduled scans.
  • Tamper protection must be enabled to prevent end users or malware altering the anti-virus and anti-malware software’s configuration or disabling the protection.
  • All IT equipment and removable media must be scanned for viruses and malware before being introduced to the trust network, system or device.
  • IT systems infected with a virus and malware that the anti-virus or anti malware software has not been able to deal with must be quarantined from the network until virus free.
  • Any instance of virus or malware infection or detection must be documented and raised as a security incident via the IR1 system.
  • Staff should connect their trust laptop to the trust network at least once every 30 days to receive security updates.

5.4.2 Administration

  • Changes that are required to the settings of any of anti-virus or anti-malware products must follow the formal trust IT change control process.
  • The trust must ensure that all anti-virus and anti-malware products are regularly and correctly updated from the vendor service.
  • The trust may periodically test anti-virus and anti-malware defences by deploying a safe and non-malicious test file.
  • A detailed log must be kept of all scans undertaken.
  • To prevent misuse and tampering by unauthorised staff, all administrative settings in the deployed anti-virus and anti-malware products must be secured by means of a password and two factor authentication (2FA).

5.5 Backup

  • All central systems will have appropriate backup regimes formalised, with all systems backed up daily. Daily backups must have a 30 day retention and weekly backups must have a 6 month retention.
  • Disk-to-disk backups will be replicated across two locations for off-site storage reasons.
  • Removable backup media must be encrypted and air gapped to ensure the integrity of the backed up data.
  • The trust must ensure that backup copies of switch configuration and data stored on the network are taken regularly in accordance with this backup control and specific system requirements.
  • The trust must ensure that a log is maintained of switch configuration and data backups detailing the date of backup and whether the backup was successful.
  • Documented procedures for the backup process must be produced and communicated to all relevant staff.
  • Documented procedures for the storage of backup tapes must be produced and communicated to all relevant staff.
  • All backup tapes must be stored securely.
  • Documented procedures for the safe and secure disposal of backup media must be produced and communicated to all relevant staff.
  • The restoration from a backup must be tested regularly and the process documented; the restoration testing should be at least annually.

5.6 Disaster recovery

The Disaster recovery control must be used to enable restoration of critical information, applications, systems and networks following a major failure or disaster.

This control supports and is linked to the trust emergency planning policies.

  • The trust must identify and prioritize critical systems, data stores and software on the basis of business criticality.
  • The trust must have a comprehensive backup process that supports the identified and prioritised systems, data stores and software.
  • The trust must identify single points of failure within the IT networks and IT systems.
  • Disaster recovery plans must be produced for each critical system that meets the business continuity requirements and will enable forensic recovery to take place if required.

5.6.1 Disaster recovery plans

  • The plan must support the requirements of business continuity.
  • The plan must be regularly tested, at least annually, using all methods below:
    • table top exercise
    • walkthrough
    • real time live test
  • The plan should cover:
    • ownership, which post owns and controls the plan.
    • responsibilities, identification of roles and their responsibilities.
    • identification of critical assets with priority order for recovery and business functionality.
    • subject matter experts, identified internal and external expertise.
    • resources, allocation of tasks to resources, internal and external:
      • tasks and recovery programme
      • communications plan
      • post action review, lessons learnt
    • test schedule
    • staff who are required to undertake specific technical and functional roles associated with disaster recovery must be trained accordingly
    • all trust staff, including third parties (where applicable), must be made aware of the requirements of the disaster recovery plan and its procedures
    • the disaster recovery policy and the resulting disaster recovery plan must be reviewed and re-issued annually or upon identification of a change in procedure or lesson learnt

The effectiveness of the policy and plan must be monitored through audits and tests (external and internal) and from lessons learnt during any business continuity activity.

5.7 Encryption

The SIRO or ISO must approve all encryption solutions. Preference must be given to encryption products recommended for use by the government and public sector that are listed on the NCSC website (opens in new window).

5.7.1 Information devices

  • All information devices  must be protected by a full disk encryption solution approved to protect the identified security classification.
  • In the event that a full disk encryption solution has not been, or cannot be, configured on the device then the risks to the information must be assessed and either:
    • an alternative encryption solution must be used for which the risks have been accepted by the senior information risk owner (SIRO)
    • the device remains unencrypted and the risks must be qualified and accepted by the SIRO

5.7.2 Removable media

  • All removable media must be encrypted or individual files or directories copied to the removable media must be encrypted with an appropriate encryption solution approved to protect the security classification of the information on the media.
  • If it is not possible nor practical to encrypt the removable media or individual files or directories, then an assessment of the potential risks to the data must be made. The IT security group (ITSG) must determine what security measures need to be put in place and whether the removable media can be used to store the information.

5.7.3 Email

  • NHSmail users can exchange sensitive information securely with other NHSmail users, without needing to use the encryption feature (for example, @nhs.net to @nhs.net).
  • Users sending sensitive information outside of NHSmail, must use the encryption feature. The only exception is when sending to emails ending in *secure.nhs.uk
  • If there is any doubt, you should use the NHSmail encryption feature. See NHSmail portal for guidance, see section 10 for link.

5.8 Environment and physical security

Any area that contains sensitive data or data processing facilities should be classed as a secure area. Secure areas must be protected against unauthorised access and adverse environmental events. Each secure area must be individually assessed, and the level of protection should be proportionate to the risks.

  • Perimeter entry or exit points to secure areas must be protected and have appropriate entry controls. See trust security policy for further information, see section 10 for link.
  • Visitor movements in and out of secure areas must be logged.
  • Secure areas must not be made readily identifiable.
  • Measures must be considered to protect against external threats such as fire, flood or explosion.
  • Unsupervised working in secure areas must be avoided.
  • Unoccupied secure areas must be locked and periodically checked.
  • When siting IT equipment consideration must be given to both physical access and environmental issues, for example, screens displaying sensitive data should be positioned so that they cannot be viewed by unauthorized people or air conditioning may be required to control temperature.
  • Supporting utilities must be considered (power supplies, generators, emergency lighting, water supply etc.).
  • Measures must be taken to protect cabling, internal and external.
  • Network cables and patch panels must be well labelled and kept tidy.
  • Patch panels not housed within secure areas must be located in a locked room or locked cabinets.
  • IT equipment and supporting equipment must be properly maintained and servicing or repairs must only be carried out by suitably trained and authorised personnel.
  • If IT equipment is to be taken off trust premises for repair, due consideration must be made to any data it contains. All sensitive data must be securely removed.

5.9 Hardware and software

5.9.1 Definitions

Hardware is defined as devices such as servers, workstations, laptops, switches, routers, hard disk drives, solid state drives, graphic cards, sound cards, RAM, motherboards and power supplies.

Software is defined as operating systems, applications and IT management tools (such as auditing tools, anti-virus, intrusion detection systems, security incident event management systems and firewall software).

5.9.2 General

  • The trust must ensure that hardware and software utilised is securely configured as outlined in the secure configuration controls.
  • Only hardware and software that is supported by an approved vendor must be procured and used.
  • Full support contracts must be arranged with the hardware or software vendors for through life support.
  • No modifications should be made to the hardware without confirmation that the vendor can continue to provide support.
  • Updates, patches and configuration changes issued by the vendor must be implemented as soon as practicable.

5.9.3 Hardware security

  • The trust must maintain a hardware configuration record (HCR) to capture and maintain an inventory of all configurable hardware. The HCR must cover the following:
    • type of hardware and vendor
    • unique ID or reference number (a unique identifying label must be placed on the item if no identifier is available)
    • owner of hardware
    • record of updates or changes including date, update or change reference from vendor or trust IT service and person who completed the change)
    • Record of when checked: a full inventory should be completed at least annually
  • Ports and connections for removable media must be deactivated (physically or logically) if they are not required for business processes.
  • Network hardware (for example, servers, blades, RAID sets, switches, routers, etc.) must be secured in lockable racks to which access is controlled and limited to authorised personnel only.

5.9.4 Software security

  • The trust must maintain a software configuration record (SCR) to capture and maintain an inventory of all authorised software. The SCR must assist with the management of software configuration, patches, or updates undertaken and must cover:
    • software vendor and item identifier
    • version number and licence details of the software
    • maintenance or support contract details and schedule
    • patching schedule
    • asset owner
    • software dependencies
    • serial number
    • date first installed and date of changes with details of person responsible for change or update. (Note: Packages such as Anti-Virus which are automatically updated do not need to be recorded
  • All devices must be configured so that unauthorised software cannot be downloaded.
  • Access to operating system, application configurations and IT management tools must be restricted to authorised personnel only, for example, a full review of software and licences must be completed at least annually. Any anomalies must be reported to the trust licence manager

5.10 Legacy IT hardware and software

The trust approach is not to use obsolete and legacy IT hardware or software (primarily operating systems) that are no longer supported, as maintenance, patches and updates will not be available and this makes the hardware and software more vulnerable to attack as time progresses. However, there are instances where the use of legacy or obsolete IT (hardware or software) will be the case (due to financial or business drivers) and this control states how the increased risks must be managed.

5.10.1 Definitions

Legacy IT hardware is defined as hardware for which the vendor no longer provides technical support or ‘spare’ parts, for example, circuit boards, processors, disks. Legacy unsupported hardware is more at risk of ‘falling over’ and not being repairable.

Legacy IT software is defined as operating systems and applications that are no longer supported by the vendor (for example, do not receive patches and updates). Legacy unsupported software has a higher risk of a vulnerability being exploited as the software is no longer patched with security patches or updated.

  • The trust must minimise the use of legacy IT hardware or software.
  • The trust must plan to move to supported IT hardware and software as soon as possible.
  • The trust must plan and aim to allocate funding to ensure IT does not become legacy by monitoring the vendor’s published support dates with a view to migrating to the latest supported hardware or software (operating system or application) before the IT becomes unsupported.

5.10.2 Management of legacy IT

Where legacy IT is in operation the following must be implemented, where possible, to mitigate the risks:

  • Prevent devices (workstations, laptops and tablets) from accessing untrusted content.
  • Prevent access to untrusted services, for example, prevention of access to external email and prevention of browsing the Internet by native web browser (for example, only allow indirect access by a thin client).
  • Where prevention of access to untrusted services is not possible then the risk must be mitigated by:
    • ensuring access to content (for example, active content) is only done by manual action
    • blocking access to rich web content and scripting
    • using a gateway to scan incoming content
  • Minimise access to sensitive data by devices utilising legacy or obsolete IT.
  • Minimise access to the legacy IT by removable media.
  • Removal of unneeded services from obsolete servers.
  • Removal of remote access capability to obsolete servers.
  • Maximise the protective monitoring and audit capability for legacy IT.
  • Use the best possible anti-malware and intrusion detection products.
  • Update trust risk register regarding legacy equipment.

5.11 Logging

This policy sets out the rules for log retention. Average time to detect a cyber attack is over 3months and it is not uncommon for incidents to take longer to detect. Logs can be used to identify malicious activity and can help organisations to investigate cyber incidents.

  • Logs are retained for a minimum of 3 months, and 6 months for critical systems.
  • Logs are to be stored read only and tamper proof.
  • Access to logs is by authorised personnel only.
  • Logs should capture logon success, failure and date or time stamp
  • Logs should capture device name, username and IP address
  • Systems should be time synchronised to an atomic clock to insure accurate time stamp.

5.12 Mobile devices

This aim of this section is to provide guidance to all staff on the appropriate use and management of mobile devices whilst at work and on or off trust premises. It applies to all users of trust mobile devices to access trust IT systems and services; including, but not limited to:

  • employees
  • contractors
  • partner organisations
  • volunteers

This policy also covers the use of trust owned mobile devices by patients or service users. Where this is permitted, there must be local guidelines in place regarding supervision of use.

5.12.1 Definition

For the purpose of this control a mobile device is any piece of equipment that can be removed from trust premises for the purpose of data processing or storage such as laptops, smartphones and USB storage devices.

5.12.2 General

  • All mobile devices provided by the trust will be registered to a named individual who is responsible for ensuring the security and correct usage of that device .
  • Trust staff working remotely must ensure that they work in a secure and authorised manner
  • The trust acceptable use controls must apply to remote workers, whatever the location.

5.12.3 Physical security of information and systems

  • Mobile equipment must be stored securely when not in use in and out of trust premises.
  • NHS, UK government security classified or other sensitive information must be protected to the appropriate level at all times.
  • Mobile systems, devices or information must be transported securely and kept with the individual at all times.
  • Remote locations must be secure to work in, for example, not overlooked by unauthorised persons.
  • If left unattended in semi-controlled areas such as conference centres or customer offices, laptops must be shut down and locked to a fixed point using a physical lock available from IT support.
  • Precautions must be taken to protect assets against opportunistic theft.
  • Mobile systems, devices or information must never be left unattended in public places.
  • Mobile systems, devices or information must never be left in parked cars, unless unavoidable and for the minimum amount of time, completely invisible from outside the vehicle and protected from extreme temperatures.
  • Users must ensure that unauthorised persons (friends, family, associates, etc.) do not gain access to mobile systems, devices or information in their charge.
  • Any loss, theft, misplacement or unauthorised access of systems, devices or information must be reported immediately via the trust IR1 system.

5.12.4 Technical security of information and systems

  • All mobile devices will be connected to a central management system to ensure security and system integrity of that device.
  • Laptops will be secured through the trust encryption, anti-virus, and configuration management systems.
  • All tablet devices will be secured through the trust mobile device management (MDM) solution.
  • All smartphones must be secured through the trust mobile device management (MDM) solution.
  • Mobile devices must have security options enabled, such as pin numbers or a password.
  • Automatic lock outs must be enabled when IT equipment is left unattended.
  • Users must ensure that NHS, UK government security classified or other sensitive information is not stored on mobile systems or devices unless it is protected with trust approved encryption, and it is absolutely necessary to do so.
  • The trust must ensure that unauthorised software is not installed on any mobile system or device in their charge.
  • Users must ensure that all security updates are applied to smartphones
  • Please refer to the trust mobile phone policy for further information. See section 10 for link

5.12.5 Multiple user devices

  • Laptops or tablet devices shared by multiple users still require individual unique login credentials.
  • Any device which cannot be set up with multiple user profiles (for example, smartphones and iPads) must not be used by multiple users as they are configured to access an individual’s trust emails. Sharing such devices may contravene the Data Protection Act and IG security principles.

5.12.6 App stores

  • All access to apple iCloud, google play, windows store, and any other online app stores will be restricted.
  • The trust will make available any approved clinical and non-clinical apps, whether public or purchased, through its own managed app store. The approved apps can be installed to designated devices for the purposes of complementing service delivery.
  • Staff will only be able to download any licensed applications from the trust managed app store to the tablet or smartphone device.

5.12.7 Installation of applications and software

  • The IT department will maintain a central store of approved applications and software. These will be distributed by the IT department using appropriate centralised management tools.
  • All devices will only be permitted to use these approved applications and software.
  • Any application or software packages to be added to the approved list should be submitted through the DPIA process for consideration. Further approval may need to be sought through recognised clinical and technical evaluation groups.
  • Any non-approved application or software package will be blocked or removed until such time as it has been reviewed and accepted to the standard list to ensure licence and security compliance.

5.12.8 Trust owned mobile devices for use by patients or service users

  • Where devices are provided for use by patients or service users, all devices will be appropriately configured to maintain network and data security and confidentiality.

5.12.9 Issuing and distribution of mobile devices

  • Laptops, smartphones, and tablet devices will be configured, issued and supported by the IT department.
  • If a member of staff leaves the department, all assets must be dealt with in accordance with the notice periods policy and any standard operating procedures.
  • Equipment to be reissued to other users will be processed by the IT department in accordance with standard operating procedures.

5.12.10 Lost or stolen devices

  • Lost or stolen devices must be reported immediately to the IT department who will implement security protocols to wipe or disable the device. They should also be reported to line managers and an IR1 report completed.

5.13 Password management

5.13.1 General

  • Passwords must be used to ensure that access to NHS systems, devices and information is controlled and restricted to approved and authorised users only.
  • Passwords must be enforced and used on systems and devices under the control of the trust.

5.13.2 Password creation

  • Unique passwords must be created, and used by individuals for each system to which they require access (these will be created under the direction of the relevant system administrators as systems may have differing requirements).
  • As a best practice guide, passwords should be created in the following format:
    • a minimum of 12 characters long
    • contain three of the following four characteristics:
      • a upper case letter
      • a lower case letter
      • a number
      • a special character such as ! ” £ $ % & * @.
    • consider using a passphrase that may be easy to remember but harder to guess
  • Users must not use “remember me” functions to record usernames and passwords.
  • Users must ensure that if passwords are to be written down they must be stored securely.
  • Users must ensure that passwords are not shared with other users.
  • Users must ensure that passwords are never revealed to any other persons. This includes system administrators, security staff and management.
  • All local server administrator passwords should be changed every 90 days.
  • If there is any indication that a password has been compromised that password must be changed immediately and reported as a security incident via the IR1 system.
  • The local administrator account passwords must differ from domain administration.
  • Separate login and passwords must be required for administrators to undertake normal day to day functions.
  • Passwords must not be incorporated in the hard coding of user accounts in application code.

5.13.3 Systems password management

  • Systems must be configured to ensure that passwords meet the required criteria (length, complexity, etc.) for that particular system.
  • All new or reset passwords must be changed immediately upon first log on.
  • Systems should be configured to force the change of passwords at regular intervals. These intervals should be of sufficient frequency to aid security, but not too frequent that this causes problems for users and administrators.
  • Systems must be configured to ensure that passwords, if stored, are held in a secure format (for example, encrypted).
  • Systems must be configured to ensure that previously used passwords cannot be reused.
  • Where possible, systems must be configured to ensure that new passwords are not just a recycled password with the addition of a number of new characters or the changing of a number of characters.
  • Systems must be configured to ensure that following the incorrect entering of a password a specified number of times, the account is locked and can only be opened or reset through a system administrator process. This specified number needs to be small enough in order to add a level of security to the system, but not too small that it causes a burden for user and administrator alike.
  • Users must ensure that different passwords are allocated and used on different systems (separate passwords for email account and network logons).
  • Users must ensure one password is not simply a derivative of another.

5.14 Patching

Patch management is a security practice designed to proactively prevent the exploitation of IT vulnerabilities that exist within an organisation. Best practice is to deploy security updates and patches in a scheduled and predictable manner. Scheduled security updates and patches would be excluded if it can be proved that the security update will cause an issue with the system or software and on completion of a risk assessment. In this case the security update would be rescheduled for release when an updated version becomes available.

  • The trust must comply with the minimum baseline requirements that are contained in this control. These minimum baseline requirements define the default operating system level, hotfix, and patch level required to ensure the security of the trust’s assets and the data that resides on the system.
  • Any applications (both commercial off the shelf (COTS) and in-house) owned or managed by the trust must be updated with the necessary security patches. This is the default configuration for all applications.
  • The trust must manage the patching needs for:
    • all IT infrastructures on the network and associated components owned or managed by the trust
    • all applications (COTS or in-house) owned or managed by the trust
  • The trust IT security group must be responsible for routinely assessing compliance with the patching policy and will provide guidance on issues of security and patch management.
  • The IT change management board must be responsible for approving the monthly and emergency patch management deployment requests  in line with the trust change approval board (CAB) process.
  • The trust endpoint infrastructure team must, upon request, compile reporting metrics that summarize the outcome of each patching cycle.
  • Trust IT management must use these reports to evaluate the current patching levels of all systems and to assess the current level of risk.
  • These reports must be made available to the trust IT security group and internal audit upon request.
  • IT management, without notice, must conduct random assessments to ensure compliance with the principles of this policy.
  • Any system found in violation of this policy must require immediate corrective action.
  • Exceptions to the trust patching policy must require formal documented approval from the IT security group and have management endorsement.
  • Any servers, workstations or applications that do not comply with this policy must have an approved exception on file.

5.15 Sanitation, reuse, disposal and destruction

This control must be used to ensure appropriate methods are used when reusing or disposing of electronic media to ensure that the data cannot be reconstructed, recovered or retrieved and made available to persons who should not have access to the data.

  • A wide range of electronic storage media may be used to store or process information including, but not limited to:
    • desktop computers
    • laptops, tablet computers and electronic notebooks
    • mobile telephones
    • USB devices
    • multifunction devices (for example, printers)
    • photocopiers
    • DVDs, CDs and other portable devices and removable media
    • cameras
    • servers
    • digital recorders
    • backup media
  • The type of sanitisation, disposal and destruction methods deployed must be based on:
    • the impact to the trust (and the wider NHS) if the confidentiality of the data is breached
    • the type of electronic storage media
    • whether the media is to be re-used and if so, where the electronic media will be re-used
  • The sanitisation and destruction method used must be in accordance with the latest HMG mandatory requirements for secure sanitisation (which can be found via the NCSC website (opens in new window)).
  • Encryption is not a sanitisation method and the trust must ensure that it is not relied on as a means of securing data when disposing of electronic media for re-use. When disposing of encrypted media an appropriate sanitisation method must be deployed.
  • If media is to be reused, the sanitisation method deployed for a given technology will depend on the type of media and the environment or classification that it is to be re-used in. The sanitisation method must irretrievably destroy any data held on the electronic media. If this is not possible then the media must be destroyed.
  • If the electronic media is to be re-used within the same secure environment and there are no “need to know” constraints, then the media may be re-used without any sanitisation. However, the existing data must be deleted before being re-used; otherwise the media must undergo appropriate sanitisation for the type of media as defined in the latest HMG guidance, secure sanitisation.
  • If the electronic media is to be re-used within a less secure environment or for re-use within a non-trust environment, then the media must be appropriately sanitised as defined in the latest HMG guidance, secure sanitisation.
  • All electronic media awaiting disposal must be stored and handled securely in accordance with the requirements for its classification.
  • Disposal of electronic media by third parties must be in accordance with this policy and covered by assured contractual agreements.
  • Faulty or unserviceable electronic media must be appropriately sanitised in accordance with the latest HMG guidance, secure sanitisation before being removed for repair, replacement or disposal.
  • All leased electronic media must be sanitised in accordance with the latest HMG guidance, secure sanitisation before being returned to the vendor.
  • All electronic media that is maintained or disposed of by third parties must be handled appropriately as required for its classification so that there is no risk to the confidentiality of the data stored.
  • Where appropriate, records must be kept documenting the asset number of the electronic media being disposed of and the method of how the media was sanitised.
  • Release or reuse of electronic media without appropriate sanitisation must be considered to be a data security incident and must be reported. See section 7.0

5.16 Secure configuration

The aim of this control is to ensure that hardware and software utilised by the trust is as secure as possible. As a general principle, trust systems must be locked down as much as possible without inhibiting business requirements.

  • Access to trust systems must be on the basis of ‘least privilege’. This applies to administrator and user access to:
    • hardware, servers
    • software, operating systems and applications
    • data
    • network configurations
    • protocols
    • security features, for example, anti-virus, intrusion detection systems, firewalls, switches and routers
  • Trust controlled systems and services must be assessed to determine exactly what business functionality is required; all unnecessary functionality must be removed and default configurations updated.
  • Trust secure configuration approach must aim to:
    • prevent the introduction of unauthorised applications or software or malicious code
    • limit the ability for the unauthorised export of data onto peripheral devices or removable media
    • ensure least privilege of access to services and applications. Improve the efficiency and accuracy of patching and update services
    • improve the efficiency and accuracy of patching and update services
  • Baseline security configurations must be developed to ensure a consistent build status for all client and server systems.
  • Protective monitoring should be in place to detect any attempt to modify the configuration of client and server systems.
  • All client systems must be configured to boot up to a secure state. It should not be possible to modify the boot configuration.
  • Client and server systems must be locked down to remove, prevent or limit access to unnecessary physical and logical communications ports (for example, USB, TCP or IP), removable media (for example, CD or DVD drives), network communications interfaces (for example, Bluetooth and Wireless).
  • Operating systems must be locked down to remove or prevent access to unnecessary applications and services.
  • Where necessary client and server systems must only host the applications required to carry out the business processes.

5.17 Social media

  • Any trust social media accounts must be managed by the information asset owner and necessary security settings must be applied to ensure safe use.
  • Please see the trust’s social media employee usage policy for further information, see section 10 for link.

6 Compliance and reporting requirements

6.1 Compliance

The trust is obliged to abide by all relevant UK and European union legislation. The requirement to comply with this legislation must be devolved to employees and agents of the trust, who may be held personally accountable for any breaches of data security for which they may be held responsible. The trust must comply with all relevant legislation appropriate; this includes but is not limited to:

  • Data Protection Act (2018)
  • Computer Misuse Act (1990)
  • General Data Protection Regulations (GDPR) (2016)
  • Network and Information Systems (NIS) Regulations (2018)
  • Freedom of Information Act (2000)
  • Health and Social Care (Safety and Quality) Act (2015)
  • European Union Waste Electrical and Electronic Equipment (WEEE) Directive and the UK Waste Electrical and Electronic Equipment Regulations 2006, relating to the disposal of electronic equipment.
  • Other regulations as referenced in the information governance policy and management framework.

6.2 Reporting

Please refer to the IG handbook and data security and protection breaches or information governance incident reporting policy and procedure.

7 Training implications

7.1 All Staff

  • How often should this be undertaken: Upon commencement of employment and annually thereafter.
  • Length of training: 1 and a half hours.
  • Delivery method: E-learning or face to face.
  • Training delivered by whom: IG or NHS Digital eLearning package.
  • Where are the records of attendance held: ESR.

As a trust policy, all staff need to be aware of the key points that the policy covers. Staff can be made aware through a variety of means such as:

  • induction
  • team meetings
  • desk alerts
  • supervision
  • all user emails for urgent messages
  • trust daily bulletin
  • intranet
  • continuous professional development sessions

8 Monitoring arrangements

The Information Governance (IG) team and the IT department are responsible for:

  • monitoring of actual or potential data security and confidentiality breaches
  • reporting on the state of data security and confidentiality within the organisation
  • carrying out technical compliance checking to ensure that systems have the appropriate hardware and software controls in place to comply with the trust’s security policies and procedures

8.1 Independent review

The organisation’s policy, its implementation, and systems will be subject to periodic review by auditors, the recommendations from which will normally be implemented unless specific dispensation is given at organisation management level.

These reviews will help identify areas of continuing best practice and possible weakness, as well as potential risks that may have arisen since the last review was completed.

8.2 Incidents

  • How: Review incidents for trends or patterns and impacts on. controls in place
  • Who by: Head of IG.
  • Reported to: Information governance group.
  • Frequency: Quarterly.

8.3 CareCERT security alerts

  • How: Review IT systems and services for vulnerability to identified threats.
  • Who by: IT security group.
  • Reported to: Health informatics group.
  • Frequency: Monthly.

8.4 IT hardware

  • How: Audit of all active IT hardware including but not restricted to:
    • network equipment
    • servers
    • desktops
    • laptops
    • handheld mobile devices
  • Who by: Network specialist server specialist asset and licence manager.
  • Reported to: Health informatics group.
  • Frequency: Annual.

8.5 Software licence compliance

  • How: Audit of all installed software and licences purchased.
  • Who by: Asset and licence manager.
  • Reported to: Health informatics group.
  • Frequency: Annual.

8.6 Temporary IT access for active directory

  • How: Monitor automated processes, for example, inactive account disablement.
  • Who by: IT server team.
  • Reported to: IT security group.
  • Frequency: Monthly.

8.7 Temporary access to information systems

  • How:  Suitable monitoring activity, for example, system audit for account activity.
  • Who by: System administrator.
  • Reported to: System owner.
  • Frequency: At least monthly.

9 Equality impact assessment screening

To access the equality impact assessment for this policy, please email rdash.equalityanddiversity@nhs.net to request the document.

9.1 Privacy, dignity and respect

The NHS constitution states that all patients should feel that their privacy and dignity are respected while they are in hospital. High Quality Care for All (2008), Lord Darzi’s review of the NHS, identifies the need to organise care around the individual, ‘not just clinically but in terms of dignity and respect’.

As a consequence the trust is required to articulate its intent to deliver care with privacy and dignity that treats all service users with respect. Therefore, all procedural documents will be considered, if relevant, to reflect the requirement to treat everyone with privacy, dignity and respect, (when appropriate this should also include how same sex accommodation is provided).

9.1.1 How this will be met

No issues have been identified in relation to this policy.

9.2 Mental Capacity Act 2005

Central to any aspect of care delivered to adults and young people aged 16 years or over will be the consideration of the individuals capacity to participate in the decision making process. Consequently, no intervention should be carried out without either the individual’s informed consent, or the powers included in a legal framework, or by order of the court.

Therefore, the trust is required to make sure that all staff working with individuals who use our service are familiar with the provisions within the Mental Capacity Act (2005). For this reason all procedural documents will be considered, if relevant to reflect the provisions of the Mental Capacity Act (2005) to ensure that the rights of individual are protected and they are supported to make their own decisions where possible and that any decisions made on their behalf when they lack capacity are made in their best interests and least restrictive of their rights and freedoms.

9.2.1 How this will be met

Not applicable.

Document control

  • Version: 10.1
  • Unique reference number: 304.
  • Date approved: 25 January 2024.
  • Approved by: Corporate policy approval group.
  • Name of originator or author: Head of infrastructure.
  • Name of responsible individual: Director of health informatics.
  • Date issued: 25 January 2024.
  • Review date: 30 November 2026.
  • Target audience: Audience: All colleagues, including temporary staff and contractors, working for or on behalf of Rotherham Doncaster and South Humber NHS Foundation Trust (RDaSH).

Page last reviewed: May 17, 2024
Next review due: May 17, 2025

Feedback

Report a problem