Security at Asurnd
An SR&ED claim is built from a company's most sensitive material: what it is inventing, what it spent, and who it pays. We designed the platform around that, and this page says what we actually do rather than what we aspire to. Where something is on the roadmap rather than in place, it says so.
1. Principles
- Fail closed. If a permission check, a configuration value, a budget or a safety check is missing or ambiguous, the action does not happen.
- Least data. We collect what the claim needs, and we ask clients to leave out what it does not (no SINs, bank details or health information).
- Least privilege. Invitation-only accounts, role-based permissions, read-only integrations, scoped provider keys.
- Evidence of method. The same audit ledger that defends a claim also records who did what on the platform.
2. Where data lives
| Component | Region |
|---|---|
| Database, authentication, file storage | Canada |
| Application, API and background workers | Canada |
| Daily backups of files and database | Canada |
| Transactional email | Canada |
| Text extraction, OCR, search embeddings (local models) | Canada |
| Large language model (opt-in per client) | United States |
| Marketing site (no client data) | Global edge network |
The providers behind each row, and the countries involved, are listed in the Privacy Policy, as privacy law requires. A full sub-processor list with contract terms is available to clients on request at security@asurnd.ca.
3. Client isolation
Every table that holds client data carries the identifiers of the firm and the client it belongs to. The API builds a client scope from the signed-in person's membership before any read or write, and every query runs inside that scope. Row-level security in the database enforces the same boundary a second time, so a bug in the application cannot reach across clients. Search indexes, file paths and AI prompts are all built within a single client's scope; the code refuses to assemble a prompt that would mix two clients.
4. Access control
- Invitation only. There is no self-service sign-up. An administrator invites each person to a specific firm or client with a specific role, and the invitation goes only to that address.
- Roles. Firm admins, senior consultants, consultants, and client contacts each see and do only what their role allows. Client contacts see their own company's workspace and nothing else.
- Passwords. Password sign-in with checks against known leaked-password lists; one-time, expiring links for invitations and resets. Sessions are held in secure, HTTP-only cookies.
- Two-step sign-in (multi-factor). Required for everyone who signs in with a password or an emailed link: a 6-digit code from an authenticator app, checked by both the web app and the API. "Continue with Google" is also available and relies on Google's own two-step sign-in; access is still by invitation only. An administrator can reset two-step sign-in for a lost phone, and the reset is recorded.
- Agreement to terms. Every sign-in asks the person to agree to the Terms of Use and Privacy Policy, and the agreement is recorded with its version and time; if it cannot be recorded, the person is not signed in. The platform refuses any session without a recorded agreement to the current version, so when the terms change, everyone agrees again at their next action.
- Our team. Access to production is limited to named engineers over SSH keys; platform-admin actions are logged. There is no shared account.
5. Encryption and infrastructure
- TLS 1.2+ for every connection, with HTTP Strict Transport Security; the API is never exposed without it.
- Encryption at rest for the database, file storage and backups.
- Uploaded files live in a private bucket; they are served only through short-lived, signed URLs issued inside the caller's client scope, never from a public path. Each file is stored under its content hash and verified against it on backup.
- Security headers (content-type sniffing off, frame embedding restricted, strict referrer policy) on every response.
- Secrets are injected from configuration, never committed; every provider key is scoped to the one job it does.
6. AI safeguards
- Off by default, per client. AI calls check the client's consent flag first and do nothing if it is off. Turning it on requires a written consent note and is recorded in the ledger.
- Not used for training. Content sent to the model provider is covered by terms that prohibit training on it and limit how long it is retained.
- One client per request. A prompt can only be assembled from a single client's scope.
- Citations we can verify. Drafts cite evidence by identifiers our own tools returned; identifiers produced by the model are rejected, so a draft cannot point at evidence that does not exist.
- Untrusted input. Document text is treated as data, not instructions; the model cannot act on the platform, only return text.
- Budgets. A hard daily token budget per firm; the call fails closed when the limit is reached.
- Human sign-off. A senior consultant's recorded approval is required before anything is filed or sent. There is no code path around it.
7. Connected services
Integrations (today, GitHub) are read-only and installed by the client with the narrowest scope the service offers. We import metadata and the records the claim needs, not whole repositories. We store no long-lived tokens: access uses short-lived GitHub App installation tokens, and each installation is bound to exactly one client. Uninstalling the app on GitHub ends our access.
8. Audit trail and backups
- An append-only ledger records uploads, status changes, approvals, access grants, consent changes and administrative actions, with who and when. Status changes go through a state machine; there is no way to set a status directly.
- The database is backed up nightly by the hosting provider, with seven days of restore points. Files are copied daily to a server in Canada, checked against their hashes; a deleted file is kept for 30 days and then removed. A backup run that fails raises an alert.
- Logs carry counts and identifiers, not client content. Sign-in links are never logged.
9. Development practices
- Strict typing, automated tests on every change, and database constraints that mirror the application's rules.
- Code review before merge; dependency updates tracked; third-party code and its origin recorded.
- Any new service that would receive client data outside Canada must be documented and disclosed before it is used.
- A written threat model and security design maintained alongside the code.
10. Incident response
We have a written incident process: contain, assess, notify, fix, and review. Clients are told about any incident that affects their workspace. Where a breach creates a real risk of significant harm, we notify affected individuals and the Office of the Privacy Commissioner of Canada (and the Commission d'accès à l'information du Québec where it applies) as soon as feasible, and keep the records the law requires.
11. Compliance and frameworks
We are a small firm and do not yet hold a third-party certification. Our controls are designed against the following, and we are honest about which is which:
| Framework | Status |
|---|---|
| PIPEDA (federal privacy law) and its ten fair information principles | In place; see the Privacy Policy |
| Quebec Law 25 (privacy officer, breach register, PIA before cross-border transfer) | In place; a PIA is carried out before AI is enabled for a Quebec client |
| CASL (anti-spam) for all email we send | In place: transactional email only, no marketing lists |
| CPCSC / NIST SP 800-171 control families (access control, audit, identification, system integrity, incident response) for clients who supply the Department of National Defence | Aligned by design; formal CPCSC assessment not undertaken |
| SOC 2 Type I | On the roadmap |
Clients who need to complete a vendor security questionnaire, or want the detailed version of this page, can write to security@asurnd.ca.
12. Reporting a vulnerability
If you believe you have found a security issue in the platform or the website, email security@asurnd.ca with enough detail to reproduce it. We acknowledge reports within two business days and keep you informed until the issue is resolved. Please do not access, change or keep any client data beyond what is needed to show the issue, and do not test with denial-of-service or social-engineering techniques. We will not take legal action against research that follows these rules.