What should organisations do when they are moving to cloud but still using on premises security habits?

Why cloud migration breaks the old security playbook

Moving from on premises to cloud changes the control plane, the operating model, and who owns which decisions. Security assumptions that worked around fixed network boundaries, static servers, and central administration often fail when workloads are elastic, shared services are managed by providers, and teams deploy faster. The real issue is not cloud versus on premises, but whether security is being redesigned around cloud ownership and cloud failure modes.

A practical migration starts with explicit cloud objectives: what is being moved, why it is being moved, and which risks are acceptable for each workload. That makes workload placement a security decision, not just a hosting decision. It also forces teams to decide where policy, logging, identity, configuration, and incident response responsibilities sit across platform teams, application owners, and service providers.

What changes when security moves into cloud operating models

On premises habits usually assume stable assets, central change control, and strong network perimeter enforcement. In cloud, the better control points are workload identity, configuration, logging, segmentation, and secure build and deployment practices. If teams keep treating cloud like a remote data center, they often miss misconfiguration, overprivilege, shared responsibility gaps, and drift between intended and actual settings.

That is why organisations should formalise a cloud strategy before or during migration. The strategy should define which services are allowed, how risk is assessed, what landing zones or guardrails are mandatory, and which controls are required at each stage of the application lifecycle. Training is part of the strategy, because teams need to recognise that the security answer in cloud is often different from the on premises one.

For teams building cloud controls from first principles, a useful baseline is the NIST Cybersecurity Framework 2.0, which helps organise governance, identification, protection, detection, response, and recovery around the migration. For implementation detail, the CIS Benchmarks provide hardening baselines that are often more realistic than trying to transpose on premises configurations unchanged.

How to design cloud security into the application lifecycle

The most durable shift is to move security left into design, build, and deployment, rather than relying on post-deployment reviews to catch cloud-specific risk. That means security requirements, infrastructure templates, CI/CD controls, secrets handling, and access decisions should be part of delivery, not an afterthought. When the lifecycle is controlled, cloud scale becomes manageable because each release inherits repeatable guardrails.

Application teams should also treat APIs, automation, and service access as part of the security design, because cloud applications rarely depend only on human users. The OWASP API Security Top 10 is useful when cloud workloads expose or consume APIs, while OWASP SAMM helps teams build security into the software delivery lifecycle itself. Where supply chain integrity matters, SLSA is the right lens for build provenance and artifact trust.

Cloud migration also changes the identity and access problem. Short-lived credentials, least privilege, and strong secret hygiene matter more when automation and services are doing the work that operators used to do manually. The NIST SP 800-53 Rev 5 Security and Privacy Controls gives a control vocabulary for access, authentication, logging, and configuration discipline, while the NIST AI Risk Management Framework is relevant where automation, decision support, or AI-enabled operations are part of the cloud estate.

Practitioner Guidance

What to prioritise: Start with workload classification and ownership, then define which cloud guardrails are mandatory before migration. If the team cannot name the business owner, control owner, and rollback path for a workload, it is not ready to move.

What to verify: Check that every migrated service has a documented control set for identity, logging, configuration, secrets, and recovery, and that those controls are enforced in code or platform policy rather than in tribal knowledge. Verify that teams can explain the cloud shared responsibility model in operational terms, not just in slides.

Common mistake: The most common failure is copying on premises patterns into cloud without redesigning access, monitoring, and deployment controls. That usually produces delayed detection, excessive privilege, and a false sense of parity.

Practitioner takeaway: Cloud migration is safest when security is treated as a design constraint and operating model change, not a relocation project; if ownership, guardrails, and lifecycle controls are unclear, the migration is already introducing avoidable risk.

Related resources from NHI Mgmt Group

• Why does moving Active Directory into a cloud environment still leave organisations exposed to security and management risk?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• Why do cloud security tools still fail when organisations have IAM in place?