Skip to main content
← Back to blog

Cannabis Cybersecurity Checklist for 2026

Twelve controls, ordered by what actually prevents loss, with the evidence each one should produce. Built for operators who have limited hours and need to spend them well.

By Alex Castrillo9 min readFact-checked September 6, 2026
CannaShield answer page: cannabis cybersecurity checklist for 2026

If you do nothing else this year: enforce phishing-resistant MFA on email and remote access, put a callback procedure on every banking-detail change, segment the POS network, and test a restore. Those four address the losses that actually happen to cannabis operators. The rest of this checklist is the program you build around them.

The short version

  • Ordered by expected loss prevented per hour spent, not by framework numbering.
  • Every item names the evidence it should produce — because the control and the proof are different deliverables.
  • Items 1 through 4 are a weekend. Items 5 through 12 are the rest of the year.

1. Phishing-resistant MFA on email and remote access

Email is where the money is lost. Enforce MFA on every mailbox, with no exceptions for executives — the exception list is the target list.

Prefer app-based or hardware authenticators over SMS. Modern phishing kits proxy one-time codes in real time, so a text message is meaningfully weaker than a passkey or security key. Do not forget service accounts, shared mailboxes, and the VPN.

Evidence: a coverage report showing enrolled accounts versus total accounts, dated, with any exceptions named and justified.

2. A callback rule for every banking-detail change

The single highest-value procedural control in this industry, and it costs nothing.

Any request to change payment instructions — vendor, payroll, loan, anything — gets verified by phone to a number already on file, never a number in the email. Two-person approval above a dollar threshold you set. Write it down, train finance on it, and make it acceptable to slow a payment down.

MariMed disclosed a $646,000 loss to a forged email containing false banking instructions. A callback would likely have caught it.

Evidence: the written procedure, training records for anyone who can initiate payments, and a log of verifications performed.

3. Network segmentation for POS and operational technology

POS and payment devices on their own segment. Guest Wi-Fi fully isolated. Cameras, badge readers, and environmental controls separated from both. The back-office computer that reads email should not be able to reach a POS terminal.

This is configuration work on hardware you already own, and it limits how far any single compromise can travel.

Evidence: a current network diagram with segments labeled, plus firewall rules reviewed and dated.

4. Backups that have actually been restored

A backup job that reports success is not a tested backup. Restore something real — a POS database, a file share, a mailbox — and time it.

Backups need to be encrypted, segregated from production, and protected against deletion by whoever compromises production. Backup administration should use separate credentials with strong MFA, because attackers go for the recovery path first.

Evidence: a restore test record with date, what was restored, elapsed time, and problems encountered.

5. Endpoint detection on every business computer

Managed EDR on every machine, including the back-office desktop everyone forgets and the manager's laptop that goes home.

Consumer antivirus is not the same product category, and underwriters increasingly know the difference. Someone also has to be responsible for looking at the alerts — a tool nobody monitors is a subscription, not a control.

Evidence: device coverage report against your asset inventory, with the gap explained.

6. An asset and data inventory that reflects reality

You cannot protect what nobody has listed. Two inventories: devices, and the systems holding customer or regulated data.

The second one always surprises people. The loyalty platform, the SMS marketing tool, the delivery app, the abandoned e-commerce menu still collecting form submissions — each holds a slice of customer data, and at least one of them was set up by someone who has since left.

Evidence: both inventories, with an owner and a last-reviewed date.

7. A vendor register with security evidence attached

For every vendor touching regulated, personal, financial, or operational data: owner, data handled, access level, contract renewal date, security evidence reviewed and when, and the recovery dependency if they go dark.

Prioritize identity, POS, seed-to-sale, payments, and backups. The STIIIZY incident ran through a point-of-sale vendor, and the operator still owned the notification and the litigation. CISA publishes a template built for small and midsize businesses.

Evidence: the register itself, plus dated review notes.

8. Access reviews and real offboarding

Named accounts for everyone. No shared manager logins. A quarterly review of who can reach POS, seed-to-sale, email, banking, and administrative consoles.

Offboarding needs to be a checklist, not a conversation — POS, email, tracking system, every SaaS tool, VPN, and physical access, same day. The gap between "left the company" and "account disabled" is measured in weeks at most operators.

Evidence: quarterly access review records and completed offboarding checklists.

9. A written information security program

Short and accurate beats long and aspirational. Describe what you actually do, name owners, and version it.

In Connecticut this has a second dimension: the state's safe harbor provisions can limit punitive damages for a qualifying business maintaining a written program conforming to a recognized framework. Whether you qualify is a question for counsel — but it changes the value of writing the thing down.

Evidence: the program document with a version history and an annual review date.

10. An incident response plan with the reporting clocks in it

Not a generic template. Yours, naming your people, with Connecticut's clocks written into the text: DCP policies can require reporting a qualifying security breach by the next business day, with immediate and 24-hour requirements attached to certain record-loss events, while § 36a-701b drives resident and Attorney General notice separately.

Print the one-page contact card. Run one tabletop a year — two hours, around a conference table, no technology required.

Evidence: the plan, the printed card, and tabletop notes with the gaps it revealed.

11. Role-based security awareness training

Annual training for everyone, weighted heavily toward whoever can move money or access customer records. Budtenders need a different twenty minutes than the controller does.

Phishing simulation is useful if you use it to find where you need better procedures rather than to punish individuals. A high click rate on a wire-fraud lure is a finance-process finding, not a personnel one.

Evidence: completion records by role and date.

12. Patch discipline, including the tablets

Inventory every device by model and OS version. Confirm what is still supported. Set patch windows around your busiest hours and document exceptions with a reason and a review date.

Dispensary floor tablets are the usual weak point — frequently running an OS version that stopped getting security updates, frequently constrained by what the POS vendor supports. Get the vendor's supported-version statement in writing so the constraint is documented rather than assumed.

Evidence: a device inventory with OS versions and a patch exception log.

What if we can only do four of these?

Do items 1, 2, 3, and 4, in that order.

MFA and the callback rule address the two ways cannabis operators most often lose real money. Segmentation limits the blast radius of everything else. A tested restore is the difference between a bad week and a closed business. Together they are perhaps a weekend of work plus a conversation with your MSP.

The other eight are how you turn four controls into something you can prove at renewal — but they are worth less than nothing if the first four are missing.

Where to go next

Scope note: This page is practical cybersecurity and GRC guidance for licensed cannabis operators. It is not legal advice, and it does not claim that every recommended control is expressly required by a cannabis regulator. Confirm how each obligation applies to your business with counsel.

Primary sources

About the author

Alex Castrillo

Founder of CannaShield. Working cyber incident response analyst and vCISO for licensed cannabis operators. Writes on cannabis breach analysis, GRC, cyber insurance readiness, and email-spoofing risk.

CannaShield on LinkedIn →

Make the risk concrete.

Start with the free CannaShield Email Security Scorecard to see whether your domain can be spoofed and whether DMARC, SPF, and DKIM are giving attackers room to impersonate your cannabis business.

Run the free scorecard →

Keep sharpening the cannabis security picture.

Compliance & Licensing

Cannabis Data Privacy Requirements by State

A method for reading any state’s obligations, plus what applies in Connecticut, New York, Massachusetts, New Jersey, and Illinois. Verify the details with counsel before you rely on them.

Security Leadership

Do Cannabis Companies Need a CISO?

Most licensed operators do not need a full-time CISO. They do need someone accountable for security decisions. Here is how to tell which one you are.