Third-party services & sub-processor disclosure¶
Who this is for: the organization deploying DataQ (the data controller / covered entity) and its privacy/security reviewers. DataQ ships as customer-deployed BYOL (ADR 0013): there is no DataQ-hosted SaaS, so DataQ the company holds none of your data and, in the classic GDPR Art 28 sense, has no sub-processors of your data at all. What a controller still needs from us — and cannot produce themselves — is the list below: every external service the software can send data to, so your own sub-processor register and DPIA can name them. Which entries apply to your deployment depends on what you enable and where you point it.
How to read this list¶
Every row is a capability of the software, enumerated whether or not it is
enabled — the same enumerate-don't-derive rule as the
residency posture, so a reviewer can see a vector
was considered rather than inferring its absence. For the live state of your
deployment, query GET /api/v1/admin/deployment (workspace-admin only), which
reports the enabled transfer vectors without shell access.
The operator column is you: in every row, the receiving service is chosen, contracted, and configured by the deploying organization. DataQ never defaults to a third-party endpoint.
The vectors¶
| # | Service (operator-chosen) | What DataQ sends | Personal data? | When active |
|---|---|---|---|---|
| 1 | Monitored datasources — Snowflake, ADLS Gen2, S3 / S3-compatible, Unity Catalog, Iceberg | Read-only queries; DQ check SQL | Reads whatever the monitored tables hold — this is the primary data flow | Always (the product's purpose) |
| 2 | Orchestration providers — ADF, Airflow, dbt | Polling reads of pipeline/DAG run status; inbound webhooks | No — pipeline metadata only | When orchestration connections exist |
| 3 | Alert delivery — MS Teams / Slack webhooks, SMTP email (incl. SES) | Check names, statuses, suite names and — when a failing sample is attached — redacted sample values | Potentially, in redacted failing samples; recipient addresses | When notifications are configured |
| 4 | Sign-in email (OTP) — the configured SMTP relay | One-time codes to user email addresses | User email addresses (account identifiers, not warehouse content) | otp auth mode |
| 5 | OIDC identity provider — Azure AD, AWS Cognito, any standards-compliant issuer | Standard OIDC flows; DataQ receives (never sends) profile claims | User identity (email, name, subject id) held at the IdP | oidc auth mode |
| 6 | Secret store — Azure Key Vault, AWS Secrets Manager, OpenBao/Vault | Warehouse credentials (write on connection create, read at run time) | No customer data — but the credentials unlock the systems that hold it | Always (one of the four backends) |
| 7 | Telemetry — Azure Application Insights, AWS X-Ray/CloudWatch, any OTLP sink | Traces + structured logs, PII-redacted at the logger | Operational metadata; request ids, not warehouse values | When an exporter is configured |
| 8 | MCP AI clients — whatever model provider stands behind a client holding a valid PAT | Run results, redacted failing samples, check configuration, via the 48 /mcp tools |
Potentially, in redacted samples — the model provider and its jurisdiction are chosen by the token holder | When PATs are issued and /mcp is reachable |
| 9 | Outbound LLM intelligence — DataQ calling a model on its own behalf | Schema + masked profiler statistics for SQL generation and check suggestions; RCA narratives additionally send the triggering check's own observed value, routed through that same column-policy/warehouse-tag masking floor, and its expected value (a check-authored threshold, not warehouse data, so never masked). Never raw sample rows | Potentially — profiler statistics or an observed value, both subject to the masking floor; model provider and jurisdiction are admin-chosen | Live, off by default — an admin must configure a provider + credential before any call leaves |
| 10 | Lineage provider — Marquez / OpenLineage-compatible catalog | Pull of lineage graph metadata | No — table/job names, not row data | When LINEAGE_PROVIDER is configured |
Cloud-platform services that host a deployment (the managed Postgres, Redis, container runtime, object storage of your chosen cloud) are your cloud provider acting as your processor under your existing cloud agreement — they are in scope for your register but are not DataQ-specific and are not repeated here.
Keeping this current — the process¶
This list changes only when the software's outbound surface changes, so it is maintained as code review discipline, not a calendar:
- Any PR that adds an outbound network call to a new service class must update this page in the same PR — same rule as the residency enumeration.
- The quarterly supply-chain audit (CONTRIBUTING rule 39) re-checks the list against the dependency tree as a backstop.
- The LLM row flips from "not built" in the PR that ships the intelligence feature — that PR is the Ch. V trigger the DPIA sheet also names.
Last reviewed: 2026-09-01 (originally 2026-08-21).