When Amgen discovered unauthorized activity in July involving data stored in third-party cloud environments, the biotech firm faced a question every risk manager confronts: who's actually responsible when your vendor's infrastructure gets compromised?
The incident, which involved potential theft of patient information, intellectual property, and confidential business data, highlights a fundamental tension in cloud security. You're expected to protect your data, but you don't control the infrastructure it sits on. So where does your responsibility end and your provider's begin?
Let's examine both sides of this debate, because the answer shapes how you allocate budget, structure contracts, and respond when things go wrong.
Trusting Your Cloud Provider
The argument for relying on your provider's security capabilities is straightforward: you hired specialists for a reason.
Major cloud providers operate security operations centers staffed 24/7, maintain threat intelligence teams, and patch vulnerabilities faster than most internal IT departments can. They hold certifications like SOC 2 Type II and ISO/IEC 27001, demonstrating third-party validated controls. When you migrate to the cloud, you're theoretically upgrading from your on-premises setup to enterprise-grade infrastructure.
This approach aligns with shared responsibility models. Your provider secures the infrastructure layer, network controls, and physical data centers. You focus on identity management, data classification, and application-level security. It's a division of labor that makes sense on paper.
From a resource perspective, you can't match what hyperscale providers invest in security. Building equivalent capabilities in-house means hiring scarce talent, maintaining 24/7 monitoring, and keeping pace with evolving threats. For mid-market organizations especially, that's not realistic.
Your contracts should reflect this trust. Service-level agreements with security commitments, breach notification clauses, and audit rights give you recourse. If your provider fails to meet contractual obligations, you have leverage.
Owning Security Yourself
Here's the problem with trusting your provider: when data gets exfiltrated, you're the one filing with the SEC, notifying patients, and managing the fallout.
Amgen activated its cybersecurity response plan and engaged external forensic experts because the breach was Amgen's problem to solve, regardless of where the data was hosted. The shared responsibility model doesn't share the regulatory consequences.
You can't outsource accountability. Under the Health Insurance Portability and Accountability Act, you remain the covered entity or business associate responsible for protected health information, even when it's stored in someone else's cloud. The General Data Protection Regulation makes you the data controller. NYDFS Cybersecurity Regulation requires you to maintain a cybersecurity program, not just delegate it.
More practically, you know your data better than your provider does. You understand which datasets contain intellectual property worth protecting, which systems process patient information, and which access patterns look normal versus suspicious. Your provider sees storage buckets and compute instances. They don't know that Dataset_2024_Q3 contains five years of R&D on your most valuable compound.
This knowledge gap creates blind spots. Your provider might detect unusual API calls, but they won't recognize that those calls are exfiltrating crown jewel data until you tell them. By then, as in Amgen's case, sensitive files may already be gone.
The access control problem compounds this. Most breaches still trace back to compromised credentials or excessive permissions. Your provider can't enforce the Principle of Least Privilege on your behalf because they don't know which users need access to what. If you grant an account read access to all cloud storage, your provider will honor those permissions, even when a threat actor is using them.
Where Practitioners Actually Land
In practice, most risk managers adopt a trust-but-verify approach that's heavier on the verify side than it used to be.
You start by mapping what's actually in your cloud environments. Not just which services you're using, but what data lives where, who can access it, and how it's classified. This inventory becomes your baseline for monitoring and your guide for implementing controls.
You implement your own logging and monitoring layer on top of what your provider offers. Cloud-native tools give you visibility into API calls, data access patterns, and configuration changes. You're not replacing your provider's security, you're adding detection capabilities tuned to your specific risk profile.
You treat your cloud provider as a business associate under HIPAA or a data processor under the General Data Protection Regulation, which means conducting due diligence, reviewing their SOC 2 reports, and including appropriate contractual protections. But you don't stop there. You audit your own configurations, test your incident response procedures, and maintain the capability to detect and respond to threats independently.
For sensitive data like patient information or intellectual property, you add encryption with keys you control, not keys managed by your provider. You implement Just-in-Time Access for privileged operations. You segment environments so a compromise in one doesn't cascade across your entire cloud footprint.
When an incident occurs, you activate your response plan immediately rather than waiting for your provider to notify you. Amgen's approach demonstrates this: they detected the activity, implemented containment measures, and engaged forensic experts. They didn't wait for their cloud provider to handle it.
Our Take
You can't delegate security to your cloud provider and call it done, but you also can't ignore the security capabilities they bring.
The right model treats your provider as a critical control in your broader security architecture, not as the security architecture itself. You use their infrastructure protections, compliance certifications, and threat intelligence while building your own detection, response, and governance layer on top.
This means investing in cloud security posture management tools, training your Computer Security Incident Response Team on cloud-specific scenarios, and maintaining visibility into your cloud environments that's independent of your provider's dashboards. It means treating cloud access credentials with the same rigor you apply to domain administrator accounts.
When you negotiate contracts, include breach notification timelines shorter than regulatory minimums, audit rights that let you verify controls independently, and clear definitions of what your provider will log and retain. Don't accept boilerplate language about "industry-standard security."
The uncomfortable truth is that cloud security is harder than on-premises security in some ways. You have less direct control, more complex identity and access management, and shared responsibility boundaries that shift depending on which services you're using. But you still own the outcome when something goes wrong.
Amgen's incident underscores this reality. Regardless of where the security gap was, whether in their configurations or their provider's controls, Amgen is managing the response, assessing the impact, and dealing with the regulatory and reputational consequences.
Your job as a risk manager isn't to trust or distrust your cloud provider. It's to build a security program that works regardless of where your infrastructure lives.
