Skip to content

DOMAIN:GDPR_IMPLEMENTATION

OWNER: julian
UPDATED: 2026-03-24
SCOPE: GDPR compliance for GE as software agency and for client projects GE builds
SERVES: julian (compliance officer), amber (auditor)
ALSO_USED_BY: boris (data handling), anna (privacy specs), aimee (client scoping)

OVERVIEW

REGULATION: General Data Protection Regulation (EU) 2016/679
EFFECTIVE: 25 May 2018
SUPERVISORY_AUTHORITY: Autoriteit Persoonsgegevens (Dutch DPA)
GE_ROLES:
- CONTROLLER: for GE's own data (agent operational data, employee/contractor data)
- PROCESSOR: when processing client personal data as part of software development
- DESIGNER: when building systems that process personal data for clients (Art. 25 obligations)

KEY_PRINCIPLE: GE builds privacy INTO client products, not as an afterthought.
CROSS_REF: domains/privacy/index.md for detailed Art. 25, Art. 32, Art. 35 implementation

DATA_PROCESSING_AGREEMENTS

TAG:GDPR_ART28 TAG:DPA

WHEN_REQUIRED

  • GE processes personal data on behalf of a client (processor role)
  • Client provides personal data for testing, staging, or development
  • GE accesses client production systems containing personal data
  • GE hosts client applications that process personal data

MANDATORY_CLAUSES (Art. 28(3))

  1. Process only on documented instructions from controller
  2. Ensure persons processing have committed to confidentiality
  3. Take all measures per Art. 32 (security of processing)
  4. Conditions for engaging sub-processors (prior authorization)
  5. Assist controller with data subject rights requests
  6. Assist controller with Art. 32-36 obligations (security, DPIA, breach notification)
  7. Delete or return all personal data after service ends
  8. Make available all information necessary to demonstrate compliance
  9. Allow and contribute to audits

GE_DPA_TEMPLATE

LOCATION: wiki/docs/company/legal/dpa-template.md
CONTENT:
- GE identified as processor, client as controller
- Processing purposes: software development, testing, deployment, maintenance
- Categories of data: as specified per project (PII categories enumerated)
- Data subjects: as specified per project (end users, employees, etc.)
- Duration: project duration + retention period
- Sub-processors: listed with purpose (LLM providers, hosting, monitoring)
- Security measures: reference to GE's security controls (ISO 27001 Annex A)
- Data location: EU only (Netherlands, GE infrastructure)
- Breach notification: within 24 hours of becoming aware (contractual, tighter than 72hr statutory)
- Audit rights: client may audit GE's compliance on reasonable notice
- Data deletion: within 30 days of project completion or client request

SUB_PROCESSOR_MANAGEMENT

LIST_MAINTAINED_BY: julian
SUB_PROCESSORS:
- Anthropic (Claude API) — LLM inference, NO personal data transmitted
- OpenAI (GPT API) — LLM inference, NO personal data transmitted
- Google (Gemini API) — LLM inference, NO personal data transmitted
NOTE: GE data masking ensures NO personal data reaches LLM providers
OBLIGATION: notify client of new sub-processors, allow objection within 14 days
EVIDENCE: sub-processor register, data masking verification logs
AGENT: julian (sub-processor management)

PRIVACY_BY_DESIGN

TAG:GDPR_ART25 TAG:PRIVACY_BY_DESIGN

OBLIGATION

Art. 25(1): implement appropriate technical and organizational measures at time of determination of means and at time of processing.
Art. 25(2): by default, only personal data necessary for each specific purpose is processed.
NOTE: applies to GE when BUILDING systems for clients — GE must engineer privacy in.

GE_IMPLEMENTATION_IN_DELIVERY_PIPELINE

INTAKE (Aimee):
- Privacy requirements identified during scoping
- Data categories and subjects enumerated
- Legal basis for processing assessed per purpose
- International transfer requirements flagged

SPECIFICATION (Anna):
- Privacy requirements included in formal specification
- Data minimization: specify MINIMUM data fields per feature
- Purpose limitation: specify purpose per data collection point
- Storage limitation: specify retention period per data category
- Privacy-enhancing technologies identified (pseudonymization, encryption, access control)

TDD (Antje):
- Privacy test cases written before development:
- Test: system does not collect data beyond specification
- Test: consent withdrawal stops processing within defined timeframe
- Test: data subject access request returns complete dataset
- Test: data deletion removes all instances (including backups within defined period)
- Test: default settings are most privacy-friendly option
- Test: no PII in logs

DEVELOPMENT (Team Alpha/Beta):
- Semgrep rules enforce: no PII in logs, no hardcoded emails, parameterized queries
- Data masking in non-production environments
- Encryption at rest and in transit
- Role-based access control with least privilege

CODE_REVIEW (Koen):
- Privacy-specific review checklist:
- CHECK: data collected matches specification (no over-collection)
- CHECK: consent flow correct (no pre-checked boxes, granular categories)
- CHECK: data subject rights endpoints implemented
- CHECK: retention logic implemented per data category
- CHECK: no PII leakage in logs, error messages, URLs

ADVERSARIAL_TESTING (Ashley):
- Privacy attack scenarios:
- Attempt: extract PII from error messages
- Attempt: access data across tenant boundaries
- Attempt: reconstruct deleted data
- Attempt: bypass consent mechanisms
- Attempt: enumerate user accounts

HOEPMAN_STRATEGIES_APPLIED:
1. MINIMIZE: collect minimum data per feature (specification-driven)
2. HIDE: encrypt PII at rest and in transit, pseudonymize where possible
3. SEPARATE: isolate client data per tenant (three-zone architecture)
4. AGGREGATE: use aggregated/anonymized data for analytics
5. INFORM: clear privacy notices, transparent processing descriptions
6. CONTROL: data subject rights implemented (access, rectification, erasure, portability)
7. ENFORCE: automated privacy controls (retention, access control, consent enforcement)
8. DEMONSTRATE: audit trails, privacy impact assessments, compliance documentation

EVIDENCE: specification documents, privacy test results, code review records, adversarial test reports
AGENT: anna (specification), antje (TDD), koen (review), ashley (adversarial), julian (oversight)

DATA_SUBJECT_RIGHTS

TAG:GDPR_ART15_22 TAG:DSR

RIGHTS_AND_IMPLEMENTATION

ART_15 — RIGHT_OF_ACCESS:
- REQUIRES: provide copy of all personal data being processed, within 1 month
- GE_BUILDS: /api/privacy/data-export endpoint in client projects
- FORMAT: machine-readable (JSON/CSV), human-readable summary
- SCOPE: all data, all systems, all backup locations
- VERIFICATION: identity verification before data release

ART_16 — RIGHT_TO_RECTIFICATION:
- REQUIRES: correct inaccurate personal data without undue delay
- GE_BUILDS: profile edit functionality with audit trail
- PROPAGATION: correction propagated to all downstream systems

ART_17 — RIGHT_TO_ERASURE:
- REQUIRES: delete personal data when: consent withdrawn, purpose fulfilled, unlawful processing, legal obligation
- GE_BUILDS: /api/privacy/delete-account endpoint with cascading deletion
- SCOPE: production data, backups (within backup cycle), logs (pseudonymization), analytics (anonymization)
- EXCEPTION: data required for legal obligation or defense of legal claims
- TIMELINE: execute within 1 month, backup cleanup within backup rotation cycle

ART_18 — RIGHT_TO_RESTRICTION:
- REQUIRES: restrict processing (store but do not process) in specific circumstances
- GE_BUILDS: processing_restricted flag per user account
- CIRCUMSTANCES: accuracy contested, processing unlawful but no deletion requested, data needed for legal claims, pending objection assessment

ART_20 — RIGHT_TO_DATA_PORTABILITY:
- REQUIRES: provide data in structured, commonly used, machine-readable format
- GE_BUILDS: export in JSON and CSV formats
- SCOPE: data provided by data subject + data generated by observation (usage data)
- DIRECT_TRANSMISSION: support transfer to another controller where technically feasible

ART_21 — RIGHT_TO_OBJECT:
- REQUIRES: stop processing based on legitimate interest upon objection
- GE_BUILDS: objection mechanism per processing purpose
- DIRECT_MARKETING: absolute right to object, no balancing test needed

ART_22 — AUTOMATED_DECISION_MAKING:
- REQUIRES: right not to be subject to decisions based solely on automated processing with legal/significant effects
- GE_BUILDS: human review mechanism for automated decisions
- IF_AI_USED: meaningful information about logic, significance, envisaged consequences
- SAFEGUARDS: right to obtain human intervention, express point of view, contest decision

DSR_PROCESS_FOR_GE_OPERATIONS

  • REQUEST_CHANNEL: email to privacy contact or through admin-ui
  • VERIFICATION: identity verification before processing request
  • LOGGING: all DSR requests logged with timestamps, actions, and completion
  • TIMELINE: acknowledge within 48 hours, complete within 1 month (extendable to 3 months for complex requests)
  • REPORTING: monthly DSR summary for management review
    AGENT: julian (DSR process), boris (data retrieval/deletion)

BREACH_NOTIFICATION

TAG:GDPR_ART33_34 TAG:BREACH_NOTIFICATION

72_HOUR_RULE (Art. 33)

TRIGGER: personal data breach (confidentiality, integrity, or availability of personal data)
TIMELINE: notify Autoriteit Persoonsgegevens within 72 hours of becoming AWARE
NOTE: "aware" = when reasonable degree of certainty that breach has occurred
IF_LATE: document reasons for delay

NOTIFICATION_TO_DPA_MUST_INCLUDE (Art. 33(3))

  1. Nature of breach (categories + approximate numbers of data subjects and records)
  2. Name and contact details of DPO / contact point
  3. Likely consequences of breach
  4. Measures taken or proposed to address breach and mitigate effects

NOTIFICATION_TO_DATA_SUBJECTS (Art. 34)

TRIGGER: breach likely results in HIGH RISK to rights and freedoms
NOT_REQUIRED_IF:
- Data was encrypted/unintelligible to unauthorized party
- Subsequent measures ensure high risk no longer likely to materialize
- Would involve disproportionate effort (use public communication instead)

GE_BREACH_RESPONSE_PROCEDURE

PHASE_1_DETECTION (0-4 hours):
- Ron/Mira detect potential data breach via monitoring
- Mira classifies: is personal data affected? (if no: security incident only, not data breach)
- IF personal data breach: Julian notified immediately
- Julian performs initial assessment: scope, categories, risk level
- Decision: does this require DPA notification? (document reasoning either way)

PHASE_2_CONTAINMENT (4-24 hours):
- Technical containment (see incident-response procedures)
- Preserve evidence for investigation
- Begin data subject impact assessment
- Draft DPA notification (do not wait for complete information)

PHASE_3_NOTIFICATION (24-72 hours):
- Submit notification to Autoriteit Persoonsgegevens via their online portal
- Include all Art. 33(3) information available
- Mark notification as "initial" if investigation ongoing
- IF high risk to data subjects: prepare data subject notification (Art. 34)
- IF GE is processor: notify controller client within 24 hours (contractual DPA obligation)

PHASE_4_SUPPLEMENTARY (72 hours+):
- Supplement initial notification with additional findings
- Complete data subject notification if required
- Implement remediation measures
- Document root cause and corrective actions
- Update controls to prevent recurrence

BREACH_REGISTER (Art. 33(5))

REQUIREMENT: document ALL breaches, even those not notified to DPA
FIELDS:
- breach_id, detected_at, assessed_at, notified_dpa_at (if applicable)
- nature, categories_of_data, approximate_number_affected
- consequences (assessed), measures_taken
- notification_decision (yes/no with rationale)
- data_subjects_notified (yes/no with rationale)
- controller_notified_at (if GE is processor)
STORAGE: PostgreSQL data_breaches table
AGENT: julian (breach register), mira (detection input)

CROSS_BORDER_TRANSFERS

TAG:GDPR_ART44_49 TAG:TRANSFERS

GE_POSITION

PRINCIPLE: EU-only processing for all client personal data
INFRASTRUCTURE: k3s cluster in Netherlands (single physical location)
LLM_PROVIDERS: NO personal data sent to LLM APIs (data masking enforced)
RESULT: minimal transfer risk — no personal data leaves EU

TRANSFER_MECHANISMS (when needed)

HIERARCHY:
1. Adequacy decision (Art. 45) — check EC list
2. Standard Contractual Clauses (Art. 46(2)(c)) — 2021 version mandatory, with TIA
3. Binding Corporate Rules (Art. 47) — intra-group only
4. Derogations (Art. 49) — narrow, case-by-case

TRANSFER_IMPACT_ASSESSMENT (TIA)

REQUIRED_WITH: SCCs (Schrems II, CJEU C-311/18)
ASSESS:
1. Legislation and practices of destination country
2. Whether third-country authorities can access transferred data
3. Whether supplementary measures can ensure essential equivalence
4. Document assessment and conclusion
UPDATE: when laws change, when new transfer mechanism adopted, annually minimum

DATA_PROCESSING_FRAMEWORK (DPF) — US

STATUS: active (EU-US adequacy decision July 2023)
RISK: NOYB challenge announced, PCLOB quorum concerns
MITIGATION: maintain SCC readiness as fallback
GE_RELEVANCE: LLM providers are US companies BUT no personal data transferred

CLIENT_PROJECT_TRANSFERS

  • Assess per client project: does the application transfer data outside EU?
  • If yes: implement appropriate safeguards in application architecture
  • Document transfer mechanism in DPIA
  • Cookie consent must cover international transfers (transparency)
    AGENT: julian (transfer assessment), anna (specification), boris (data controls)

TAG:EPRIVACY TAG:COOKIES

LEGAL_BASIS: ePrivacy Directive (2002/58/EC) Art. 5(3), Dutch Telecommunicatiewet Art. 11.7a
CROSS_REF: domains/privacy/index.md COOKIE_CONSENT section for full implementation checklist

GE_BUILD_STANDARD_FOR_CLIENT_PROJECTS

ARCHITECTURE:
- Cookie consent as server-side enforced (not just client-side banner)
- No cookies/trackers set before explicit consent
- Consent stored with: timestamp, policy version, specific categories, withdrawal mechanism
- Third-party scripts blocked until relevant category consented
- Consent Management Platform (CMP) recommendation: open-source (Orejime, Klaro) or certified (OneTrust, Cookiebot)

MANDATORY_CHECKLIST:
CHECK: zero cookies before consent (verify with browser dev tools)
CHECK: granular categories (necessary, analytics, marketing, functional)
CHECK: accept and reject buttons equally prominent
CHECK: no pre-checked checkboxes
CHECK: consent logged server-side with full audit trail
CHECK: withdrawal as easy as giving consent (persistent settings link)
CHECK: no cookie wall (site functional without consent)
CHECK: Google Consent Mode = Basic Mode only
CHECK: third-party scripts conditionally loaded
CHECK: re-consent on policy change
CHECK: consent renewal annually

TESTING (Antje/Marije):
- Test: site functional with all cookies rejected
- Test: no tracking cookies present before consent
- Test: consent withdrawal stops all non-essential cookies
- Test: consent banner reappears on policy change
- Test: reject button equally accessible as accept button

AGENT: julian (consent requirements), antje (test cases), koen (code review)

PRIVACY_IMPACT_ASSESSMENTS

TAG:GDPR_ART35 TAG:DPIA

WHEN_REQUIRED

  • Systematic/extensive automated evaluation with legal/significant effects (profiling)
  • Large-scale processing of special category data (Art. 9)
  • Systematic monitoring of publicly accessible area
  • Dutch DPA mandatory list (see privacy/index.md)
  • ANY use of AI/ML processing personal data (precautionary approach)
  • New technology not previously assessed

GE_DPIA_PROCESS

TRIGGER: Aimee identifies DPIA requirement during project scoping
ASSESSMENT_LEAD: julian (Compliance Officer)
TEMPLATE_LOCATION: wiki/docs/company/legal/dpia-template.md

DPIA_CONTENTS (Art. 35(7)):
1. Systematic description of processing operations and purposes
2. Assessment of necessity and proportionality
3. Assessment of risks to rights and freedoms of data subjects
4. Measures to address risks (safeguards, security measures, mechanisms)

PROCESS:
1. Aimee flags DPIA need during scoping
2. Julian conducts DPIA using template
3. Anna incorporates DPIA findings into formal specification
4. Development implements safeguards identified in DPIA
5. Amber verifies safeguards implemented correctly
6. Julian signs off on DPIA before go-live
7. DPIA reviewed annually or on significant change

STORAGE: PostgreSQL dpias table, wiki for human-readable version
RETENTION: duration of processing + 3 years

DPA_CONSULTATION (Art. 36)

IF: DPIA indicates high risk that cannot be mitigated
THEN: consult Autoriteit Persoonsgegevens before processing
TIMELINE: DPA has 8 weeks to respond (extendable by 6 weeks)
NOTE: this is rare — indicates controls are insufficient

AGENT: julian (DPIA lead), aimee (trigger), anna (specification input), amber (verification)

RECORDS_OF_PROCESSING (Art. 30)

TAG:GDPR_ART30 TAG:ROPA

AS_CONTROLLER (GE operations)

MAINTAIN_RECORDS_OF:
- Name and contact details of controller (GE)
- Purposes of processing
- Categories of data subjects and personal data
- Categories of recipients (including third countries)
- Transfers to third countries (with safeguards)
- Retention periods per category
- Description of technical and organizational security measures

AS_PROCESSOR (client projects)

MAINTAIN_RECORDS_OF:
- Name and contact details of processor (GE) and controller (client)
- Categories of processing carried out on behalf of controller
- Transfers to third countries (with safeguards)
- Description of technical and organizational security measures

FORMAT: structured data in PostgreSQL, human-readable export for audit
REVIEW: annually, or on significant processing change
AGENT: julian (ROPA maintenance)

TAG:GDPR_ART6 TAG:LEGAL_BASIS

FOR_GE_OPERATIONS

  • Agent operational data: legitimate interest (system operation)
  • Incident records: legitimate interest (security) + legal obligation (NIS2)
  • Client contact data: contractual necessity (Art. 6(1)(b))
  • Marketing: consent (Art. 6(1)(a))

FOR_CLIENT_PROJECTS (GE advises during scoping)

COMMON_BASES:
- Art. 6(1)(a) CONSENT: marketing, analytics, non-essential cookies
- Art. 6(1)(b) CONTRACT: order processing, account management, delivery
- Art. 6(1)(c) LEGAL_OBLIGATION: tax records, regulatory reporting
- Art. 6(1)(f) LEGITIMATE_INTEREST: fraud prevention, security, basic analytics
NOTE: legitimate interest requires balancing test (three-step assessment per EDPB)
NOTE: legitimate interest NOT valid for cookie-based tracking (EDPB Guidelines 1/2024)

AGENT: julian (legal basis guidance), aimee (scoping assessment)

COMPLIANCE_EVIDENCE_SUMMARY

Requirement Evidence Agent Frequency
DPA with clients Signed DPA documents julian Per client
Sub-processor register Sub-processor list with DPAs julian On change
Privacy by design Spec + test + review records anna, antje, koen Per feature
DSR handling DSR log with timelines julian, boris Per request
Breach register Breach records (all, not just notified) julian, mira Per breach
Cookie consent Consent logs, audit results julian, koen Per project
DPIA Assessment documents julian, aimee Per project if triggered
ROPA Processing records julian Annual review
Transfer safeguards TIA documents, SCC records julian Annual + on change
Art. 32 security Security control evidence julian, rutger Continuous + annual

READ_ALSO: domains/privacy/index.md, domains/eu-regulation/index.md, iso27001-controls.md, evidence-automation.md