Call IT Support Email IT Support

Access Control

Defining the University’s approach to Access Control

Policy Statement

This control procedure defines the University's approach to access control and directly supports the following statement from the Information Security Policy:

Access to all information will be controlled and will be driven by business requirements. Access will be granted or arrangements made for users according to their role, only to a level that will allow them to carry out their duties.

A formal user registration and de-registration procedure will be maintained for access to all information systems and services. This will include mandatory authentication methods based on the sensitivity of the information being accessed, and will include consideration of multiple factors as appropriate.

Specific controls will be implements for users with elevated privileges, to reduce the risk of negligent or deliberate system misuse. Segregation of duties will be implemented, where practical.


This procedure is intended to be read and understood by all users of University IT systems.‌

Control Statements

Access to University resources must be granted on a need-to-know basis. Access control must be implemented to grant the least privileges required to fulfil a role. This applies to physical access, system and device level access and methods of authentication.

Appropriate access levels are defined and maintained by business owners, in consultation with Information Asset Owners.

 1. Authentication mechanisms

The central university Active Directory (AD) system is the core authentication system and should be used by any service requiring user account authentication, including federating to non-AD or cloud services as appropriate. To maintain lists of who has access to systems, AD Groups should be used to grant privileged access to systems or aspects of systems.

We use Shibboleth – an industry-standard system based on SAML – to control third party authentication requests for some web-based services, primarily library services.

LDAP authentication to AD is used for some corporate web sites and third party integrations, such as Moodle.

These system are managed by ISDS.

Where systems cannot use AD credentials, they will follow the same principles of need-to-know and least-privilege, but there must be an access control process ensuring that local ownership is taken for keeping access control lists up-to-date with staff and business changes.


2. User registration and deregistration

Human Resources provide an automated data feed to ISDS each day which provides details of all new staff joining the institution. Building access and IT access, including an individual email account will be automatically assigned by teams in ISDS and Estates based on this feed. The line manager of the new staff member will receive their login details by email from the IT Helpline.

Human Resources provide an automated data feed to ISDS about staff leaving the institution based on contractual information from the HR system. Leaver accounts will be timestamped, which 

prompts a number of actions to allow the account to be closed down. If there is any confusion over whether a member of staff has left, this should be confirmed with HR before any action is taken.

For security reasons it is essential that accounts are not left accessible for longer than is necessary once a member of staff is no longer employed by the University. Accounts of leavers will be disabled on the day the contract expires and deleted 90 days later. IT Administrator accounts will be disabled on the user’s last working day, even if this pre-dates the end of the contract.

Guest accounts must be requested and authorised by a permanent manager. Requests for guest accounts must be requested via the IT Helpline.  All guest accounts will then be processed by ISDS with a defined end date which automatically triggers the closure of the account. Guest accounts are only provided for a specified time period and at most a period of 5 years.

The University reserves the right to disable any account with immediate effect, for example where the user is subject to disciplinary action or there is a threat to the University or others. HR, Legal and/or the Assistant Director Information Security will confirm the need to disable an account. Accounts will be retained for as long as necessary in line with any on-going investigation.

Student account creation follows the same principles, but information comes from the Student Record System. Students retain access to core systems for 120 days after the end of their course, email and cloud storage for another 150 days, and are deleted after one year.

3. Changes to access rights

Changing of roles internally may require changes to access control privileges. As a change in role will result in a change in contract, the contract changes will be updated on the HR system, which then feeds directly to ISDS. Once a current contract ends, users are automatically removed from previous access groups and their new contract will attract the users new access rights. Any specific changes may need to be made manually on receipt of specific authorisation from a manager.

4. Privileged access

The creation of user accounts with higher privileges such as administrators is controlled, and restricted to those users who have a clear business need to manage information systems or networks.

Each administrator will be given a specific administrator account, which should only be used for system administrative purposes; otherwise, their standard user account should be used. Administrator accounts will not be given access to email, to mitigate the risk of malware spreading via privileged access. More complex passphrase management is required for administrator accounts. Access over the internet to accounts with system level privileges will use the University’s VPN and two factor authentication. No other systems should be used to allow privileged remote access to systems.

Unix/Linux systems should have additional accounts setup for people using the systems that do not require root access. It is often necessary to use the root account to perform system administrative tasks, so where possible these additional accounts should be used to login and root only used when necessary.

Where structure and existing staffing allows, segregation of duties will be implemented and administrators will be given the least access possible to allow them to complete administrative tasks. This will also assist with maintaining a clear audit trail of domain management and help to prevent catastrophic accidental changes being made to the domain by a single user. Full Domain Administrator accounts should only be used when there is no alternative, and their use should be documented and flagged to the Information Security Manager.

Research academics may require local administrator privileges in order to undertake their roles. Access can be granted where the access request is supported by a short written statement explaining 

the need, and is endorsed by the relevant Head of Service or line manager. When access is granted, research academics agree:

Accounts used to run programs or batch jobs should be unique to each service. Each should have the description field appropriately completed and be set to ‘password never expires’. Where possible these accounts should be setup in Active Directory and passphrases recorded in an encrypted secure vault with an audit trail of access. These service accounts should only be used for automated logins and never used to login manually. 

5. Database access

Access to databases should be sufficiently granular to protect the need-to-know principle. Where possible, this should relate to AD groups. Where access control is specified by naming a user on the database access control list, this must be maintained by the service owner.

6. Remote Access

Remote access to University systems is detailed in a dedicated procedure, and includes the University’s approach to the use of Mobile Device Management, VPN and MFA.

7. Secure areas

Secure areas must be protected by appropriate entry controls to ensure that only authorised personnel are allowed access. The following controls will be implemented to minimise risk:

8. Data Centre Security

The Operations Team are responsible for the management of access control to the University Data Centre environments including sensitive data processing areas that may be subject to specific controls.

The team will run regular reports providing details of access to these areas and will report any attempted or actual unauthorised access under the incident management procedure.


Failure to comply with this procedure could result in action in line with the University’s Disciplinary Procedure or Capability Procedure.

Compliance checks will be undertaken by the University’s Information Governance functions. The results of compliance checks, their risk assessment and their remediation will be managed by the Information Governance Board.

Related documents

This control procedure needs to be understood in the context of the other policies and procedures constituting the University’s Information Security Management System.

Browse Information Security policies and control procedures


A review of this policy will be undertaken by the Information Security team annually or more frequently as required, and will be approved by the Information Governance Board.

Information Security