Security & privacy
QR codes and GDPR — when a scan becomes personal data
A static QR code generated client-side and pointing straight at your site adds no personal-data processing beyond an ordinary web visit. Dynamic codes are different: every scan log containing an IP address is personal data under GDPR, so you need a lawful basis, a processor agreement with the provider, and transparency at the code.
Where GDPR enters a QR flow
A QR code is printed text; the ink itself processes nothing. GDPR becomes relevant at three possible points: what you put in the payload, what happens at creation, and what happens at every scan. This page is educational background for designing lower-risk QR flows — it is not legal advice, and specific questions belong with a qualified adviser.
The three cases:
| Flow | Personal data processed? |
|---|---|
| Static code, client-side generated, pointing at your site | Only the ordinary web visit your site already handles |
| Payload containing personal data (a vCard, an email address) | Yes — at creation, by any server-side generator that receives it |
| Dynamic code via a redirect provider | Yes — per-scan logs held by a third party |
Scan logs are personal data
A dynamic provider records the scanner's IP address, device details and timestamp on every scan — the mechanics are in dynamic QR codes and privacy. An IP address is personal data even when you cannot identify the person yourself; the EU Court of Justice settled that in its Breyer judgment. Consequences follow directly:
- You are the controller of a campaign's scan analytics; the provider processing them for you is a processor, which requires a data processing agreement (Article 28).
- A provider hosted outside the EU/EEA adds an international transfer to analyse.
- Data subjects hold their usual rights over the logs — access, erasure — which you can only honour if the provider supports them.
Lawful basis for scan analytics
Counting scans in aggregate is commonly argued under legitimate interest; building per-person profiles from scan behaviour points toward consent, which is awkward to collect before a redirect fires. The practical guidance is data minimisation (Article 5(1)(c)): collect scan counts if counts answer the question, and resist the dashboard maximalism of tools that log everything because they can. A fuller inventory of what gets recorded is in what is logged when you scan.
Transparency at the code
A person deciding whether to scan cannot see where the code goes or what the scan triggers. The clean pattern is a notice at the code: print the destination domain and, where analytics run, a short honest line — "Scans are counted anonymously" — next to the code. This does double duty: it is a transparency measure and it makes fraudulent sticker overlays easier to spot. Wording that tells people what scanning does belongs to the same craft as a good call to action.
Designing for minimisation
The lowest-exposure design is also the simplest: a static code pointing directly at your own domain, generated client-side so no third party sees the payload — see client-side vs server-side generation. Measurement then runs through your existing, already-documented site analytics using campaign parameters, with no new processor and no new scan-log dataset to account for.
The CCPA contrast
California's CCPA/CPRA takes a different shape: an opt-out regime rather than opt-in, built around rights to know, delete and opt out of "sale" or "sharing" of personal information — definitions broad enough that scan analytics passed to an adtech-flavoured provider may qualify. The design conclusion is the same on both sides of the Atlantic: the less a scan generates about a person, the less law you drag into a piece of printed matter.
FAQ
Are QR codes GDPR compliant?
The code itself is out of scope — it is printed text. Compliance questions attach to the flow around it: what the payload contains, whether generation sends data to a server, and whether scans are logged by a provider. A static, client-side-generated code pointing at your own site adds nothing new to comply with.
Is a QR code scan personal data?
A scan handled by a dynamic provider produces a log entry containing the scanner's IP address, which is personal data under GDPR. A static code produces no scan record beyond the ordinary visit to the destination site.
Do I need consent for QR code analytics?
Aggregate scan counting is commonly run under legitimate interest; anything approaching individual profiling points toward consent. Either way you need transparency, a lawful basis you can articulate, and a processor agreement with any provider holding the logs.
Do I need a privacy notice next to a QR code?
It is good practice: print the destination domain and a short line saying what scanning does. It satisfies the spirit of transparency and simultaneously makes a substituted malicious sticker easier to notice.
Try it — free, no signup
Related
- Are QR codes safe? — Scanning a QR code is safe in itself — it decodes text and nothing else. The risk is entirely in what you do next. A code cannot install software, dial,…
- Dynamic QR codes and privacy — what every scan reveals — Every scan of a dynamic QR code transits the provider's server, which can log IP, device and time. What is collected, what to ask, and when static is safer.
- QR codes in HIPAA contexts — keeping PHI out of the pixels — Never encode PHI in a QR code — a printed code is plain text forever. Safe token patterns, the BAA question for providers, and why wristbands get it right.
- QR codes and PCI DSS — what is actually in scope — UPI, PIX and EPC codes carry account references, not card numbers — largely out of PCI scope. Where QR payment flows do and do not touch PCI DSS.
- An enterprise QR code policy you can adopt — An adoptable enterprise QR policy — approved generators, own-domain rules, design standards, a code registry, audit cadence and an incident playbook.