How to make a successful Cloud security transformation : key success factors and pitfalls

Temps de lecture : 5 minutes

Let’s be honest: not all cloud projects succeed on the first try. From the initial target to what actually goes into production several months later, there is sometimes a gap. We offer you here our feedback on a large-scale Cloud transformation project: some topics worked, others didn’t. Our objective here will be to highlight the key success factors, and to draw lessons from the failures observed, with a focus on the « security » theme.


To set the context, the French entity of a large international company, whose IT is partly outsourced, wanted to launch a Cloud initiative to increase agility and time to market.

The objective was to start a vast transformation and migration program, from scratch, and to launch several foundational projects simultaneously. Generally, two approaches are possible for this type of project. A progressive start with one or more POCs, then an acceleration over time, or a global approach with a quick start, as it was the case here:

  • Creation of a Cloud platform (with production environment and dedicated Internet access)
  • Design of a Cloud operational model (integrating DevOps, architecture, security, etc…)
  • Construction of an application migration roadmap
  • Setting up a Cloud community 

Security targets

One of the challenges of this project was to integrate security from the very first steps of the minimum viable product (MVP). Taking security into account from the start of this type of project is a strategic choice that is unfortunately still too rare.

That’s why we wanted to focus on this aspect in this blog article, to show the key success factors and the limits when trying to address all the following subjects in parallel:

  • Technical security, notably through the deployment, from the first weeks of the project, of measures to secure the landing zone and Internet access, and to control internal security rules.
  • Security governance, in particular through the definition of the RACI of the security teams, the update of the security operational processes and the identification of operational management tools…
  • The definition of a security change management plan, including the definition of an awareness and training plan for the security referents (to increase their competences about « Cloud Operations » and « Cloud Security »)…

The CISO, the operational security referents, the Permanent Controls managers, the application migration leaders and the data governance referents were involved in these initial discussions about security. 

Change management is therefore an investment, not a cost

Assessment of the implementation

On paper, we had a perfect case study of project start-up. Several months later, however, we have to admit that not everything has gone according to plan. For example, the access bastions, the fundamental building blocks of the security system, have still not been deployed. 

Another example is the difficulty in choosing a long-term solution for managing secrets, due to a discrepancy between the tools proposed by the Group and those recommended for Cloud use. 

In most cases, the obstacles to the deployment of security solutions were not related to technical problems, but rather to functional and organisational issues: difficulty in accessing the right information, organization of teams in silos, management of part of IT by an external department and outsourcing of part of IT services, lack of knowledge of security tools and services specific to the Cloud. 

Fortunately, the picture is not completely black, and far from it! Including security in the early stages of the project also brought significant gains: by supporting the security managers from the start, it was possible to facilitate the recruitment of Cloud security experts in the first few months of the project. This made the difference in terms of security contribution levels to the project. Similarly, the teams were able to quickly update the organisation’s permanent control plan to integrate the Cloud environments and processes. 

By taking the time to train, inform, alert and explain, it is also easier to find internal relays capable of mobilising time and budget to commit the resources necessary for the transformation, including the security aspect. 

This clearly shows that imposing a large-scale change in technology requires, above all, being well prepared to manage the change.

The technical issues are simple, the organisational and functional issues are key and above all complex. Change management is therefore an investment, not a cost. 

In the end, the involvement of the security team and the collaborative approach largely contributed to breaking down the preconceived ideas linked to a silo organisation and to improving the image of the security referents with the other stakeholders: many feared that including the security managers from the outset would be a hindrance, and yet, in the opinion of all, this mode of operation brought a real gain for the project.

To date, after a three-month phase to build the Landing Zone, followed by an automated deployment phase for the workloads of 200 entities, the project’s security results are as follows:

  • Implementation of a standard security base at the start of the project (access management, authentication, network filtering, centralization and analysis of logs, encryption, segregation of accounts and roles, etc.)
  • Creation of security user stories and definition of « security criteria of done  » for all user stories
  • Identification of Cloud security referents, stakeholders of Agile project ceremonies (planning, retro…) 
  • Setting up workshops to discuss Cloud security issues with all IT and business stakeholders 

While there is still work to be done to achieve all of the security targets, the awareness and acculturation work has worked well: some solutions, such as the implementation of an SD-WAN, have been proposed by the customer (and deployed with the help of Revolve teams). 


In conclusion, we would like to emphasise the importance of working on the resistance to change of all the stakeholders, the need to mobilise internal resources for the operational implementation of the tools and the benefits that can be gained from the involvement of the governance and operational security referents from the start of the project.

Commentaires :

A lire également sur le sujet :