By Bartosz K. — Published: 8 December 2025 — Updated: 16 December 2025 — 10 min read
Moving business data and infrastructure to the cloud brings significant advantages: flexibility, scalability, reduced capital expenditure, and access to managed services that would be prohibitively expensive to run in-house. But it also introduces a new security landscape that many organisations underestimate. Cloud breaches are rarely caused by failures of cloud providers — they are almost always the result of misconfiguration, weak access controls, or poor practices on the customer side. This article explains how to protect your business data in the cloud, practically and comprehensively.
The foundation of cloud security is the shared responsibility model. Cloud providers (AWS, Azure, Google Cloud, and others) are responsible for the security of the cloud: the physical infrastructure, the hypervisor, the managed services' underlying software, and the global network. You — the customer — are responsible for security in the cloud: your data, your applications, your identity and access management, your network configuration, and your operating system configurations.
This distinction matters because many organisations assume that "the cloud provider handles security." They do not handle your data's security — they handle their infrastructure's security. The vast majority of cloud security incidents involve customer-side failures: S3 buckets left publicly accessible, API keys hardcoded in source repositories, overly permissive IAM roles, unpatched virtual machines.
Misconfigured cloud storage is one of the leading causes of data exposure. Public object storage buckets containing customer records, database backups with no authentication, or development environments with production data — these mistakes are common, consequential, and easily avoided with the right controls and review processes.
Excessive permissions are a systemic problem in cloud environments. When every developer has administrator-level access "for convenience," a single compromised credential can expose an entire organisation's infrastructure. The principle of least privilege — granting only the permissions needed for a specific task — must be applied rigorously across all identities: human users, service accounts, and automated pipelines.
API keys, database passwords, and service account credentials regularly appear in source code repositories, CI/CD pipeline logs, and container images. Attackers continuously scan public repositories for exposed secrets. Even briefly exposed credentials can be harvested and exploited within minutes. Secrets management must be treated as a first-class engineering concern, not an afterthought.
Cloud-native applications are built on APIs. Poorly secured APIs — lacking authentication, missing rate limiting, returning excessive data — are prime attack targets. API security requires careful design, not just perimeter firewalls.
Data should be encrypted both in transit and at rest. In transit: use TLS 1.2 or higher for all communications, including internal service-to-service calls. At rest: use cloud provider-managed encryption (which most services enable by default) or, for sensitive data requiring higher assurance, manage your own encryption keys using a Key Management Service (KMS). The latter gives you the ability to revoke access to data independently of IAM controls.
Audit all IAM roles and policies regularly. Remove permissions that are not actively used. Use separate accounts or projects for different environments (development, staging, production) to limit blast radius if credentials are compromised. Enable multi-factor authentication (MFA) for all human users, and require it especially for administrative access.
Never store credentials in code, configuration files, or environment variable files committed to version control. Use a dedicated secrets management solution — AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager, or HashiCorp Vault — to store, rotate, and audit access to secrets. Applications should retrieve secrets at runtime, not at build time.
Visibility is the foundation of cloud security operations. Enable audit logging (AWS CloudTrail, Azure Activity Logs, GCP Cloud Audit Logs) and store logs in a separate, protected account so they cannot be tampered with after a breach. Set up alerting for suspicious activity: unusual authentication patterns, API calls from unexpected regions, large data exfiltration events, configuration changes to security-critical services.
Do not place all resources in a single flat network. Use Virtual Private Clouds (VPCs), subnets, and security groups to segment workloads. Databases should not be accessible from the public internet — access should be restricted to application servers in specific subnets. Use private endpoints for cloud services rather than routing traffic over the public internet.
For businesses handling personal data, financial records, or health information, cloud security is also a compliance matter. GDPR, for example, requires that personal data be processed with appropriate technical and organisational measures, that data transfers outside the EU meet specific adequacy standards, and that breaches are reported within 72 hours of discovery.
Cloud providers offer compliance tools — data residency controls, compliance dashboards, pre-configured security baselines — but using these tools requires deliberate configuration. Compliance is not automatic simply because you are running on a major cloud platform.
Technical controls are necessary but not sufficient. The majority of security incidents involve a human element: a developer who committed a secret to a public repository, an administrator who granted excessive permissions "just temporarily," a team that skipped security review under deadline pressure.
Building security into development processes — mandatory code review for infrastructure changes, automated secret scanning in CI/CD pipelines, regular security training, clear escalation paths for suspected incidents — creates the conditions for technical controls to be effective.
For organisations looking to improve their cloud security posture, a practical starting point includes:
At BKI, we help engineering teams build cloud infrastructure that is secure by design — from initial architecture to deployment pipelines to ongoing operational practices. Reach out if you would like to discuss your cloud security posture.