Risk management of the enterprise IT for CESG Digital
A case study of how decisions with a security impact were taken during the creation of the enterprise IT service for CESG Digital.
Approach to making technology decisions when designing enterprise IT for CESG Digital
Overview of the service
The team working on our risk management guidance needed a solution to create and share documents. We put together a small enterprise IT service to meet our needs, taking steps and making decisions that we thought were sensible, balancing user needs with those of security within the context of our existing procurement vehicles. You can read about the choices we made as part of a series of blog posts on this topic.
Our approach to risk management
We set out some overarching principles to govern our approach:
- We will manage risk responsibly and in the spirit of the wider risk management change we are trying to achieve, balancing this with our need to deliver at a fast tempo
- We will take decisions on the basis of evidence, react promptly to events, and seek expert advice where we need it
- We’ll be sensible when making technology decisions that result in risk
- We will record significant decisions
The diagram above captures the way in which we’ve been making decisions as we have built our enterprise IT service. The most important thing to notice is that we don’t have a risk management process which runs separately or alongside; we just make sensible decisions throughout our project delivery on the basis of multiple factors – one of which is security. We take security seriously, but we need to make sure security controls and processes we put in place are proportionate to the overall risk of the project.
At the start of the project we had some initial things to establish:
- The needs of our users
- What information we expect to handle on the IT service
- Ground rules for how different types of data would be handled (agreed with senior risk owners)
- Agreement and clarity as to which decisions and risks we can take in-team and those that we must escalate
- We recognise that as our team contained many people who are heavily involved in collating and assessing internal and external research and guidance which was directly relevant to this project that we used much less external input in this specific instance than many other projects would
For each technology decision we used the following informal process:
- We identified a set of options or approaches, and assessed each against our user needs
- For each option that met our user needs we assessed how well it fitted with other decisions made previously, how it measured up against the security factors that were most important for this particular decision set within the context of our existing procurement vehicles.
- We made a decision based on the assessments, with a preference for the most usable service which was acceptable against other criteria
- We escalated the decision if we did not feel empowered to make it locally
- We recorded the decisions made and tracked any risks which are not fully mitigated
As well as following the steps described above, the following points were fundamental to our approach:
- The End User Device Security Principles and Cloud Security Principles were the basis of the security assessment for devices and services
- We made sure that the right people were in our team. We ensured that those people were trusted by accountable people (outside of our team) to make decisions which they would support
- All decisions would consider a range of viable options, with decisions made on the basis of evidence and professional judgement
- Important decisions would be discussed in the team, with two or more people being responsible for more challenging decisions
- Risks would not be taken if the team did not feel empowered, informed or qualified to take them
- When required we would seek help from independent experts in specific areas
- The team were all asked to agree to follow this approach
How did it meet the Principles of Effective Risk Management?
This case study was one of a number of case studies that informed the creation of the Principles of Effective Risk Management. This section describes how this project embodied the principles, and where there were areas for improvement.
Trust competent people to make decisions
We put together a skilled and experienced team of people for this task, with support from technical experts. Despite this level of experience in the team, it would still be unusual for a small team to be able to act autonomously when it came to making decisions that would carry risk for the organisation. To address this, we made sure the people responsible for information risk within the organisation were well briefed on what we were doing, and we worked to make them comfortable with us having a level of autonomy over the actions we took.
Security is part of every technology decision
The approach we took to assessing different options included how well it met our user needs, how well that choice fitted with others we had made previously, and if we were comfortable with the security implications or properties of that choice. We used the Cloud Security Principles, the End User Device Security Principles, or asked some of our security experts what the most important security considerations were for any given decision, and assessed the options which were viable against them.
User experience is fantastic - security should be good enough
This was one of our mantras for the project.
Demonstrate why you made the decisions, but don’t go overboard
For every important decision we made, we kept a record of why we did what we did, in case we need to justify it in event of a security incident in future or explain the rationale to others in the team, for example when additional services are added. We tried to keep the bare minimum paperwork required to do that. If we scale up the service we may need to do more.
Because this is a new approach for us, we are missing some supporting tools to help us track our decisions and resulting risks effectively. We used documents to do this, but as we move forward we would like to use a web tool to help us with this. We also need some tools to help us produce summaries and understand quickly how much cumulative risk we were exposed to.
Accept there will always be uncertainty
Luckily, as an organisation we are quite mature in this area. None of the choices we made as a team came without some risk but we were always able to reach a level of comfort with the decisions we made, from a security perspective at least.
Ensure the business understands the risks it is taking
We were careful to speak in plain English in all of our internal workings and external outputs. However, it would be wrong to say we were completely successful in meeting this principle. For example, one area where we could have done better was in providing a greater level of comfort to our External Communications team around what we would say publicly about our activities. We should have worked harder up front to give them confidence we would not put our brand unnecessarily at risk, had met our legally required disclosure thresholds for placing information in the public domain, and gained their support and assistance to start speaking publicly earlier.
Everyone is part of your delivery team:
Within the team there was a very strong delivery focus, with everyone very committed and excited to be part of it. However, we underestimated the need to engage with some key influential people outside of our project team in advance, and this had quite an impact on the pace of our delivery. In future we would look to identify everyone whose support was critical to our delivery, and work to ensure that those people were totally bought in to the vision of our project. We would also ensure that we did not place additional people on the critical path unnecessarily.
Recognise that decisions are interconnected
Since our project is only in ALPHA we have only had to worry about the relatedness of decisions we’ve made in ALPHA, but this is something we will need to monitor and revisit as the project evolves.