Security

Isolation: your own instance, not a shared database

Every firm runs on its own dedicated infrastructure — there is no shared application database and no cross-tenant table anywhere.

• A dedicated application container — no shared compute with other firms' requests.
• A dedicated database with its own credentials; a bug in another firm's instance cannot reach yours.
• A dedicated file bucket for documents and uploads, closed to public access.
• A dedicated encryption key (AWS KMS) that only your instance's role can use.

Data residency: Canada

• All service data — application, database, files, and backups — lives in the AWS Canada (Central) region in Montreal.
• Payment processing is handled by Stripe against billing contacts only; client data never goes to Stripe.

Encryption

• TLS for all data in transit.
• Encryption at rest across the database and file storage.
• Field-level encryption for sensitive identifiers — Social Insurance and government ID numbers are encrypted with your instance's dedicated key before they reach the database, so even a raw database leak would not expose them.

Access: no standing access, even for us

• Your firm controls its own users and roles (advisor, manager, owner) inside the instance.
• Multi-factor authentication (authenticator apps + recovery codes) is built in; administrators are required to enrol, and firms can require it for everyone.
• Advirra staff have no standing credentials to any firm's database. Support access uses a break-glass procedure — a recorded reason, credentials that expire automatically, and an audit entry you can ask us about.
• Every administrative and data change in your instance lands in your own audit log, visible to your firm's administrators.

Availability and recovery

• Automated daily backups sized so that no recovery scenario loses more than 24 hours of data (RPO ≤ 24h).
• Restore procedures designed to bring an instance back within 8 business hours (RTO target).
• Fleet-wide health monitoring with paging alerts to the operator, and a public status page that reports incidents.

Secure development and operations

• All changes flow through code review, automated tests, and a staged release train: continuous integration → QA → a canary instance → gradual rollout across the fleet, with automatic halt on failures.
• Secrets live in AWS Secrets Manager, scoped per firm; nothing sensitive is kept in source code.

Compliance posture

• Built to SOC 2-aligned controls, with evidence collected as we operate (access reviews, restore tests, incident records). A formal SOC 2 report is planned when customer demand requires it.
• Our PIPEDA and Québec Law 25 program covers a designated privacy officer, a breach register and notification process, and privacy impact assessments for new processing.
• Firms remain accountable for their own regulatory obligations (e.g. CIRO record-keeping); our retention and export design is built so the Service never becomes the reason a firm can't meet them.

Incident response

• We maintain a written incident-response runbook covering detection, containment, assessment against the PIPEDA/Law 25 “real risk of significant harm” standard, notification of affected firms without undue delay, and a post-incident review.