# GDPR mapping

EU Regulation 2016/679 — **General Data Protection Regulation**. Edge processes personal data only when the deployer feeds personal data into a dataset. The mapping below documents the controls Edge ships, by article.

## Coverage matrix

| Article          | Principle                                  | How Edge satisfies                                                                   | Where                                                  |
| ---------------- | ------------------------------------------ | ------------------------------------------------------------------------------------ | ------------------------------------------------------ |
| **Art 5(1)(a)**  | Lawfulness, fairness, transparency         | Data only enters when explicitly uploaded; no implicit collection                    | Source code review of `datasets_import.py`             |
| **Art 5(1)(b)**  | Purpose limitation                         | Datasets are scoped to a workspace; cross-workspace queries impossible               | [Security boundaries](/architecture/security.md)       |
| **Art 5(1)(c)**  | Data minimisation                          | Operator chooses what fields enter; no enrichment                                    | Operator config                                        |
| **Art 5(1)(d)**  | Accuracy                                   | Item-level edit/version history; modified\_by + modified\_at fields                  | [Data flow](/architecture/data-flow.md)                |
| **Art 5(1)(e)**  | Storage limitation                         | Backup retention bounded; tenant can purge via SQL on `pb_data`                      | [Backup & recovery](/operations/backup-recovery.md)    |
| **Art 5(1)(f)**  | Integrity & confidentiality                | TLS, RBAC, secret rotation, encryption at rest                                       | [Security boundaries](/architecture/security.md)       |
| **Art 5(2)**     | Accountability                             | Audit log in `admin_actions` collection (append-only)                                | [Architecture overview](/architecture/overview.md)     |
| **Art 17**       | Right to erasure                           | Per-record SQL delete on `pb_data`; tooling planned in Gate 20                       | Manual today, automated planned                        |
| **Art 20**       | Right to data portability                  | `sqlite3 .dump` exports all of a tenant's data in portable SQL                       | [On-prem](/deployment/on-prem.md)                      |
| **Art 25**       | Data protection by design                  | Workspace isolation, no cross-tenant joins, gitleaks at every boundary               | Architecture-wide                                      |
| **Art 30**       | Records of processing                      | Per-tenant `pb_data` is itself the record; queries are workspace-scoped              | Architecture-wide                                      |
| **Art 32**       | Security of processing                     | All Gates 00–07 contribute (see [Banking Readiness](/banking-readiness/overview.md)) | Banking readiness section                              |
| **Art 32(1)(c)** | Ability to restore                         | Restic backups + quarterly restore drill                                             | [Backup & recovery](/operations/backup-recovery.md)    |
| **Art 33**       | Notification of breach to authority (72 h) | Incident-response runbook; severity ladder forces declaration                        | [Incident response](/operations/incident-response.md)  |
| **Art 34**       | Communication of breach to data subject    | Operator-side; Edge provides the audit log to identify affected records              | [Architecture / Data flow](/architecture/data-flow.md) |

## Right of erasure tooling (planned — Gate 20)

Today, Art 17 requests are handled by direct SQL on `pb_data`:

```sql
-- Identify all records linked to a subject across collections
DELETE FROM dataset_items WHERE creator_id = '<user_id>';
DELETE FROM evaluation_metrics WHERE created_by = '<user_id>';
DELETE FROM admin_actions WHERE actor_id = '<user_id>';
-- ... etc
```

Gate 20 adds a CLI:

```bash
edge gdpr erase --subject-id=<id> --workspace=<ws> --dry-run
edge gdpr erase --subject-id=<id> --workspace=<ws> --confirm
```

with an audit trail of the erasure itself (which fields, when, by whom).

## Git history & personal data

Authorship in `git log` is personal data (name + email). The acceptable basis is **legitimate interest** (security audit trail). On Art 17 request from a contributor, the procedure is `git filter-repo --mailmap` rewriting their identity to a pseudonym across all six repos. The original GitLab archive is consulted for legal hold but is **never modified**.

## Data residency (planned — Gate 21)

Today the operator chooses the cloud region of their Cloud Run / on-prem cluster. Gate 21 adds a CLI flag to enforce a region affinity at the control-plane level (for SaaS v2).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.edge.nyami.fr/compliance/gdpr.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.