The BAA above is the US HIPAA Business Associate Agreement — it is separate from this GDPR / nFADP DPA. Use the BAA for HIPAA-regulated workloads and the DPA for EU / Swiss data-protection coverage. The current subprocessor list is at /legal/subprocessors.
This Data Processing Addendum (“DPA”) supplements the AdaptivMapr Terms of Service (the “Agreement”) entered into between you (“Customer”) and AdaptivMapr (“Processor”). It governs the processing of Personal Data carried out by AdaptivMapr on behalf of Customer in the course of providing the Services. In the event of any conflict, this DPA prevails over the Agreement with respect to data protection matters.
Article 1 — Definitions
Unless otherwise defined below, capitalised terms have the meanings given to them in Article 4 of the EU General Data Protection Regulation 2016/679 (“GDPR”) and, where applicable, the Swiss Federal Act on Data Protection 2020 (“nFADP”).
- Personal Data — any information relating to an identified or identifiable natural person, processed by AdaptivMapr on behalf of Customer in connection with the Services;
- Data Subject — the identified or identifiable natural person to whom Personal Data relates;
- Processing — any operation performed on Personal Data, whether or not by automated means;
- Controller — the natural or legal person that determines the purposes and means of the Processing;
- Processor — the natural or legal person that processes Personal Data on behalf of the Controller;
- Subprocessor — any Processor engaged by AdaptivMapr to assist in fulfilling its obligations under the Agreement;
- Personal Data Breach — a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to Personal Data;
- SCCs — the Standard Contractual Clauses adopted by the European Commission in Decision (EU) 2021/914 of 4 June 2021.
Article 2 — Subject matter & duration
AdaptivMapr processes Personal Data on behalf of Customer for the sole purpose of providing the Services as described in the Agreement. Processing begins on the effective date of the Agreement and continues for the term of the Agreement, plus any additional period during which AdaptivMapr is required to retain Personal Data for the return-or-deletion process in Article 13.
Article 3 — Nature & purpose of Processing
AdaptivMapr processes Personal Data to:
- Receive Customer's files, tables and records (in schema-only mode, column headers and up to three sample row values per column, each truncated to 80 characters; in full-data mode, the rows) and the target schemas Customer defines;
- Run the mapping cascade — deterministic statistics, heuristic and fuzzy layers, then, for columns those leave unresolved, the mapping ranker and the model layer — to recommend a target field for each column, and run the structural reshape, convert, Chat and macro features Customer invokes;
- Return mapping recommendations, validation results and transformed rows or files to Customer, and deliver them to destinations Customer configures (webhooks, connectors);
- Store what Customer chooses to keep — saved schemas, layouts, reshape programs and remembered chats — until Customer deletes it;
- Authenticate API calls, enforce rate limits, meter usage, generate audit log records, and record prompt-injection signals as set out below.
Model processing. Which cascade layers run is decided by AdaptivMapr's configuration and by which columns remain unresolved; there is no Customer setting that excludes the model layers. The mapping ranker (AdaptivMapr's own model) receives column names and statistical profiles computed by AdaptivMapr, never cell values. The model layer, and the reshape, convert, Chat and macro features, send their prompt through phi-cloud to a model provider listed in Article 8. Customer controls what a model can see by choosing schema-only or full-data mode, and controls routing by choosing PHI routing for a workspace or a run.
Schema-only mode (the default). Only column headers and the clamped sample (≤3 rows × ≤80 characters per cell) leave Customer's environment. The clamp is enforced at the HTTP edge (clampForSchemaOnly()) and re-applied at the model call boundary. The sample is persisted as parsed_sample with the upload record (Article 13); parsed_rows stays empty.
Full-data mode. Requires the full-data entitlement on Customer's workspace and, for PHI routing, Customer's in-app acceptance of the BAA. Full rows are held for the upload retention window and sent to phi-cloud with the PHI marker and the workspace region, subject to the host-allowlist gate (MAPR_PHI_ALLOWED_HOSTS); phi-cloud forwards the call only to a PHI-eligible model resident in that region. The sandbox that executes a generated reshape program is, for now, called without the PHI marker; such a run is billed at the standard rate and carries a warning on its result.
Prompt-injection signals. When an automated detector flags text bound for a model as a possible prompt-injection attempt, AdaptivMapr keeps a record with an excerpt of the matched text only (at most 2,000 characters), for 180 days, to detect and study attempts to manipulate its AI processing and to train and evaluate a model that detects them. The record changes nothing about the run. Incognito Chat runs are never recorded. Customer receives these records in its data export; they are deleted with the workspace.
Article 4 — Categories of Personal Data
The categories of Personal Data Processed depend on Customer's configuration but typically include:
- Identifiers and contact data (name, email, phone) where these appear as column headers or sample values in Customer's inputs;
- Any other data contained in the records Customer submits, including employee, customer, payment and patient data where Customer uses a vertical pack (e.g. healthcare, finance, HR templates);
- Account contact data of Customer personnel (workspace owners, admins, billing contacts);
- Technical data — IP address, user agent, API key identifier, request metadata.
Special categories of personal data (GDPR Art. 9), including health data, are processed only where they appear in the records Customer submits. Customer should use PHI routing, which requires the in-app acceptance of the BAA, for health data.
Article 5 — Categories of Data Subjects
- Customer's personnel (workspace users, admins);
- Customer's end users, members, customers, patients, or counterparties whose data appears in the records Customer submits to AdaptivMapr.
Article 6 — Customer's responsibilities
- Customer is the Controller of Personal Data submitted to the Services and is responsible for the lawful collection, use, and transfer of that data;
- Customer warrants that it has all necessary consents, notices, or other lawful bases to enable AdaptivMapr to process Personal Data for the purposes set out in Article 3;
- Customer is responsible for choosing schema-only or full-data mode and standard or PHI routing as appropriate to its compliance posture, and for accepting the BAA before sending PHI;
- Customer is responsible for the security of its API keys, and for not sending patient information through support requests, which are ordinary email.
Article 7 — AdaptivMapr's responsibilities
AdaptivMapr will:
- Process Personal Data only on documented instructions from Customer (the Agreement, this DPA, and any written instructions Customer provides through the dashboard or API);
- Ensure that personnel authorised to process Personal Data are bound by appropriate confidentiality obligations;
- Implement technical and organisational measures consistent with Article 32 GDPR. A current description of those measures is maintained at /legal/security and is incorporated here by reference;
- Assist Customer in fulfilling its obligations under Articles 32–36 GDPR, including responding to data subject requests and notifying breaches;
- Make available all information necessary to demonstrate compliance with this DPA, subject to reasonable confidentiality protections.
Article 8 — Subprocessors
Customer grants general authorisation to AdaptivMapr to engage the Subprocessors listed below. AdaptivMapr enters into written agreements with each Subprocessor that impose data protection obligations no less protective than this DPA.
| Subprocessor | Purpose | Location |
|---|---|---|
| Cloudflare | Runs the whole application: Workers compute (the API, which the MCP server calls, and the dashboard), KV (parsed uploads for the workspace retention window, webhook secrets and delivery records, quota and cache entries), Queues (webhook delivery), Workers Logs and Analytics Engine (operational events and scrubbed browser error reports — ids and metadata, no file content), DNS, DDoS protection, edge cache, and the private tunnel to our own mapping-ranker host. | Global network; requests are served from the data centre nearest the caller |
| Supabase | Postgres database and sign-in (Supabase Auth): accounts, workspace settings and members, a mirror of each upload for its retention window (the clamped sample in schema-only mode, full rows in full-data mode), saved schemas, mappings, layouts and reshape programs, remembered chats and their files, the audit log, the billing ledger, signed agreements and policy acceptances, rate-limit counters, and the prompt-injection signal log. | Switzerland — Zurich (AWS eu-central-2). One project for every workspace: the workspace region setting does not move it. |
| phi-cloud | Model gateway (OpenAI-compatible, PHI-aware) for every model call except the mapping ranker: the mapping model (cascade layer 5), structural-reshape code generation and the sandbox that runs the generated program over the data, document and image extraction for convert, and the Chat assistant. It forwards each call to a model provider chosen by routing: PHI-routed calls only to PHI-eligible providers resident in the pinned region (currently Infomaniak in Switzerland, Scaleway in the EU, Microsoft Azure in CH/EU/US — which also does layout OCR for PDFs — and, once activated, Fireworks in the US); standard calls to the general models listed in the next two rows. Its own provider list is published at phi-cloud.com/legal/sub-processors. | Per the workspace region (CH, EU, UK or US) for PHI-routed calls; standard calls run where the chosen general model runs |
| Inception Labs (via phi-cloud) | The default general-purpose model (Mercury 2) for STANDARD-routed calls: Chat replies and routing, and the mapping model on a standard run. Receives the prompt for that call — on a schema-only map, column headers and at most three sample values of at most 80 characters each. | United States |
| Z.ai / Zhipu AI (via phi-cloud) | General-purpose models (GLM-5.3 and GLM-5.3-Flash) for STANDARD-routed calls that need more capability: one-off pieces of work and code generation for structural reshape. Receives the prompt for that call. | Worldwide — the provider does not offer a region-resident endpoint |
| AdaptivMapr mapping ranker | Mapping ranker (cascade layer 3½): scores each still-unresolved column against the fields of the target schema. Receives column NAMES and a statistical profile computed in the Worker (value kind, length range, uniqueness, letter case, share of empty cells). Never receives a cell value, a row or a file. | Switzerland — our own hardware, reached over a private Cloudflare tunnel. Used for workspaces pinned to CH or with no pin. |
| RunPod | Failover GPU for the mapping ranker — the same model, used only when our Swiss hardware is unreachable. Receives exactly what the ranker receives (column names and the computed profile, never a cell value). Processed in memory, not stored. | EU data centres only. Used only for workspaces with no region pin; never for a CH, EU, UK or US pin. |
| Monopea | Spreadsheet macro editing (Chat asks to write or change VBA), and structural-reshape code generation when that provider is enabled. A macro edit sends the WHOLE workbook: it is stored in Monopea’s document library for the duration of the edit and deleted there when the edited file comes back. The workspace’s PHI flag and region travel with every request. | Fly.io infrastructure; Monopea’s own model calls go through phi-cloud with the forwarded region, but the Monopea host is not region-pinned |
| Stripe | Wallet top-ups, the monthly plan, invoices, payment processing and the customer portal. Receives billing name, email, address, VAT number and card details (which we never see). | Ireland (Stripe Payments Europe), with US affiliates |
| Resend | All email we send: sign-in links and codes (Supabase Auth uses Resend as its mail relay), transactional email (welcome, billing, quota, destructive-action notices) and support requests, which are forwarded as ordinary email to our support mailbox. Receives the recipient address and the message. | The Resend sending region configured for our domain (Resend operates in the US and other regions) |
| Sign in with Google (Google Identity Services). Google learns that you signed in to AdaptivMapr; we receive your Google account email and basic profile. Nothing you upload is sent to Google. | Google global infrastructure |
The same list, with each subprocessor's agreement status, is published at /legal/subprocessors. The AdaptivMapr mapping ranker is AdaptivMapr's own hardware, listed for transparency. Destinations Customer connects (webhooks, connectors) receive data on Customer's instruction and are not Subprocessors.
AdaptivMapr will announce an added or replaced Subprocessor on /legal/subprocessors at least 30 days before it processes Customer's Personal Data, and email the announcement to workspaces under a signed BAA and to subscribed contacts. Customer may object to the change for reasonable data protection grounds; if the parties cannot resolve the objection in good faith, Customer may terminate the affected portion of the Services without penalty and receive a pro-rata refund of any prepaid fees.
Article 9 — International transfers
Where AdaptivMapr transfers Personal Data outside the EEA, the UK, or Switzerland to a country that has not been recognised as providing an adequate level of protection, the transfer is governed by the SCCs (Modules 2 or 3, as applicable), incorporated into this DPA by reference. For UK transfers the SCCs are read together with the UK ICO International Data Transfer Addendum. For Swiss transfers the SCCs are read together with the FDPIC implementation guidance (reference to FADP, the FDPIC, and the Swiss courts where applicable).
Article 10 — Data subject rights
AdaptivMapr will, taking into account the nature of the Processing, assist Customer through appropriate technical and organisational measures, insofar as possible, in responding to requests from Data Subjects to exercise their rights under Articles 12–22 GDPR. Customer is responsible for primary handling of Data Subject requests, including verifying identity and tracking timelines.
Article 11 — Data breach notification
AdaptivMapr will notify Customer without undue delay, and in any event within 72 hours, after becoming aware of a Personal Data Breach affecting Customer's data. The notification will, to the extent known at the time:
- describe the nature of the breach and the data affected;
- state the likely consequences;
- describe the measures taken or proposed to address it;
- provide a contact point for further information.
AdaptivMapr will cooperate with Customer's reasonable requests for further information and assistance, including for the purposes of Customer's notifications to its own supervisory authority and Data Subjects.
Article 12 — Audits
AdaptivMapr will make available to Customer, on reasonable request, the information necessary to demonstrate compliance with this DPA, including:
- Any independent assurance report AdaptivMapr holds at the time of the request (there is no SOC 2 report yet);
- The current Subprocessor list and the security measures described at /legal/security.
Customer may, no more than once per calendar year and on at least 30 days' written notice, audit AdaptivMapr's compliance with this DPA, at Customer's expense, subject to reasonable confidentiality and access restrictions. The right is satisfied by AdaptivMapr's provision of the documents above unless an audit is required by a supervisory authority or by applicable law.
Article 13 — Return or deletion
Uploads. The parsed content of an upload is held in Cloudflare KV for the retention window configured for Customer's workspace — destroyed on commit, 24 hours (the default), 7 days or 30 days — and mirrored in the database. The window is written into the storage entry when the upload is created and returned as expires_at. A committed upload is deleted from KV and the database at commit. A scheduled sweep runs every 15 minutes and clears the full rows (parsed_rows, full-data mode) of any upload whose window has elapsed. The upload record of an upload that was never committed — file name, headers, the clamped parsed_sample and the mappings — remains until the workspace is deleted.
Deletion by Customer. Customer can delete a remembered chat, a saved schema or a workspace at any time from the dashboard, and can download its data first. Deleting a workspace erases everything in it, for every member: uploads and their stored copies, connectors and their secrets, API keys, chats and stored files, schemas, saved mappings and reshape programs, settings, and the workspace’s audit log. Its phi-cloud key is revoked and its Stripe customer profile is deleted, which also cancels any subscription. The audit log is erased with the workspace. What remains is one anonymous erasure record — a one-way hash of the workspace id, the time, and how many records were removed — so an erasure can be shown to have happened without keeping whose it was. The erasure runs in one database transaction and is never reported as complete unless every step finished.
What is kept. The billing ledger (amounts, dates and Stripe references, with the link to the workspace removed) is kept for accounting. Signed BAA / DPA records and policy acceptances are kept as evidence of the agreement, with the signer's identity, and deleted automatically six years later. Data that cannot be erased on demand: Cloudflare's logs and analytics (identifiers, no file content) under Cloudflare's retention, the email provider's log of sent messages, short-lived markers that expire within 7 days, and the database provider's daily backups, which age out after 7 days.
On termination of the Agreement, AdaptivMapr will, at Customer's election, return (through the data export) or delete all Personal Data Processed on Customer's behalf, subject to the retention above.
Article 14 — Liability
Each party's liability arising out of or in connection with this DPA is subject to the limitations set out in the Agreement. Nothing in this DPA limits liability that cannot be limited under applicable law.
Article 15 — Governing law
This DPA is governed by the laws of Switzerland; the courts of Zurich have exclusive jurisdiction, except where the SCCs require a different forum, in which case the SCCs prevail.
Article 16 — Contact
Data protection contact: dpo@adaptivmapr.com. Any customer may request a counter-signed copy of this DPA by contacting hello@adaptivmapr.com.
Talk to compliance
Have a procurement form, security questionnaire, or BAA workflow to run through? Book a 30-minute call with our compliance team. We respond in one business day across CH, EU, US business hours.
Or email us directly: compliance@adaptivmapr.com.