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 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.

Amazon Web Services Bedrock (cross-region inference)

Active
Location
Entry point in ca-central-1; inference may run in any AWS region with capacity (in practice US)
Purpose
AI extraction and chatbot via Claude Haiku 4.5, Sonnet 4.5, and Opus 4.6 through AWS `global.*` inference profiles — used for renewal PDF parsing, claims experience parsing, booklet comparison, document-difference analysis, plan-member chatbot routing, and bulk text extraction
Categories
Booklet PDF content, claims experience document content, renewal PDF content, plan-member chat messages, and any other document or message content the platform sends to Claude models
Transfer mechanism
As of 2026-05-15, AWS no longer accepts on-demand invocation of any Claude 4.x model from a single region — every Haiku, Sonnet, and Opus call must route through an inference profile. AWS publishes no `ca.*` profile for Claude 4.x; only `us.*` (US regions only) and `global.*` (any region with capacity). We use `global.*`. All inference is covered by the AWS Customer Agreement + AWS DPA. Anthropic does not see the data. Switching to a `ca.*` profile the moment AWS publishes one is a single-line code change.

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 benefits assistant, 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. 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 AWS Bedrock, which routes to a US region as described in the AWS Bedrock entry above. 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 assistant, which their employer cannot see, as the private alternative.

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.

Anthropic PBC

Standby / fallback
Location
United States
Purpose
Claude AI inference, when AWS Bedrock is unavailable (fallback only)
Categories
None in current production. Retained as a disaster-recovery path.
Transfer mechanism
Anthropic Commercial Terms + DPA. Production routes 100% of AI traffic through AWS Bedrock — entry point in ca-central-1, inference per the Bedrock entry above; the Anthropic API is reachable from staging but disabled in production by the `USE_BEDROCK=true` task setting.
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-05-14. 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