As today’s organizations migrate to the cloud, they expose themselves to a rapidly growing threat landscape. As if protecting on-premise data wasn’t hard enough, your team faces many new security challenges in the cloud. Now is the time to ask some tough questions. How ready is your company for the next approaching cloud security audit? Any idea what the auditors will be prioritizing? Are you confident that your security management practices are able to keep data safe in the cloud? All right, deep breath.

The good news? You’ve come to the right place, and it’s not too late. On November 19th, 2020, we hosted a webinar with Jacques Nack, CEO at JNN Group, and John Gukian, senior engineer at IBM, and picked their brains on cloud security, compliance, and, specifically, how to audit your cloud environments to suss out potential vulnerabilities. This article will discuss industry changes, what many organizations currently do to keep their cloud data safe, and what your team can do to better prepare for your next security audit. There’s a lot to learn, so let’s get started.

Industry changes
Organizations have increasingly turned to cloud services in the last decade. In 2010, worldwide spending on public cloud services was 76.94 billion with projected growth to 362 billion by 2022. Keep in mind, 67% of enterprise infrastructure will be cloud-based and a whopping 82% of workload will be in the cloud by the end of 2020. Cloud services offer organizations increased agility, flexibility, and speed, but many aren’t prepared for the increased security and compliance challenges of using cloud resources.

Security risk has grown exponentially with the arrival of remote workforces. Cloud data is being accessed from anywhere and everywhere, attackers have more vulnerabilities to target, and the job of safeguarding data is more challenging than ever. Companies now realize security and compliance in the cloud requires ongoing, relentless effort.

Addressing security in the cloud

Securing data in your cloud environments comes with unique challenges and raises a new set of questions. What’s the appropriate governance structure for an organization’s cloud environment and the data that resides within them? How should cloud services be configured for security? Who is responsible for security, the cloud service provider or the user of that cloud service?

Cloud compliance is becoming front of mind for organizations of all sizes. Smaller companies with limited staff and resources tend to rely more on cloud vendors to run their businesses and to address security risks (we’ll get into why this is a bad idea later in this article). Often roles will overlap with team members wearing many hats in smaller operations. Larger enterprises frequently keep more security and compliance duties in-house, using vast resources to create individual teams for threat hunting, risk management, and compliance/governance programs.

Regardless of size, the challenge of balancing security and business objectives looms large for all companies. Security must be built around the business, and Jacques accurately describes the nature of the relationship: “Security is always a support function around your business.”

Many teams seeking to build assurance while managing cost rely on Governance, Risk and Compliance (GRC) frameworks to keep their data secure in the cloud. There are many available, such as the Cloud Security Alliance Cloud Controls Matrix (CSA CCM), NIST 70053, and ISO 27001, which can help your team better understand cloud-specific compliance considerations and prepare for IT compliance audits.

Which one you choose should depend on your organization’s unique circumstances, preferences, and partners. For example, the Cloud Security Alliance Cloud Controls Matrix is specifically designed to provide fundamental security principles to guide organizations in assessing the overall security risk of their cloud environments. FEDRAMP would be a sensible choice for companies doing business with the federal government. Jacques recommends taking the time to thoroughly understand your business environment, risk tolerance, and maturity level to implement controls before finalizing your risk framework.

Key Security and Compliance Considerations When Operating in the Cloud

When assessing the security posture of your cloud environment, the first question both you and your auditor need to ask is, “Where is your data going?” “Your data’s journey—how it’s received, stored, handled, and treated by third parties—will determine your cloud security and compliance agenda,” says Jacques. All security controls and processes must align with your data’s flow around business objectives. Keep in mind that security’s role is supportive but must never become secondary.

Security by design

During the age of legacy systems, security was often “bolted on” as an after-thought. This doesn’t fly today as cloud systems demand a renewed awareness and commitment from the top, embedding security into the company culture and daily operations.

With this new security by design mindset, all departments share responsibility and empowerment in the decision process. Security by design is the only way modern enterprises can achieve the agility and flexibility needed to face the cloud’s continually evolving threat landscape.

Building your cloud compliance program

Both of the experts we interviewed agree that today’s organizations need an established cyber program to help prepare for cloud compliance audits. If your company doesn’t have established security management processes, you will struggle when it comes to passing cloud audits.

So, what does your organization need to do to ensure compliance? Below are some key steps to create a compliance program:

Determine your level of risk tolerance
Assign critical roles like security and privacy officers
Select the compliance framework that you will build around
Design your controls in alignment with business objectives
Adopt a privacy policy to govern how data is shared
Draft an administration contract to document your data handling policies
Adhering to these steps will help you create a solid foundation for maintaining information security in your cloud environment.

Key Compliance Considerations for Cloud Environments
One of the most important things to focus on is asset management. You need to document all the cloud services within your cloud environment as well as the data that resides within them. Organizations should define how all cloud services should be securely configured, to prevent them from becoming exploitable.

Knowing What Regulations Apply to Your Data

This can be tricky because you’ll need to keep up with region-specific and sometimes overlapping privacy regulations. For example, you’re doing business in Italy and must adhere to GDPR, but Italy may also have its own set of required laws.

Cloud Strategy & Architecture

Organizations should clearly define their cloud account structure, ownership, and accountability.

Change Control

The agility, speed, and flexibility of cloud environments make changes difficult to control. Change processes in traditional on-premise environments typically involve multiple roles and approvals and could take days or weeks. With the cloud, infrastructure is software, and their entire lifecycle may only last minutes or seconds. Companies should use automation and leverage cloud services to continuously monitor configurations and immediately remediate issues.

Signs of success

How do you know your organization’s cloud security and compliance program is positioned for success? Besides getting a thumbs up from auditors, there are other ways to gauge your program’s effectiveness.

John Gukian suggests looking at a company’s onboarding process and how new staff is introduced to security policy. Is there a well-understood set of policies and procedures to guide the onboarding process? How is access control handled? What is taught during the initial training period regarding security? Are awareness and best practices emphasized in the daily routine out of the gate?

Speaking of training, are there continuous education programs to keep staff current on rapidly changing cloud threats and remediation tactics? Hopefully so, because in the final analysis, training can make the difference in driving high levels of security awareness.

Passing your compliance audit is the crowning act of affirmation that pleases stakeholders—feel free to take a deserved moment to jump in the air and fist bump your teammates. However, remember cloud compliance results from a program of well-documented policies and procedures built on a continuous pattern of disciplined habits and company-wide awareness.

Conclusion
Securing cloud environments today comes with unique challenges, and verifying compliance is an ongoing quest for organizations and external auditors. Securing your cloud environment starts with understanding all cloud services in your environment and the flow of data between various services and applications. You’ll also need to pay close attention to who gets access to that data and who is authorized to make changes to configurations. It is only then that your team can create the proper processes and controls to ensure safety and compliance in the cloud.

Compliant organizations have established, well-documented cyber programs modeled on appropriate risk management frameworks. Their leaders embed security awareness into daily operations. They continually ingrain security awareness into their culture with robust awareness training.

So, do you feel better prepared for your next cloud compliance audit? We hope so; at the very least, you know the steps secure and compliant organizations take to keep their data safe in the cloud, and that’s what we call a good start.

Shifting Security Left: What DevSecOps Means in Practice

Security used to be the responsibility of a dedicated team working at the final stage of software delivery. That model made sense when release cycles were measured in months. Today, with teams shipping multiple times per day, bolting on security at the end is no longer viable.

DevSecOps addresses this by integrating security practices directly into the DevOps workflow — from the first line of code through deployment and into production. The core idea is simple: find and fix security issues early, when they are cheapest and fastest to resolve, rather than discovering them after release and scrambling to retrofit fixes across running systems.

For teams just getting started, four areas deserve close attention.

1. Understand Your Organisation’s Security Policies Before Choosing Components

Security and audit requirements should drive component selection at development time, not after the fact. A key goal of any mature DevSecOps programme is the ability to prove that what is expected to run in production is exactly what runs there — without adding special verification code to the application itself.

Practically, this means your team should:

• Document the organisation’s security policies, compliance requirements, and approved component lists before development begins.
• Establish criteria for evaluating third-party libraries against those policies — licensing, known vulnerabilities, maintenance status.
• Aim for runtime visibility that provides continuous reporting on what is actually running across all applications, so security, governance, and compliance can be verified without manual audits.

When developers understand these boundaries up front, they make better component choices and avoid the costly rework of replacing non-compliant dependencies discovered late in the cycle.

2. Implement Build Environments That Are Static, Reproducible, and Immutable

Inconsistent build environments are a common and underappreciated source of security risk. If each developer or pipeline stage resolves dependencies differently, you lose the ability to reason about exactly what code is running — and you create opportunities for supply-chain attacks and version drift.

To reduce this risk:

• Standardise dependency resolution across the organisation. Define a single, policy-driven process for how open source language dependencies, licenses, and security checks are resolved.
• Use immutable build artefacts. Once a build is certified, it should not change. Any change should trigger a new build and a new certification cycle.
• Automate the three lifecycle stages of open source languages: build, certify, and resolve. Trusted and curated language distributions can enforce these stages consistently across every team and project.

Reproducible builds eliminate the class of vulnerabilities that arise from environment drift and make it far easier to respond quickly when a new CVE is disclosed — because you know exactly what is in every artefact.

3. Be Proactive: Scan and Monitor Throughout the Entire SDLC

License compliance violations and known vulnerabilities should be identified during development — not after a release, and certainly not after an incident. The challenge is scale: a modern application may depend on hundreds of direct and transitive open source packages, and that dependency graph changes every time a component is updated.

Automation is essential here. Key practices include:

• Scan all third-party and open source components for known vulnerabilities and license compliance as part of the CI/CD pipeline, not as a one-off exercise.
• Monitor continuously. An application’s risk profile changes over time as new vulnerabilities are disclosed against components that were clean at build time. Monitoring must extend from development into production.
• Automate developer notifications. When a component used in a project receives a security update, the responsible team should be alerted automatically so they can act quickly.

Historically, runtime security monitoring required installing agents — either at the system level via application scanning tools (AST) or within the application using runtime application self-protection (RASP) solutions. A more recent approach uses agentless monitoring through interpreter plugins, which allows security to be embedded closer to the source code without modifying application code directly. This can give security, InfoSec, and risk management teams greater visibility with less operational overhead, though the maturity and applicability of specific tooling varies.

4. Use Up-to-Date Components from Actively Maintained Projects

Outdated or unmaintained open source packages are one of the most common attack vectors in modern application stacks. Many open source libraries are contributed by multiple developers and may not go through a formal security review. Even packages that passed a security assessment at adoption may later develop new vulnerabilities — ones that existing tools and static inventories will not catch unless actively monitored.

To manage this risk effectively:

• Enforce policies that prevent the use of packages with known critical vulnerabilities, flagged licenses, or no active maintenance.
• Maintain a current software bill of materials (SBOM) for each application — an up-to-date inventory of every package and version in use.
• Perform regular vulnerability checks against trusted advisory sources and apply patches promptly when vulnerabilities are confirmed.
• Prefer actively maintained projects. A library with recent commits, responsive maintainers, and an established security disclosure process is substantially lower risk than one that has been dormant for years.

DevSecOps Is a Team Responsibility, Not a Developer Checkbox

Individual developers play a critical role in establishing security standards during development, but DevSecOps is not solely the developer’s responsibility. Security teams, operations, and leadership all have a part to play in defining policies, selecting tooling, and maintaining organisational standards.

The opportunity DevSecOps presents is significant: by moving security earlier in the pipeline — covering license compliance, vulnerability scanning, immutable builds, and component hygiene — teams reduce the cost and disruption of late-stage security fixes, accelerate time to market, and build a culture where security is everyone’s concern rather than a last-minute gate.

Starting with these four considerations gives any team a practical foundation for a more secure delivery pipeline.

Why Kubernetes Has Become Central to Multi-Cloud Strategy

Kubernetes has moved well beyond experimental status. IT leaders across industries are deploying it in mainstream production environments, using it to bridge on-premises infrastructure with public cloud platforms. A significant driver of this adoption is that major cloud providers — AWS (Amazon EKS), Microsoft Azure (AKS), and Google Cloud (GKE) — have all embraced Kubernetes and offer it as a managed service. This lowers the barrier to entry, allowing teams to experiment incrementally and scale consumption on a pay-as-you-go basis.

The result is a growing ecosystem of tooling, community knowledge, and integrations that continues to accelerate enterprise digitalization. But with opportunity comes complexity. As Kubernetes use cases expand, three considerations stand out for teams operating in multi-cloud environments.

1. Evolving IT and Developer Roles Demand a New Operating Model

The shift to multi-cloud and multi-cluster Kubernetes environments has fundamentally changed what IT operations teams manage. Applications are increasingly decomposed into microservices and packaged as containers — but not all workloads are ready for containerization at the same pace. This means IT teams often manage hybrid environments where containerized and non-containerized workloads coexist, sometimes across multiple clusters and clouds simultaneously.

For application developers, Kubernetes introduces genuine workload portability. Because it operates as a consistent abstraction layer across public and private cloud infrastructure, developers can target Kubernetes APIs regardless of the underlying provider. Combined with a large open-source community, rich documentation, and widely available tutorials, this portability increases developer velocity and reduces friction when moving workloads between environments.

The practical implication: both operators and developers need to upskill. Platform engineers need to understand multi-cluster networking, policy management, and federated workload scheduling. Developers need enough operational awareness to write applications that take advantage of Kubernetes primitives — health checks, resource limits, rolling deployments, and service discovery — from the start.

2. The Network Security Surface Area Is Expanding

Running containers in production — especially on bare metal — pushes the boundaries of what traditional networking and security tooling was designed to handle. Container workloads are ephemeral, horizontally scaled, and communicate extensively over internal service meshes. Each microservice boundary is a potential attack surface, and in large deployments those surfaces multiply rapidly.

Kubernetes is designed for continuous delivery, zero-downtime deployments, and high availability. These are valuable operational properties, but they also mean the environment is in constant flux — pods spin up and down, IP addresses change, and network policies need to reflect the current state of the cluster at all times. Static, perimeter-based security models are inadequate in this context.

Security teams working with Kubernetes environments should focus on several layers:

• Pod security: Use Pod Security Admission (or equivalent policies) to restrict what containers can do at runtime.
• Network policies: Define explicit ingress and egress rules between namespaces and services using Kubernetes NetworkPolicy resources or a CNI plugin that supports fine-grained policy (e.g., Calico, Cilium).
• Image security: Scan container images for known CVEs before they reach production. Implement admission controllers to block non-compliant images.
• Secrets management: Avoid storing secrets in environment variables or ConfigMaps. Use a dedicated secrets manager and integrate it with the cluster via a CSI driver or sidecar.
• Audit logging: Enable Kubernetes API audit logs and ship them to a central SIEM for anomaly detection.

As microservice architectures grow, mutual TLS (mTLS) between services — often implemented via a service mesh such as Istio or Linkerd — becomes an important defense-in-depth measure, encrypting and authenticating east-west traffic inside the cluster.

3. DevOps Adoption Is Accelerating — and Kubernetes Is a Catalyst

DevOps aims to unify application development and operations across the full software lifecycle: planning, coding, building, testing, releasing, deploying, operating, and monitoring. Kubernetes contributes directly to this goal by providing a common substrate that both developers and operators can target, removing the “it works on my machine” problem at the infrastructure level.

Practically, this means developers can use the same Kubernetes manifests or Helm charts across local development environments, CI pipelines, staging clusters, and production — reducing environment drift and accelerating release cycles. Operators, in turn, gain standardized interfaces for observability, scaling, and rollback rather than managing bespoke deployment scripts per application.

The growing Kubernetes ecosystem reinforces this collaboration. Tools like Argo CD and Flux bring GitOps workflows to cluster management. Prometheus and Grafana provide a consistent monitoring stack. Tekton and other Kubernetes-native CI systems let teams define pipelines as code in the same repositories as their applications. This convergence gives DevOps teams a coherent, auditable, and repeatable delivery pipeline from code commit to production.

Looking Ahead: Kubernetes as Enterprise Infrastructure

Kubernetes is no longer a cutting-edge experiment — for many enterprises it is foundational infrastructure. As adoption matures, the ecosystem of tools, managed services, and community knowledge will continue to expand, making it easier for organizations at every stage of the journey to adopt and operate it effectively.

For IT leaders planning their multi-cloud strategies, the three considerations above are not one-time checkboxes. They require ongoing attention as cluster scale grows, as new workloads are onboarded, and as the threat landscape evolves. Organizations that invest in the operational discipline to manage Kubernetes well — across roles, security, and DevOps culture — will be better positioned to deliver software faster and more reliably across both private and public cloud environments.