HPA4.0

The supplier will provide the data centre address and the current data centre owner’s / operator’s details, to NHS Digital.

HPA5.0

The supplier will provide the build date of the data centre, its current age and any planned or expected Data Centre services uplift or refit covering but not limited to:

• Power
• Space
• Cooling
• Security
• Construction

HPA16.1

The supplier will ensure that the Data Centre perimeter is protected by an IDS (Intrusion Detection System) compliant to BS EN 50131-1:2006

HPA25.0

The supplier’s Data Centre will have arrangements such that a vehicle is unable to enter the site before all the checking of the vehicle and driver has been completed.  The gate will prevent the tail gating of vehicles.

HPA32.0

The supplier’s Solution will provide at a minimum two separate geographically physical locations to hold the data and capability to run the services.  The distance between the two locations will be such that they cannot both be affected by concurrent loss due to overlapping items on the Location Risk Assessment.

HPA34.0

The supplier will provide permanent access to the Data Centre and equipment, supported by an access request process of 24hrs notice for normal maintenance requests and 1hr for emergency access, with unlimited frequency, for the purpose of maintaining the systems and services

Note: If the hosting provider is a 3^rd party / sub-contractor to the supplier and escorted access is the policy enforced then permanent access to the Data Centre will still be provided.

HPW11.0

Refuelling of the tanks for the generators will be possible with the generators in use.

HI2.0

The supplier to ensure that log files written, even if the device is passive, will write the log with the synchronised time to NHS Network and written in UTC but can be displayed in the supplier’s application in local time.

HI3.0

The supplier will ensure the infrastructure’s time is synchronised with a NHS & National Apps, Cloud / CNSP NTP service, delivered as a minimum, by a stratum 3 service

HI5.0

The supplier to ensure that message time stamping is performed using UTC, for all infrastructure, but can be displayed in the suppliers supported applications in local time.

Note: This requirements scope is the infrastructure; see IG Requirements for further related time stamping and representation. This requirement is to ensure that there is a consistent time stamping policy across all infrastructures and  messaging so that correlation can occur locally, between suppliers and also national applications. The requirement is to ensure that the raw date use is of the format defined.  Local support applications (Applications used to manage the service) can represent the date in their local time if required and in line with the IG Requirements.

HI9.0

The supplier to ensure that all hardware, devices, servers and components have support agreements in place to replace faulty items if they fail.  The replacing of components will not impact live service and meet SLA and planned down time agreements.

HI13.0

The supplier will ensure that Live environments are segregated from the development activity by using processors, virtual servers, domains and partitions that are not in use by live and by storing development utilities away from the live environment.

HS9.0

The supplier will ensure that all operating systems and applications have undergone a hardening process to ensure only the necessary services are in place, within their domain of responsibility in the equipment and services they provide.

Note: Hardening is the process of securing a system reducing its vulnerability, through the use of patching, removal of unnecessary software and services.

Good Practice guidance can be found on the NHS Digital Web Site

The supplier to ensure that due diligence to hardening is performed for their domains of responsibility. 

If the supplier is responsible for the hardware / OS then this hardening will be performed on the hardware and OS. 

If the supplier only provides application software then the necessary hardening will have been performed on that application software. 

If the mobile device hardware (Phone, Medical Device, mobile appliance) is provided by the supplier as part of their Solution then hardening on the components they have provided will have been performed.

Where a BYO device is used the supplier will ensure their application is hardened to protect the data and application.

HS20.0

The supplier will ensure that servers are configured to disable or restrict:

• non-essential or redundant services (eg X Windows, Open  Windows, fingered and web browsers)
• communication services that are inherently susceptible to abuse (e.g. tftp, RPC, rlogin, rsh or rexec)
• communication protocols that are prone to abuse, where not required (e.g. HTTP, HTTPS, SSH, FTP, SMTP, Telnet and UUCP)
• execute permissions on sensitive commands or scripts (e.g. rlogin, rcp, rsh, remsh, tstp and trtp)
• powerful utilities (e.g. Windows ‘Registry Editor’) or ‘control panels’
• run commands or command processors (e.g. Perl or Tcl).

HS24.0

The supplier to ensure that physical servers hosting virtual instances are protected from resource overload (e.g. excessive use of the CPU, memory, hard disk and network).

HNT1.0

The supplier’s data centre to be connected to the Internet and the NHS Network, for clinical services holding PID that are accessed from either an Internet or NHS Network attached end point.

HNT1.1

If the suppliers Data Centre are connected to the NHS Network termination will be from an approved termination point.

HNT1.2

The supplier’s data centre to be connected to the Internet and the NHS Network, for services that communicate with national systems. (PDS, TMS, etc)

HNT1.3

The supplier will respond to the Authorities request for information around security, network settings and ports used, from time to time, in how their services operate across the NHS Network, to support the NHS Network QoS Policy over HSCN.

HNT2.0

Communications in and out of the Data Centre will adhere to the HSCN connection Agreement and NHS Network QoS policy for the classification of data across the network, to enable network traffic prioritisation and ‘class of service’ to reduce network latency.  The supplier will evidence their adherence to the QoS policy, to NHS Digital, for changes to the system in how it communicates across the NHS Network, prior to release. 

Note:

See HSCN Quality of Service overview

See HCSN Technical Guidance

HNT2.1

The supplier’s NHS Network connections to be compliant with the HSCN Connection Agreement and compliant with the DNS and IP addressing policies for the network, where HSCN is used

See NHS digital HCSN Page

HNT3.1

The supplier to provide evidence that the system complies with the requirements and best practice operating principals and guidance when operating over the NHS Network.  Specifically the system to:

• Comply with the NHS Network QoS (Quality of Service) Policy
• Performs adequately within the network latency constraints
• Performs adequately within the typical bandwidth (downstream and upstream) provided to consumers
• Collaborate with NHS Digital and relevant network providers to resolve escalated performance issues which could include installing diagnostic probes into the DC environment.

HNT4.0

The supplier will have completed a NHS Network QoS Policy review, where the suppliers application makes use of or is accessed across the NHS Network, have demonstrated the application and services adhere to the NHS Network policy.  NHS Network QoS rules may need to be amended as a part of this review. Updates to refreshed QoS policies to be applied as required.

See HSCN Quality of Service overview

HNT6.0

The supplier will provide the details of any carriers and the redundancy of all communications utilised in and out of the data centre as part of the Solution. This is to include but not limited to:

• Internet Connections
• NHS Network Connections
• Intra Site communication
• Management / Support Connections

HNT7.0

The Data Centre will have dual Internet and dual NHS Network connections via two exchanges, where available.

HNT21.0

The supplier to ensure that all connections to remote servers and applications are authenticated.

HNT22.0

The supplier to ensure that access to diagnostic ports for network and server components are securely controlled.

HNT23.0

The supplier will segregate the networks that support deployments from other unrelated services to ensure the appropriate level of service. 

HNT30.0

The supplier to ensure network devices are restricted to authorised network staff, using access controls that support individual accountability, and protected from unauthorised access / configuration / updates.

HNT31.0

The supplier to ensure network devices that perform routing (e.g. routers and switches) are configured to prevent unauthorised or incorrect updates by:

• verifying the source of routing updates Verifying the destination of routing updates (e.g. by transmitting updates only to specific routers)
• protecting the exchange of routing information (e.g. by using passwords)
• encrypting the routing information being exchanged.

HNT36.0

The supplier to ensure there are documented standards / procedures at the appropriate level and implemented for controlling wireless access to the network, which cover:

• placement and configuration of wireless access points (hardware devices that provide interfaces between the wireless network and a wired network)
• methods of limiting access to authorised users
• use of encryption (e.g. Wi-Fi Protected Access II (WPA2)) for protecting information in transit
• detection of unauthorised wireless access points and wireless devices.

Note:  See NHS Digital's Good practice Guidance on Wi-Fi 

The supplier to ensure that new services or applications are accessible from the internet.  New services or applications are those which are NOT currently deployed into an operational environment.

The supplier to ensure existing services or applications are transitioned to comply with the Internet First strategy in line with NHS Digital published guidance (see Standards Road map). 

The supplier to ensure HSCN connectivity is procured where there are any systems or services the supplier needs to reach that are only on the HSCN network.

HMI9.0

The supplier will ensure that encrypted administrative access to information systems, network devices and telecommunications equipment (e.g. by using secure management consoles or secure remote login shells such as ssh), is used.

HMI10.0

The supplier will ensure access to critical systems and networks by external individuals for remote maintenance purposes (e.g. remote diagnosis / testing, software maintenance) should be managed by:

• defining and agreeing the objectives and scope of planned work
• authorising sessions individually
• restricting access rights so that they do not exceed those required to meet the objectives and scope of planned work
• logging all activity undertaken
• revoking access rights and changing passwords immediately after agreed maintenance is complete
• performing an internal independent review of remote maintenance activity

HMI12.0

The supplier to ensure a patch management process is established to govern the application of patches to:

• business applications, operating system software and firmware (eg on servers, mobile devices and consumer devices)
• computer equipment
• consumer devices (including tablets and smartphones)
• virtual systems (e.g. virtual servers and virtual desktops)
• network storage systems (including Storage Area Network (SAN) and Network-Attached Storage (NAS))
• network equipment (e.g. routers, switches, wireless access points and firewalls)

HMI13.0

The supplier to ensure that the patch management process will:

• specify methods of validating patches (e.g. ensuring that the patch is from an authorised source)
• assess the business impact of implementing patches (or not implementing a particular patch)
• ensure patches are tested against known criteria
• describe methods of deploying patches in a timely manner (e.g. grouping multiple patches and using software distribution tools)
• provide methods of deploying patches to systems that are not connected to the network (e.g. standalone computers) or devices that connect to the network infrequently (e.g. travelling staff)
• report on the status of patch deployment across the organisation
• include methods of dealing with the failed deployment of a patch (e.g. redeployment of the patch).

HCM1.0

A CMDB (Configuration Management Data Base) will be maintained and contain all CI’s, including but not limited to:

• Software versions
• Licenses with expiry and type e.g. Open Source, Seat, GPL, SSL
• Certificates and their expiry
• Portable devices
• Appliances
• Version of CI
• Location
• Hardware components
• Install applications and versions
• Network connections
• Network devices
• Authentication tokens and devices
• CI (Configuration Item) relationships
• Location Details
• Virtualisation deployment and state
• Service related to (parent and Child)

The level of detail within the CMDB will be of sufficient detail at the CI level to be able to support the change and incident process.

The supplier will ensure that a consistent naming convention (e.g. computer / server addresses, network device names, terminal locations and user identifiers) is used and recorded within the CMDB.

The supplier to ensure that CIs that are used as part of the definition of configuration or an asset are held in the CMDB and DSL.  This could include but is not limited to:

• Network configuration
• Patches
• Scripts

HCM4.0

The supplier to make the results of its data centre audits available to NHS Digital on request along with any work off plans.

HSM1.0

The supplier to implement a toolset to be able to monitor capacity and utilisation of equipment, to support the capacity planning and incident process.   This could include but not limited to:

• Disk IO and Space
• CPU and Memory
• Active user sessions
• Messaging throughput
• Key transaction performance both front door and intra-subsystem.

HSM2.0

The supplier to implement service management tools and procedures within the sub-system including but not limited to:

• systems monitoring (disk, CPU, memory, utilisation)
• audit and logging (time stamped)
• messaging throughput and queue management
• maintenance
• backup and recovery
• deployment of services and patches
• altering at set thresholds below servicing impacting levels

HSM4.0

The supplier to implement a toolset to be able to benchmark the performance of the infrastructure and software assets to be able to understand the deviation from the normal operation.

Note: This measurement will include but not limted to, memory, CPU, bandwidth (Tx/Rx), timing points and throughput.

HSM5.0

For technology uplifts and new services on new hardware provisions the supplier will select hardware that enables equipment power and temperature to be monitored through standard interfaces allowing integration with the supplier’s management system. 

Note: This could be through the use of but not limited to :

• SNMP – Simple Network Management Protocol
• IPMI – Intelligent Platform Management Interface
• DCMI – Data Centre Manageability Interface

HSM6.0

The supplier should allow for the installation of NHS Digital’s National Monitoring System (NMS) probes, if NHS Digital requests and the necessary configuration of the SPAN ports required supporting the NMS service.

Note: A SPAN port is a network switch port setup such that traffic can be sent to the port without any modification to the network traffic.  The SPAN port will allow the connection of a monitoring device in promiscuous mode.

The SPAN port will typically be on the Access layer, after any SSL terminators, so the communications can be seen clear text.

The probe does not collect any clinical information and could be utilised to capture messaging headers or application URLs to understand usage patterns.

Suppliers will be given access to Book of Views - NMS for viewing of their own results if a probe is installed.

HDM1.0

The supplier will provide a ‘lights out’ operational model for the systems with specific processes to allow named engineer access to the environment.

HDM4.0

It will be possible for the supplier to perform software related maintenance and upgrade remotely without requiring physical access to the data hall.

HDP1.0

The supplier to ensure protection of clinical data at the storage level through the use of RAID, block snapshot, replication or mirroring technology within a single data centre / data hall. 

HDP2.0

The supplier to ensure clinical data is protected using methods against up to two disk or media failures, within any one device configuration offering a discrete storage service.

HDP3.0

The supplier will provide Transactional Integrity for clinical data by the use of a 2^nd physical location for storing of data. 

Note: The 2nd site could be a DR Site, Active 2nd site or a site used for storage replication.

HDP5.0

The clinical data transferred to additional locations will be stored in accordance of NHS Digital’s data handling policies.

HDP6.0

The supplier’s approach to Transaction Integrity to securing data to at least two separate physical locations to be communicated to and assured by NHS Digital at the suppliers design stage.

HDP7.0

The supplier to ensure that Data Protection is performed in line with the Disaster Recovery and Business Continuity standard.

Business Continuity and Disaster Recovery

HDP9.0

The supplier will ensure that the clinical data applied to the primary site and sent to the 2nd site is processed in time order of how the data was applied to the primary site. Thus ensuring a consistent data set across the two sites and to maintain the application integrity.

HDP10.0

The supplier to provide a “Data Management Policy”, to NHS Digital, detailing the data retention and level of resilience / protection needed. 

HDP11.0

The supplier will demonstrate, if requested by NHS Digital, that functions/elements provided to meet Data Protection Legislation are operating in accordance with NHS Digital's Requirements and the Design Documents.

HDP12.0

The supplier will ensure that during disposal of equipment all data is removed from devices before they are passed to a 3^rd party or reused in line with the “Disposal and Destruction of Sensitive Data Good Practice Guideline”.

See: Guidelines for Media Sanitization