GDPR Quick-Start

A beginner-friendly walk of the EU General Data Protection Regulation — the EU's data-protection law since May 2018, enforced by each Member State's independent data protection authority and by the European Data Protection Board for cross-border cases, applicable to any controller or processor that handles the personal data of people in the EU. The primer drops the Article-pin wall into plain English: what GDPR is, who is on the hook, the seven principles that govern every processing activity, and how it differs from US frameworks like HIPAA and SOC 2 in the language the audit and the procurement team actually read.

Last updated: 2026-08-01

Pair this primer with the full course: Full /courses/gdpr walk →

What GDPR is

GDPR — the General Data Protection Regulation — is the EU's data-protection regulation, in force since 25 May 2018. It replaced the 1995 Directive and harmonised data-protection law across the EU and the EEA, so a controller answering to Berlin answers to the same law as one answering to Madrid, Dublin, or Paris. The single keyword is 'personal data': any information relating to an identified or identifiable natural person. Most of what HIPAA calls PHI, what a SOC 2 reviewer calls PII, and what a marketing team calls 'user data' lands inside GDPR's personal-data definition — broadly scoped on purpose, narrower than a marketing database, broader than a clinical record.

Enforcement runs through the national data-protection authorities — the CNIL in France, the BfDI in Germany, the ICO in the UK, the AEPD in Spain, and one in every Member State — each independent of the government it sits alongside. For cross-border processing the European Data Protection Board (EDPB) coordinates a one-stop-shop mechanism: a single lead authority handles the case, the other cooperating authorities contribute, and the resulting decision lands in a single public order rather than twenty parallel ones. Each authority can fine up to the higher of €20 million or 4% of total worldwide annual turnover for the most serious infringements, and the orders are public — the published decisions list the controller, the Article breached, and the fine. The regulator-first framing is the same as OCR under HIPAA: a written policy without the corresponding artifact is the most common finding pattern.

Why a US analyst cares: GDPR is territorial. A US SaaS that targets EU customers, a US publisher that ships cookies into EU visitors, a US AI training pipeline that ingests data about EU residents — all of those land inside GDPR regardless of where the company is incorporated. The Art. 3(2) extra-territorial gate pulls in US-headquartered companies by the offering-goods-or-services and the monitoring-behaviour limbs of the Article. The regulation is now a standing line item on the SOC 2 vendor questionnaire, the BAA review packet, and the privacy-page citing list — a US analyst reading GDPR is reading the document the EU customer, the EU DPA, and the global procurement team will all open.

Who GDPR applies to

Controllers and processors at Art. 4 — the regulation splits the world into two roles. A controller decides why the processing happens and how it happens (purposes and means); a processor processes personal data on behalf of a controller, on the controller's instructions. The same vendor can be a processor for one product line (a cloud host that stores EU customer records on behalf of the SaaS) and a controller for another (its own marketing database of EU leads). Joint controllers — two entities that jointly determine purposes and means — fall under Art. 26 and have to publish a Joint Controller Arrangement between them. Most vendor questionnaires classify the role on the data-processing addendum, and the regulator expects the classification to be defensible, not aspirational.

The Art. 28(3) Data Processing Agreement (DPA) is the contractual gate between a controller and a processor — the GDPR analogue to HIPAA's Business Associate Agreement. It is a written contract that names the subject-matter, duration, nature and purpose of the processing, the type of personal data, the categories of data subjects, and the obligations and rights of the controller; sub-processors downstream get the same treatment under Art. 28(4). A vendor contract without a DPA where personal data is exchanged is the most direct path to a supervisory-authority finding when the processing relationship comes under scrutiny.

Territorial scope at Art. 3(1) — the regulation applies to the processing of personal data in the context of an establishment of a controller or processor in the Union, regardless of where the processing itself takes place. An 'establishment' is read functionally: a sales office, a subsidiary, or one staff member handling EU data subjects from inside the EU can count. Extra-territorial scope at Art. 3(2) extends the regulation to non-EU controllers and processors when the processing relates to offering goods or services to data subjects in the Union, or monitoring the behaviour of data subjects in the Union. The Art. 3(2) limb is the gate that pulls in a US SaaS targeting EU customers and any US AI training pipeline that ingests data about EU residents.

The seven processing principles

Lawfulness, fairness and transparency — every processing activity needs a defensible legal basis (one of the six Art. 6 bases) and a privacy notice the data subject can actually read. Lumora Learning's parental-consent flow is the operational example here: a parental-consent screen is the transparency artifact, and 'consent' (Art. 6(1)(a)) is the chosen basis; if you cannot defend both, the principle is breached.
Purpose limitation — personal data is collected for specified, explicit, and legitimate purposes and not further processed in a way incompatible with those purposes. The Art. 13 / 14 notice names the purpose; the RoPA names the use case; a marketing team repurposing onboarding telemetry for ad-targeting without refreshing the basis is the most common principle finding.
Data minimisation — processing is limited to what is necessary for the purposes. The principle is the reason every "do you really need this field?" question lands on the form-design meeting, and the reason a free-text address field on a checkout form is a principle-3 breach waiting to happen.
Accuracy — personal data must be accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that inaccurate personal data is erased or rectified without delay. The principle is the reason an account-update flow lives in-product and the reason a DSR rectification request (Art. 16) routes back to the data steward, not just to support.
Storage limitation — personal data is kept in a form which permits identification of data subjects for no longer as is necessary for the purposes. WovenCart's customer-order retention window (the operational example: orders retained for the minimum needed for tax and return handling, then pseudonymised or deleted) is the Art. 5(1)(e) artifact that an Art. 5 audit will ask for.
Integrity and confidentiality — processing is performed in a manner that ensures appropriate security of the personal data. Art. 32 carries the technical safeguards: pseudonymisation, encryption, the ability to restore availability after an incident, regular testing. The bridge: Art. 5 names the principle, Art. 32 names the control set.
Accountability — the controller is responsible for, and able to demonstrate, compliance with the other six principles. The principle is the one that turns GDPR from a virtue list into an evidence requirement: the RoPA, the Art. 30 records, the DPIA under Art. 35, the documented lawful-basis choices — every one of them is the "able to demonstrate" artifact this principle demands.

How GDPR differs from US frameworks

GDPR vs HIPAA — GDPR rests on a consent-and-lawful-basis gate (Art. 6); HIPAA rests on a permitted-use-and-disclosure gate (the §164.502 Treatment-Payment-Operations default plus the §164.508 written authorisation). The GDPR consent is more demanding than the HIPAA marketing authorisation: freely given, specific, informed, and unambiguous, and as easy to withdraw as to give. GDPR's special-category data (the Art. 9 list: health, biometric, genetic, racial, ethnic, political, religious, trade union, sex-life or sexual-orientation data) is broader than HIPAA's PHI — it captures PHI-adjacent data that HIPAA does not always see, so a vendor pitching the same safeguard stack across both has to plan for the wider Art. 9 set, not just for PHI. The fine regime is the other contrast: GDPR tops at the higher of €20 million or 4% of total worldwide annual turnover, while HIPAA enforcement runs through the OCR resolution-agreement cycle with civil monetary penalties tied to tier and culpability. The data-subject "right to be forgotten" (Art. 17) sits beside HIPAA's §164.526 amendment right but reaches further — erasure, not just correction, where the lawful-basis no longer applies — so the rights workflow on the data-subject-operations team reads Art. 17 requests as a heavier intervention than the §164.526 ones. Finally, the Art. 3(2) extra-territorial gate pulls a US SaaS that targets EU customers into GDPR regardless of where it is incorporated; HIPAA stops at the US border.
GDPR vs SOC 2 — SOC 2's Privacy TSC overlaps with GDPR at the safeguard layer (the AICPA Generally Accepted Privacy Principles map onto parts of Art. 5 and Art. 32), but the documents are not the same. SOC 2 is attestation: an independent CPA firm issues a Type I (point-in-time design opinion) or a Type II (operating-effectiveness over a window) report on the entity's controls. GDPR is regulation: each Member State's DPA can open an investigation, name a breach of a specific Article, and order remediation backed by a fine — there is no auditor-signed report that substitutes for the regulator's decision. SOC 2 covers what the entity does with the PII it holds; GDPR covers every data subject the entity touches, including the ones whose data the entity never directly sees (an Art. 28(3) processor relationship still drags the controller into GDPR). A vendor with a clean SOC 2 Type II report still needs an executed Art. 28(3) DPA to satisfy GDPR on the controller side; the SOC 2 does not satisfy the DPA gate, and a DPA does not satisfy the SOC 2 attestation gate.
GDPR + HIPAA — a US-based Covered Entity that handles EU data subjects is reading HIPAA and GDPR concurrently, with PHI (the HIPAA term) and personal data (the GDPR term) as adjacent but distinct concepts. The HIPAA BAA and the GDPR DPA are not interchangeable: one draft does not satisfy both, and the BAA does not address GDPR-only obligations like the lawful-basis gate, the Art. 12(3) one-month data-subject-rights response window, or the Art. 33 72-hour breach-notification clock. The dual-framework pattern in practice: one BAA for the PHI flow under HIPAA, one DPA for the EU-touched personal-data flow under GDPR, with the HIPAA BAA and the GDPR DPA indexed to each other so a single breach does not trigger two parallel and inconsistent notification runs. The Art. 5(1)(f) integrity-and-confidentiality principle is where SOC 2, HIPAA, and GDPR agree — a control that maps to Art. 32 and to §164.312(a)(2)(iv) is the same control in the dual stack.

Next steps

Once you can name which principle a brief opens first — and which lawful basis the Art. 13 / 14 notice is defending — you are no longer reading GDPR as a wall of Articles; you are using it as an evidence obligation with a named audit trail (the RoPA, the lawful-basis choice, the retention window, the DPIA). The next concrete move is to draft the Art. 35 DPIA against a real high-risk processing scenario, with the Article-by-Article map pre-walked and the prior-consultation trigger (Art. 36) ear-marked for any residual high risk.

When you are ready to read the matching course, the full /courses/gdpr walk maps the Article-by-Article control surface end to end, including the Art. 28 processor obligations and the Art. 44 onward Chapter V transfer rules. The /mentors directory carries GDPR-specialist reviewers under the Browse GDPR mentors link below — the deep-link lands on the GDPR group on first paint so a privacy-focused learner can read the cards without scrolling. Until then, the laminate for GDPR is: name the principle, name the lawful basis, name the next concrete artifact.

Next: try the DPIA lab

Run the GDPR Art. 35 DPIA against the Lumora Learning K-12 tutoring scenario and walk the article-by-article output with the high-risk-processing gates pre-mapped.

Open the DPIA lab →

Browse the Labs index

Every hands-on lab the platform ships — DPIA, Gap Analysis, Risk Register, Policy Drafter, Compliance Checklist — on one page, with the framework selector and the free sub-form marked.

Browse the Labs index →

Browse GDPR mentors

Practicing privacy and EU-compliance analysts signed up as reviewers. Click through to the GDPR group on /mentors — the deep-link lands on the GDPR cards without scrolling.

Browse GDPR mentors →