GDPR Technical Architecture Guide

Evidence boundary: This is an engineering control map, not legal advice or a statement that TeaQL makes an application GDPR compliant. The controller and processor must establish lawful processing, configure the application, test every access path, and retain evidence appropriate to their obligations.

The primary legal source is Regulation (EU) 2016/679 on EUR-Lex. Article 5 covers purpose limitation, data minimisation, storage limitation, and accountability. Article 25 covers data protection by design and by default.

Control Map

Engineering concern	TeaQL mechanism that can help	Application and organizational responsibility
Data minimisation	Generated selection APIs and explicit relation shaping.	Define the minimum fields for each purpose; verify responses, exports, errors, logs, and custom SQL paths.
Purpose limitation	Query comment and purpose; mutation auditAs / audit_as.	Establish lawful purposes and prevent incompatible processing; intent text is evidence, not authorization.
Accountability	UserContext, mutation audit metadata, safe audit-event configuration.	Authenticate the actor; verify event coverage, durability, access, retention, deletion, alerting, and tamper resistance.
Privacy by design/default	Model review, generated typed APIs, sensitive-field metadata.	Choose and test restrictive defaults; TeaQL does not automatically classify every field or block every unsafe path.
Data-subject access/portability	Typed queries and explicit export services.	Locate all stores, verify identity and legal scope, produce the required format, and protect the export.
Erasure/restriction	Generated mutation APIs and application workflows.	Select the lawful strategy, cover replicas/backups/downstream systems, preserve required records, and prove completion.
Storage limitation	Model fields and audited retention jobs.	Define schedules and legal holds; execute and monitor deletion/anonymization across every store.
Tenant/data isolation	Trusted context plus application request policies.	Resolve authoritative scope server-side and test list, ID, relation, export, batch, and background-job paths.

Minimal Query Shape

Keep trusted authorization and scope in an application-owned helper, shape the smallest result, and put intent immediately before execution:

authorizedUserDirectory(ctx)
    .comment("Query the authorized user directory")
    .purpose("Fulfil the approved directory request")
    .executeForList(ctx);

authorizedUserDirectory is an application helper, not a generated TeaQL method. Its implementation and returned selection must be reviewed against the actual generated request API. A purpose string does not grant access.

Sensitive Fields and Audit Masking

_audit_mask_fields can carry masking metadata into generated output. Current Golden Path evidence confirms evaluator guidance for an email field and the regenerated metadata. It does not yet prove every runtime sink and failure path is free of raw personal data.

Verify separately:

• field-level authorization and selection;
• safe versus raw/debug audit sinks;
• application responses and exception payloads;
• support tools, exports, analytics, events, and backups;
• encryption, secrets management, retention, deletion, and residency.

See Sensitive Field Handling and Security and Trust Boundaries.

Audit Evidence

For each processing path, test that the evidence answers:

• which authenticated user or service initiated it;
• which tenant and application operation were in scope;
• what business purpose was declared;
• which data categories and records were affected;
• whether the operation succeeded or failed;
• which sink received the event and under which retention/access policy.

TeaQL can provide intent and runtime hooks on registered paths. Handwritten SQL, external tools, direct database access, exports, and downstream processors require their own coverage.

Data-Subject Workflow Checks

Workflow	Required verification
Access/export	Identity verification, complete store inventory, authorized relations, secure delivery, and export audit.
Rectification	Exact generated mutation method, authorization, audited change, propagation to dependent stores, and conflict handling.
Erasure	Hard delete, anonymization, restriction, or retention exception chosen under reviewed policy; backups and downstream copies addressed.
Restriction/objection	Processing gates apply to every read/write/batch path and remain effective after regeneration.

Tenant Isolation Test

Use at least two tenants and attempt list, direct-ID, nested relation, dynamic filter, export, and background-job access. An untrusted filter containing the other tenant's identifier must not broaden the trusted request. See Multi-Tenant Query Boundary.

Review Checklist

• The processing purpose and legal basis are documented outside the query code.
• Generated selections and response mappings expose only necessary data.
• comment and purpose are present but are not treated as authorization.
• Mutations use audit intent and the actor comes from authenticated context.
• Audit sinks, raw/debug paths, exports, custom SQL, and external tools are tested.
• Retention, erasure, backup, residency, and downstream-processor behavior are documented.
• A privacy/legal reviewer approves the complete system, not only the TeaQL layer.

This guide describes technical patterns and does not replace legal advice, records of processing, data-protection impact assessment, contracts, or regulator guidance.