You issue employee badges, member cards, or transit credentials every quarter — and each one carries a name, an ID number, sometimes a photo or even a biometric template. Under the GDPR, that is personal data, and the moment you print, encode, or revoke a card you are “processing” it. For a B2B buyer, the question is no longer can we put this on a card, but are we allowed to, and have we built the program so a regulator — or a breach — does not land on our desk. This guide walks through what a card program must get right, in the order a procurement or security lead actually has to decide it.
What Personal Data Actually Lives on a Card
Before you can protect cardholder data, you have to know where it sits. A credential is typically three layers deep:
- Printed surface — name, employee or member number, department, photo, and sometimes a job title or access zone.
- Machine-readable marks — a magnetic stripe, barcode, or QR code. These are often stored in plaintext, which means anyone with a reader can extract the value.
- The chip or secure element — a file structure that may hold a cardholder reference, a certificate, or cryptographic keys. On a contactless card this is read wirelessly within a few centimetres.
The practical takeaway: a card is a portable copy of identity data. The more of it you emboss on the surface or encode in the clear, the larger your exposure if a card is lost, cloned, or photographed.
Why GDPR Reaches Your Card Program — Even Outside the EU
The GDPR’s territorial scope (Article 3) catches organisations that are not established in the EU but offer goods, services, or monitor individuals in the EU. If your programme covers EU-based staff, members, students, or visitors, you are in scope regardless of where your factory sits. The UK retains a near-identical UK GDPR, and several non-EU jurisdictions have copied the model.
Critically, “processing” is broad: it includes issuance, personalization, encoding, daily verification, and revocation. Simply handing a card to an employee is a processing activity, which means the accountability obligations attach to your programme from day one — not just after a breach.
Choose a Lawful Basis Before You Print
Every processing activity needs a lawful basis under Article 6. For card programmes the realistic options are:
- Contractual necessity — issuing an access card because employment or membership requires it.
- Legitimate interest — the most common basis for physical access control, supported by a documented balancing test.
- Consent — freely given and revocable, but weak for employees because of the power imbalance; do not default to it for staff.
Pick the basis per use case, write the reasoning down, and reflect it in your privacy notice. A buyer who can show this trail is far better protected than one who assumed “everyone does it.”
Data Minimization: Put Less on the Card
The principle of data minimization (Article 5(1)(c)) is your cheapest security control. Store a reference number, not a name, on the magnetic stripe or QR code; keep the personal record in a backend system the card only points to. A lost card then reveals a token, not an identity, which dramatically shrinks the blast radius of a breach and the size of your breach-notification duty.
For most B2B programmes this means designing the card as a key, not a folder — a credential that unlocks a record rather than carrying the record itself.
How the Chip Protects Cardholder Data
A contact or contactless smart-card chip is a tamper-resistant secure element. Well-designed credentials use mutual authentication and AES-128 encryption so files are only readable by an authorized reader, and the cryptographic keys never leave the chip. This is the technical backbone that lets you store a credential — rather than raw personal data — on the card.
Good key management is what makes this real. If you specify and rotate keys properly (see our smart card key management guide), a cloned card yields nothing useful, and offline verification means no central database has to be queried at every door.
Run a DPIA for Higher-Risk Programs
Where a programme involves large-scale systematic monitoring or special-category data such as biometric templates, a Data Protection Impact Assessment is mandatory under Article 35. The DPIA documents why the processing is necessary, what risks cardholders face, and how you mitigate them. Even when not strictly required, running one is good buying discipline: it forces you to justify every data field before it goes to print.
Lock It Down in Supplier and Processor Contracts
When your factory personalizes or encodes cards, it is a “processor” and Article 28 requires a written contract. Insist on clauses covering purpose limitation, sub-processing controls, security measures, breach notification within 72 hours, secure deletion on termination, and audit rights. Ask for evidence of an ISO/IEC 27001 information-security management system — it is the fastest signal that a supplier takes data protection seriously. Our card shipment inspection checklist covers the receiving-side controls that pair with this.
Handle Employee, Member, and Transit Data Differently
Not all cardholders are equal in the eyes of the regulation:
- Employees — rely on contract or legitimate interest, never consent; honour access and erasure requests (DSARs) promptly.
- Members and guests — contractual basis with a clear, readable privacy notice at enrolment.
- Transit and loyalty users — behavioural and location data attracts higher scrutiny; anonymize or aggregate where you can.
When you weigh physical versus mobile credentials, the data-handling trade-offs matter as much as the hardware — our mobile vs physical card comparison covers that decision.
Breach Response and Accountability
Accountability is the GDPR’s overarching principle. Keep records of processing (Article 30), train staff, appoint a DPO where required, and build a revocation workflow that can remotely disable a credential the moment it is reported lost. If a Personal Data Breach occurs, notify the supervisory authority within 72 hours under Article 33 where the risk is high. A programme that ties card issuance to a documented PII protection standard such as NIST SP 800-122 is markedly easier to defend.
The good news for buyers: most of the heavy lifting is design work done once, at specification time. Decide the lawful basis, minimize what sits on the card, choose chips that encrypt, and write the obligations into your supplier contract. Do that, and a card programme becomes a manageable compliance asset rather than a lurking liability.
Ready to specify a privacy-by-design card programme? Talk to our team about chip selection, secure encoding, and a procurement specification that bakes in GDPR obligations from the first draft.
