blankit
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 are all hosted in Canada. AWS Canadian Customer Agreement governs. AI processing is a separate AWS service, listed below with its own location.

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.

Amazon Web Services Canada (Amazon SES — outbound email)

Active
Location
Canada (ca-central-1, Montreal)
Purpose
Outbound transactional email — sign-in and password emails, firm notifications and digests, and the name and contact details a plan member submits when they ask an advisor to follow up or enrol in optional coverage
Categories
Recipient email address and the body of the email, which can include a plan member’s name, email address, phone number and the question they asked an advisor
Transfer mechanism
Sent from Canada under the AWS Canadian Customer Agreement. Once delivered, a message is held by the recipient’s own email provider, wherever that provider stores mail. Health information is never sent by email: a signed health questionnaire or an application carrying tobacco status is opened through an expiring secure link to blankit, where it stays stored in Canada.

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 stay stored in Canada, and the AI step that reads them is the same 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 where a plan sponsor’s data is stored changes 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 organization — 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 organization-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.

Canada Post Corporation (AddressComplete, operated by GBG)

Active
Location
Canada and the United Kingdom
Purpose
Address search on the Evidence of Insurability form, so a plan member can pick their mailing address instead of typing it
Categories
The partial address a plan member types into the search box, and the address they choose. No name, date of birth, health information or any other field on the form is sent.
Transfer mechanism
Canada Post’s AddressComplete terms. A cross-border transfer: Canada Post may process the address search in the United Kingdom. Only the address search box is sent; the completed form, its health answers and the signature stay in blankit, stored in Canada.

BoldSign (by Syncfusion)

Active
Location
Canada (BoldSign’s Canada data centre, Toronto)
Purpose
Electronic signature of the Evidence of Insurability form, and of the optional beneficiary designation, for optional Critical Illness coverage, and the signed record of each
Categories
The completed form the plan member signs — including their answers to the medical questions, or the names, relationships and birth dates of the beneficiaries, insured family members and any trustee they name, with the member’s home address — their name and email address, and BoldSign’s record of the signing (time, IP address).
Transfer mechanism
BoldSign’s terms. BoldSign states that data for an account in its Canada data centre is stored and processed in that data centre. The signed form and BoldSign’s audit trail are copied back to blankit and stored in Canada, and blankit then deletes the form from BoldSign.

Amazon Web Services Bedrock (AI processing)

Active
Location
Requests enter AWS in Canada (ca-central-1, Montreal). AWS may process them outside Canada, including in the United States
Purpose
AI processing for every document type blankit reads and every AI feature it offers, using Anthropic’s Claude models hosted by AWS — carrier renewals, claims experience reports, coverage booklets, commission statements, carrier quotes and correspondence, Rider, and plan-member chatbot answers.
Categories
Document content sent for reading — plan sponsor names, benefit and rate tables, aggregate claims figures, and booklet text. Plan-member questions and the booklet passages needed to answer them. Census and roster files are parsed in code and never sent to an AI model.
Transfer mechanism
Storage and processing are two separate statements. Client data — documents, the database and backups — is STORED in Canada (AWS ca-central-1) and stays there. The AI PROCESSING of a request enters AWS in Montreal, and AWS may carry it out outside Canada, including in the United States, because Claude models on Bedrock are served through AWS cross-region inference. Disclosed as a cross-border transfer. Governed by the AWS Customer Agreement and the AWS Data Processing Addendum. AWS hosts the model; Anthropic does not receive the data on this path. 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.

Anthropic PBC

Standby / fallback
Location
United States
Purpose
Developer of the Claude models blankit uses. In production those models are hosted by AWS Bedrock (above), and Anthropic does not receive blankit data.
Categories
None. Requests go to AWS Bedrock, not to Anthropic.
Transfer mechanism
No transfer to Anthropic while AWS Bedrock is the configured path. Listed so a reader who sees “Claude” elsewhere on this site knows where it runs.
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-10-16. 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