Risk management in the Cabinet Office Technology Transformation Programme
A case study of how decisions with a security impact were taken in the Cabinet Office Technology Transformation Programme.
Approach to making technology decisions in the Cabinet Office Technology Transformation Programme
Overview of the service
Cabinet Office is building a new enterprise IT service for its OFFICIAL information to replace its legacy service which is nearing end of contract with the existing supplier. The new service will also be rolled out to the Department for Culture, Media & Sport, who are co-located with the Cabinet Office and have almost identical technology needs. The service will serve around 3500 users based across 20 sites.
There is a strong driver to make the user experience at least as good as people have at home, whilst providing the functionality that would be expected in any medium to large organisation. The Cabinet Office want to ensure that this programme is an exemplar for both technology and security at OFFICIAL and demonstrate that the two do not need to be mutually exclusive. The Programme also leveraged the latest advice and guidance on cloud services, devices and networking from CESG.
You can read more about the Technology Transformation Programme on their blog.
Approach to risk management
The Cabinet Office team delivering the project do not have a separate or silo’d security function. They have seconded a security expert from elsewhere in the department who is bought in to the transformative vision and the success of the project. His primary goal is for the user experience to be fantastic and for security to be good enough.
There were around 45 key technology decisions identified at the start of the project. Security was an important consideration for most of these choices, but it was almost always secondary to user needs. Figuring out how to procure something was the last consideration. For each of the key decisions a set of options were analysed against the factors and records of the rationale for each decision were kept. The programme board were briefed on progress, and the most difficult choices from a security perspective were escalated to this board to endorse.
The decisions made all need to fit together, and may be revisited as the service goes through staged releases towards being fully live.
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.
Trust competent people to make decisions
Decision-making was heavily influenced by a pool of trusted, skilled members of staff. The team was built using the principle that involving the right experts with the right attitude was essential. Staff members with proven, complementary skillsets were then empowered to make key decisions together. The security advisor is trusted by the team and programme board to ensure that the solution would be both secure enough but also that it would not be burdened by unnecessary controls. This degree of trust meant that security decisions were very rarely challenged, although it was always clear that challenge was healthy and welcome.
Security is part of every technology decision
While security was a factor in technology decisions, it was deliberately a secondary consideration to user needs. Keeping this balance encouraged the team to innovate and come up with new solutions to meet security requirements, rather than automatically resorting to tried and tested controls or following received wisdom. In many cases the technology and delivery teams would consider security aspects without prompting or intervention and in many cases developed acceptable solutions without further input from the security advisor.
Demonstrate why you made the decisions - and no more
The majority of security decisions were documented using a lightweight process, which explained the rationale at the time, rather than formally documenting every element of the project. They used a model where certain assumptions are documented (e.g. the product has been built to a defined set of security principles by a known set of trusted people) rather explained and validated. A more in-depth security overview is being produced to provide assurance to the SIRO and Board, although this paper will be written explicitly for this purpose and the language, length and degree of detail tailored accordingly. A wiki will be used to record details of security controls and policies, this approach will ensure that information is easily findable and kept up-to-date rather than lost within a large, single document.
Accept there will always be uncertainty
During the project there were a number of situations where decisions were made in uncertain or challenging circumstances. The rigour around making decisions in uncertain circumstances was managed by seeking out independent input from experts who could offer different perspectives.
Ensure the business understands the risks it is taking
The Programme Director and Board were regularly consulted to verify that they were happy with key risk management decisions and the level of detail available to provide context. Important risk decisions were contextualised by experienced personnel, in some cases with the aid of CESG support, before being escalated to the Board to verify that they were happy with the level of detail provided. The security advisor had a seat on the board and risk issues were always given a high level of prominence in board discussions.
Make everyone part of your delivery team
Everyone on the team shared a desire for the project to succeed. The principal security expert in the team was bought into the success of the project from an early stage and involved in key technology decisions, with the rest of the team having a good sense of when there was a potential security impact of a choice.
User experience should be fantastic - security should be good enough
This principle was explicitly followed by the project, with the consistent belief that user experience and technical fit are the most important factors in the project. Security (as it encroached on functionality and user experience) was seen as something that should be kept to the acceptable level and not gold-plated, in order to avoid disruption to the end user and business. This approach did not preclude important security issues being given a high degree of importance and investment, although this would always be set against the primacy of user needs.
Understand that decisions affect each other
The process by which technology decisions were made, coupled with the use of the Agile methodology ensured that there was always scope to re-evaluate, adjust or change previous decisions. This approach provided a high degree of flexibility and meant that when a new decision, or the sum of several decisions, had a material affect on another, then it could be revisited without too much disruption to the programme.