1. Purpose
This policy sets out the University’s approach to managing its information security objectives (see below). It addresses the governance and operation of IT security and sits above the Staff and Student Information Security policies, which address user behaviour.
1.1. Audience and scope
The audience for this policy is managers, technical staff, information asset owners, system owners, and others responsible for the management, operation, delivery, or oversight of University information assets, systems, services, and infrastructure.
This policy applies to all University organisational units, including Technology Information Services, professional services, faculties, schools, research groups, and other teams that own, manage, operate, support, or procure information assets, systems, services, or facilities. Such organisational units are responsible for implementing and maintaining controls necessary to comply with this policy and associated standards for assets under their control.
2. Information security roles and responsibilities
Role: Senior Information Risk Owner (SIRO)
Role/title: University Secretary and Registrar
Responsibility: Providing accountability and assurance to UEG that information governance policies, including data protection and information security policies are complied with.
Role: Information Asset Owners
Role/title: Executive Deans Directors, Deputy Vice-Chancellors, members of the Senior Leadership forum
Responsibility: Has accountability and authority to manage the risk; approving the risk treatment plan and residual risk for the risks that they own.
Role: Risk Assessors
Role/title: Privacy Coordinators
Responsibility: Compliance with Data Protection policy, including assessment of information security risk within their organisational area.
Role: Risk Assessors
Role/title: TIS Enterprise Security
Responsibility: Assessing cyber security risk across the University and providing advice on appropriate mitigating measures.
Role: Security Incident Management
Role/title: IT Director
Responsibility: Co-ordinating the University’s technical response to a major or critical information security incident.
3. Information classification
The University Information Classification policy sets a framework for classifying and handling University information based on its level of sensitivity, and its value to the University. Personally Identifiable Information (PII) must be managed and protected in accordance with the University Data Protection and Information Classification Policies.
4. Communications security
4.1. Network controls
Any part of the University that manages a network, or networks on behalf of others, shall define and implement responsibilities and procedures to protect information, systems, applications, and network services.
Information transmitted across University networks, including University-managed cloud environments, shall be protected against unauthorised access, interception, or modification through appropriate digital and physical security controls, including encryption where required by the information classification and risk profile.
University operated wireless networks shall be protected using modern authentication and encryption technologies ('modern' meaning currently in active development and supported by a vendor or community). Cryptographic controls used for wireless networks shall meet approved institutional standards and applicable regulatory requirements.
Connections to University systems and services shall be protected using modern authentication and encryption technologies. Where this is not possible, the exception shall be documented, managed as an information security risk, and approved through the University risk management process.
Network security events shall be logged from network devices, including routers, firewalls, wireless infrastructure, and virtual network infrastructure in cloud hosted environments and retained in accordance with the
University records retention schedule.
Access to systems connected to the University network through wired, wireless, remote access, or VPN connections shall be authenticated unless an exception has been formally approved by the institution responsible for managing the network.
Network controls shall be implemented to appropriately segregate and protect information systems, network services, and network connections based on business requirements, risk, and information classification.
Network activity shall be monitored and logged to support the identification, investigation, and response to security events.
Network controls shall be implemented to protect the confidentiality, integrity, and availability of University information and services.
4.2. Unauthorised use
Attaching more than one device to any network port by use of network switches, firewalls, routers or wireless access points or any other means without authority should be prevented using technical controls. Use of any software or hardware which causes disruption to the correct functioning of University systems is prohibited under the Student and Staff Information Security Policies. If such disruption does occur the offending device or software should be disconnected from the University network by the institution responsible for managing the network.
5. Access control
Access to University information, systems and resources shall only be granted based on need, the principle of least privilege, and in accordance with the University Information Classification and Data Protection policies.
Access rights shall be assigned, reviewed, modified and removed throughout the user account lifecycle to reflect changes in employment status, enrolment status, role, responsibilities and requirements.
5.1. Regular user access control
Role Based Access Control (RBAC) shall be used wherever possible to assign access rights throughout the account lifecycle, with access determined by approved roles and data from authoritative staff and student information systems or other relevant information systems.
Access granted outside approved RBAC roles shall be authorised and reviewed regularly. Where recurring exceptions are identified, RBAC roles shall be modified or created where practicable to minimise individual access assignments.
All user accounts shall be uniquely assigned to an individual and remain inactive until the user's identity has been verified through an approved process. Following activation, users shall establish their own authentication credentials.
As the status of a user changes within the relevant information systems, accounts shall either:
- be deactivated promptly if no longer required and deleted after no more than three months; or
- have access rights and group memberships amended to reflect the user's current role and responsibilities.
Access rights shall be reviewed regularly to ensure they remain appropriate and authorised. Information asset owners shall approve and periodically review access to sensitive information assets under their control.
Privileged or administrative access shall be granted only where required, approved by an appropriate authority, and reviewed regularly.
5.2. Privileged user access control
Staff who require privileged access for the technical administration of information systems must be provided with a separate account for that purpose. Those accounts are only for use where privileged access is required, and not for any routine activity including email or instant messaging and web browsing.
Privileged access to systems must be reviewed by system owners annually.
Role Based Access Control (RBAC) is the default method of assigning privileged access rights based on the responsibilities of that member of staff.
Any privileged access granted outside the RBAC groups must be reviewed as part of the annual privileged account review, and wherever possible RBAC groups should be created or modified to incorporate that access to minimise exceptions.
Technical controls should enforce enhanced authentication measures (including but not limited to increased password length, multi-factor authentication and conditional access) for all privileged accounts.
Access to and administration of systems by privileged accounts must be logged.
6. Protection from malware
6.1. Security awareness
6.2. Controlling software installation and use
Staff should not have administrative access to desktops and laptops unless their role requires it. Where administrative access is required it should be actively managed, proportionate to user need, wherever possible time limited, and subject to annual review.
6.3. Malware detection
The Student and Staff Information Security Policies (see above) require that all personal computers which store or process University information must be protected using up to date anti-virus software, and updated frequently with the latest operating system and application patches and updates. University computers must comply with the same requirement, and wherever possible anti-virus and patching should be managed by IT to ensure compliance.
Email services used in the University must have built-in malware protection to prevent the transmission of viruses contained in both inbound and outbound messages.
7. Management of technical vulnerabilities
7.1. Inventory of assets
All University server and endpoint (desktop and laptop) assets should be recorded within an IT asset inventory which should be maintained and regularly reviewed by the responsible IT team to ensure it is accurate.
7.2. Identifying vulnerabilities
Appropriate information sources and resources shall be maintained to identify vulnerabilities affecting assets within the University asset inventory and shall be updated to reflect changes to that inventory.
System owners are responsible for identifying, monitoring, assessing, and addressing vulnerabilities affecting systems under their control. TIS is responsible for providing oversight, guidance, including advising the University on the level of risk presented and assurance activities where required.
To support these responsibilities, TIS may assess, audit, or monitor University systems, infrastructure, and networks to verify compliance with information security policies, standards, and regulatory requirements.
7.3. Reacting to vulnerabilities
A documented process shall be maintained for assessing the risk of identified vulnerabilities and implementing appropriate corrective actions. The process shall define roles and responsibilities and how actions are recorded for audit and review purposes.
Identified vulnerabilities shall be addressed through appropriate corrective actions, including patching, mitigation, compensating controls, or approved workarounds, based on the level of risk.
High risk or critical security updates for operating systems, firmware, applications, and other supported technology assets shall be addressed as soon as possible and within 14 days of release for all systems.
Medium and low risk security updates shall be applied on a regular maintenance cycle and, where possible, within 30 days of release.
Where vulnerabilities or security updates cannot be addressed within the required timeframe, the exception shall be documented, managed as an information security risk, approved by the appropriate authority, and reviewed regularly.
7.3.1 Patch Management Requirements
Update classification and required timeframe
- Critical / High - Within 14 days of release
- Medium - Within 30 days of release
- Low - Within 30 days of release
- Unable to Patch - Risk assessment, compensating controls, and formal approval and exception logging required
7.4. Monitoring vulnerabilities
Owners of systems and infrastructure shall ensure compliance with applicable vulnerability and patch management requirements.
A documented process shall be maintained to verify that network and server infrastructure remains compliant with applicable security update requirements.
The process shall include the identification, reporting, escalation, and remediation of non compliant systems.
Vulnerability and patch compliance information shall be reviewed regularly to support the timely remediation of identified issues.
8. Backup
All data should be backed up according to its value to the University, the cost of recreating the data, any financial costs or penalties which might be incurred as a result of data loss or corruption, and the risk of data loss or corruption.
The primary purpose of data backup is to allow the Faculty or Service to continue its activity after a data loss incident, by retrieving some or all of the data lost, ideally from a point in time backup taken within the last 24 hours.
All backups should meet the following minimum requirements:
- It has been designed to meet the recovery time and recovery point requirements of the Faculty or service.
- It is physically secured against theft.
- It is sufficiently resilient that failure of a single hardware component would not result in data loss.
- It is held separately from the original data storage location such that it would be unaffected by hardware or software failure or physical/environmental incidents (e.g., fire or flood).
- It is protected from unauthorised access through technical controls and as far as possible physical separation from the original data storage location (to prevent destruction in the event of a security incident, e.g. ransomware).
- It is tested at least annually to ensure the data backed up could be used in the event of a data loss incident.
Suitable backup locations include cloud based backup services, tape libraries and mirroring to resilient disk storage. Portable backup devices are not suitable for backup of PII or data where loss would result in significant cost to recreate or disclosure would result in financial penalties due to breach of legislation or regulation
9. Cryptographic controls
University information shall be protected at all times in accordance with the
University Information Classification Policy. Where the policy requires encryption, modern cryptographic controls shall be used to protect information both at rest and in transit. This requirement applies to servers, desktop computers, laptops, mobile devices and other systems that store or process University information.
Where cryptographic protection cannot be implemented, the exception shall be documented, managed as an information security risk, approved by the appropriate authority, and reviewed at least annually.
Backups shall be encrypted to prevent unauthorised access, disclosure, modification, or loss of information.
Wherever possible, cryptographic key management solutions shall be used to centrally provision, store, manage, rotate, and revoke encryption keys and secrets.
Responsibilities for the implementation, management, and monitoring of cryptographic controls and cryptographic keys shall be clearly defined.
10. Physical and environmental security
Areas where sensitive or critical information is processed, stored, or accessed shall be provided with an appropriate level of physical security and access control based on the criticality of the information, systems, and services they support.
Access to such areas shall be restricted to authorised individuals with a legitimate business, academic, or operational need. Staff and other authorised individuals granted access shall be provided with information on the relevant security risks and the measures used to control them.
The organisational unit responsible for the area shall ensure appropriate physical security controls are implemented, maintained, and reviewed.
As the status of an individual changes within the relevant area, physical access rights shall either:
- be removed promptly if no longer required; or
- be amended to reflect the individual’s current role and access requirements based on business need.
Access rights shall be reviewed regularly to ensure they remain appropriate and authorised.
10.1 Low Criticality Systems
Areas supporting low criticality systems shall be protected through normal building access and control procedures.
10.2 Medium Criticality Systems
Areas supporting medium criticality systems shall be located in defined rooms or facilities with controlled access using appropriate physical access controls.
Visitors, contractors and delivery personnel shall be identifiable, authorised where required, and supervised while in controlled areas.
10.3 High Criticality Systems
Areas supporting high criticality systems shall be located within specially designated secure areas with physical security controls appropriate to the level of risk.
Access to high criticality areas shall be controlled and recorded through an approved access control mechanism.
Visitors, contractors, and delivery personnel shall be authorised, identifiable, and accompanied at all times within high criticality areas.
Deliveries and public enquiries shall be managed so as to prevent unauthorised access to high criticality areas.
11. Supplier relationships
Responsibility for the management of supplier relationships should be clearly documented.
Cloud service providers and third-party software suppliers should by default have no access to University data, including administrative accounts on systems. Data is protected by access control and encryption, with the encryption keys being managed and controlled by the University. Non-Disclosure Agreements (NDAs) shall be used in all situations where the disclosure of Confidential or Restricted to a Cloud service provider or third-party software supplier is deemed necessary and appropriate.
Supplier access to systems should only be allowed when authorised by the University as part of a technical support call or planned maintenance activity, provided on the principle of least privilege, audited and logged. Where necessary, supplier access will be accompanied or observed in order to ensure compliance with University policy.
12. Information security incident management
Any part of the University that manages their own network or systems, or manages networks or systems on behalf of others should establish Incident Management procedures to ensure a quick, effective and orderly response to information security incidents. Those procedures should identify the individual or team responsible for responding to information security incidents.
12.1. Identifying security events
Information security events reported by service users or triggered by monitoring and management systems should be recorded. Those events should be assessed by staff with the appropriate skills and experience (or an appropriate third party), and decision made whether those events are classified as an information security incident
12.2. Responding to security incidents
Information security incidents should be recorded as such and responded to according to the institution’s documented incident management procedures. Any knowledge gained from analysing and resolving those incidents should be recorded and used to reduce the likelihood or impact of future incidents.
Any evidence gathered during the incident response process should be appropriately recorded, and as far as possible original evidence should be preserved as per
ACPO guidelines and
ISO/IEC 27037.
The institution's incident management procedures should include appropriate escalation guidance, such as for internal escalation (including to TIS, Legal, HR, Finance and the Media and Communications Team), and for reporting to the relevant authorities (Jisc, Action Fraud, and the South West Regional Cyber Crime Unit).
13. Mobile device management
The scope of Mobile Device Management applies to mobile devices for which the University requires security controls to enable access to University information, systems, or services.
Mobile devices within scope shall be authorised, maintained in a secure and supported state, and protected using security controls appropriate to the information classification, level of risk and method of access.
Where required by the University, mobile devices shall be enrolled in an approved Mobile Device Management (MDM) solution to enable the application and enforcement of security controls.
Where mobile access is permitted, appropriate authentication, cryptographic, and device security controls must be applied according to the information classification and level of risk.
Loss, theft, compromise, or non-compliance of an in-scope mobile device shall be reported promptly and may result in the removal of access to University systems and information.
Exceptions to mobile device security requirements shall be documented, managed as an information security risk, approved by the appropriate authority, and reviewed regularly.
14. Compliance and Audit
Compliance with information security policies, standards, legal, regulatory, and contractual requirements shall be monitored and assessed regularly.
The University may undertake audits, reviews, and assessments to verify compliance with information security requirements and the effectiveness of security controls. Relevant users and stakeholders shall cooperate with authorised compliance and audit activities.
Non compliance, control deficiencies, and audit findings shall be recorded, addressed through appropriate corrective actions, and managed through the University risk management processes.
Exceptions to information security requirements shall be documented, approved by the appropriate authority, managed as an information security risk, and reviewed regularly.
Version 1.1. Reviewer: Anthony Bruton (Information Security Manager). Approved 02 September 2026. Next review Q3 2027
Version 1.0. Reviewer: Anthony Bruton (Information Security Manager). Approved 03 June 2024. Next review Q3 2025
Version 1.0. Author: Richard Bartlett (Enterprise Security Architect). Approved 9 February 2021