Moving to the cloud does not make your data secure. It changes who is responsible for which part of the security. The provider secures the data centers, the hardware and the core services. Everything you configure on top of them, including who can log in, what is exposed to the internet, how data is encrypted and what gets logged, is still yours. That is where most cloud breaches happen, and it is the territory a cloud security expert exists to own.
Many businesses treat cloud security as something the provider handles or something the general IT team will get to. The result is predictable: storage left public, administrator accounts without multi-factor authentication, access keys sitting in code repositories, and logging turned off to save money. None of these are sophisticated failures. They are ownership failures, and fixing them starts with understanding the line between the provider’s job and yours.
The shared responsibility model, in plain terms
AWS, Microsoft Azure and Google Cloud all publish a version of the shared responsibility model. The wording differs, but the principle is the same. The provider is responsible for security of the cloud: physical facilities, the hypervisor, the network backbone and the managed services themselves. The customer is responsible for security in the cloud: identities and permissions, network rules, data classification and encryption choices, operating systems on virtual machines, application code and monitoring.
The split shifts with the service type. With infrastructure as a service you patch the operating system; with a managed database you do not, but you still decide who can connect to it; with a SaaS application you control almost nothing except identities, sharing settings and data. Across every model, identity and configuration stay on the customer side of the line.
Two well-known incidents show what that means in practice. In 2019 a former cloud employee exploited a misconfigured web application firewall at Capital One to obtain credentials and copy data on roughly 100 million people in the United States and about 6 million in Canada. In 2024 attackers used passwords stolen by infostealer malware to log in to customer accounts on the Snowflake data platform; Mandiant, which investigated, found the affected accounts lacked multi-factor authentication. In neither case was the provider’s own infrastructure breached. The weakness sat in the customer’s half of the model.
What a cloud security expert actually owns
The job title varies, from cloud security engineer to cloud security architect, but the responsibilities cluster into four areas.
Identity and access. In the cloud, identity is the perimeter. The expert designs identity and access management (IAM) so that people and services get the minimum permissions they need, enforces multi-factor authentication, removes long-lived access keys in favor of short-lived credentials, and watches for privilege creep as projects grow. This is the practical core of a Zero Trust approach: no user or workload is trusted just because it is inside the network.
Configuration and posture. Cloud environments change daily, and every change can open a gap. The expert uses cloud security posture management (CSPM) tools and the providers’ native services, such as AWS Security Hub, Microsoft Defender for Cloud or Google Security Command Center, to continuously check configurations against benchmarks like those from the Center for Internet Security, and to catch public storage, open management ports and unencrypted data before an attacker does.
Data protection. That means knowing where sensitive data lives, encrypting it at rest and in transit, managing encryption keys properly, and controlling how data moves between regions and services. This is also where compliance obligations such as GDPR, SOC 2 and ISO 27001 become concrete: auditors want evidence of data inventory, access control and key management, not just policies.
Detection and response. Cloud logs, such as AWS CloudTrail, Azure activity logs and Google Cloud audit logs, record who did what. The expert makes sure they are turned on, retained and fed into detection tooling, and builds automated responses for high-confidence events, such as disabling a compromised key. AI-assisted analytics help sort signal from noise, but someone still has to decide what normal looks like for your environment and what to do when it changes.
Security that does not slow the business down
A cloud security expert who blocks every request quickly gets routed around. The ones who succeed make the secure path the easy path. In practice that means security guardrails built into the platform rather than enforced by ticket: preapproved templates for networks and storage, policy-as-code checks in the deployment pipeline that reject a public bucket before it is created, and organization-level policies that prevent anyone from disabling logging.
This is where cloud security overlaps with DevSecOps. When infrastructure is defined in code, security review can happen in the same pull request as the change itself, and the fix is a line of code rather than a meeting. Developers keep their speed, and the business gets a consistent baseline instead of a hundred hand-built exceptions.
Where to start: a first 90 days checklist
Whether you hire a full-time cloud security expert, assign the role internally or bring in outside help, these are the steps that close the most common gaps first:
- Inventory every account and subscription. Shadow cloud accounts created with a company card are a frequent blind spot. You cannot secure what you do not know exists.
- Enforce MFA everywhere, starting with administrators. Phishing-resistant methods such as passkeys or hardware keys are best for privileged accounts.
- Remove long-lived access keys. Replace them with role-based, short-lived credentials, and scan code repositories for secrets.
- Turn on and centralize audit logging. Protect the logs from deletion and keep them long enough to investigate an incident discovered months later.
- Run a posture scan and fix the critical findings. Public storage, open remote-access ports and unencrypted databases come first.
- Review SaaS integrations and third-party access. OAuth grants and vendor accounts are a growing attack path, as covered in our post on SaaS supply chain and OAuth attacks.
- Write down who owns what. A one-page responsibility map for each cloud service prevents the “I thought you were handling that” gap.
Hire, train or outsource?
Large organizations running many workloads usually need dedicated cloud security staff. Smaller businesses often do not have enough work to keep a specialist busy, and a generalist asked to cover cloud security in their spare time tends to cover it only after something goes wrong. The middle path is a combination: train an internal owner on the basics, use native provider tooling for continuous checks, and bring in specialists for architecture reviews, compliance preparation and incident response.
Whatever the structure, the key is that cloud security has a named owner with authority to change configurations. As we argued in cloud computing and cybersecurity are two sides of the same coin, the decision to move a workload to the cloud is also a security decision, and it deserves someone accountable for the result.
Frequently asked questions
Isn’t my cloud provider responsible for security?
Partly. The provider secures its infrastructure and the services it runs. You are responsible for how you configure and use them, including accounts, permissions, network exposure and data. Most cloud incidents trace back to the customer’s side of that line.
What skills should a cloud security expert have?
Deep knowledge of at least one major platform’s identity model and security services, infrastructure as code, logging and detection, and the compliance frameworks your business answers to. Provider certifications such as the AWS Certified Security Specialty or Microsoft’s Azure security engineer credential are useful signals, but hands-on experience fixing real environments matters more.
We use multiple clouds. Does that change anything?
It raises the bar. Each provider names and implements identity, networking and logging differently, so consistent policies take deliberate effort. Many multi-cloud businesses standardize on one identity provider for single sign-on and one posture management tool across all platforms.
Get a clear view of your cloud security
Delana Technologies helps businesses secure their side of the shared responsibility model: identity and access reviews, posture assessments, logging and detection, and the documentation auditors ask for. Learn more about our cybersecurity and compliance services, call 239.414.5126 or contact us.
Sources: AWS, Microsoft Azure and Google Cloud shared responsibility model documentation; US Department of Justice and Capital One disclosures on the 2019 Capital One breach; Mandiant (Google Cloud) report on UNC5537 and Snowflake customer account compromises (June 2024); Center for Internet Security Benchmarks.