1.1What counts as personal data
References
GDPR Art. 4(1) ·
Recital 26 · CJEU
Breyer C-582/14
(dynamic IPs) ·
WP29
Opinion 4/2007
The ruleIf a value can be linked to a person (directly,
indirectly, or via a third party), it's personal data. That includes IPs, cookie/device IDs, and your own
user UUIDs.
Why we care
The scope is much wider than "name + email." If your logs, metrics, telemetry or feature flags contain
values that could be linked to a person, even via a third party, they are in scope. This determines
whether a system needs a lawful basis, retention controls, Data Subject Access Requests (DSAR) support,
and cross-border safeguards.
Key patterns
- Treat IPs, cookie IDs, advertising IDs (IDFA/AAID), device fingerprints, MAC addresses, and
session IDs as personal data by default.
- Treat pseudonymous identifiers (user UUIDs, customer numbers) as personal data. They
identify a person within your system.
- Tag data classes at the schema level (e.g., Lake Formation LF-tags and Glue column-level tags in
AWS). Don't rely on developer memory.
- Apply the "means reasonably likely to be used" test (Recital 26): if re-identification is
plausible with available data + effort, it's personal data.
Anti-patterns / gotchas
- "We only store hashes": a hash of an email is still personal data; it's pseudonymized, not
anonymized (see 1.2).
- "It's just an IP for rate limiting": Breyer settled that dynamic IPs are personal data when
the controller has legal means to identify the subscriber.
Cloud notes: AWS · K8s
- AWS: CloudTrail records
sourceIPAddress; VPC Flow Logs contain IPs;
ALB access logs contain client IPs. All in scope.
- K8s: Ingress and Gateway API controllers (Traefik, Envoy Gateway) and
service-mesh sidecars default to logging client IP and User-Agent; treat the log pipeline
(Loki, ELK, Datadog) as a personal data store.
1.2Pseudonymization vs anonymization
References
GDPR Art. 4(5) ·
Recital 26 ·
WP29
Opinion 05/2014 ·
EDPB
Opinion 28/2024
The ruleOnly irreversible anonymization leaves GDPR scope.
Hashing, tokenizing, or keeping a stable ID is pseudonymization. That's still personal data, with all the
obligations.
Why we care
Engineers routinely call something "anonymized" when it's pseudonymized. The legal consequences differ:
anonymized data has no retention limit, no DSAR obligation, no lawful basis required. Pseudonymized data
has all of these.
Key patterns
- Pseudonymization techniques: tokenization, deterministic encryption, keyed HMAC,
format-preserving encryption. Store keys/maps separately with strict access (KMS, Vault, separate
account/project).
- Anonymization techniques to evaluate: k-anonymity (k≥5 typical), l-diversity, t-closeness,
differential privacy with calibrated epsilon. None are "press button".
- Run a motivated-intruder test before declaring anonymization: assume an adversary with access to
public data and your dataset.
- For analytics: prefer aggregation + DP noise over raw pseudonymous events.
- Document the assessment. "Anonymized" without a documented re-identification risk analysis will
not survive a DPA review.
Anti-patterns / gotchas
- Hashing emails with SHA-256: trivially reversible via rainbow tables for any common email domain.
Pseudonymization at best.
- Removing the "name" column and calling the rest "anonymous": quasi-identifiers (zip + DOB + gender
≈ 87% of US population uniquely identifiable per Sweeney 2000, a US figure; the EU has no single
canonical equivalent, but the re-identification principle is the same, which is exactly what the
motivated-intruder test probes).
- "Anonymized" event streams that retain a stable
user_id or session_id:
pseudonymized.
- LLM training data: even if you strip PII, memorization can leak originals. Treat training corpora
as personal data.
Cloud notes: AWS · K8s
- AWS: Macie for discovery; KMS for key separation; Lake Formation row/column
filters for pseudonym/key separation across accounts.
- K8s: never bake the de-pseudonymization key into a workload that also processes the
pseudonymized data: separate namespaces and IAM/Workload Identity.
1.3Controller, processor, sub-processor
References
GDPR Art. 4(7)(8)
· Art. 28 ·
EDPB
Guidelines 07/2020 · CJEU
Fashion ID
C-40/17 (joint controllership)
The ruleYour role decides who signs DPAs, who notifies on breach,
and who answers DSARs. Map every external system to a role, and yes, your cloud provider is a
sub-processor.
Controller
You / your product
decides why & how
→
Processor
SaaS vendor
acts only on instructions
→
Sub-processor
Their cloud (AWS…)
downstream vendor
Every arrow needs a DPA. Get the roles wrong and the wrong party
signs contracts, notifies on breach, and answers DSARs.
Why we care
The controller decides why and how data is processed; the processor acts only on the controller's
instructions; a sub-processor is anyone the processor brings in to help (your cloud provider, your SaaS
dependencies). Engineers often build systems assuming they're a processor when the architecture makes
them a controller (or joint controller).
Key patterns
- Map every external system touching personal data to a role: controller, joint controller,
processor, sub-processor, or independent controller.
- Maintain a sub-processor registry per product (e.g., AWS, Datadog, Sentry, Stripe, OpenAI). Each
needs a DPA on file and ideally appears on a public sub-processor page.
- Implement a sub-processor change-notification process. Many DPAs require 30 days' notice to
customers before adding one.
- If you're a processor, build "instruction-only" controls: don't enrich, profile, or derive
features from customer data unless contractually permitted.
- Separate telemetry you collect as controller (your product analytics) from data you
process as processor (customer payloads). Different lawful bases, different retention.
Anti-patterns / gotchas
- Treating cloud providers as "infrastructure" not sub-processors: AWS, GCP, Azure are
sub-processors when they store/process customer personal data.
- Using customer data to train shared ML models without explicit controller authorization. That
decision makes you a controller for the training purpose.
- Embedding third-party analytics (Google Analytics, Meta Pixel) on pages handling customer data.
Fashion ID-style joint controllership likely applies.
Cloud notes: AWS · K8s
- AWS: GDPR DPA is incorporated into the AWS Service Terms; SCCs included. Region
selection controls primary storage location, not all transit.
- K8s: managed K8s (e.g., EKS) means the control plane operator is a sub-processor
for control-plane metadata.
1.4Lawful basis
References
GDPR Art. 6 ·
EDPB
05/2020 (consent) ·
EDPB
2/2019 (Art. 6(1)(b)) ·
EDPB
8/2020 (LI tests)
The rulePick one of the six Art. 6 bases per purpose before you
build, document it, and don't switch later. Consent is the last resort, not the default.
Why we care
Lawful basis drives feature design: consent requires a UI and a withdrawal path; contract necessity
narrows scope to the contract; legitimate interest requires a documented balancing test (LIA). The basis
also affects which data-subject rights apply (e.g., right to object, portability).
Key patterns
- The six bases: (a) consent, (b) contract, (c) legal obligation, (d) vital interests, (e) public
task, (f) legitimate interests.
- Default first-choice tree for B2B SaaS: contract (Art. 6(1)(b)) for core service delivery;
legitimate interest (Art. 6(1)(f)) for security, fraud prevention, basic product analytics; consent
(Art. 6(1)(a)) only for marketing, non-essential cookies, optional features.
- For each processing purpose in your RoPA, record: basis, who decided, balancing test reference
(if LI), retention.
- Build consent infrastructure once: a consent service with timestamped, granular, withdrawable,
auditable records.
- Cookies and similar tracking: governed by ePrivacy (consent required for non-essential), not just
Art. 6. Don't conflate.
Anti-patterns / gotchas
- Using consent as a catch-all. Consent must be freely given, specific, informed, unambiguous, and
withdrawable as easily as granted. Bundled consent for employment, contracted services, or
"necessary" features is invalid.
- "Legitimate interest" for ML training on customer data without an LIA and without considering
whether subjects would reasonably expect it.
- Changing the lawful basis after the fact (e.g., starting on consent then switching to LI when
withdrawal rates spike) generally not permitted.
Cloud notes: AWS · K8s
- AWS: there is no "lawful basis" field in the cloud; this is a design +
documentation discipline. Encode purpose tags on resources (e.g.,
purpose=marketing-consent, purpose=fraud-LI) and enforce via IAM/policy.
- K8s: separate namespaces or clusters per lawful basis when retention/access rules
diverge significantly. Avoids "one cluster, many rules."
1.5Special categories of data
Art. 9
References
GDPR Art. 9 ·
EDPB
3/2019 ·
EDPB
05/2022 · CJEU
OT C-184/20
The ruleHealth, biometrics, ethnicity, religion, politics, sex
life, union membership, genetics (and anything you infer about them) need an Art. 9 exception on top
of a lawful basis. Isolate and DPIA them.
Why we care
Special-category data raises the bar on encryption, access control, audit, and DPIA obligations.
Engineers frequently introduce Art. 9 data without realising: face embeddings, voice prints, fitness
tracker exports, photos that reveal ethnicity, support tickets containing health complaints.
Key patterns
- Tag Art. 9 data classes explicitly in your data catalog and treat them as the highest sensitivity
tier.
- Default to explicit consent (Art. 9(2)(a)) for consumer apps; employment context uses Art.
9(2)(b) with national law; healthcare uses Art. 9(2)(h) under professional secrecy.
- Always run a DPIA (Art. 35) when Art. 9 data is processed at scale or with new tech (biometrics,
AI inferences).
- Isolate Art. 9 stores: separate KMS keys, separate buckets/datasets, separate IAM roles, stricter
retention.
- Inferred special-category data counts. Predicting health status, sexual orientation, or political
views from non-sensitive inputs creates Art. 9 data (CJEU OT v. Vyriausioji tarnybinės etikos
komisija C-184/20).
Anti-patterns / gotchas
- Storing user-uploaded profile photos in a generic S3 bucket. These can reveal ethnicity, religion
(head coverings), health (visible conditions). Argue scope carefully; isolate if used for
inference.
- Biometric authentication: face/voice templates are Art. 9 when used to uniquely identify a person.
On-device matching with no server-side template export significantly reduces scope.
- Free-text support fields are an Art. 9 risk surface. Plan for redaction or restricted access.
Cloud notes: AWS · K8s
- AWS: For Rekognition face data confirm region and DPA terms; use customer-managed
KMS keys; restrict via SCPs at org level.
- K8s: use PodSecurity + NetworkPolicies to fence Art. 9 workloads; consider
dedicated node pools with disk encryption and no shared volumes.
1.6The seven principles
References
GDPR Art. 5 ·
Art. 24 · Art.
25 (accountability & DPbDD) ·
EDPB
4/2019
The ruleArt. 5's seven principles are enforceable defaults: a
lawful basis, a declared purpose, minimal fields, accurate data, a retention clock, encryption + least
privilege, and written proof of all of it.
Why we care
These principles translate directly into architectural defaults: retention TTLs, field-level scoping,
schema review gates, encryption baselines, and audit logs. Most enforcement actions cite Art. 5
alongside specific articles. So get the principles right and most downstream obligations fall into
place.
Key patterns: the seven principles
- Lawfulness, fairness, transparency: publish a privacy notice that matches your
data flows; align UX disclosures with backend reality. If telemetry collects X, the notice must
mention X.
- Purpose limitation: every dataset has a declared purpose; new uses require
compatibility assessment or fresh basis. Tag pipelines with purpose IDs.
- Data minimisation: collect the minimum fields needed. Pre-aggregate before
logging. Default-off PII in logs; opt-in for debugging.
- Accuracy: provide subject-facing correction UX; propagate updates downstream
(CDC events to ML feature stores, analytics warehouses).
- Storage limitation: every table/topic/bucket has a documented retention; enforce
via lifecycle rules, not crons.
- Integrity & confidentiality: encryption in transit + at rest as baseline;
least-privilege IAM; key management with rotation; audit logs.
- Accountability: keep a Record of Processing Activities (RoPA), DPIAs, LIAs, and
architecture decisions. If you cannot show your work, you do not comply.
Anti-patterns / gotchas
- "We'll clean up old data later." Storage limitation is not a backlog item. DPAs treat unset
retention as a finding.
- Logging full request/response bodies in production for "debugging." Violates minimisation; common
breach amplifier.
- Copying prod data to staging for testing. Almost always a purpose-limitation and security
violation; use synthetic or properly anonymized data.
Cloud notes: AWS · K8s
- AWS: S3 Lifecycle + Object Lock (governance mode) for retention; CloudTrail +
Config for accountability; KMS CMKs per data class for confidentiality and blast-radius control.
- K8s: set TTLs on logs and metrics backends (Loki retention, Prometheus TSDB,
Elasticsearch ILM); never default to "keep forever."
1.7Territorial scope: does GDPR apply?
References
GDPR Art. 3 ·
Recital 23 ·
Recital 24 ·
EDPB
Guidelines 3/2018 · Art. 27 (EU representative)
The ruleGDPR follows the data subject, not your servers. If you
have an EU establishment, or you offer goods/services to (or monitor the behaviour of) people who are
in the EU/EEA, you are in scope, wherever your company and infrastructure sit.
Why we care
This is the first question: "does GDPR even apply to us?" And engineers routinely get it wrong by
reasoning about server location ("we're a US company on us-east-1, so we're fine"). Art. 3 is about
who you process data about, not where the bytes live. It decides whether everything else in this
playbook is mandatory for your system.
Key patterns
- Establishment test (Art. 3(1)): if processing happens "in the context of the
activities of" an EU establishment, you are in scope, regardless of where the processing physically
occurs.
- Targeting test (Art. 3(2)(a)): offering goods or services to people in the EU
brings you in scope. Signals: EU languages, pricing in euros, EU country domains, shipping to the
EU, EU-targeted marketing. Mere accessibility of a website is not enough on its own.
- Monitoring test (Art. 3(2)(b)): tracking the behaviour of people in the EU (web
analytics, ad profiling, device fingerprinting, cookies) brings you in scope.
- Scope follows location, not citizenship. It applies to data subjects who are
in the EU at the time, regardless of nationality or residence.
- Appoint an Art. 27 representative in the EU if you fall under Art. 3(2) and have
no EU establishment.
Anti-patterns / gotchas
- "Our servers/company are in the US, so GDPR doesn't apply." Infrastructure location is irrelevant
to Art. 3.
- Treating a geo-block as a get-out: it must be genuine and effective, not a fig leaf over
EU-targeted marketing and euro pricing.
- Forgetting the Art. 27 representative obligation when you target the EU from outside it.
Cloud notes: AWS · K8s
- AWS: Region choice (e.g.
eu-central-1) affects residency and
transfers (see 2.5), not whether GDPR applies. Don't conflate "we deploy in the US" with "GDPR
is out of scope."
- K8s: Same here. Cluster topology decides where data sits, not whether the regime
applies. Use scope to decide what controls are mandatory, then use region/topology to satisfy
residency.
1.8What counts as "processing"
References
GDPR Art. 4(2)
The ruleAlmost anything you do with personal data is "processing":
collecting, storing, structuring, accessing, transmitting, and even deleting it. If your code or
infrastructure touches personal data, it's processing, and the principles apply.
Why we care
Engineers often read "processing" as "analytics" or "ML," and assume plain storage or internal access is
out of scope. GDPR defines processing as any operation performed on personal data, automated or
not. That means a read replica, a nightly backup, a log line, a cache entry, and an erasure job are each
processing, and each needs a lawful basis (1.4) and a place in the RoPA (2.3).
Key patterns
- Treat every operation as processing: collection, recording, organisation, structuring, storage,
adaptation, retrieval, consultation, use, disclosure, alignment, combination, restriction, erasure,
and destruction.
- Passive storage is processing. Keeping a backup of personal data, even if
nothing reads it, is processing.
- Access / consultation is processing. An engineer running a query against a
production table is processing personal data; gate and log it (3.1, 3.4).
- Each distinct processing activity gets a lawful basis and a RoPA entry; tag pipelines and stores
with the activity they serve.
Anti-patterns / gotchas
- "We only store it, we don't process it." Storage is processing.
- "It's just internal debugging access." Consultation is processing; it needs a basis and an audit
trail.
- Assuming manual / non-automated handling is exempt: it's in scope when the data forms part of a
filing system.
Cloud notes: AWS · K8s
- AWS: Every S3 bucket, RDS instance, DynamoDB table, SQS queue, CloudWatch log
group, and backup vault holding personal data is a processing operation: inventory them all, not just
the "analytics" ones.
- K8s: PVCs, etcd, log sinks (Loki/ELK), caches (Redis), and message buses are all
processing surfaces; an erasure or restriction job is itself processing.
Quick reference: terminology cheatsheet
| Term |
Means |
Engineers often confuse with |
| Personal data | Anything identifying a person, directly or indirectly | "PII" (a narrower US concept) |
| Pseudonymization | Reversible separation of identifiers from data | Anonymization |
| Anonymization | Irreversible: no one can re-identify | Hashing |
| Controller | Decides why and how | Whoever owns the database |
| Processor | Acts on controller's instructions only | Any vendor |
| Sub-processor | Processor's downstream vendor | "Just infrastructure" |
| Lawful basis | One of six Art. 6 grounds | Consent |
| Special category | Art. 9 data, extra-protected | "Sensitive data" generally |
| Art. 5 principles | Seven mandatory principles | Best practices |