GDPR and Smart Card Data

GDPR and Smart Card Data

The General Data Protection Regulation (EU 2016/679) imposes obligations on any organisation that processes personal data of EU/EEA residents. Smart card deployments routinely process personal data at multiple points: during personalisation, on-card storage, terminal-side transaction logging, and backend database management. GDPR compliance is therefore not optional for European card programmes — it must be designed in from the start.

Personal Data in Smart Card Systems

Smart cards often carry or trigger processing of the following categories:

Special category data (biometrics, health) requires a specific legal basis under Article 9 — typically explicit consent or the employment/social protection gateway — and demands elevated security measures.

Card Personalisation and Data Minimisation

During card personalisation, data preparation bureaux encode personal data onto the chip's file system (see the Card Personalization Systems Guide). GDPR Article 5(1)(c) requires that only data necessary for the stated purpose be collected and stored. Common personalisation data minimisation steps include:

• Store a reference identifier (e.g., hashed employee number) rather than full name on the chip whenever the terminal can resolve identity from the backend.
• Use derived credentials — the card stores a public key certificate; the backend holds the identity binding.
• Omit optional data fields (e.g., DG7 signature image in ePassports) unless the programme specifically requires them.
• Set retention limits: EEPROM records such as loyalty counters or transit logs should have defined purge conditions.

On-Card Biometric Data

Where the card stores fingerprint templates (e.g., national ID cards or high-security access cards) rather than relying on match-on-server, GDPR Article 9 requires:

1. Explicit consent or a specific Article 9(2) gateway (often Article 9(2)(g) for public interest identity schemes).
2. Data Protection Impact Assessment (DPIA) under Article 35 — biometric processing is explicitly listed as high-risk.
3. Match-on-cardMatch-on-cardBiometricBiometric matching performed inside the smart card chip.Click to view → architecture where possible: keep the template on the chip, never transmit it to a reader. The Secure Element boundary ensures the template cannot be extracted externally.

Match-on-card implementations using a PACE-secured channel (as in modern ePassports) satisfy the technical safeguards requirement.

Data Subject Rights

Card programmes must implement mechanisms to satisfy GDPR data subject rights:

On-chip erasure of EEPROM or Flash memory must be cryptographic (overwrite with random data or destroy the encryption key) rather than logical delete, given that flash storage can retain data after logical deletion.

Data Processor Relationships

Card personalisation bureaux, terminal management providers, and transaction processors typically operate as data processors under Article 28. GDPR requires:

• A written Data Processing Agreement (DPA) for each processor relationship.
• Documented processor security measures — relevant certifications include ISO/IEC 27001 and SSAE 18 SOC 2.
• Notification obligations: processors must inform controllers of breaches within 72 hours (Art. 33).
• Sub-processor approval clauses for fourth-party relationships (e.g., the bureau's own cloud infrastructure provider).

Privacy by Design Checklist

See the PSD2 SCA Guide for payment-specific GDPR intersections, and the ePassport Technology Guide for biometric data handling in travel documents.