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 / OneLake, S3 / S3-compatible, Unity Catalog, Iceberg, PostgreSQL, MySQL / MariaDB, Trino, SQL Server / Azure SQL / Synapse / Fabric SQL, Amazon Athena, Amazon Redshift, Google BigQuery | Read-only queries; DQ check SQL (on Unity Catalog, a DQX-engine check also submits a serverless job to your own Databricks workspace) | 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 59 /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; and, separately, OpenLineage emission of a START + terminal RunEvent per suite run with DQ facets (never sample rows) | No — table/job names and check outcomes, not row data | Pull: when LINEAGE_PROVIDER is configured. Emission: when OPENLINEAGE_URL (or the library's own transport config) is set |
| 11 | Audit tamper anchor — an HMAC-signed webhook, or an immutable object store (S3 Object Lock / S3-compatible, Azure immutable blob) | The audit hash-chain head: a SHA-256 hash, a label, the hashed-event count and a timestamp — daily and before every retention purge | No — never an audit event's actor, action or payload | TAMPER_ANCHOR=webhook or object_lock (off by default) |
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-10-20 (originally 2026-08-21).