1. Separation between firms
Each firm's records live in a separate database schema — its own set of tables — rather than sharing tables with every other firm and being told apart by a column.
The difference shows up when something goes wrong. With a shared table, a query that loses its filter returns another firm's clients. With a schema per firm, the same mistake returns nothing. One is a bug; the other is a breach, and the architecture decides which one you get.
Every database connection is pointed at exactly one firm's schema before it can be used, and reset before it is reused.
2. Social Insurance Numbers
SINs are encrypted before they are written to the database, with a key belonging to that firm alone.
Each firm's key is itself encrypted under a master key held outside the database. A copy of the database — a stolen backup, a compromised dump — contains ciphertext and nothing that reads it.
SINs are never written to application logs, are masked on screen unless a user deliberately reveals one, and are excluded from error reports.
3. Documents
Documents your firm and its clients upload are stored in Canada, encrypted at rest, and reachable only through the application with a signed-in session or a single-purpose link.
Client upload links are write-only. Someone holding an upload link can add a file to that client's record and cannot read a single one back — so a link forwarded to the wrong person discloses nothing.
4. Accounts and access
Passwords are stored using Argon2, a memory-hard hashing function designed for exactly this. We never store a password and cannot tell you what yours is.
Sign-in attempts are rate-limited per account and per address. Sessions are carried in a signed, HttpOnly, Secure cookie.
Access to production systems by our own staff requires multi-factor authentication, and any access to a firm's client data is logged in a record the firm can ask for — clause 7 of the Data Processing Agreement sets out the rules.
5. Backups
The database and every document are backed up nightly. Each bundle is encrypted before it leaves our systems, so the storage provider holds ciphertext it has no key for.
A restore is rehearsed monthly against the offsite copy, into a scratch database, and the result is checked rather than assumed. A backup nobody has restored is a hope.
Backups age out on a rolling schedule; a record deleted from the live system is gone from every backup within 90 days.
6. The audit trail
Significant actions are recorded with who did them and when: stage changes, document deletions, exports, signature requests, and changes to who has access.
A closed season becomes read-only. A return filed in a season that has closed cannot be quietly edited afterwards, which is the property that makes the trail worth having.
Electronic signatures carry a certificate recording when the link was opened, from where, and when it was signed, appended to the document itself.
7. Getting your data out
Any client's complete file exports as a zip, and your firm's records export as spreadsheets, at any time and without asking us.
This is a security property as much as a convenience: a firm that can leave in an afternoon is a firm whose data is not hostage to our continued existence.
8. What we have not done
We hold no security certification — no SOC 2, no ISO 27001 — and we have not had a third-party penetration test. We are a small company and those are expensive; we would rather tell you than let you assume.
What we have instead is a small, comprehensible system: five subprocessors, all data in Canada, separation enforced by the database rather than by application code remembering to filter, and backups that are actually restored. If a certification is a requirement for your firm, tell us — it is a question of when, and knowing it is needed changes the order we do things in.
If you find a security problem, write to [contact email]. We will not pursue anyone who reports one in good faith and gives us a reasonable chance to fix it.