mirror of
https://github.com/github/awesome-copilot.git
synced 2026-04-13 11:45:56 +00:00
feat: add GDPR-compliant engineering practices skill documentation (#1230)
* feat: add GDPR-compliant engineering practices skill documentation * Add GDPR compliance references for Security and Data Rights - Introduced a comprehensive Security.md file detailing encryption, password hashing, secrets management, anonymization, cloud practices, CI/CD controls, and incident response protocols. - Created a Data Rights.md file outlining user rights implementation, Record of Processing Activities (RoPA), consent management, sub-processor management, and DPIA triggers. * Refine GDPR compliance documentation by removing unnecessary symbols and ensuring clarity in security and data rights references * refactor: streamline description formatting in GDPR compliance skill documentation --------- Co-authored-by: Aaron Powell <me@aaron-powell.com>
This commit is contained in:
Mikael
GitHub
177
skills/gdpr-compliant/references/data-rights.md
Normal file
177
skills/gdpr-compliant/references/data-rights.md
Normal file
@@ -0,0 +1,177 @@
|
||||
# GDPR Reference — Data Rights, Accountability & Governance
|
||||
|
||||
Load this file when you need implementation detail on:
|
||||
user rights endpoints, Data Subject Request (DSR) workflow,
|
||||
Record of Processing Activities (RoPA), consent management.
|
||||
|
||||
---
|
||||
|
||||
## User Rights Implementation (Articles 15–22)
|
||||
|
||||
Every right MUST have a tested API endpoint or documented back-office process
|
||||
before the system goes live. Respond to verified requests within **30 calendar days**.
|
||||
|
||||
| Right | Article | Engineering implementation |
|
||||
|---|---|---|
|
||||
| Right of access | 15 | `GET /api/v1/me/data-export` — all personal data, JSON or CSV |
|
||||
| Right to rectification | 16 | `PUT /api/v1/me/profile` — propagate to all downstream stores |
|
||||
| Right to erasure | 17 | `DELETE /api/v1/me` — scrub all stores per erasure checklist |
|
||||
| Right to restriction | 18 | `ProcessingRestricted` flag on user record; gate non-essential processing |
|
||||
| Right to portability | 20 | Same as access endpoint; structured, machine-readable (JSON) |
|
||||
| Right to object | 21 | Opt-out endpoint for legitimate-interest processing; honor immediately |
|
||||
| Automated decision-making | 22 | Expose a human review path + explanation of the logic |
|
||||
|
||||
### Erasure Checklist — MUST cover all stores
|
||||
|
||||
When `DELETE /api/v1/me` is called, the erasure pipeline MUST scrub:
|
||||
|
||||
- Primary relational database (anonymize or delete rows)
|
||||
- Read replicas
|
||||
- Search index (Elasticsearch, Azure Cognitive Search, etc.)
|
||||
- In-memory cache (Redis, IMemoryCache)
|
||||
- Object storage (S3, Azure Blob — profile pictures, documents)
|
||||
- Email service logs (Brevo, SendGrid — delivery logs)
|
||||
- Analytics platform (Mixpanel, Amplitude, GA4 — user deletion API)
|
||||
- Audit logs (anonymize identifying fields — do not delete the event)
|
||||
- Backups (document the backup TTL; accept that backups expire naturally)
|
||||
- CDN edge cache (purge if personal data may be cached)
|
||||
- Third-party sub-processors (trigger their deletion API or document the manual step)
|
||||
|
||||
### Data Export Format (`GET /api/v1/me/data-export`)
|
||||
|
||||
```json
|
||||
{
|
||||
"exportedAt": "2025-03-30T10:00:00Z",
|
||||
"subject": {
|
||||
"id": "uuid",
|
||||
"email": "user@example.com",
|
||||
"createdAt": "2024-01-15T08:30:00Z"
|
||||
},
|
||||
"profile": { ... },
|
||||
"orders": [ ... ],
|
||||
"consents": [ ... ],
|
||||
"auditEvents": [ ... ]
|
||||
}
|
||||
```
|
||||
|
||||
- MUST be machine-readable (JSON preferred, CSV acceptable).
|
||||
- MUST NOT be a PDF screenshot or HTML page.
|
||||
- MUST include all stores listed in the RoPA for this user.
|
||||
|
||||
### DSR Tracker (back-office)
|
||||
|
||||
Implement a **Data Subject Request tracker** with:
|
||||
- Incoming request date
|
||||
- Request type (access / rectification / erasure / portability / restriction / objection)
|
||||
- Verification status (identity confirmed y/n)
|
||||
- Deadline (received date + 30 days)
|
||||
- Assigned handler
|
||||
- Completion date and outcome
|
||||
- Notes
|
||||
|
||||
Automate the primary store scrubbing; document manual steps for third-party stores.
|
||||
|
||||
---
|
||||
|
||||
## Record of Processing Activities (RoPA)
|
||||
|
||||
Maintain as a living document (Markdown, YAML, or JSON) version-controlled in the repo.
|
||||
Update with **every** new feature that introduces a processing activity.
|
||||
|
||||
### Minimum fields per processing activity
|
||||
|
||||
```yaml
|
||||
- name: "User account management"
|
||||
purpose: "Create and manage user accounts for service access"
|
||||
legalBasis: "Contract (Art. 6(1)(b))"
|
||||
dataSubjects: ["Registered users"]
|
||||
personalDataCategories: ["Name", "Email", "Password hash", "IP address"]
|
||||
recipients: ["Internal engineering team", "Brevo (email delivery)"]
|
||||
retentionPeriod: "Account lifetime + 12 months"
|
||||
transfers:
|
||||
outside_eea: true
|
||||
safeguard: "Brevo — Standard Contractual Clauses (SCCs)"
|
||||
securityMeasures: ["TLS 1.3", "AES-256 at rest", "bcrypt password hashing"]
|
||||
dpia_required: false
|
||||
```
|
||||
|
||||
### Legal basis options (Art. 6)
|
||||
|
||||
| Basis | When to use |
|
||||
|---|---|
|
||||
| `Contract (6(1)(b))` | Processing necessary to fulfill the service contract |
|
||||
| `Legitimate interest (6(1)(f))` | Fraud prevention, security, analytics (requires balancing test) |
|
||||
| `Consent (6(1)(a))` | Marketing, non-essential cookies, optional profiling |
|
||||
| `Legal obligation (6(1)(c))` | Tax records, anti-money-laundering |
|
||||
| `Vital interest (6(1)(d))` | Emergency situations only |
|
||||
| `Public task (6(1)(e))` | Public authorities |
|
||||
|
||||
---
|
||||
|
||||
## Consent Management
|
||||
|
||||
### MUST
|
||||
|
||||
- Store consent as an **immutable event log**, not a mutable boolean flag.
|
||||
- Record: what was consented to, when, which version of the privacy policy, the mechanism.
|
||||
- Load analytics / marketing SDKs **conditionally** — only after consent is granted.
|
||||
- Provide a consent withdrawal mechanism as easy to use as the consent grant.
|
||||
|
||||
### Consent store schema (minimum)
|
||||
|
||||
```sql
|
||||
CREATE TABLE ConsentRecords (
|
||||
Id UUID PRIMARY KEY,
|
||||
UserId UUID NOT NULL,
|
||||
Purpose VARCHAR(100) NOT NULL, -- e.g. "marketing_emails", "analytics"
|
||||
Granted BOOLEAN NOT NULL,
|
||||
PolicyVersion VARCHAR(20) NOT NULL,
|
||||
ConsentedAt TIMESTAMPTZ NOT NULL,
|
||||
IpAddressHash VARCHAR(64), -- HMAC-SHA256 of anonymized IP
|
||||
UserAgent VARCHAR(500)
|
||||
);
|
||||
```
|
||||
|
||||
### MUST NOT
|
||||
|
||||
- MUST NOT pre-tick consent checkboxes.
|
||||
- MUST NOT bundle consent for marketing with consent for service delivery.
|
||||
- MUST NOT make service access conditional on marketing consent.
|
||||
- MUST NOT use dark patterns (e.g., "Accept all" prominent, "Reject" buried).
|
||||
|
||||
---
|
||||
|
||||
## Sub-processor Management
|
||||
|
||||
Maintain a **sub-processor list** updated with every new SaaS tool or cloud service
|
||||
that touches personal data.
|
||||
|
||||
Minimum fields per sub-processor:
|
||||
|
||||
| Field | Example |
|
||||
|---|---|
|
||||
| Name | Brevo |
|
||||
| Service | Transactional email |
|
||||
| Data categories transferred | Email address, name, email content |
|
||||
| Processing location | EU (Paris) |
|
||||
| DPA signed | 2024-01-10 |
|
||||
| DPA URL / reference | [link] |
|
||||
| SCCs applicable | N/A (EU-based) |
|
||||
|
||||
**MUST** review the sub-processor list annually and upon any change.
|
||||
**MUST NOT** allow data to flow to a new sub-processor before a DPA is signed.
|
||||
|
||||
---
|
||||
|
||||
## DPIA Triggers (Article 35)
|
||||
|
||||
A DPIA is **mandatory** before processing that is likely to result in a high risk. Triggers include:
|
||||
|
||||
- Systematic and extensive profiling with significant effects on individuals
|
||||
- Large-scale processing of special category data (health, biometric, racial origin, sexual orientation, religion)
|
||||
- Systematic monitoring of publicly accessible areas (CCTV, location tracking)
|
||||
- Processing of children's data at scale
|
||||
- Innovative technology with unknown privacy implications
|
||||
- Matching or combining datasets from multiple sources
|
||||
|
||||
When in doubt: conduct the DPIA anyway. Document the outcome.
|
||||
Reference in New Issue
Block a user