GDPR Principles and Compliance Questions

Approach (short)
As a Security Architect I separate responsibilities by law: the controller determines purposes/means of processing and thus owns risk/architectural decisions; the processor acts on instructions and implements technical and organizational measures (TOMs) to meet controller requirements.

Typical controls — Controller (technical obligations)

• Data classification, retention policies, lawful-basis mapping
• Privacy-by-design: minimization, pseudonymization default in architecture
• Access control policy, entitlement review cadence, consent tracking systems
• DPIA, breach detection requirements, SLA for incident notification
• Encryption key policy ownership for tenant/master keys (where controller owns keys)

Typical controls — Processor (technical obligations)

• Implemented TOMs: encryption at rest/in transit, secure backups, logging/monitoring
• Patch management, vulnerability scanning, change control evidence
• Data segregation multi-tenant controls, secure deletion on termination
• Assist with DPIA evidence, timely breach reporting, subprocessor vetting controls

Key clauses in Data Processing Agreement (technical perspective)

• Exact processing scope, purpose, and duration; list of subprocessors and notification rules
• Security measures: minimum encryption standards, logging retention, MFA, vulnerability management metrics
• Incident response: time-to-notify (eg. within 24 hours), investigation cooperation, forensic data access
• Audit rights and frequency, penetration test sharing and remediation timelines
• Data return/deletion: verification procedures and proof of secure erasure
• Key management and access to encryption keys; geographic/location restrictions and cross-border transfer mechanisms

These distinctions guide architecture choices: controllers set security requirements and risk appetite; processors provide verifiable implementation and operational controls.

Intro (role perspective)
As a Security Architect I translate GDPR obligations into concrete design constraints and controls—below are concise architectural implications and when to consult the DPO.

• Data minimization
  Architectural implication: Design systems to collect, store, and retain only the minimal attributes required (use attribute-based access, tokenization, and schema-level pruning).
  Consult DPO: Before changing data models or adding new data collection to validate necessity.

• Purpose limitation
  Architectural implication: Enforce purpose-tagging of data at ingestion and policy-driven access controls that prevent secondary uses.
  Consult DPO: When introducing new data uses, analytics, or sharing that may deviate from declared purposes.

• Data subject rights
  Architectural implication: Build auditable workflows, subject-access APIs, and reversible pseudonymization to support access, rectification, erasure, portability.
  Consult DPO: When designing erasure/portability processes or automated fulfillment that may impact systems.

• Data Protection Impact Assessments (DPIA)
  Architectural implication: Integrate DPIA checkpoints into design lifecycle; require threat models and mitigation mapping for high-risk processing.
  Consult DPO: At project start for any high-risk processing, new technologies, or large-scale profiling.

• Lawful bases for processing
  Architectural implication: Implement consent management, recordkeeping, and conditional processing gates tied to legal basis metadata.
  Consult DPO: When defining which lawful basis applies or changing processing that may affect legal basis.

• Cross-border transfer constraints
  Architectural implication: Architect data residency controls, encryption-in-transit/at-rest, and contractual/SCC mechanisms with selectable storage regions.
  Consult DPO: Before sending data outside the EEA or using third‑party cloud regions.

If needed I map these into controls (encryption, logging, consent stores, access policies) and incorporate them into threat models and architecture review checklists.