Information Service and Service Partners Policy

To provide some elements of its IT infrastructure and corporate and local IT systems cost effectively, the University works with a range of external partners. For example, IT solutions may be hosted by systems operated by the partner, information systems such as Agresso and iTrent are supported under contract with the company which develop and maintains them. Loughborough University has a “Cloud First” strategy when it come to the procurement/re-procurement of Information Systems, meaning that increasingly, such systems will be delivered off campus as Software as a Service (SaaS) or via Platform as a Service (PaaS). It is expected that the number of locally delivered Information Systems will diminish with time as they are replaced by cloud delivered alternatives, however there will continue to be many locally delivered services for some time as the refresh period on such solutions, is by their nature, long, and there are still Information Systems where there is still no viable cloud delivered alternative on the market.

In addition to the above remote monitoring services may be purchased from a partner organisation. As part of the contracts relating to these services, third party organisations are likely to require physical and/or remote access to University information and systems.

To ensure the security and integrity of University information and systems, this policy sets out the conditions for providing access to third party organisations in the contractual context outlined above. It should be read in conjunction with the Management of User Access to Information policy which covers authorization of individual access to information and systems.

This policy applies to any person or group who is commissioning any external IT solutions on behalf of the University, IT Services, Facilities Management Staff, Schools and other Professional Services within the University should also use this policy when procuring services which require providing access to locally managed information or physical and/or remote access to locally managed infrastructure, information or systems, including when such access is provided as part of a wider service provision.

This policy applies to:

• Service Providers – These are external to the University, and may maintain systems on the University’s behalf. Service Providers supporting locally hosted systems and/or components are likely to require remote access to University information systems. Those supporting systems hosted in the cloud will require similar access to these cloud delivered systems, which may include management of a system in the case of SaaS, or remote access to the platform on which a system is delivered in the case of PaaS. An example of the latter might be access to the Loughborough University Microsoft365 tenancy for managed services integrated into this platform. This includes systems that are provided as part of a broader service, such as car parking, travel booking or student recruitment.
• Service Contractors – These are external to the University, and may host systems externally on behalf of the University (e.g. SaaS). Service Contractors are likely to require access to University information to provide a service.

This policy should be referenced:

• When third party organisations are involved in the design, development or operation of information systems for the University. There may be many reasons for this to happen, including installing and configuring commercially developed software, third party maintenance or operation of systems, to full outsourcing of an IT facility (e.g. SaaS). (Service Provider)
• When access to the University’s information systems is granted from remote locations where computer and network facilities may not be under the control of the University. (Service Provider)When users who are not members of the University are given access to information or information systems. (Service Provider)
• When a service is outsourced to a third party which involves University data being hosted at an external location outside the control of the University. (Service Contractor)

Where a delivered service has multiple components delivered via different mechanisms (e.g. locally delivered systems combined with a SaaS back end) the same external partner may be acting both as a Service Provider and a Service Contractor and should be expected to adhere to the University’s Information Security policies relevant to both of these roles.

The policy section has been separated depending on the type of service.

Staff responsible for agreeing service, maintenance and support contracts will ensure that the contracts being signed are in accordance with the University’s Information Governance Policies. This will require review of the relevant policies and procedural documentation of the partner organisation.

Service owners/managers must assess the risk to the information and services to be covered by the contract. If Confidential information is to be shared the service provider will be required to sign a confidentiality agreement. Access to Highly Confidential information will not be given to service providers unless the arrangement is part of the initial contractual arrangements relating to the information. Should any changes be required subsequently, the authorization of all relevant parties must be obtained and documented in advance of any changes to previously agreed arrangements for ensuring the security of the Highly Confidential information.

If a service is being procured which requires that a third party has enhanced access to critical University infrastructure, the contractual terms must be approved and signed by the Chief Operating Officer before implementation of the service.

Physical access to locations which are deemed high value security risk areas (e.g. locations containing core networking equipment) must be arranged in advance and service providers must be accompanied in these locations at all times by a member of University Security, Facilities Management or IT Services personnel.

Where remote access to locally hosted information systems is required, the Remote Access to Server(s) Procedure needs to be followed by the service provider conducting the work. The following information will be required:

• Primary contact in the organisation, including name, job title, telephone number and email address.
• Details of locally hosted systems which remote access is required for, for example hostname/IP address, ports, and protocols.
• Service provider contact confirming they have read and understood Loughborough University IT Acceptable Use Policy (AUP).

Prior to the service provider conducting any work, a detailed change request must be completed. Only if the request is approved under the IT Services Change Management Process will access be granted.

A clear distinction should be made between Service Accounts (accounts used in the hosting of a system, or for specific integration reasons) and Service Provider Accounts (accounts used by individuals in order to provide a service to the University). The two separate uses must never be combined, and specifically, Service Providers should never use Service Accounts, which are not traceable to an individual person in order to access services for maintenance or monitoring purposes. 

Standard user accounts (-remote accounts), which have no administrative privileges, will be provided to service provider staff to allow access to locally hosted systems under the Management of User Access to Information policy. These accounts should be for individual members of staff at the Service Provider, and in order to maintain traceability and audit trail, must never be shared by multiple people. Such accounts must be subject to the University’s Multi-Factor authentication system. It is the responsibility of the Service owner/manager to ensure that such accounts are created only for the period of time for which they are required for the delivery of service, and that they are removed or otherwise disabled promptly when they are no longer required (e.g. when an individual leaves the employ of a Service Provider, or a contract is terminated). 

Only protocols approved by IT Services will be authorised for use and usage will be monitored and logs retained as per the data retention period.

In the specific instance where a system being accessed is hosted within a cloud platform under the administration of the University, the mechanism for granting access may be direct to the existing user credentials of the Service Provider. Where this is the case, equivalent security measures must be in place (e.g. Multi-Factor Authentication). The most common example of this is where services are delivered within the framework of the University’s Microsoft365 tenancy, but access is provided to a service provider though user accounts in their own Microsoft365 tenancy, and use Microsoft Authenticator as their MFA service.

In the event that additional access rights to any component of the University’s systems be needed in order for a Service Provider to provide the service that they are contracted to supply, those access rights should only be provided by the relevant IT Services team where it is safe and appropriate to do so. If there is any doubt whatsoever as to this, the matter should be referred to the IT Services Risk Management meeting, which is a function of the IT Services SLT. This meeting will decide whether those access rights are granted, refused or whether the decision needs to be referred to a senior member of the University (e.g. COO) or to a University committee or subcommittee (e.g. IGSC).

Where staff members of Service Provider organisations are granted access to University Information systems, as a part of the contract negotiations, it should either be established during negotiations that the Service Provider provides its staff with a sufficiently robust programme of information security training, which meets or exceeds the University’s own information training requirements, or the contract should specify that staff of the Service Provider working on our systems should carry out the University’s own information security training to the same schedule as a member of University staff. Where there is any doubt, the latter approach should be the default position. All deviations from the default position should be referred to the ITS Risk Management meetings for approval or appropriate escalation.

Staff responsible for agreeing and approving changes must ensure that all changes made are logged for auditing requirements. The preferred method of logging is via the ITS Change Management process, however there may be cases where the logging of changes is best recorded within another core system, either in addition to the ITS system, or as a replacement (e.g. within an Estates Management System). Services considering alternative methods of logging changes should consult fully with ITS to agree a robust methodology which will be employed by that service.

Staff responsible for agreeing service, maintenance and support contracts will ensure that the contracts being signed are in accordance with the University’s Information Governance Policies. This will require review of the relevant policies and procedural documentation of the partner organisation.

All Information Systems being procured will be subject to the University’s Software Risk Assessment process, irrespective of whether they are delivered via locally hosted software, or via the cloud. This approach encompasses much of the requirements of this policy and provides a robust process for their initial approval.

Service owners/managers must assess the risk to the information and services to be covered by the contract. If Confidential information is to be shared the service provider will be required to sign a confidentiality agreement and a DPIA must be carried out. Access to Highly Confidential information will not be given to service providers unless the arrangement is part of the initial contractual arrangements relating to the information. Should any changes be required subsequently, the authorization of all relevant parties must be obtained and documented in advance of any changes to previously agreed arrangements for ensuring the security of the Highly Confidential information. If the required changes are likely to impact the risk profile of the system being delivered, then it will be necessary to re-apply the Software Risk Assessment process to ensure that the risk levels are still acceptable.

Where systems were procured prior to the introduction of the Software Risk Assessment process, systems should be reviewed by the service owner/manager in conjunction with the IT Security team, and the Cloud Applications Manager, to identify their relevant risk profile (e.g. High, Medium or Low) and to plan a suitable schedule for them to be brought up to the same level of scrutiny as a newly approved system, based upon this risk profile.

Likewise, all approved software systems will also be assigned a risk profile based upon multiple risk factors carried out as a part of the ongoing SaaS Portfolio Review process and brought to the IT Services Risk Management meetings (SLT level function) for relative prioritisation for re-application of the information security parts of the Software Risk Assessment process to ensure continued compliance.

When transferring data to the Service Contractor, unless the information falls into the Public or Not Sensitive information category, the transfer should be conducted via a secure means approved by the IT Security team, (e.g. encrypting the data first and using a secure protocol for actual transmission).

The Software Risk Assessment process ensures that relevant detailed information is obtained from the external contractor and reviewed by IT Services. Amongst other things, this is to ensure that the contractor is capable of handling the University’s information securely.

Examples of the type of information required can be found in Appendix A. These are provided only as indicative information and should not be viewed as a comprehensive list of requirements. Where a software solution is required, the SRA (Software Risk Assessment) process provides the full list of requirements for the different system risk profiles.

• Is the service contractor ISO27001 certified?
  This certification formally specifies a management system that is intended to bring information security under explicit management control.
• Can the service contractor provide a copy of their information security policy? This policy would outline the management controls that are in place to manage information security.
• Can the service contractor provide a copy of their data retention policy? 
  This would indicate the length of time the contractor would hold the University’s information.
• Is the service contractor on the Data Protection register? Every organization that processes personal information must notify the Information Commissioner’s Office. This information is then held in the form of the Data Protection Register.
• If the service contractor is going to be processing electronic payments on behalf of the University, are they PCI DSS compliant?
  PCI DSS is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This standard is intended to help organisations proactively protect user account data.
• Is the service contractor subject to regular security testing (penetration testing) or Information Security audit?
  This is to ensure that service contractors, which are certified against any information security standards, are still compliant. Penetration testing will ensure that the contractors’ infrastructure is secure.
• Can the service contractor ensure that all web applications, which leverage the University information will be conducted via secure web (HTTPS)?
  This is to ensure that if Confidential information is involved in the service provision it is communicated securely.
  Does the contract include appropriate Data Protection assurances in-line with EU Data Protection equivalency requirements? As controls change frequently, please contact the IT Service Desk for advice.
• Where personal data is transferred to and from the service contractor, how is the data secured in transit to ensure it is kept appropriately secure at all times.