Security

Last updated: 11 September 2026

Draft, not reviewed by a lawyer

This document was written to reflect how the software actually works and to cover the obligations a small Canadian software business would normally address. It has not been reviewed by a lawyer, and it should be before this company takes on a material customer. If you are relying on this for anything, talk to us first.

This is a plain account of how we try to keep Sitka secure, written by the person who built it rather than in security-marketing language. It says where our detection capability actually stands today, not where we would like it to be, and it sets out what we do if something goes wrong.

1.What this page is

A plain description of how we try to keep Sitka secure, and what we do if that fails. It is written for a prospective tenant deciding whether to trust us with their clients' information, and it is the process referenced by our Data Processing Agreement.

For the technical measures built into the product itself, see the Security Measures section of our Data Processing Agreement. This page is about what happens around those measures: how we would notice a failure, and what we would do about it.

2.How this is operated

Sitka Systems is operated by one developer. We are telling you that plainly rather than dressing up a one-person security team as something larger. It shapes what is realistic to promise below, and we would rather you knew the real shape of the operation than assume a security desk that does not exist.

3.Detecting a problem

A few things run today without a person watching them:

  • A nightly job enforces the data-retention periods published in our Privacy Policy and emails the operator if any step of it fails, so a silent failure does not stay silent.
  • Our hosting platform's own build and runtime error surfaces are reviewed as part of normal operation.
  • Every write to workspace data is recorded in an append-only audit log, which is the record we would use to reconstruct what happened during an investigation.

Beyond that, detection today relies substantially on us noticing something ourselves, and on reports from tenants and from security researchers. We are working toward continuous automated error monitoring across the application; it is not yet active in production, and we are not going to claim otherwise on this page.

4.Reporting a vulnerability

If you believe you have found a security vulnerability in Sitka, email legal@sitkasystems.ca with enough detail to reproduce it. We do not run a bug bounty program, but we will read every report, acknowledge it, and work on a fix.

Please report a suspected vulnerability privately and give us a reasonable chance to fix it before any public disclosure. Do not access, modify, or exfiltrate another tenant's data to prove a finding; describing how you believe it could be done is enough. Testing carried out in good faith, within these bounds, and reported to us this way will not be treated as a breach of our Acceptable Use Policy.

5.If a breach happens

If we discover, or are told about, an incident that may have exposed personal information, we follow roughly this sequence. It will not be identical every time, because the right response depends on what actually happened, but the shape holds:

  • Contain and assess. Stop the exposure where we can, and work out what happened: which systems and tenants are affected, what categories of personal information were involved, and how it could be misused.
  • Decide whether the real-risk-of-significant-harm threshold under PIPEDA and, for BC tenants, PIPA is met. That threshold, not the mere fact that an incident occurred, is what triggers a formal notification duty under Canadian law.
  • Where that threshold is met, notify the Office of the Privacy Commissioner of Canada and, for BC-based individuals affected, the Office of the Information and Privacy Commissioner for BC, and notify the affected tenants so they can in turn notify their own clients.
  • Keep a record of the incident, including one that falls short of that threshold. PIPEDA requires organizations to keep records of every breach of security safeguards, whether or not it was reportable, for at least 24 months, and we do that regardless of severity.
  • Tell affected tenants directly, in plain language: what happened, what information was involved, what we have done about it, and what we recommend they do.

Our Data Processing Agreement sets out the timing commitment to tenants specifically; this section describes the process behind it.

6.What we ask of the providers we rely on

Sitka is built on infrastructure from a small number of named providers (Anthropic, Leonardo.Ai, Supabase, Vercel, Stripe, Resend, and Google), listed with what each of them sees in our Privacy Policy and our Data Processing Agreement. We do not operate our own data centres; a breach at one of them could become a breach here, and the notification process above applies just the same regardless of where in that chain it originated.

7.Getting in touch

Security reports and questions: legal@sitkasystems.ca. Everything else: legal@sitkasystems.ca.