CANOPY LEDGER

Draft, pending legal review

Security at Canopy Ledger

Last updated: [EFFECTIVE DATE]

Cannabis businesses trust us with their operational records. This page explains, in plain language, how we protect that information. It is a general overview, not a contractual commitment; our obligations to customers are set out in our Terms of Service and any agreement we sign with you.

Certifications: Canopy Ledger does not currently hold SOC 2, ISO 27001, or any other third-party security certification or attestation. We will update this page if that changes.

Where your data lives

  • The Canopy Ledger web application is hosted on Vercel.
  • Customer data is stored in a Neon Postgres database located in the United States.
  • The Service currently runs as a single-customer deployment: each deployment has one database, and there is no separation between customers inside it. [UPDATE THIS LINE, AND DPA ANNEX 2, BEFORE SERVING MORE THAN ONE CUSTOMER FROM THE SAME DEPLOYMENT.]

Both providers operate their own security programs. You can review their security documentation on their websites.

Encryption

  • In transit: Connections to Canopy Ledger use HTTPS (TLS) encryption, as provided by our hosting provider's default configuration. Connections between our application and our database are also encrypted in transit.
  • At rest: Data stored in our database is encrypted at rest using our database provider's default encryption.

Access controls

  • The Service does not yet have individual user accounts or passwords. Access to the current deployment is restricted at the hosting layer (Vercel Deployment Protection), not by an in-app sign-in. In-app roles control which menus people see; they are not a security boundary. [UPDATE THIS LINE WHEN PER-USER SIGN-IN SHIPS.]
  • Access to production systems and customer data by our team is limited to personnel who need it to operate, support, or secure the Service, and is granted on a least-privilege basis.
  • We do not access the contents of a customer's account except as needed to provide support the customer requests, to maintain or secure the Service, or as required by law.

Custom scripts

Customers can write custom JavaScript that runs on record events (such as before or after a record is saved). These scripts run in a separate V8 isolate (using the isolated-vm library) with a 32 MB memory limit, a 1-second execution limit (with a 1.5-second hard stop), and a 20,000-character source limit. Scripts have no direct access to the file system, network, or server modules, but they can read and change Customer Data through the script interface. This isolation reduces risk but is not a guaranteed security boundary, so only trusted staff should be allowed to write or enable scripts. We may suspend a script that threatens the security or stability of the platform. Customers are responsible for the logic and results of their own scripts, so we recommend testing scripts before relying on them in live operations.

Backups and recovery

We rely on our database provider's built-in backup and point-in-time recovery capabilities to help protect against data loss. The restore window depends on our database plan: [RESTORE WINDOW]. We also encourage customers to periodically export their own records, especially records they are required by law to retain.

Incident response

If we become aware of a security incident that affects customer data, we will investigate, take steps to contain it, and notify affected customers as required by law and our agreements.

What you can do

  • Only give access to people who should be able to see all of your data (there are no per-user accounts yet).
  • Tell us promptly when someone should no longer have access, so we can remove it.
  • Review and test custom scripts before enabling them.
  • Export and retain copies of records you are legally required to keep.
  • Contact us right away if you suspect unauthorized access to your account.

Responsible disclosure

If you believe you have found a security vulnerability in Canopy Ledger, please let us know. Email [CONTACT EMAIL] with:

  • a description of the issue and where it occurs;
  • steps to reproduce it; and
  • any proof-of-concept details (please do not include real customer data).

We ask that you:

  • give us a reasonable amount of time to investigate and fix the issue before sharing it publicly;
  • only test against accounts you own or have permission to test;
  • avoid accessing, modifying, or deleting other people's data;
  • avoid degrading the Service (no denial-of-service testing, spam, or social engineering of our staff or customers); and
  • do not use custom scripts to attack the script isolate or platform beyond what is needed to demonstrate the issue.

We will acknowledge your report, keep you updated on our progress, and will not pursue legal action against researchers who act in good faith and follow these guidelines. We do not currently offer a paid bug bounty.

Questions

For security questions, contact [CONTACT EMAIL].

[COMPANY LEGAL NAME], [BUSINESS ADDRESS]