Skip to content
CanShip

Security & Compliance

CanShip holds your inventory, your orders, your customers' shipping addresses and your carrier credentials. This page sets out how we protect them, as things stand today. If you need more detail for a security review, email security@canship.co.

Where your data lives

CanShip runs on Amazon Web Services in the Canada (Central) region, ca-central-1, in Montreal. That covers the application database (Aurora PostgreSQL), file storage, backups and application logs.

Some AWS services sit outside that region by AWS design. The web application firewall in front of our CDN and the certificate for our status page are in AWS's US East region, and our AWS account activity log (CloudTrail) is multi-region.

These services receive customer data and may process it outside Canada:

  • Card payments are processed by Stripe. Card details are tokenized by Stripe and never reach CanShip's servers in raw form.
  • Email is sent through Amazon SES. Email metadata may pass through AWS infrastructure outside ca-central-1 on its way to you.
  • Carriers and sales channels. When you rate or buy a label, the shipment details and ship-to address go to the carrier or service you connected (for example UPS, ShipStation or Stallion Express). Sales channels you connect exchange order data with CanShip under their own terms.
  • US duty prepayment. For Canada Post shipments to the US, customs declarations and recipient details go to Zonos to calculate and prepay duty.

Encryption

  • In transit: TLS 1.2 or higher, from your browser to CanShip and between our services and the database.
  • At rest: the database is encrypted with AES-256 under an AWS-managed KMS key. Database backups are encrypted the same way.
  • Carrier and sales channel credentials: encrypted a second time with AWS KMS envelope encryption. Only the functions that need a credential are granted the key to decrypt it.

Access controls

  • Sign-in uses AWS Cognito. Refresh tokens are kept in HttpOnly cookies that page scripts can't read.
  • Roles: Admin has full access. Staff does the day-to-day warehouse work, without user management or billing. Customer is a read-only login for a 3PL's client, limited to the clients it's assigned to.
  • Two-factor authentication with an authenticator app is required on every Admin account, and the server enforces it on every request. Staff and Customer users can turn it on too.
  • Passwords: 12 characters minimum, with complexity rules. We don't force periodic password changes, which tend to produce weaker passwords; we rely on two-factor authentication instead.
  • Tenant isolation: every query on customer data is scoped to your company. A static check blocks a merge or a release when a query against a company-scoped table is missing that scope. On 2026-09-30 it scanned 444 files and found 0 violations. It is a static check with documented exceptions, not a formal proof.
  • Our own access: access to production infrastructure is limited to two named people and requires multi-factor authentication. The database is not reachable from the public internet.

Audit trail

  • Every change to stock, allocations and holds is written to an audit trail by the database itself (PostgreSQL triggers), with the time and the quantities before and after.
  • You can review it in CanShip under Reports, on every plan.

Testing and monitoring

  • Penetration testing: three rounds of internal penetration testing, run by our own team in April 2026. Every finding was fixed, including an authentication bypass, IAM role privilege separation, and the database TLS certificate bundle.
  • Security scans on every change: secret scanning (TruffleHog), dependency vulnerability scanning (npm audit) and static analysis (Semgrep) run on every pull request and every release. A finding blocks the merge.
  • AWS monitoring: Amazon GuardDuty watches the AWS account for threats, and Amazon Inspector scans our compute for known vulnerabilities.
  • Edge protection: public endpoints sit behind CloudFront and AWS WAF managed rule sets, with rate limits per route.

Shopify customer data

  • Shopify classes the name, address, phone and email on an order as Protected Customer Data. CanShip uses it to fulfil the order and for nothing else. We don't sell it or use it for advertising.
  • We request only the Shopify access scopes fulfilment needs.
  • Erasure requests from Shopify (customers/redact and shop/redact) erase the ship-to personal data automatically. Data access requests (customers/data_request) are handled by a person within Shopify's 30-day window.

Full details are in our privacy policy, section 11.

Privacy and compliance

  • PIPEDA: CanShip is operated by My Passion Media Inc., a British Columbia corporation, and handles personal information under PIPEDA. How long we keep each kind of data is in section 8 of our privacy policy.
  • SOC 2: CanShip does not hold a SOC 2 report.
  • Data Processing Agreement: available on request from legal@canship.co.

Incidents

  • We keep a written incident response plan with severity levels, escalation paths and notification steps.
  • If a security incident affects your data, we tell you directly, without unreasonable delay once we know its scope, and sooner if you need to act. We report to the Office of the Privacy Commissioner of Canada as PIPEDA requires.
  • Live service status and incident history: status.canship.co

Reporting a vulnerability

If you've found a security issue in CanShip, email security@canship.co with the details. It opens a ticket with our team. We don't run a bug bounty program.

Security reviews

Larger 3PLs and brands often have their own security questionnaire. We're happy to fill it in, share our incident response plan and data handling policy, or walk through the architecture on a call. Email security@canship.co or book a demo.