Security Overview

Encryption

• Everything travels over TLS. HTTP Strict Transport Security is enforced.
• Social Insurance Numbers and direct-deposit bank account numbers are encrypted with AES-256-GCM before they are written to the database, using a key held outside it.
• Uniqueness checks on a Social Insurance Number use a keyed hash rather than a plain one, because there are few enough valid Social Insurance Numbers that an unkeyed hash could be reversed by brute force.
• The database and file storage are encrypted at rest by our infrastructure provider.

Tenant isolation

Every table carrying customer data is protected by row-level security in the database itself, scoped by organisation. Isolation is enforced one layer below the application, so a bug in application code cannot by itself expose one firm’s data to another.

Access control and audit

• Seven roles, from firm administrator down to employee, each with a defined set of permissions.
• Sign-in is by emailed one-time code; passwords are a secondary option.
• Reading a decrypted Social Insurance Number is recorded as a distinct audit event with the user, timestamp, IP address and user agent. That log is what lets a firm answer “who looked at this record”.
• Creates, updates and deletes on customer records are recorded with before and after values.

Documents

Uploaded files live in a private bucket. They are never publicly addressable; access is through short-lived signed links issued to an authenticated user with rights to that client.

Application hardening

• A Content Security Policy, and framing denied outright, so the application cannot be embedded and clickjacked.
• Input validated at every server boundary before it reaches business logic.
• Database access is parameterised throughout; no query is assembled by string concatenation.
• Rate limiting on authentication and other sensitive endpoints.
• Diagnostics are scrubbed of Social Insurance Numbers before leaving our systems, and error reporting is configured never to attach request bodies, cookies or headers.

Hosting

Customer data is currently held in the United States. The full provider list, and what each receives, is on the Subprocessors page. We are moving to Canadian regions and will update that page when it is done.

Backups and recovery

The database is backed up on our provider’s managed schedule with point-in-time recovery, and we maintain a written restore procedure. Backups age out on their own cycle and are not selectively edited.

Incidents

We keep a register of confidentiality incidents. Where a breach creates a real risk of significant harm we notify the relevant regulators and affected individuals, and we notify the affected firm without undue delay so it can meet its own obligations. See the Data Processing Addendum.

Reporting a vulnerability

Tell us through the contact page. We will not pursue a researcher who reports a genuine vulnerability in good faith and gives us a reasonable opportunity to fix it before disclosure.