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.
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.
Your data resides only on Canadian servers; what can pass through servers elsewhere is a READING of it, never the file itself. Every document blankit reads — carrier renewals, claims experience reports, coverage booklets, commission statements and carrier correspondence — is processed by Augure, a Canadian-owned AI provider with no US parent company in the stack, and never routed to the United States. Augure’s published privacy policy serves certain model tiers, and failover during outages or peak demand, from partners in the European Union rather than Canada. Augure names the region that served each request and blankit CHECKS it: any response not served in Canada is refused rather than used, so nothing the EU tiers produce is ever relied on. That check reads the region off the response, so it discards a foreign-served answer rather than preventing the request — stated here because the distinction is the whole disclosure. Residency of the data itself is unaffected: documents, database and backups stay in ca-central-1 throughout. Full detail, including retention and training terms, on the sub-processors page.
Two Canadian models read a document before anything else is tried: Augure Tofino, then a second Augure model. Where both genuinely fail to read THAT document, blankit stops and asks the advisor whether Claude, in the United States, may read that one file. Nothing is sent until they answer, an approval covers one document once and expires, and declining leaves the document reported unread exactly as it would be otherwise. Both gates are enforced in code rather than by policy: an approval that does not carry the two failed Canadian attempts is refused, so there is no setting that makes this routine and no way to reach it without the Canadian models having tried first. ⚠️ What crosses is ONE READING of one document. Storage does not move: S3, RDS and your firm’s own database are in ca-central-1 before and after, and blankit neither relocates nor copies the file. Every approval and refusal is written to your firm’s audit log, so "was anything of ours read outside Canada?" has an answer you can show. Retention and training terms for that US reading are a contract matter and are stated on the sub-processors page, not claimed here.
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 and AI), Stripe (billing), Resend (transactional email), 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. Each is contracted under Canadian law where possible.
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