Trust & security
The platform handles renewal data, claims experience, and plan-member coverage for Canadian group benefits firms. This page is the single source for "is it safe to put our group on this?" — point a procurement contact here and they can self-serve answers to most security questionnaires.
Cross-firm access
Day to day, every firm sits in its own tenant — separate queries, separate auth, no cross-firm reads. The harder question is what happens during support: when a problem in your data needs an engineer to look. blankit's answer is a read-only impersonation session with client identities replaced by deterministic pseudonyms (e.g. Client-A4F2) the moment the session starts.
Client-XXXX across pages and sessions, so a support conversation can reference a specific case without exposing identity.The screenshot on the right is an actual support session. The banner along the top makes the read-only state unmistakable, and the body of the page shows what we see — your reminders and renewal pipeline rendered through the mask.
Every part of the application runs in AWS Canada (Central) — Montreal region. Compute (ECS Fargate), database (RDS PostgreSQL), object storage (S3), and secrets (KMS) are all provisioned in ca-central-1. The application itself, every byte of client data at rest, and every backup live in Canada.
Blankit Health Inc. is a Canadian company. No US parent, no offshore operations.
All Claude AI calls go through AWS Bedrock under the AWS DPA. Bedrock entry points are in ca-central-1, but AWS no longer accepts on-demand invocation of any Claude 4.x model (Haiku, Sonnet, or Opus) from a single region — every call is routed through an AWS `global.*` inference profile, which AWS sends to a region with capacity (in practice, US regions). All AI inference is covered by the AWS Customer Agreement and AWS DPA; Anthropic does not see the data. We will switch to `ca.*` profiles the moment AWS publishes them. Disclosed on the sub-processors page.
Built around PIPEDA principles from day one — purpose limitation, accountability, individual access. Consent records are stored per-plan-member for the chatbot and CI enrolment flows, with explicit purpose statements.
A designated Privacy Officer is publicly listed. Quebec French is supported end-to-end in plan-member deliverables. The Subject Access Request flow resolves access and portability requests within the 30-day Law 25 window. A Privacy Impact Assessment template governs new features that touch personal information.
Every category of personal information the platform processes is inventoried in our internal RoPA — source, purpose, retention period, sub-processors, transfer mechanism. Available to firms under NDA.
The complete list of third parties that process any personal information on our behalf — with location, purpose, and transfer mechanism — is published publicly. Firms are notified at least 30 days before a new sub-processor enters the production data path.
Engineering practices follow the SOC 2 Trust Services Criteria for security, availability, and confidentiality. Type I attestation is being prepared with a Canadian auditor; Type II observation begins immediately after. Ask for the current audit-readiness summary if procurement needs it before the audit window closes.
HTTPS-only at the application load balancer (TLS 1.2 or higher). RDS storage encryption enabled. S3 buckets enforce server-side encryption with KMS-managed keys and block all public access. Secrets stored in AWS Secrets Manager — never in source.
Two distinct session systems — one for advisors and firm admins (JWT cookie with short TTL), one for plan-member portal users (hashed bearer tokens). Cross-session access is impossible by design — portal users cannot read advisor data, and vice versa.
Every model in the schema is firmId-scoped. The data-access layer enforces tenant filtering at the query layer, so a coding mistake in a route handler cannot leak data between firms.
Available for every advisor account. Required for accounts with admin privileges. TOTP secrets are encrypted at rest with an AES-GCM key held separately from the database.
Every advisor action that touches personal information or runs a privileged operation is recorded — who, what, when, from where. Logs are retained for seven years and are immutable from the application surface.
Target service-level objective is 99.9% monthly availability — about 43 minutes of allowed downtime per month. ECS Fargate runs two or more tasks behind an Application Load Balancer with health checks; deployments are zero-downtime rolling updates with automatic rollback on health-check failure.
Support is staffed during Eastern and Pacific business hours by real people based in Canada. No offshore tier-1, no scripted bots. Response targets: 4 hours for critical incidents, 1 business day for everything else.
CloudWatch alarms watch the renewal-analysis pipeline, claims ingest, and authentication endpoints 24/7. On-call rotation pages engineering directly on a SEV-1 load balancer or database event.
RDS automated backups run nightly with 7-day point-in-time recovery. Snapshots are encrypted with the same KMS key as the live database and remain in ca-central-1.
All schema changes are version-controlled migrations, applied automatically on deploy with the same migration runner used in development. Rollback procedures are documented per migration.
External SaaS dependencies are deliberately short: AWS (hosting and AI), Stripe (billing), Resend (transactional email), and Salesforce (optional CRM sync for firms that ask for it). Each is contracted under Canadian law where possible.
A documented breach response runbook governs incident triage, regulator notification (Law 25 / PIPEDA), and firm notification within 72 hours of confirmation. Tabletop exercises run twice a year.
Questions or a security questionnaire? Email chris@blankit.ca — most questionnaires are answered the same business day. If something a prospect needs isn't covered here, we add it to this page rather than maintaining a parallel one-off document.
See also: Sub-processors · Privacy policy