This article is based on insights originally shared at the IBM Security Summit in London, during the “Innovating With Cloud Security” breakout session hosted by Martin Borrett, CTO of IBM Security Europe. The original piece was published on securityintelligence.com.
When security professionals gathered for the “Innovating With Cloud Security” breakout session at the IBM Security Summit in London, a clear picture emerged: cloud adoption is near-universal, but a mature security strategy is not. Audience polls revealed that all attendees used cloud services, with the majority relying on public multi-cloud environments — yet fewer than 10 percent had a formal, policy-backed strategy for cloud security.
That gap between usage and governance reflects a broader industry tension. On one side is the belief that the cloud is inherently too insecure for enterprise workloads. On the other is the equally dangerous assumption that cloud providers handle security automatically. Neither extreme serves the business well. What follows are the key themes from that discussion, reframed as actionable guidance for DevOps and security teams.
Cloud Security: For vs. From
One of the most useful conceptual distinctions in cloud security is the difference between security for the cloud and security from the cloud. These are not interchangeable terms, and conflating them leads to gaps in coverage.
- Security for the cloud means protecting cloud workloads themselves. This includes native cloud controls and off-the-shelf products for identity and access management (IAM), patch management, and data encryption applied to cloud-hosted resources.
- Security from the cloud means using cloud-delivered services to protect other infrastructure — whether that’s other cloud workloads or on-premises systems. Security-as-a-Service (SECaaS) offerings such as cloud-delivered SIEM, IAM platforms, and vulnerability or application scanning tools fall into this category.
Both dimensions are necessary. Organisations that focus only on securing their cloud environments while ignoring how cloud-based services can extend protection to the rest of the estate are leaving significant coverage gaps.
Regulatory Requirements and the Cloud
Moving workloads to the cloud does not move them outside the reach of compliance obligations. Standards, regulations, and legislation that applied to on-premises environments continue to apply when those same workloads are migrated or rebuilt in the cloud. This is a point that auditors and regulators have increasingly made explicit.
Security leaders should expect auditors to scrutinise the following areas in a cloud context:
- Data sovereignty — where data physically resides and which legal jurisdiction governs it
- Identity and access management — who can access what, under what conditions, and how that access is monitored
- Auditability — whether logs are complete, tamper-evident, and retained appropriately
- Availability — SLA commitments from cloud providers and their alignment with business continuity requirements
- Data classification and encryption — whether sensitive data is identified, labelled, and protected in transit and at rest
- Incident management and response — defined processes for detecting, reporting, and recovering from security incidents in a cloud environment
Where compliance controls have already been documented for on-premises environments, the practical step is to review each control and assess whether it remains applicable, needs to be re-implemented differently, or can be replaced by a cloud-native equivalent that achieves the same outcome more efficiently.
Map Your Cloud Transformation Journey
Cloud transformation is not a single path. Most organisations operate across a mix of transformation contexts simultaneously:
- Migration — lifting and shifting (or re-platforming) existing workloads to a cloud provider
- Hybrid cloud — maintaining on-premises infrastructure alongside cloud resources, often with workloads spanning both
- Cloud-native — designing applications and services specifically to take advantage of cloud capabilities, including containers, serverless functions, and managed services
Migration and hybrid approaches tend to dominate in established enterprises, with cloud-native as the longer-term direction of travel. Regardless of where an organisation sits on this spectrum, the recommended approach is the same:
- Conduct a current-state security assessment to understand your existing controls, policies, and procedures.
- Map that assessment to your target cloud environment to identify gaps, overlaps, and opportunities.
- Develop or refresh a cloud security strategy that reflects the specific deployment model you are using.
- Look for opportunities to use the cloud environment to automate or improve security-enforcing functions — not just replicate what you had on-premises.
That last point is important. The cloud introduces automation capabilities that can make security controls faster, more consistent, and more scalable than their on-premises equivalents. Treating cloud migration purely as a like-for-like port misses this opportunity.
Infusing Cloud Security Into DevOps
The cloud has fundamentally changed how software is built and operated. DevOps practices — tightly integrated development and operations teams working in continuous delivery cycles — have flourished in cloud environments. But this shift also creates new security challenges that traditional security models were not designed to address.
In many organisations, DevOps engineers now have direct access to cloud environments and the ability to provision infrastructure, configure services, and deploy applications — all at a pace that outstrips traditional security review cycles. If security is positioned as an external gate, it will either slow delivery unacceptably or be bypassed entirely.
The answer is to integrate security into the DevOps workflow itself. Practically, this means:
- Security-as-code — encoding security controls, policies, and compliance checks as code that lives alongside application and infrastructure code in version control. Just as developers write application code and operations teams write infrastructure-as-code (IaC), security requirements can be expressed in the same way.
- Shift-left security — moving security testing, scanning, and policy checks earlier in the development pipeline, so issues are caught before they reach production rather than after.
- Security culture in DevOps teams — helping developers and operations engineers adopt a security mindset, so they identify risks and design controls proactively rather than waiting for a security team to review their work.
This approach — sometimes called DevSecOps — does not replace dedicated security expertise. It extends security thinking throughout the team and allows security professionals to focus on harder problems while automated controls handle routine enforcement.
Different Techniques, Same Outcomes
Across all of these themes, one thing remains constant: the security outcomes organisations are trying to achieve have not fundamentally changed. Confidentiality, integrity, availability, accountability, and compliance are still the goals. What has changed is the tooling, the delivery mechanisms, and the speed at which everything moves.
More automation, faster feedback loops, and greater operational efficiency are not ends in themselves — they are means to delivering those outcomes more reliably and at scale. Cloud security, done well, is not a constraint on innovation. It is a capability that enables the business to move faster with confidence.
Organisations that embed security into their cloud strategy from the start — rather than bolting it on after adoption — are better positioned to use the cloud as a competitive advantage, not just an infrastructure decision.
Originally based on a session summary from the IBM Security Summit, London. Source: securityintelligence.com.