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.
Day to day the question does not arise: your firm has its own database, its own storage bucket and its own encryption key, so no other firm’s connection can query your clients, and yours cannot reach theirs. 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 into that one firm, 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.
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. Every byte of client data at rest, and every backup, is stored in Canada. AI processing is the one step that may happen outside Canada — see below.
Blankit Health Inc. is a Canadian company. No US parent, no offshore operations.
Every AI feature in blankit — reading carrier renewals, claims experience reports, booklets, quotes and correspondence, Rider, and the plan-member chatbot — uses Anthropic’s Claude, hosted by AWS on Amazon Bedrock. Requests enter AWS in Montreal (ca-central-1). AWS serves these models through cross-region inference, so a request may be processed outside Canada, including in the United States, under the AWS Customer Agreement and the AWS Data Processing Addendum. Anthropic does not receive the data on this path; AWS hosts the model. blankit runs Amazon Bedrock with data retention set to “none” (zero data retention). AWS states that in this mode no request or response data is written to durable storage or shared with the model provider. Storage is a separate matter and does not change: documents, the database and backups stay stored in ca-central-1. Census and roster files are read in code and never sent to an AI model. Disclosed on the sub-processors page.
Every document blankit produces that states a price or makes a recommendation — renewal reports, the carrier challenge email, counter-proposal letters, quote reports and Benefits Presentations, coverage-change pricing and claims reports — carries a short notice that artificial intelligence was used in preparing it. It is added over the firm’s own footer, so it cannot be switched off, and French PDF documents carry it in French.
AI’s job is reading: it takes the figures off a carrier’s renewal, a plan booklet or a claims experience report. The fair renewal premium is then calculated by blankit’s documented actuarial engine, which gives the same answer every time for the same inputs; it is not generated by a model. Every renewal is read twice, and any premium the two readings disagree on is put in front of the advisor with both figures.
blankit is a tool for group benefits advisors, not a substitute for one. The Terms of Service require a firm to review AI-assisted work before it reaches a client or is used in a decision about their coverage or pricing, and the renewal report tells the plan sponsor so on its cover.
Paige, the plan-member chatbot, tells members it is an AI chatbot — on screen in the web chatbot, and at the start of every conversation in the chat apps it runs in. Its answers come from the member’s own plan booklet, and on the web each answer cites the page it came from. The booklet and the insurer have the final word, and Paige says so.
Every AI feature in blankit uses Anthropic’s Claude, and the Terms of Service bind every firm on the platform to Anthropic’s Usage Policy alongside blankit’s own acceptable-use rules. Where AI processing takes place is set out under Data storage and processing.
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.
blankit fills a client’s missing province from public corporate registers — Corporations Canada’s register of federal corporations, and the Registraire des entreprises du Québec. The whole published file is downloaded and matched locally, so no client name, address or identifier is ever sent to a lookup service, and no third party learns who a firm’s clients are — which a per-client search API would. The register is a public record, so anything it answers can be checked against the filing itself. It is also the lowest-ranked evidence the platform accepts: it can fill a province that has nothing behind it and can never move one an advisor confirmed, a carrier document stated, or a CRM supplied.
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 are built and documented against the SOC 2 Trust Services Criteria for security, availability, and confidentiality, and we maintain a control-by-control readiness tracker against them. To be precise about where that stands: no auditor has been engaged yet, no observation window has opened, and blankit holds no SOC 2 attestation — Type I or Type II. Engaging an independent CPA firm is the next step. If procurement needs evidence before an audit exists, ask for the current readiness summary and we will share it, including what is still open.
HTTPS-only at the application load balancer (TLS 1.2 or higher). RDS storage is encrypted with KMS-managed keys. S3 buckets enforce server-side encryption (AES-256) and block all public access at the account-resource level. 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.
Firm-owned data is not rows in a shared table separated by a filter. Every advisor firm is provisioned its own PostgreSQL database, its own S3 bucket, and its own KMS key; a firm’s connection cannot address another firm’s database at all, so a cross-firm read is not something the application declines to do — it is something it has no route to attempt. Control-plane records (billing, the firm directory) live in a separate catalog database that holds no client data. This is a fixed property of the platform rather than a tier: there is no plan on which firms share a database.
Inside a firm’s own database every model holding firm-owned data is still firmId-scoped, with the data-access layer injecting the tenant filter at the query layer — so a coding mistake in a route handler cannot cross a boundary even within one tenant. A short, explicit allow-list covers the pre-authentication lookups where the credential itself resolves the firm (sign-in, API tokens); a schema-consistency test fails the build if any other model carrying a firmId escapes scoping. Scripts are audited the same way, by walking the import graph rather than grepping for a helper name.
Mandatory for every administrator account — an admin without a second factor cannot reach the product until they enrol one, and cannot later remove their last one. Any firm can additionally require it of every member. Advisors can use TOTP, email OTP, or a WebAuthn passkey — and a verified passkey also enables passwordless, phishing-resistant sign-in on its own. TOTP secrets are encrypted at rest with an AES-GCM key held separately from the database; passkey public keys are not secret and are stored unencrypted.
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. Entries are also chained: each one stores a SHA-256 over its own fields plus the hash of the entry before it, per firm, so altering a recorded field, deleting an entry, or reordering history breaks the chain arithmetically and is detectable on verification. Entries written before the chain existed carry no hash and are reported as uncovered rather than counted as protected.
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 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 14-day point-in-time recovery, so any moment in the last two weeks can be restored. The production database is Multi-AZ — a synchronous standby in a second Montreal availability zone, failed over automatically by AWS. 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, AI, and transactional email sent from Montreal), Stripe (billing), and an optional CRM connection — Salesforce, HubSpot, Microsoft Dynamics 365 or Zoho — for firms that ask for it. A CRM is connected per firm, is never required, and reads only — unless the firm turns write-back on itself. The other optional integrations are also off until a firm switches them on: Slack, Microsoft Teams, a watched Google Drive folder and a connected Microsoft 365 or Google mailbox. Each is contracted under Canadian law where possible, and the full list, with what each one receives and where, is on the sub-processors page.
Every night blankit re-reads each firm’s stored data and looks for defects that render correctly but are wrong underneath — one experience period on file twice, a commission statement counted twice, a document whose file is no longer where the record points. Findings are listed for the firm with what each one costs; where a defect can be repaired without a judgment call, the repair is applied automatically and to every firm, including firms onboarded after it was written. A check that cannot run is reported as such and never as a clean result.
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