The economics of cloud computing are compelling even for small cannabis operators: no on-premises servers to maintain, automatic backups, scale-as-you-grow infrastructure, and software-as-a-service compliance tools that run in someone else’s data center. But “someone else’s data center” is where many cannabis operators get into trouble.
Cloud migrations in cannabis create a specific set of risks that general-purpose cloud security guides don’t address: state-level data residency requirements, METRC API integrations that weren’t designed for cloud security models, Schedule 8 / Schedule I data sensitivity, and the unique liability exposure of a federally illegal industry storing its records on infrastructure operated by companies with federal government contracts.
This guide covers what cannabis operators need to understand before — and after — moving their data to cloud platforms.
The Shared Responsibility Model (And Why It Bites Cannabis Operators)
Every major cloud provider operates on a shared responsibility model. The cloud provider secures the underlying infrastructure (data centers, physical security, network hardware). The customer — your dispensary or cannabis business — is responsible for everything inside the cloud: your data, your configurations, your access controls, your encryption settings.
This model catches cannabis operators off guard because it means:
The cloud provider will not protect your misconfigured S3 bucket. AWS, Azure, and GCP have extensive security tools available, but none of them default to maximum security. An S3 bucket that stores compliance audit logs is publicly accessible by default until someone configures it to be private. Cannabis operators — often with limited IT staff — frequently miss these configurations.
The cloud provider cannot detect your insider threat. A manager-level employee with legitimate access to your cloud console can exfiltrate customer data without triggering any native cloud provider alerts unless you’ve specifically configured logging and alerting.
The cloud provider’s BAA may not cover your cloud footprint. If you handle patient health information (medical cannabis states), you may need a HIPAA Business Associate Agreement (BAA) from your cloud provider. AWS, Azure, and GCP all offer BAAs, but you must specifically request and sign them — and they only cover specific services. Running patient data on a service outside the BAA scope creates HIPAA exposure even if you have a BAA for other services.
Common Cloud Security Failures in Cannabis
Misconfigured Storage (The Most Common Cause of Cannabis Data Breaches)
Public-facing cloud storage buckets containing sensitive data are the single most common cause of healthcare and regulated-industry data exposures. In cannabis, this manifests as:
- S3 buckets or Azure Blob Storage containers holding METRC reports, audit logs, or customer records — not set to require authentication
- Shared links to compliance documents that never expire and can be enumerated
- Backup files (database dumps, CSV exports) stored in cloud storage without encryption
Fix: Implement a cloud security posture management (CSPM) tool — AWS Security Hub, Microsoft Defender for Cloud, or GCP Security Command Center are native options. Enable it, review findings weekly. Block public access at the account level and require all storage to be private by default.
Overprivileged IAM (Identity and Access Management)
Cloud IAM controls who can do what in your cloud environment. Cannabis operators frequently grant admin-level access to everyone who “needs to see the system” rather than scoping permissions to the minimum required.
Consequences:
- A breached employee account can destroy or exfiltrate your entire cloud environment
- Terminated employees retain access if offboarding procedures don’t include cloud access revocation
- Contractors with broad access can move data outside your control
Fix: Implement the principle of least privilege. Compliance staff need read access to compliance data — not the ability to create new cloud resources or access customer databases. Use role-based access control (RBAC) and review permissions quarterly. Require MFA for all IAM users, especially those with any write permissions.
Logging Gaps
Cloud platforms generate rich audit logs — but only if you turn them on. AWS CloudTrail, Azure Activity Log, and GCP Cloud Audit Logs are the services that capture who did what in your cloud environment. Without them, you have no ability to reconstruct what happened during a security incident, and no way to demonstrate compliance to regulators.
Many cannabis operators run cloud environments for months or years without enabling audit logging, then discover the gap only when an incident requires forensics.
Fix: Enable CloudTrail (AWS), Activity Log + Microsoft Sentinel (Azure), or Cloud Audit Logs (GCP) in all regions from day one. Set retention to align with your data retention requirements — at minimum 90 days, ideally 1 year. Forward logs to a SIEM or at minimum to a separate storage account that your primary cloud account cannot modify.
Unencrypted Data at Rest
Cloud storage and databases are often not encrypted by default — or are encrypted with provider-managed keys that provide minimal protection against insider threats. For medical cannabis patient data, HIPAA requires encryption. For consumer cannabis data, state privacy laws increasingly imply encryption as part of “reasonable security.”
Fix: Enable encryption for all cloud storage and databases. Use customer-managed keys (CMK) for sensitive data where you control key rotation and revocation. AWS KMS, Azure Key Vault, and GCP Cloud KMS are purpose-built for this.
State Cannabis Data Residency Requirements
Several states have data residency or sovereignty implications for cannabis data that affect cloud architecture:
California (CCPA/CPRA): No explicit residency requirement, but businesses must be able to fulfill consumer rights requests (access, deletion, portability). Your cloud architecture must support this. If patient data is sharded across regions and you can’t locate it in response to a data subject access request, you’re out of compliance.
New York: New York’s SHIELD Act and the proposed NY Privacy Act impose security requirements for any data about New York residents. Cannabis businesses operating in New York should be aware that these obligations follow the data, not the company’s headquarters.
Colorado: Colorado Privacy Act (CPA) applies. Cannabis operators handling sensitive data — which includes financial information — have enhanced obligations including data protection assessments.
Massachusetts: Massachusetts 201 CMR 17 requires encryption for personal data transmitted over public networks and stored on portable devices. This applies to cannabis data stored in cloud environments if transmitted without TLS or stored without encryption.
Federal contractor implications: AWS, Azure, and GCP all have U.S. government cloud segments (AWS GovCloud, Azure Government, GCP Assured Workloads). If you’re using a standard commercial cloud region, your data may technically reside on the same infrastructure used by federal agencies — an irony given cannabis’s federal status. For most operators this is a non-issue practically, but it’s a compliance conversation worth having with legal counsel if you’re in a highly regulated medical state.
METRC API Security in the Cloud
METRC is the most widely used seed-to-sale tracking system, and most operators integrate METRC via API with their POS or compliance systems. In cloud environments, this integration creates specific risks:
API key exposure: METRC API keys grant access to your entire compliance record in METRC’s system. If stored in plain text in cloud environment variables, configuration files, or version control, they’re exposed to anyone with access to your cloud environment.
Fix: Store METRC API keys in a cloud secrets manager — AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager. Rotate keys quarterly. Never commit API keys to version control.
Webhook security: If your METRC integration uses webhooks (callbacks from METRC to your system), ensure your cloud endpoint is behind authentication and validates request signatures. An unauthenticated webhook endpoint can be abused to inject false compliance data.
Audit log integrity: In cloud environments, METRC integration logs should be stored in immutable logging systems — not editable by any application or user. This protects against both accidental corruption and deliberate tampering.
Choosing a Cloud Region: Cannabis Considerations
For most small operators, region selection is driven by latency (choose a region near your users). But there are compliance considerations:
Data processing agreements: GDPR and similar regulations require that personal data transferred outside certain jurisdictions have appropriate legal protections. If you’re a multi-national cannabis operator (Canada + US, or EU + US), you need data processing agreements covering cross-border transfers.
State attorney general jurisdiction: Some state AGs are aggressive about data privacy enforcement. Storing data in a cloud region doesn’t change which state’s laws apply — your obligations follow your customers and employees, not your servers.
Disaster recovery: Choose a secondary cloud region for backup/DR that’s geographically separated from your primary. A cloud outage affecting a single region should not take down your compliance record-keeping capability.
Cloud Security Checklist for Cannabis Operators
Before migration:
- Inventory all data to be moved to cloud — classify by sensitivity (public, internal, confidential, PII, health data)
- Sign BAA with cloud provider if handling medical cannabis patient data
- Map cloud services to data types — which services will hold which data categories
Day-one configurations:
- Block all public access to cloud storage at account level
- Enable audit logging in all regions (CloudTrail/Activity Log/Cloud Audit Logs)
- Enable encryption for all storage and databases using customer-managed keys for sensitive data
- Require MFA for all IAM users
- Store all API keys (METRC, POS integrations) in secrets manager — never in code or environment variables
Ongoing:
- Enable CSPM tool and review findings weekly
- Conduct quarterly IAM access reviews — remove departed employees immediately
- Rotate API keys quarterly
- Test backup restore procedures at least annually
- Review cloud provider’s compliance certifications (SOC 2, ISO 27001, FedRAMP) and confirm your services are in-scope
Vendor Due Diligence for Cloud-Based Cannabis SaaS
Most cannabis operators don’t build custom cloud infrastructure — they use cloud-hosted SaaS platforms for POS, METRC integration, loyalty programs, and compliance tools. Asking the right questions of vendors:
- Which cloud provider and regions do you use?
- Do you have a SOC 2 Type II report? May I see it?
- How do you encrypt our data at rest and in transit?
- What is your breach notification SLA? (Should be 72 hours or less for GDPR-adjacent compliance)
- How do we retrieve and delete our data if we terminate the relationship?
- Do you subcontract data processing to any fourth parties? Who are they?
A vendor who can’t answer these questions clearly is a vendor whose cloud security posture you cannot trust.
Cloud adoption in cannabis is accelerating — and done right, cloud infrastructure offers better security than most operators could achieve with on-premises equipment. But “done right” requires active configuration, not passive trust in the cloud provider. The shared responsibility model is only shared if you carry your half.
See our Cannabis Cybersecurity Hardening Guide for on-premises security controls that complement a cloud strategy.
