When Amgen notified the SEC about unauthorized access to data in third-party cloud environments, they didn't blame the cloud. This shows they understand what many organizations miss: these breaches aren't cloud failures. They're governance failures.
You've moved your crown jewels to hosted environments. But if you're making the mistakes below, you're essentially handing attackers a map to your most sensitive data, whether that's protected health information, intellectual property, or confidential business files.
Why These Mistakes Keep Happening
Third-party cloud breaches follow a pattern. Organizations treat cloud migration as an infrastructure decision when it's actually a control redesign project. Your security team configured on-premises access controls over years. Then you lift-and-shift to AWS or Azure and assume the provider's baseline security handles what your internal controls used to manage.
It doesn't. Cloud providers secure the infrastructure. You secure everything you put on it, everyone who touches it, and every integration that connects to it. In the gap between what you think the provider handles and what you actually configured, attackers find their entry point.
Mistake 1: Treating Cloud IAM Like On-Premises Access Control
You're applying the same access logic you used for on-premises systems to cloud environments. That's the problem.
Why it happens: Your identity and access management policies were built around network perimeter thinking. Users inside the firewall got broader access. Cloud environments don't have that perimeter. Every API call, every service account, every federated identity is a potential attack vector.
Real consequence: Consider a research team that needs read access to a cloud storage bucket containing clinical trial data. With traditional Role-Based Access Control, you might grant "Contributor" or "Editor" roles because that's the closest match to their on-premises permissions. Those roles often include write, delete, and share permissions they don't need. When an attacker compromises one account through credential stuffing or phishing, they inherit those excessive privileges.
The fix: Implement Zero Trust Architecture with the Principle of Least Privilege at the resource level. In cloud IAM:
- Grant permissions to specific resources, not broad categories
- Use attribute-based access control (ABAC) to add context: location, device posture, time of day
- Implement Just-in-Time Access for elevated permissions with automatic expiration
- Require multi-factor authentication for any access to sensitive data classifications
Map your cloud permissions to ISO/IEC 27001 control 5.15 (Access control) and 5.18 (Access rights), but apply them at the API and service level.
Mistake 2: Not Inventorying Third-Party Provider Access
You don't actually know which cloud service providers have access to what data, or what their employees can see.
Why it happens: Cloud adoption is decentralized. Your development team spins up a service. Your HR system integrates with a cloud provider. Your marketing team uses a SaaS analytics platform. Each decision makes sense in isolation. Nobody's maintaining a registry of what data each provider can access and under what conditions.
Real consequence: When a breach occurs in a third-party cloud environment, you can't quickly determine exposure scope. You don't know if the compromised environment held protected health information, trade secrets, or both. That delays your notification obligations under HIPAA's Breach Notification Rule (45 CFR §§ 164.400-414) or the General Data Protection Regulation's 72-Hour Notification Requirement. It also means you can't execute effective containment because you don't know what to contain.
The fix: Build a third-party cloud inventory that documents:
- Provider name and service type
- Data classifications stored or processed (map to your data inventory)
- Authentication methods and access controls
- Data residency and sovereignty implications
- Contractual security obligations and audit rights
- Incident notification procedures and SLAs
Update this quarterly and after any new cloud service adoption. Your SOC 2 Type II auditors will ask for it under the "Vendor Management" common criteria.
Mistake 3: Assuming Provider Security Certifications Mean You're Compliant
Your cloud provider has SOC 2 Type II, ISO/IEC 27001, and HITRUST CSF certifications. You think that means your data is secure and you're compliant. It doesn't.
Why it happens: Compliance teams see the provider's certification badges and check the box. But those certifications attest to the provider's controls over their infrastructure, not your configuration of the services you're using on that infrastructure.
Real consequence: You deploy a cloud database with default settings. The provider's ISO/IEC 27001 certification covers their physical security, their change management, their employee background checks. It doesn't cover the fact that you left the database publicly accessible, didn't enable encryption at rest, or used weak authentication. When data gets exfiltrated, your regulators don't care about the provider's certifications. They care about your controls.
The fix: Conduct your own control assessment of your cloud configuration:
- Review the provider's SOC 2 Type II report, specifically the complementary user entity controls (CUECs). These tell you what you're responsible for.
- Map your required controls (HIPAA Security Rule, NIST SP 800-53, ISO/IEC 27002) to your actual cloud configuration, not the provider's capabilities
- Use cloud security posture management tools to continuously validate configuration against your security baseline
- Document your control implementation in your Statement of Applicability or system security plan
The provider secures the cloud. You secure what's in it.
Mistake 4: No Dedicated Incident Response Plan for Cloud Breaches
Your incident response plan was written for on-premises infrastructure. It doesn't address cloud-specific investigation and containment procedures.
Why it happens: Your Computer Security Incident Response Team built runbooks for traditional infrastructure. They know how to isolate a compromised server, image a hard drive, preserve logs from your SIEM. Cloud environments require different tools, different forensic approaches, and different containment strategies.
Real consequence: When you detect unauthorized activity in a cloud environment, your team wastes critical hours figuring out how to preserve evidence without disrupting services. You don't know if you should shut down the compromised instance (destroying volatile evidence) or leave it running (allowing continued exfiltration). You're not sure how to collect logs from the cloud provider's infrastructure. By the time you engage external forensic experts, as Amgen did, the attack has progressed far beyond initial compromise.
The fix: Develop cloud-specific incident response procedures that address:
- Evidence preservation in ephemeral environments (containers, serverless functions)
- Log aggregation from cloud provider APIs and services
- Snapshot and forensic imaging procedures for cloud instances
- Containment strategies that don't destroy evidence (network isolation, API key revocation, IAM policy modification)
- Communication protocols with cloud providers for their investigation support
Test these procedures quarterly with tabletop exercises that simulate cloud-specific attack scenarios: compromised API keys, misconfigured storage buckets, lateral movement through service accounts.
Mistake 5: Not Monitoring for Data Exfiltration at Scale
You're monitoring for intrusion, but not for large-scale data movement out of your cloud environments.
Why it happens: Traditional security monitoring focuses on inbound threats: malware, unauthorized access attempts, vulnerability exploitation. Cloud breaches increasingly involve authorized credentials used to exfiltrate massive amounts of data. Your security tools flag the initial compromise, but miss the slow, steady data theft that follows.
Real consequence: Attackers gain access through compromised credentials. They don't trigger alerts because they're using legitimate authentication. Over days or weeks, they exfiltrate intellectual property, protected health information, and confidential business data. You discover the breach only when the attacker lists your data for sale on the dark web or when you receive a ransom demand.
The fix: Implement data exfiltration detection:
- Set baseline metrics for normal data egress from each cloud environment
- Alert on anomalous data transfer volumes, especially to unusual destinations
- Monitor API calls for bulk download operations (ListObjects, GetObject in AWS S3, for example)
- Implement data loss prevention controls that inspect outbound traffic for sensitive data patterns
- Require approval workflows for large-scale data exports
Integrate these detections into your Security Information and Event Management system and your Computer Security Incident Response Team's escalation procedures.
Prevention Checklist
Before your next cloud deployment or security review, verify:
- Cloud IAM policies implement Principle of Least Privilege at the resource level
- Multi-factor authentication is required for all access to environments containing sensitive data
- Third-party cloud provider inventory is current and documents data classifications, access methods, and incident notification procedures
- You've reviewed complementary user entity controls in provider SOC 2 reports and implemented required controls
- Incident response plan includes cloud-specific procedures for evidence preservation, log collection, and containment
- Security monitoring includes data exfiltration detection with baseline metrics and anomaly alerting
- Cloud security posture management tools continuously validate configuration against your security baseline
- Quarterly tabletop exercises test cloud incident response procedures
The cloud isn't less secure than on-premises infrastructure. But it requires different controls, different monitoring, and different incident response capabilities. Organizations that treat cloud security as an extension of their existing program, rather than a redesign, are the ones that end up filing breach notifications with the SEC.
