Sub-processors

Every third party that touches blankit data.

Blankit Health Inc. operates inside AWS, primarily in AWS Canada (Montreal, ca-central-1). The list below is the complete inventory of third parties that may process personal information in connection with the platform, the purpose of that processing, and how it complies with Quebec Law 25 and PIPEDA cross-border disclosure obligations. Where a vendor operates outside Canada, that is stated explicitly.

The list covers two kinds of third party, and the difference matters for who holds the contract. Some are engaged by blankit and process personal information on our behalf — hosting, email delivery, billing, AI inference. They are in the production data path for every firm, and we notify firms at least 30 days before adding one. The rest are integrations a firm connects itself to systems it already uses — its CRM, its document folder, its Slack or Microsoft Teams workspace, its mailbox. Those are off by default, connected only by an administrator of the firm, and governed by the firm’s own agreement with that vendor rather than by ours; disconnecting stops the processing. They are listed here anyway, because what matters to a plan sponsor asking where their data can travel is the complete picture, not the contractual boundary.

Amazon Web Services Canada (storage + compute)

Active

Location: Canada (ca-central-1, Montreal)
Purpose: Hosting, database (RDS PostgreSQL), object storage (S3), and secrets management (KMS)
Categories: All client data at rest. Application servers, database, object storage, and backups.
Transfer mechanism: Application servers, database, object storage, and backups all stay in Canada. AWS Canadian Customer Agreement governs.

Stripe Payments Canada

Active

Location: Canada with US data processing
Purpose: Subscription and usage-based billing for firms that subscribe to blankit
Categories: Firm billing contact identity and the firm’s aggregate AI-usage quantities (credit counts for metered billing) — no plan-sponsor or plan-member data, and no per-advisor detail
Transfer mechanism: Stripe DPA + PCI DSS Level 1 controls. Plan-sponsor and plan-member data is never sent to Stripe.

Resend

Active

Location: United States
Purpose: Outbound transactional email — password resets, daily firm-facing notification digests
Categories: Recipient email address and the body of the operational email
Transfer mechanism: Resend DPA. Health information is never sent by email; only operational metadata (e.g. "you have 3 new Critical Illness enrolment requests in the dashboard").

Slack Technologies (Salesforce)

Active

Location: United States
Purpose: Two separate, independently installed integrations. (1) Advisor workspace — when a firm connects its own Slack, documents shared in the channels it maps are read into blankit, and analysis outcomes, alerts and generated documents are posted back. (2) Plan sponsor workspace — where an employer installs Paige, the employee chatbot, their employees can ask coverage questions in Slack and get answers drawn from their own plan booklet.
Categories: Advisor workspace: whatever the firm chooses to share — carrier renewal and claims documents, client names, premium and claims figures, and generated reports. Plan sponsor workspace: the employee’s question, the answer, and their Slack user id. No name or email is requested there. The question is held only for as long as it takes to answer it — Slack requires a fast acknowledgement, so it is queued while a background worker produces the reply, and that queue row is cleared as soon as the reply is delivered. One further holding is disclosed because a plan sponsor asking where their employees’ words go is entitled to the complete answer: the last few messages of a conversation are held for about thirty minutes, in temporary storage outside any firm’s database, so the chatbot can answer a follow-up; they expire automatically, and an employee can clear them at once by typing “start over”. Employees are told this in the notice shown before their first question. Nothing is sent to Slack for a firm, or an employer, that has not connected it.
Transfer mechanism: Slack Customer Agreement + DPA, held between the workspace owner and Slack — the firm for its own workspace, the employer for theirs. Both integrations are off by default and connected only by an administrator of the workspace concerned; disconnecting stops all further processing. Documents and questions are stored in Canada; the AI step that reads them runs through whichever AI sub-processor is marked active below, on that entry’s stated terms. Slack itself is the transport and the destination for the reply, not the processing location. For the plan-sponsor integration one consequence is worth stating plainly rather than leaving implied: the workspace belongs to the employee’s employer, so what that employer can see or export from it — including direct messages with apps, on some Slack plans — is governed by Slack’s administrator controls and the employer’s own Slack agreement, not by blankit. Employees are told this before their first answer, and are offered the web chatbot, which their employer cannot see, as the private alternative.

Meta Platforms (WhatsApp Business Platform)

Active

Location: United States and Ireland
Purpose: Transport for the plan-member benefits chatbot on WhatsApp — the employee’s question reaches blankit through Meta, and the answer goes back the same way. blankit never starts a conversation: every message it sends is a reply to one an employee sent first, and no message templates are registered, so there is no mechanism by which an employee can be messaged unprompted.
Categories: The employee’s question, the answer, and their mobile number — which on this surface is how the message is addressed and cannot be withheld from the transport. blankit itself stores a scrambled code derived from that number, never the number, so blankit’s own records cannot be used to contact anyone; the number is written down once, in the queue row that carries the reply, and that row is cleared as soon as the answer is delivered. One further holding is disclosed here for the same reason it is on the Slack row below: the last few messages of a conversation are held for about thirty minutes, in temporary storage outside any firm’s database, so the chatbot can answer a follow-up; they expire automatically, and an employee can clear them at once by typing “start over”. Employees are told this in the notice shown before their first answer. No name, no email, and no profile field is requested. Photos, documents and other media sent to the number are ignored rather than read.
Transfer mechanism: WhatsApp Business Solution Terms + Meta’s data processing terms, held between blankit and Meta — unlike the two rows above, this agreement is not the employer’s. ⚠️ What this surface adds is the MESSAGE crossing the border, in transit. The plan booklet the answer is drawn from and the client’s data are stored only in Canada, and the AI step that reads them takes the same Canadian-first path as on every other version of the chatbot — through whichever AI sub-processor is marked active below, on that entry’s stated terms — so nothing about a plan sponsor’s data moves because their employees use this surface. One consequence worth stating plainly, because it runs the opposite way to Slack and Teams: the WhatsApp account belongs to the EMPLOYEE, not to their employer, so an employer has no administrative visibility into these conversations at all. Employees are told all of this before their first answer, and can end it at any time by replying STOP.

Microsoft (Teams, through the Azure Bot Framework)

Active

Location: United States (Microsoft’s Bot Framework relay); the firm’s own Microsoft 365 tenant otherwise holds the conversation, wherever that tenant is hosted
Purpose: Advisor organisation — when a firm adds blankit to its own Microsoft Teams, documents shared in the channels it sets up are read into blankit, analysis outcomes are posted back to the channel, and firm members can ask blankit about their own book from Teams. Only firm members matched by their Microsoft 365 email can feed documents through it; a guest or a client in a shared channel cannot.
Categories: Whatever the firm chooses to share — carrier renewal and claims documents, client names, premium and claims figures — and the replies posted back. A channel upload lands in the firm’s own SharePoint and is fetched from there; blankit reads messages only in channels the app is added to and that the firm has set up for a document type. Nothing is sent to Microsoft for a firm that has not connected it.
Transfer mechanism: Microsoft Product Terms + DPA, held between the firm and Microsoft. The integration is off by default and connected only by a firm administrator, using a single-use connection code issued in blankit; disconnecting stops all further processing. Documents are stored in Canada; the AI step that reads them runs through whichever AI sub-processor is marked active below, on that entry’s stated terms. Microsoft’s Bot Framework is the transport and the destination for the reply, not the processing location.

Customer relationship management — Salesforce, HubSpot, Zoho, Microsoft Dynamics

Active

Location: United States (Zoho and Dynamics offer other regions; the firm’s own tenant decides)
Purpose: Only where a firm connects its own CRM. blankit reads client records to match them to the firm’s book, and — only if the firm switches the connection to bidirectional — writes mapped fields such as renewal dates and premium figures back onto the matching record. The default is pull-only: nothing is written back unless an administrator turns that on.
Categories: Plan sponsor (employer) names and contact details, renewal dates, and the premium and renewal figures the firm chooses to map. No plan-member data, no claims detail, and no booklet content is written to a CRM.
Transfer mechanism: The firm’s own agreement with its CRM vendor — blankit is not a party to it, and the data is going into a system the firm already controls and already holds this information in. Off by default, connected only by a firm administrator, and disconnecting stops all further processing. Listed here for transparency rather than because blankit engages these vendors: like the Slack advisor workspace above, the contract is the firm’s.

Google (Drive)

Active

Location: United States
Purpose: Only where a firm connects its own Google Drive as a claims-document folder. blankit polls the folder the firm nominates, downloads new PDFs for analysis, and — only if the firm enables the cleanup option — moves the processed source file to the folder’s trash after a retention window the firm sets.
Categories: Whatever the firm places in that folder: carrier claims and renewal documents, which typically contain plan sponsor names and aggregate claims figures.
Transfer mechanism: The firm’s own Google Workspace agreement. blankit holds an OAuth grant to that one folder, not to the firm’s Drive at large; the tokens are encrypted at rest. Off by default, connected by a firm administrator, and revoking the grant stops all further processing. Deletion is to the provider’s trash — recoverable — never a hard delete.

Microsoft 365 and Google (mailboxes)

Active

Location: United States
Purpose: Only where a firm OPTIONALLY connects its own mailbox to the evidence-of-insurability reply monitor. Carrier replies normally reach blankit by email at the firm’s own inbound address, with no mailbox connected and no data reaching either provider; where a firm does connect one, blankit reads that single inbox to match carrier replies to pending medical-underwriting submissions.
Categories: The carrier’s reply message and its attachments, which may identify a plan member and reference a medical-underwriting decision.
Transfer mechanism: The firm’s own Microsoft 365 or Google Workspace agreement. The consent is scoped to the single mailbox that granted it — deliberately not the organisation-wide variant, which would let the monitor read every mailbox in the tenant. Off by default, connected by a firm administrator, and revoking consent stops all further processing.

The Altercation Company Inc., operating as Augure

Active

Location: Canada — federally incorporated (Canada Business Corporations Act), head office Toronto, Ontario. Data RESIDES on Canadian servers. The READING is Canadian on most tiers and, per the vendor’s published privacy policy, passes through servers in the European Union on certain model tiers and during failover. Every response names the region that served it: observed `ca-on-toronto`, gateway `ca-montreal-1`
Purpose: AI extraction and chatbot inference for every document type blankit reads: carrier renewals, claims experience reports, coverage booklets, commission statements, carrier quotes, carrier correspondence and plan-member questions.
Categories: Document content sent for extraction — plan sponsor names, benefit and rate tables, aggregate claims figures, and booklet text. Plan-member questions and the booklet passages needed to answer them.
Transfer mechanism: The distinction that governs this row: YOUR DATA RESIDES ONLY ON CANADIAN SERVERS, and what can pass through servers elsewhere is a READING of it. Nothing is relocated, copied or stored abroad. Their published privacy policy (effective April 2026, last updated July 2026, read 2026-09-23) states account information, user content and conversation history are held exclusively on Canadian infrastructure, and the vendor is Canadian-owned with no US parent and never routes to providers in the United States. WHERE THE READING HAPPENS IS NOT ALWAYS CANADA, and this page said it was until 2026-09-23. That policy discloses that certain model tiers, and failover during outages or peak demand, are served by partners in the European Union — named there as Scaleway (France) and Mistral AI — under what it describes as zero-data-retention agreements; the Canadian inference partner is named as Spur Innovation, Waterloo, Ontario. So an EU transfer of document content is possible, and is disclosed here as one. What blankit does about it: Augure returns the serving region on every response and blankit CHECKS it, refusing outright any response not served in Canada rather than using it — so nothing these EU tiers produce is ever relied on. Read the limit of that honestly: the region is read off the RESPONSE, so where a request did fail over, the document content was already processed in the European Union before blankit could refuse it. The check prevents a foreign-processed ANSWER being used; it cannot un-send the request. Retention, per the same policy: the inference providers retain no prompt content after a request completes, while Augure itself holds user content for the life of the account and deletes it within 30 days of account termination or of a deletion request, with anonymized usage logs kept up to 12 months. Training: the policy states customer content is not used to train AI models WITHOUT EXPLICIT CONSENT — a condition rather than a prohibition — and it does not address human review or evaluation and quality sampling at all, so neither is claimed here. No data processing agreement is executed with this vendor; the relationship is governed by the published terms of service.

Amazon Web Services Bedrock (cross-region inference)

Standby / fallback

Location: Entry point in ca-central-1; inference may run in any AWS region with capacity (in practice US)
Purpose: Standby path for the same AI work, reached only if the Canadian-owned provider above is unavailable
Categories: None in current production. Retained as a disaster-recovery path.
Transfer mechanism: AWS no longer accepts on-demand invocation of any Claude 4.x model from a single region — every call must route through an inference profile, and AWS publishes no `ca.*` profile for these models, only `us.*` and `global.*`. So this path gives a Canadian ENTRY POINT and inference wherever that profile has capacity, in practice US regions, and nothing in the response says where it ran. Covered by the AWS Customer Agreement + AWS DPA; Anthropic does not see the data. Disclosed as a cross-border transfer whenever this path is the active one.

Anthropic PBC

Standby / fallback

Location: United States
Purpose: The third and last rung of the Canadian-first reading ladder. Reached for ONE document at a time, only after both Canadian models have genuinely failed to read that document, and only when the advisor approves that specific file. There is no setting that makes it routine and no path to it that skips the Canadian attempts — both gates are enforced in code.
Categories: The content of an individual document an advisor has approved for a US reading — a carrier renewal, claims experience report, booklet, quote or carrier reply that blankit could not read in Canada. Nothing else: no plan-member questions, and no document an advisor has not approved one at a time. A census or roster never reaches any model at all, here or anywhere — those are parsed as a spreadsheet in code.
Transfer mechanism: A cross-border transfer, disclosed as one, and the only one blankit has. ⚠️ What crosses is ONE READING of one document: storage does not move, and S3, RDS and the firm’s own database stay in ca-central-1 before and after. Every approval and refusal is written to the firm’s audit log. Governed by Anthropic’s Commercial Terms, and under blankit’s agreement with Anthropic that reading is not retained. ⚠️ That is the retention of the DOCUMENT and nothing adjacent: this entry does not tell you what is logged, whether a person ever sees it, or whether content is used for training or evaluation, because nobody here has read terms covering those. A residency answer would not settle them either — content can be deleted from our side and still be held by a processor — so what is claimed here is the one thing that was checked, attributed to where it was checked.

Operator access

We're a sub-processor too — and we can't see your clients.

Blankit Health Inc. is the entity that operates the platform, so we are ourselves a processor under PIPEDA / Law 25. The platform admin role (currently held by the founder) is the operator identity that can step into a tenant for support. The relevant disclosure for your procurement review is what that role can and can't see.

The day-to-day product is single-tenant per firm — cross-firm reads are absent from the code paths your sessions touch. The exception is a read-only impersonation session the platform admin can start when a problem needs an engineer. Such sessions are:

Time-boxed to 30 minutes
Refused at the edge for any write, upload, delete, or message-send
Wrapped in a mask at the database extension that replaces client and contact names with deterministic pseudonyms (Client-XXXX), redacts emails / phone / policy numbers, and replaces document titles and free-text blobs with sentinels
Audit-logged at start and end with both operator and target identities

See Trust & security · Cross-firm access for the full mechanics and a live capture of what the operator actually sees on screen during a session.

Notification of change

We tell you before adding a sub-processor.

Firms that subscribe to blankit are notified at least 30 days before a new sub-processor is added to the production data path. Notification is emailed to the firm's billing and security contact and posted to this page.

A firm that objects to a new sub-processor within the 30-day window may terminate the subscription without penalty.

Privacy Officer: Chris Gory · chris@blankit.ca

Last reviewed 2026-09-18. The internal source of truth is the Records of Processing Activities document (Blankit Health Inc., Section 3) — any change there is mirrored here in the same release.

See also: Privacy policy · Trust & security