Case Study: How SOC 2 Mistake Costed Drizly $1B in Damages
By Ramyar Daneshgar
Security Engineer | USC Viterbi School of Engineering
Looking for a security engineer? Visit SecurityEngineer.com
Disclaimer: This article is for educational purposes only and does not constitute legal advice.
Executive Summary
In 2020, Drizly—a fast-growing alcohol delivery startup—suffered a breach that exposed the personal information of 2.5 million customers. Although the company publicly claimed to maintain "industry-leading security standards," an FTC investigation revealed fundamental failures across areas that directly map to SOC 2’s Trust Services Criteria.
This case serves as a critical warning: having policies that look like SOC 2 controls is not enough—those controls must be operational, enforced, and auditable. In this analysis, we unpack what went wrong, how it violated core SOC 2 principles, and why Drizly’s CEO became personally liable for the company’s failures.
Company Overview
- Company: Drizly, Inc.
- Founded: 2012
- Industry: Alcohol e-commerce / delivery
- Acquired by: Uber Technologies in 2021 for $1.1 billion
- Security Commitment (Pre-Breach): Publicly stated use of "industry-standard security"
Timeline of Events
| Date | Event Description |
|---|---|
| April 2018 | A Drizly executive is granted GitHub repo access for a hackathon. Access remains active for two years. |
| 2018–2019 | An engineer commits AWS credentials to a personal GitHub repository. |
| 2018 | Drizly’s AWS environment is compromised and used for cryptojacking. |
| July 13, 2020 | Drizly discovers a new compromise involving GitHub access and AWS credentials. |
| July 28, 2020 | Public breach notification issued. 2.5 million records exposed. |
| October 2022 | FTC issues proposed enforcement order against Drizly and CEO James Cory Rellas. |
| January 2023 | FTC finalizes order—mandates data minimization, ongoing audits, and executive accountability. |
What Data Was Exposed?
- Full names
- Email addresses
- Date of birth
- Postal addresses
- Phone numbers
- Last four digits of payment cards
- Order history and geolocation metadata
This data was later found listed on underground forums.
Root Cause: SOC 2 Failures in Practice
Despite Drizly’s public-facing security claims, the breach stemmed from fundamental control breakdowns—many of which would have been flagged or mitigated through consistent SOC 2 implementation.
1. Access Control (CC6.2, CC6.3)
- GitHub access was not reviewed or revoked for an employee who left the company.
- No multi-factor authentication (MFA) was required for GitHub or AWS access.
- No quarterly access reviews were documented.
SOC 2 Expectation: RBAC enforcement, periodic access reviews, MFA on privileged accounts.
2. Change Management (CC8.1)
- AWS credentials were committed to GitHub without approval or peer review.
- There was no documented change management process for code pushes or configuration changes.
SOC 2 Expectation: All production changes must follow a documented approval process with clear audit logs.
3. Security Monitoring & Detection (CC7.1 – CC7.4)
- The initial cryptojacking incident (2018) indicated a failure in monitoring infrastructure logs and alerting.
- The 2020 intrusion occurred despite previous warnings, showing no improvement in incident response or log analysis.
SOC 2 Expectation: Organizations must detect and respond to anomalous activity in real-time.
4. Governance & Accountability (CC1.1 – CC1.2)
- Drizly lacked a dedicated CISO or data protection officer.
- The FTC cited a failure to assign security responsibility and to oversee policy implementation.
SOC 2 Expectation: Security governance must be documented, assigned, and enforced at the leadership level.
Regulatory Outcome
FTC’s final enforcement order held CEO James Cory Rellas personally accountable, citing a pattern of negligence and failure to enforce basic security practice.
Key requirements of the order included:
- 20-year obligation for Drizly to implement and maintain a comprehensive security program
- CEO Rellas is personally bound to implement similar controls in any future role involving consumer data
- Mandatory biennial third-party security assessments, similar in scope to SOC 2
- Data minimization: collect and retain only what is strictly necessary
- Deletion of data not tied to ongoing user accounts or regulatory requirements
This is one of the first cases where executive liability was explicitly codified into a data security enforcement order.
Key Lessons Summary
| Lesson | SOC 2 Alignment | What Drizly Missed |
|---|---|---|
| Access must be tightly controlled and reviewed | CC6.2, CC6.3 | No revocation process, no MFA |
| Credential leakage must be monitored and enforced | CC7.1 – CC7.4 | No detection on credential exposure |
| Change management is a frontline defense | CC8.1 | No PR approvals or peer validation |
| Security is a board-level function | CC1.2 | No formal ownership or escalation structure |
| Breaches from past events must inform future controls | CC4.1 | Prior cryptojacking incident was not remediated systemically |
Closing Thoughts
Drizly’s breach is not just a story about missing controls—it’s a case study in the gap between policy and practice. For any company pursuing SOC 2, the lesson is clear:
Achieving compliance means nothing unless controls are continuously enforced, monitored, and adapted as the company evolves.
Whether you’re an early-stage SaaS company or an enterprise compliance officer, Drizly’s story is a reminder: security controls don’t fail—people do when enforcement stops.
Looking for a security engineer? Visit SecurityEngineer.com
Need a Cybersecurity Attorney?
Get top legal guidance in breach response, data privacy, and cybersecurity compliance. Connect with attorneys who know how to defend against audits, investigations, and liability.
👉 Hire a Cybersecurity Attorney