Eu Legal Compliance

EU Legal Compliance

> Scope & disclaimer. This skill is an engineering/product-oriented reference for EU-level law as of June 2026. It is not legal advice and does not replace a qualified EU data-protection lawyer or your DPO. EU regulations apply directly, but directives (NIS2, EAA, ePrivacy, consumer directives) are transposed into national law that varies by member state — always check the local implementing act and the lead/competent authority for your establishment. Engage counsel for: high-risk processing, cross-border transfers, breach notifications, AI Act high-risk/GPAI classification, M&A/data deals, regulator inquiries, and any consumer-facing contract terms. > > Controller vs processor. Most obligations below differ by role. A controller decides the purposes and means of processing (Art. 4(7)); a processor acts only on documented controller instructions (Art. 4(8)). Joint controllers (Art. 26) need an arrangement allocating responsibilities. Identify your role per processing activity before applying any checklist — it changes who answers DSARs, who notifies breaches, and who signs which contract (controller↔processor needs an Art. 28 DPA).

GDPR (Regulation 2016/679)

Lawful Bases (Art. 6)

| Basis | Use Case | Notes | |-------|----------|-------| | Consent (Art. 6(1)(a)) | Marketing emails, cookies | Must be freely given, specific, informed, unambiguous. Withdrawable. | | Contract (Art. 6(1)(b)) | Service delivery, billing | Only data strictly necessary for the contract | | Legal obligation (Art. 6(1)(c)) | Tax records, AML | Must identify the specific law | | Vital interests (Art. 6(1)(d)) | Medical emergency | Rarely applicable for tech companies | | Public interest (Art. 6(1)(e)) | Government services | Requires legal basis in member state law | | Legitimate interest (Art. 6(1)(f)) | Analytics, fraud prevention, B2B marketing | Requires LIA (balancing test). Document it. |

Data Subject Rights Implementation

Response timing (Art. 12(3)): Act without undue delay and within one month of receipt (a calendar month, not 30 days — e.g. a 15 Jan request is due 15 Feb). Extendable by two further months where requests are complex or numerous, but you must inform the requester of the extension and the reasons within the first month. If you take no action, you must tell the requester within one month and explain why + their right to complain to a DPA / seek a remedy (Art. 12(4)). Requests are normally free; you may charge a reasonable fee or refuse only if manifestly unfounded or excessive, and you bear the burden of proving that (Art. 12(5)).

| Right | Article | Response Deadline | Notes | |-------|---------|-------------------|-------| | Access | Art. 15 | 1 month (+2) | Copy in common electronic format; don't adversely affect others' rights (Art. 15(4)) | | Rectification | Art. 16 | 1 month (+2) | Notify each recipient unless impossible/disproportionate (Art. 19) | | Erasure ("right to be forgotten") | Art. 17 | 1 month (+2) | Exceptions: legal obligation, freedom of expression, public-interest, defence of legal claims (Art. 17(3)) | | Restrict processing | Art. 18 | 1 month (+2) | Data stored but not otherwise processed; lift only with notice | | Data portability | Art. 20 | 1 month (+2) | Only data provided by the subject, processed on consent/contract, by automated means; structured machine-readable format (JSON/CSV) | | Object | Art. 21 | 1 month (+2) | Absolute for direct marketing; otherwise you may continue only on compelling legitimate grounds | | Automated decision-making | Art. 22 | 1 month (+2) | Right to human intervention, to express a view, and to contest the decision |

Identity verification: You may request information to confirm identity where there are reasonable doubts (Art. 12(6)), but don't over-collect — the one-month clock starts on receipt; pausing for verification must be proportionate, not a stalling tactic.

Build: Expose a DSAR intake (form/email alias/in-app) and an admin tooling path to fulfil each right. Log every request immutably. Use the inline DSAR workflow below.

DSAR intake & fulfilment workflow (inline)

Intake fields to capture:

• Request ID (immutable), received-at timestamp (starts the clock), channel (email/form/in-app/phone)
• Requester identity + verification method/outcome (Art. 12(6)) and whether requester is the data subject or an authorised agent
• Right(s) invoked (access / rectification / erasure / restriction / portability / objection / Art. 22)
• Scope: accounts, products, date range, specific data categories
• Your role for the data in scope (controller / processor — processors forward to the controller and assist per Art. 28(3)(e))
• Due-date (received-at + 1 calendar month), extension flag + reason + extension-notice-sent date

Fulfilment steps:

1. Acknowledge within a few business days; state the statutory deadline.
2. Verify identity proportionately; if reasonable doubt persists, request minimal additional proof.
3. Discover data across all systems: primary DB, data warehouse/analytics, logs, backups, email/CRM/support tickets, third-party processors (list them — you must propagate erasure/rectification to processors and downstream recipients, Art. 19). Maintain a data-source map so discovery is repeatable.
4. Apply exemptions/redactions: withhold third-party personal data and privileged/IP material; for access, never disclose others' data (Art. 15(4)).
5. Produce output: access → structured copy + the Art. 15(1) info (purposes, categories, recipients, retention, source, rights, existence of automated decisions). Portability → machine-readable export (and, on request, transmit directly to another controller "where technically feasible").
6. Execute changes: erasure must reach backups on the next backup-rotation cycle (document your rotation interval and put the record beyond use meanwhile); restriction must be enforced in code (flag that suppresses processing).
7. Respond & close within one month (or notify extension within the first month). Record completion date, action taken, and any refusal + reason + complaint-rights notice.

Free-tier exceptions: charge/refuse only when manifestly unfounded or excessive — document the justification; "we get a lot of requests" is not sufficient.

Breach Notification (Art. 33-34)

Discovery → 72h → Notify supervisory authority (Art. 33)
         → "Without undue delay" → Notify affected individuals if high risk (Art. 34)

What to report: Nature of breach, categories/numbers affected, DPO contact, likely consequences, mitigation measures. Document ALL breaches even if not reportable (Art. 33(5)).

Record of Processing Activities — RoPA (Art. 30)

Required for controllers/processors with ≥250 employees, or where processing is not occasional, or involves special-category/criminal data, or is likely to risk rights (in practice: almost everyone). Maintain as a living register.

Controller record (Art. 30(1)) — one row per processing activity:

| Field | Example | |-------|---------| | Activity name + purpose(s) | "Customer support — resolve tickets" | | Controller (+ joint controllers, EU rep, DPO contact) | Acme GmbH; DPO dpo@acme.example | | Categories of data subjects | Customers, prospects | | Categories of personal data | Name, email, order history; flag special categories | | Lawful basis (per purpose) | Contract (Art. 6(1)(b)); marketing = consent | | Recipients / processors | Zendesk (processor), Stripe (controller for payments) | | Third-country transfers + safeguard | US → SCCs + TIA; or DPF if recipient certified | | Retention period / criteria | 24 months after last contact | | Technical & organisational measures (TOMs) | Encryption at rest, RBAC, MFA |

Processor record (Art. 30(2)): name/contacts of each controller you act for, categories of processing per controller, transfers + safeguards, and TOMs.

DPIA — Data Protection Impact Assessment (Art. 35)

Mandatory when processing is "likely to result in a high risk," explicitly including: systematic & extensive profiling with legal/significant effects (Art. 35(3)(a)), large-scale special-category or criminal-offence data (Art. 35(3)(b)), large-scale systematic monitoring of a publicly accessible area (Art. 35(3)(c)). Also consult your DPA's mandatory-DPIA list (each member-state authority publishes one under Art. 35(4)) and the WP248 nine-criteria test — two or more criteria usually triggers a DPIA: evaluation/scoring, automated decisions with legal effect, systematic monitoring, sensitive/highly-personal data, large scale, matching/combining datasets, vulnerable subjects (children, employees), innovative tech (AI/biometrics/IoT), preventing data subjects from exercising a right/using a service.

> If a DPIA shows high residual risk that you cannot mitigate, you must consult your supervisory authority before processing (prior consultation, Art. 36).

DPIA template (inline)

1. Describe the processing — nature, scope, context, purposes; data flows diagram; categories of data & subjects; recipients; retention; data volumes.
2. Necessity & proportionality — lawful basis per purpose; is the data minimal vs the goal? data-minimisation, accuracy, storage-limitation measures; how data-subject rights are supported; processor/transfer safeguards.
3. Consult stakeholders — DPO opinion (record it), and where appropriate seek the views of data subjects/representatives.
4. Identify & assess risks — for each risk to rights & freedoms: source, likelihood (low/med/high), severity (low/med/high), overall rating. Cover illegitimate access, unwanted modification, and data disappearance.
5. Mitigations — measures + residual risk after mitigation; encryption, pseudonymisation, access controls, retention limits, human oversight, opt-outs.
6. Sign-off & review — owner, DPO sign-off, date; prior consultation (Art. 36) if high residual risk remains; scheduled review date; trigger to re-run on material change.

Cross-Border Transfers (Post-Schrems II)

| Mechanism | Status | When to Use | |-----------|--------|-------------| | Adequacy decision (Art. 45) | Several in force (e.g. UK, Switzerland, Japan, S. Korea + the EU–US Data Privacy Framework, 2023) | Recipient country/programme on the Commission's adequacy list — for the US, importer must be DPF-certified for that data type | | SCCs (Art. 46(2)(c)) | 2021 modular SCCs; valid only with a documented TIA | Default for non-adequate countries; pick the right module (C2C, C2P, P2P, P2C) | | BCRs (Art. 47) | Valid, DPA-approved, costly/slow | Intra-group transfers for large orgs | | Derogations (Art. 49) | Narrow, case-by-case | Explicit consent, contract necessity, legal claims — not for repetitive/systematic transfers |

> DPF caveat (as of Jun 2026): the EU–US Data Privacy Framework remains in force but is under legal/political challenge (a "Schrems III"-type action is foreseeable). Don't make it your only US transfer mechanism — keep SCCs + TIA as a fallback. Verify a US importer's live certification at the official DPF list (dataprivacyframework.gov) and confirm the data type is covered. Check current adequacy decisions at the Commission's adequacy page before relying on one.

Transfer Impact Assessment (TIA) checklist (required alongside SCCs/Art. 46 tools, per Schrems II / EDPB Recommendations 01/2020):

1. Map the transfer — exporter, importer, data categories, purpose, onward transfers, transit countries, processing locations (incl. sub-processors and support access from abroad).
2. Identify the tool — SCC module / BCR / derogation; confirm it's signed and current.
3. Assess the destination's law & practice — government access powers, surveillance laws, redress for non-nationals; use EDPB/EU sources and the importer's transparency reporting, not just the importer's say-so.
4. Supplementary measures — technical (strong encryption with keys held in the EU/EEA, end-to-end encryption, pseudonymisation, split processing), contractual (warranties, notice of access requests, challenge obligations), organisational (access logging, policies for handling government requests).
5. Conclude & document — is protection "essentially equivalent"? If not even supplementary measures suffice, do not transfer. Record the assessment, set a review date, and re-run on legal change.

Penalties

• Up to €20M or 4% global annual turnover (whichever higher) — Art. 83(5)
• Lower tier: €10M or 2% for processor/technical violations — Art. 83(4)

Digital Services Act (Regulation 2022/2065)

Fully applicable since 17 Feb 2024 to all in-scope intermediaries. Obligations are cumulative and layered by service type — each tier inherits the obligations of the ones above it. Find your most specific category, then apply that row plus everything above it.

| Layer | Who it covers | Obligations added at this layer | |-------|---------------|---------------------------------| | Intermediary services (mere conduit / caching / hosting) | All providers offering services to EU recipients, regardless of establishment | Single point of contact for authorities (Art. 11) and for recipients (Art. 12); T&C transparency incl. content-moderation rules (Art. 14); annual transparency report on moderation (Art. 15 — micro/small enterprises exempt unless VLOP/VLOSE) | | + EU legal representative (Art. 13) | Only providers with no establishment in the EU that offer services in the EU | Appoint a named legal/natural person in a member state where they operate; that rep can be held liable for non-compliance. (EU-established providers do NOT need this.) | | + Hosting services | Store info at a recipient's request (incl. cloud/web hosting) | Notice-and-action mechanism (Art. 16); statement of reasons to the affected user for any restriction (Art. 17); report suspected serious criminal offences threatening life/safety (Art. 18) | | + Online platforms | Hosting that also disseminates info to the public (social, marketplaces, app stores) | Internal complaint-handling system (Art. 20); out-of-court dispute settlement (Art. 21); give priority to notices from trusted flaggers (designated by the national Digital Services Coordinator, not appointed by the platform) (Art. 22); measures against misuse (Art. 23); ban dark patterns in interface design (Art. 25); ad transparency + label (Art. 26); recommender-system transparency (Art. 27); enhanced protection of minors, no profiling-based ads to minors (Art. 28). Micro/small enterprises are exempt from Arts. 20–28. | | + Online marketplaces (B2C) | Platforms allowing consumers to conclude distance contracts with traders | KYBC — trace your trader (Art. 30); compliance-by-design of the interface (Art. 31); inform consumers when they bought an illegal product/service (Art. 32) | | + VLOPs / VLOSEs | Platforms/search engines with ≥45M average monthly EU users, designated by the Commission | Annual systemic-risk assessment + mitigation (Arts. 34–35); independent audits (Art. 37); recommender opt-out from profiling (Art. 38); public ad repository (Art. 39); data access for vetted researchers (Art. 40); compliance function + supervisory fee to the Commission (Art. 43) |

Establishment matters: Art. 13's legal-representative duty is only for providers with no EU establishment that nonetheless target the EU. Don't tell an EU-incorporated company it needs an Art. 13 rep — it needs Art. 11/12 contact points instead.

Notice-and-action workflow (Art. 16, inline — for hosting/platforms)

1. **Easy-to-use electronic su

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: san-npm
• Source: san-npm/skills-ws
• License: MIT
• Homepage: https://skills-ws.vercel.app

Install and usage instructions live in the source repository linked above.