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.