The cloud changes the nature of risk, not just the infrastructure
Migrating to the cloud (AWS, Azure, GCP or SaaS solutions) profoundly changes how an organization must think about security. It is not simply "the same information system hosted elsewhere": the cloud introduces new responsibility models, new types of configuration to master, a disconcerting ease of creating and destroying resources, and an elasticity that can be either an asset or a risk factor if it is not properly managed from the start. A company that approaches its cloud transformation purely from a technical or financial angle, without building in security from the design stage, risks having to fix structural choices after the fact — choices that are far harder to revisit once the project is in production. This is especially true for organizations migrating progressively, application by application, without a coherent overall view of their total cloud exposure, and that sometimes discover too late that no team has a consolidated view of all the cloud resources actually deployed.
Misconfiguration, the top cloud risk
A significant share of security incidents observed in the cloud stem not from a technical flaw in the cloud provider itself, but from a client-side misconfiguration: storage mistakenly made publicly accessible, overly permissive firewall rules, services exposed without sufficient authentication, logging disabled by default. The flexibility of the cloud, which allows resources to be created and modified in a few clicks without going through a formal validation process, also increases the risk that an incorrect configuration goes unnoticed if it is not reviewed regularly by a competent team. It is this very speed of deployment, usually seen as a cloud advantage, that becomes a risk factor when it is not paired with systematic security checks at every change.
The shared responsibility model, often misunderstood
Cloud providers secure the underlying infrastructure (data centers, physical network, virtualization, availability of base services), but the security of what is built on top of it — resource configuration, identity management, data and application security, patch management on systems operated by the client — remains the client's responsibility. This division of responsibilities is often misunderstood, with some organizations wrongly assuming that "being in the cloud" means the provider handles all of security, including configuration choices made by their own teams. Clearly clarifying this boundary, service by service, is an essential step before any migration, and should be formalized in the project's internal governance rather than left to individual interpretation.
Identity and access sprawl (IAM sprawl)
The cloud makes it easy to create accounts, roles and permissions, which often leads to an accumulation of access granted over time without regular review: service accounts created for a one-off project and then forgotten, overly broad permissions granted "to move faster" during a high-pressure development phase, access for former employees or former contractors never deactivated after they leave. This identity sprawl (IAM sprawl) widens the attack surface in a way that often stays invisible until a regular access audit is conducted, since each individual access right can seem minor while their accumulation represents a significant risk.
Data residency: where is your data actually stored?
Major cloud providers operate data centers across multiple regions of the world, which in theory offers great deployment flexibility. Depending on the configuration chosen, however, a company's data may end up stored in a geographic region different from the one expected, which has implications for regulatory compliance and applicable law — particularly for personal data subject to localization or control requirements. Explicitly checking and configuring data location is a step often overlooked during a cloud migration carried out under project deadline pressure, even though it can have direct consequences on a company's compliance obligations toward its clients, partners, or relevant authorities.
How to secure a cloud migration without slowing it down
Securing a cloud transformation does not mean slowing the project down, but building it in from the design stage rather than treating it as a last-minute constraint. This involves several concrete practices: auditing resource configuration before and after migration, reviewing IAM permissions regularly rather than only once at account creation, encrypting sensitive data at rest and in transit, and integrating automated security checks into deployment pipelines (DevSecOps) rather than treating them as a manual step handled at the end of the project, when deadlines are already tight. Clear cloud governance, with responsibilities explicitly defined internally between IT, security and business teams, remains the most decisive factor in preventing cloud flexibility from turning into a security blind spot that is hard to fix after the fact. Involving security as a stakeholder in the migration project, on the same footing as technical and business teams, rather than as a final gate, fundamentally changes how these risks are anticipated and addressed.