For procurement and counsel. This DPA incorporates the European Commission’s Standard Contractual Clauses (Module 2, controller-to-processor), the UK Addendum and CCPA service-provider terms, and is executed as an attachment to the order form. Contact [email protected] for a countersigned copy.
1. Roles and the nature of processing
| Data | Customer’s role | EvalQA’s role | Where it is processed |
|---|---|---|---|
| Schema metadata (INFORMATION_SCHEMA, dbt manifest) | Controller | Processor | Customer perimeter (extraction); EvalQA (invariant synthesis, metadata only) |
| Generated SQL, prompts, tool calls | Controller | Processor | Customer perimeter only in Mode 1; EvalQA under Mode 2 authorisation, pseudonymised, 14-day TTL |
| Query result-set data | Controller | None — never transmitted | Customer perimeter only |
| Hashes, invariant status, nonces, signatures | Controller | Processor | EvalQA immutable store |
| qabit console ratings and rater profiles | Controller | Processor | EvalQA hosting |
2. The limited processing licence
A blanket “zero vendor rights” clause would make delivering the service legally impossible (audit finding #24). Instead: the customer grants EvalQA a limited, non-exclusive, revocable licence to process customer data solely to deliver the contracted service — invariant synthesis, execution, adjudication, reporting and recall. No other purpose. No derivative learning on customer data unless the customer switches on the named option below.
Non-training commitment
We do not use customer data to train or fine-tune any model, ours or anyone else’s. Our detection engine is built on synthetic and internal fixtures so that our improvement never depends on a customer’s opt-in. If the customer chooses to allow de-identified examples for reviewer calibration, that is a named field on the order form, off by default, and it trains people, not models.
3. Evidence modes as processing instructions
The evidence mode named on the order form is the customer’s documented processing instruction. Changing mode requires written authorisation from the customer’s named owner.
- Mode 1 — local-only. Default. Processing of raw data occurs only inside the customer boundary. EvalQA receives hashes, booleans, counts, latency and signed manifests.
- Mode 2 — sanitised escalation. On explicit authorisation per incident: pseudonymised AST snippets and execution plans, encrypted at rest under a per-tenant KMS key, deleted at a 14-day TTL.
- Mode 3 — restricted VDI review. Remote visual inspection by a named reviewer inside customer-controlled infrastructure. The parties acknowledge this is processing under applicable law even though no data is transferred.
4. Redaction and pseudonymisation
Before any Mode 2 export, automated regex and NER tokenisation (Presidio / GLiNER) removes named entities and masks literal values; column and table identifiers are stably pseudonymised with semantic role tags so that evaluation utility survives. Disclosure controls are risk-tiered with reference to NIST SP 800-188; we do not claim that a fixed “≥5 records” rule confers privacy (audit finding #25).
5. Personnel safeguards
Reviewer governance
- Individual confidentiality agreement covering all customer content indefinitely
- Government ID verification before any paid task
- Qualification battery and continuous gold-canary monitoring
- Processing location and access authorisation recorded per engagement
Access restrictions
- Per-engagement, time-boxed access; nothing standing
- Every view and rating logged and attributable; log available to the customer
- Mode 3 only for Tier-1 regulated schemas, inside customer VDI
- Background screening for financial, health and legal schemas
6. Subprocessors and advance notice
Listed by name on the subprocessors page. Thirty days’ notice before a new subprocessor processes customer data; reasonable objection leads to a good-faith resolution or termination of the affected service without penalty.
7. Technical and organisational measures
- Encryption in transit (TLS) and at rest; per-tenant KMS keys for Mode 2 diagnostics
- Immutable object-lock store containing only non-sensitive cryptographic artefacts
- Signed runner builds (Sigstore/Cosign), ephemeral nonces, challenge-suite pre-commitment, dual-signed manifests
- Strict Content-Security-Policy, CSRF protection, rate limiting, private data store outside the web root
- Incident notification within 48 hours (24 where required); method recall protocol with a 4-hour automated hold
8. Return, deletion and cryptographic erasure
Signed bundles already live in the customer’s perimeter; there is nothing to return. On termination or written request, Mode 2 diagnostics are deleted and the tenant KMS key is destroyed, rendering any residual encrypted payload unrecoverable; we confirm in writing within 30 days. Hashes and signatures in the immutable store are retained because they contain no personal data and because a notary record must outlive the engagement to remain meaningful.
9. Audit assistance
We provide the information reasonably necessary to demonstrate compliance, including access logs for your data, the CAIQ v4 pack, and the assurance bundles’ chain-of-custody records. On-site audits are by agreement, once per year unless a regulator requires otherwise.
10. International transfers
Where Mode 2 or Mode 3 involves a transfer out of the UK or EEA, the SCCs and UK Addendum apply together with a documented Transfer Impact Assessment, subprocessor controls and local-law analysis. SCCs alone are not treated as sufficient (audit finding #33).