Information Risk Management - Guiding Principles | Information Security - UCL

Endorsed by the Security Working Group - 16th December 2014. Approved by the Information Risk Governance Group - April 2017. These principles are to be applied on a "comply or explain" basis.

Back to: Information Security Principles

The top level guiding principles which apply to all information handling across UCL (including project work and day-to-day activities). They are intended to be used to inform and guide University members in their normal work, and to ensure that information is handled in a suitably secure fashion.

For guidance on Information Classifications please see:

UCL Information Management Policy (.pdf)

Reference	Principle	Explanation
1	Business requirements drive security requirements	Security requirements should exist to support the requirements of a business activity and should be relevant and appropriate.
2	Protect the confidentiality, integrity and availability of information to the right levels	Information's requirements for confidentiality, integrity and availability should be identified and security measures should be matched to these requirements.
3	The Internet and the general campus network are both untrusted environments.	Because the UCL campus network connects thousands of machines under widely varying management regimes, it cannot be considered as trusted. You should install the same level of protection on any machine connected to the campus network as you would for connection to the general Internet.
4	Role-based access	Privileges should be assigned to roles, not individual people. People should then be assigned roles.
5	Least privilege	Each role should have the minimum set of privileges needed to carry out the tasks required of that role.
6	Separation of duties	Where the risk or impact of a failure to execute a process correctly is unacceptably high, the process should require appropriate oversight before it can be completed. For example, when placing a purchase order, it has to be approved by a second person before it can be placed, or when writing software, a code review is undertaken by a second person before release.
7	Segregation of environments handling information rated at different security levels	Systems which store, process or transmit information classified as Secret should be physically segregated from other systems which operate with information at a different level (e.g. Normal). Systems which store, process or transmit other (not Secret) levels of information should be logically separated. Logical segregation can be achieved by appropriate network architecture. Note that it is expected that development/test and pre-production/production systems will be handling information at different levels.
8	No sensitive data to be held on development systems	Development systems should not hold any data rated other than "Normal". Test and pre-production systems which require data rated other than "Normal" should be secured to the same standard (or better, e.g. only accessible to a specific network or set of hosts) as the related production system.
9	Traceability of activity to individuals	This is restricted to operations involving information above "Normal". Actions carried out by an individual on information should be capable of being traced back to that individual. This includes audits of access to data. Please see: UCL Records Retention Schedule (pdf)
10	Documented security standards	Information processing systems where data with a classification other than "Normal" are processed should be designed, deployed and managed according to documented security standards (e.g. a secure software development lifecycle).
11	Competence and training	Individuals must be competent to carry out their responsibilities. Heads of Departments and Divisions must ensure that training to the appropriate level is provided.
12	Responsibility and accountability	Roles where there are activities which require access to information rated other than "Normal" should have those activities clearly documented as part of the role description. In addition, the responsibility for protecting that data should also be clearly defined in the role description along with a path of accountability to the line management structure.
13	Continuous improvement	All roles should be responsible for identifying and highlighting opportunities for improvement to manage risk. Systems and processes should be improved as opportunities appear.
14	Defence in depth	No individual security measure should be relied upon in isolation to protect information.
15	Risk ownership	Information risks should be owned by a role at an appropriately senior level in the organisation, i.e. one with sufficient authority to ensure the risk is effectively managed.
16	Logical and physical security	Logical security should mirror physical security in its rigour.