I've spent four years reviewing SaaS Data Processing Agreements from the supplier side and one year reviewing them from a fintech buyer's seat. The clauses everyone worries about — encryption-at-rest, retention windows, the breach-notification SLA — are usually fine on a serious shortener. The clauses that actually decide procurement are subtler. They're the ones the DPO has read enough times to have an opinion about, and the ones a generic "GDPR compliant" badge does not address.
This post is a working DPO's read on what the GDPR requires of a URL shortener that processes click data on EU subjects, with the article numbers cited so you can take the claims to your own counsel and verify. I'll flag where Elido's posture is conservative, where it's industry-standard, and where the reasonable buyer should still ask for an addendum.
The article references are to Regulation (EU) 2016/679 — the consolidated GDPR text on EUR-Lex. Where I cite supervisory authority guidance, I link to the source decision. Where I cite case law, the citation is to the CJEU judgment.
Why a URL shortener is in scope at all#
A URL shortener is a processor under Article 4(8) when it processes click data on identifiable natural persons on behalf of the customer. The customer is the controller; they decide why the data is collected (campaign attribution) and on what basis (Article 6 — typically legitimate interest under 6(1)(f) for click-level analytics, consent under 6(1)(a) where granular tracking is involved). The shortener is the processor; it processes that data only on documented instructions from the controller, which is the substance of Article 28.
Two pieces of data make this clear-cut. Every redirect logs an IP address; the CJEU has held since Breyer (C-582/14, 2016) that dynamic IP addresses can be personal data when combined with information available to the controller. Every redirect also logs a user-agent, which when combined with IP and timestamp is enough to single out individuals in many high-traffic patterns — the EDPB has flagged this in Guidelines 04/2020 on the use of location data and the principle generalises.
So: a URL shortener processes personal data on EU subjects, even if the click event itself looks anonymous on first glance. The questions follow from there.
Article 3: territorial scope#
Article 3 is the article that gets misread most often by US-based vendors selling into the EU.
Article 3(1) covers processing in the context of an EU establishment. Article 3(2) covers processing of EU-subject data by a non-EU controller or processor when the processing relates to (a) offering goods or services to EU subjects, or (b) monitoring their behaviour where it takes place in the EU. Click tracking on EU users is monitoring; the GDPR applies regardless of where the shortener is hosted.
The takeaway is that "we're a US company, GDPR doesn't apply" is wrong. Every shortener processing EU-user clicks must comply. The relevant question for procurement is not whether the GDPR applies — it does — but how the vendor demonstrates compliance and what residency commitments are contractually binding.
Article 6: lawful basis#
Click tracking via a shortener typically rests on one of three lawful bases.
6(1)(a) — consent. The controller has obtained the data subject's consent for the processing. For shortener-level click tracking, consent is usually layered into the cookie banner or the marketing opt-in flow on the destination page. The EDPB guidelines on consent (Guidelines 05/2020, version 1.1, 2020) require freely given, specific, informed, and unambiguous consent.
6(1)(b) — necessary for performance of a contract. The redirect itself — taking the click and routing it to the destination — is necessary for the service the user requested. The cleanest line is that the routing is performance of contract, while the analytics layer (whether that click is recorded for retrospective analysis) is a separate processing operation that may need a different basis.
6(1)(f) — legitimate interest. Most B2B customers ground campaign-level analytics in legitimate interest after running a Legitimate Interest Assessment (LIA). The LIA balances the controller's interest in measuring marketing effectiveness against the data subject's interests; for aggregate click counts and standard attribution, the balance generally tips in favour of the controller. For high-resolution behavioural profiling — fingerprinting, cross-site tracking, retargeting at the user level — the LIA gets harder.
The shortener is the processor in all three cases. It processes the data on documented instructions from the controller. It does not pick the lawful basis; the controller does.
Article 28: the processor agreement#
Article 28(3) lists the eight obligations that any contract between a controller and a processor must include. Read it directly; the sub-paragraphs (a) through (h) are short and concrete. A serviceable DPA for a URL shortener has to address each.
I'll walk through what those clauses look like in practice.
(a) Processing only on documented instructions. The controller's instructions are the contract plus the customer's written instructions on a per-feature basis (e.g. "process click events for these workspaces, retain for X months"). The shortener cannot use click data for its own purposes without the controller's instruction. In practice this means: no using customer click data to train internal recommendation models without an opt-in, no aggregate analytics shared with third parties without notice. Elido's standard DPA is explicit about this; if your incumbent shortener's DPA isn't, ask why.
(b) Confidentiality. People processing the data are bound by confidentiality obligations. This is operational on the supplier side and rarely contested.
(c) Security measures (Article 32). Covered below in its own section.
(d) Sub-processor engagement. The processor only engages sub-processors with the controller's authorisation, and the sub-processor must accept equivalent obligations under a written contract. There are two flavours of authorisation. Specific prior authorisation requires the controller to consent to each new sub-processor. General prior authorisation requires only notice in advance, with a right to object. Most SaaS contracts use general authorisation with a 30-day notice window. Both are fine under Article 28; what matters is that the contract specifies which.
(e) Data subject rights assistance. The processor has to help the controller respond to data subject requests under Articles 15-22. For a shortener, this means the controller can ask for a click record export keyed to a specific identifier (rare but happens), and the shortener has to be able to deliver it. The Elido API includes GET /v1/clicks?subject_id= for this purpose; if your incumbent doesn't have this, you'll be answering subject-access requests by hand.
(f) Article 32 / 33 / 34 / 35 / 36 assistance. The processor has to help the controller meet security, breach-notification, and DPIA obligations. The "help" is operational — providing security audit reports, notifying breaches within an SLA, supplying the technical detail needed for a DPIA.
(g) Return or deletion at end of services. When the contract ends, the processor returns or deletes all personal data unless union or member state law requires storage. Elido's standard clause is 30 days post-termination, with a documented deletion certificate on request.
(h) Audit rights. The processor must make available all information necessary to demonstrate compliance and submit to audits. SaaS contracts narrow this to written audit questionnaires plus on-site audits with reasonable notice; full unrestricted audit rights are unusual outside enterprise contracts.
If your incumbent's DPA is missing or vague on any of (a)-(h), the procurement conversation should not move forward. A DPA that meets Article 28 is the floor, not the ceiling.
Article 30: records of processing#
Article 30 requires processors to maintain records of processing activities (RoPA). The processor's RoPA is the controller-facing artefact that lets your DPO understand what the shortener is doing with the data.
Elido publishes a per-customer RoPA template you can map to your own. The columns are categories of data subject, categories of personal data, recipients, transfers to third countries (none by default), retention, and security measures. Cookie-cutter, but procurement teams want to see it filled in concretely. The DPO doesn't want a placeholder. If your shortener won't supply this, the burden falls on you to compile it from their documentation.
Article 32: security of processing#
Article 32 requires "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk. The article is deliberately not prescriptive; the supervisory authorities flesh it out via guidance.
For a URL shortener, the operational floor most DPOs will look for:
- TLS 1.3 in transit, no fallback to TLS 1.0 or 1.1.
- Encryption at rest for the click event store, with documented key rotation.
- Network segmentation between the redirect plane and the analytics plane.
- Authentication via SSO/SAML or OIDC for the customer-facing surface; service-to-service via short-lived credentials.
- An audit log of administrative actions on the shortener side, retained for at least 12 months.
- Documented incident response and regular tabletop exercises.
- ISO 27001 certification or equivalent independent attestation.
Elido is ISO 27001 certified and is mid-flight on SOC 2 Type II (target H2 2026). The technical-control surface is documented in the trust page. For HIPAA-relevant traffic, BAAs are available on the Business plan.
The article-level wording matters here: "appropriate to the risk" is a relative standard. A shortener processing campaign clicks on a public marketing site is lower-risk than one used internally to share authenticated session URLs. Your DPO should be sized for the risk you actually run.
Article 35: DPIA#
Article 35 requires a Data Protection Impact Assessment for processing "likely to result in a high risk to the rights and freedoms of natural persons", with particular attention to (a) systematic and extensive evaluation, (b) special-category data, and (c) systematic monitoring of publicly accessible areas on a large scale.
For most shortener use cases, a DPIA is not strictly required — campaign click tracking on a marketing site is not "systematic and extensive evaluation" within the meaning of 35(3)(a). Where a DPIA does become advisable:
- Cross-site behavioural profiling at the individual level.
- Tracking that combines shortener data with other personal data (CRM enrichment, third-party data brokers) to build a person-level profile.
- Use of click data to make decisions with legal or similarly significant effects on the data subject (rare, but conceivable in lending or employment contexts).
- High-volume traffic from special-category contexts (health, religion, political opinion).
If you're commissioning a DPIA for shortener-related processing, the WP29 guidelines (WP248 rev.01) are the methodological reference; many supervisory authorities have published their own templates, including the CNIL's PIA software.
Article 28(2): sub-processor disclosure#
The most tractable single GDPR question is "who else touches the data?". Article 28(2) requires that the processor disclose any sub-processor it engages and obtain authorisation. In practice, every serious SaaS publishes a sub-processor list and a notification process for adds.
What a good list looks like:
- Sub-processor name, location of processing, role.
- Categories of personal data shared.
- Legal basis for the transfer (where applicable).
- Date the sub-processor was added.
- Notification mechanism for adds (typically email + RSS/JSON feed).
- Right to object: usually 30 days from notification.
Elido's public sub-processor list names five vendors. That number is small on purpose — every new sub-processor adds to the surface area of your privacy programme. Compare against the incumbent: if they have 30 sub-processors and you can't tell which are on the click-event path, that's a material disclosure question.
Schrems II: when EU residency becomes contractual#
Schrems II (CJEU C-311/18, 2020) invalidated the EU-US Privacy Shield and required, for international data transfers under SCCs, a Transfer Impact Assessment evaluating whether the destination country's surveillance regime would deny EU subjects effective rights protection.
The successor framework — the EU-US Data Privacy Framework, adopted via Commission Decision (EU) 2023/1795 — replaces Privacy Shield for participating organisations. Two important caveats:
- Coverage is voluntary; not every US SaaS vendor is certified. Check the DPF participant list.
- The framework is itself the subject of pending litigation. NOYB has signalled an intent to challenge and a third Schrems judgment is plausible. Buyers prudent enough to plan for that scenario are increasingly contractually requiring EU-only processing.
Where this lands for shortener selection: if your buyer has flagged data residency or your sector regulation requires EU-only processing (German healthcare under the social data protection law, French health data via HDS certification, financial services under EBA guidelines), an EU-hosted shortener simplifies the contract. The residency clause is concrete, the TIA is unnecessary, and the procurement cycle shortens.
Elido is hosted in Frankfurt by default. Business+ customers can pin to Ashburn or Singapore where their traffic profile demands it. The pinning is per-workspace, contractually documented, and operationally enforced — not a marketing claim.
Data minimisation: what you don't have to log#
Article 5(1)(c) requires that processing be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed". For a shortener, this lands on the click-event schema.
The signals a shortener can collect at redirect time:
- IP address (full, /24 truncated, or hashed).
- User-agent string (full, or parsed into client/OS without the rare-tokens that fingerprint).
- Referrer.
- Timestamp.
- Geo-derived from IP (country, city).
- Device-derived from UA (mobile/desktop/tablet, OS family).
- Click ID (the shortener's own identifier for the event).
Of those, the controller's actual purpose usually requires the parsed device, the country, the timestamp, the click ID, and possibly the referrer. The IP address itself is rarely needed past the moment of redirect — once geo and device parsing are done, the IP can be truncated or hashed before it lands in the click store. Same for the UA: the parsed device.type / device.os fields are what attribution actually uses; the full UA string is fingerprinting bait that should be discarded.
Elido truncates IPs to /24 (IPv4) or /48 (IPv6) before persisting click events. The full UA is parsed and dropped. Both behaviours are documented and configurable per-workspace if your specific use case requires the higher-resolution data — but the default is minimisation, which is the Article 5(1)(c) posture by design rather than by patch.
Data subject rights at the shortener layer#
The controller fields data subject rights requests; the processor assists. For a shortener, two requests come up:
Article 15 — right of access. The data subject asks for a copy of their personal data. The shortener has to be able to retrieve click events keyed to a subject identifier. In practice, this is hard if the only identifier is "everyone who clicked link X from this IP". The pragmatic answer: the shortener exports the click events for the IP/timeframe the controller specifies, and the controller filters to the relevant subject.
Article 17 — right to erasure. The data subject asks for deletion. The shortener has to be able to delete click events on demand within the GDPR's "without undue delay" wording — the default operational SLA is 30 days. The complication: click events are usually stored in an append-only analytics database (ClickHouse, BigQuery, Snowflake). Deletion is real, but it's a DELETE against the partition rather than a row-level edit. Make sure your shortener's DPA commits to a specific erasure SLA and that the underlying architecture can meet it.
Elido supports both via the API: GET /v1/subjects/{id}/clicks and DELETE /v1/subjects/{id}. The deletion is propagated to the click event store within 24 hours and confirmed via webhook.
What to ask procurement#
The compressed checklist for a procurement conversation:
- Where is the shortener hosted? (One sentence answer; pin or not.)
- Is the DPA pre-signed or negotiated per customer? (Pre-signed is faster.)
- How many sub-processors? (Smaller is simpler.)
- Does the standard contract include EU-only processing, or is that a separate addendum?
- What's the IP-truncation default on click events?
- Is there an Article 15 / 17 endpoint, or does erasure go through support?
- What's the breach-notification SLA? (24 hours from awareness is industry norm.)
- Independent attestation: ISO 27001? SOC 2 Type II? When was the last audit?
A vendor that can answer those eight in writing on the discovery call is procurement-ready. A vendor that can't is going to add weeks to your sales cycle.
Read the cornerstone series#
This is the cornerstone of the compliance cluster. Sibling posts in the cluster: the upcoming EU data residency for marketing analytics (deeper on contractual specifics), Schrems II and tracking pixels (the practical impact on attribution), and Click attribution after Safari ITP (the operational consequence of the cookieless world). For the procurement-facing summary, the trust page and solutions/compliance are the two artefacts to bookmark. For the architectural detail behind the residency claim, the edge-redirect architecture doc walks through how the regional pinning is enforced at routing time.