May we ask a customer or an employee for their personal code?

A personal code is personal data. Among identifiers, Article 4(1) GDPR names an identification number separately. A code usually stays the same for life. A standard code shows the date of birth and the sex. If a code falls into the wrong hands, it makes it easier to pretend to be someone else.

Article 87 GDPR lets Member States set specific conditions for processing a national identification number. Lithuania did this in Article 3 ADTAĮ. It contains three rules:

1. The code may be processed when at least one lawfulness condition in Article 6(1) GDPR applies.
2. The code may not be made public.
3. The code may not be processed for direct marketing.

A personal code is not special-category data. It is not on the list in Article 9(1) GDPR. But because it is sensitive, it is worth protecting just as carefully.

The law requires it (Article 6(1)(c) GDPR). Example: financial institutions and other obliged entities, when they identify a customer (a natural person) who is physically present, require an identity document that contains the personal code, or, for a foreign national, the date of birth (Article 10(1)(3) of the Law on the Prevention of Money Laundering and Terrorist Financing, PPTFPĮ). An employer must give Sodra (the State Social Insurance Fund) the employee's personal code. Before the employee starts work, the employer files a 1-SD notification, which includes the personal code, or the date of birth if no code has been assigned (Article 17(3) of the Law on State Social Insurance; points 14.2 and 18.1.1 of Sodra's rules on submitting data). Always write down which law and which article requires it.

The contract cannot be concluded or performed without the code (Article 6(1)(b) GDPR). The key word is "necessary". Ask yourself: can the contract really be performed only with the code? If a name, a surname, a date of birth or a customer number is enough, you do not need the code.

Legitimate interest (Article 6(1)(f) GDPR). Example: you provide a service with deferred payment and will need to identify the debtor reliably if they do not pay. Here you need a balancing test. The person may object to this processing on grounds relating to their particular situation (Article 21(1) GDPR). You then stop processing the code, unless you show compelling legitimate grounds that override the person's interests, or you need the code to establish, exercise or defend legal claims.

Consent rarely fits. If you will not provide the service without the code, although the service does not need it, the consent is probably not free (Article 7(4) GDPR). Recital 43 GDPR says that consent is not considered freely given if the performance of a contract depends on the consent, even though the consent is not necessary for that performance.

Article 5(1)(c) GDPR requires you to collect only the data the purpose needs. So a personal code is usually not needed:

• for an online shop order and delivery of goods;
• for registration for an event or a training course;
• for a newsletter or a loyalty programme (processing the code for marketing is prohibited, Article 3(3) ADTAĮ);
• for an enquiry form on a website;
• to check identity, when it is enough to see the document, not to copy it.

1. Write the purpose in one sentence. For example: "We need the code to identify the customer as the law requires."
2. Find the basis. It must be a specific article of a law, a contract clause, or a balancing test you have carried out.
3. Check whether there is a less intrusive way. A date of birth, a customer number or checking the document by eye is often enough.
4. Inform the person. Article 13(2)(e) GDPR requires you to say whether providing the data is required by law or by contract, and what happens if the person does not provide it.
5. Protect the code. Data must be protected against unlawful processing (Article 5(1)(f) GDPR). Let only the employees who need the code see it. Do not show the full code on screens and in documents where it is not needed. Do not send lists of codes by unencrypted email. Set a retention period (Article 5(1)(e) GDPR).

We ask for your personal code because [law and article / contract clause]. Providing it is [required / not required]. If you do not provide the code, [we will not be able to conclude the contract / we will provide the service without it]. We keep the code for [period], and only [roles] can see it.

If the code is not needed, remove the field. Keep an optional field only when the code serves a specific purpose and you have a basis for it.

• A code in a public document. A list of winners, meeting minutes on a website, or a document in a public folder. This is prohibited (Article 3(2) ADTAĮ).
• A code in a marketing system. Sorting customers into groups by age taken from the code, when this is done to send offers, is processing the code for direct marketing (Article 3(3) ADTAĮ).
• A "just in case" field. The code is collected everywhere because "we might need it". This breaches the data minimisation principle.
• A copy of the document when the law does not require one. A copy holds more data than the code: a photo, a signature, the document number. Exception: obliged entities must make a copy (Article 10(6)(5) PPTFPĮ).

Review every form, contract template and system where you collect personal codes. For each process, enter the basis and the retention period in your record of processing activities. With the tool you can find out whether you must keep a record of processing activities.

May we ask only for the last digits of the code?
Yes, if that is enough for the purpose. This is in line with data minimisation. But part of a code together with a name is still personal data, so the GDPR applies to it.

A customer refuses to give their code. What do we do?
If the code is required by law, explain this and state the consequences. If it is not required, offer another way, for example the date of birth.

May a personal code be sent by email?
There is no general ban, but you must ensure security (Article 5(1)(f) GDPR). An encrypted file, or a system with access rights, is safer.

May we work out age from the code and send offers based on it?
No. That would be processing the code for direct marketing (Article 3(3) ADTAĮ). If you need the age, ask for the year of birth separately.

• Legitimate interest balancing test: how to carry it out
• Must we keep a record of processing activities?
• How to set a retention period when the law does not set one?
• Candidate recruitment data in practice

The law and the risk: Personal code and ID copies: what you may ask a customer for (dat.lt)

• Conditions for processing the personal code: Article 3(1) ADTAĮ; ban on making it public: Article 3(2); ban on using it for marketing: Article 3(3).
• Member States may set conditions for a national identification number: Article 87 GDPR.
• Definition of personal data: Article 4(1) GDPR.
• Legal bases: Article 6(1)(b), (c) and (f) GDPR; consent as a condition of a contract: Article 7(4) GDPR and recital 43.
• Principles: data minimisation: Article 5(1)(c) GDPR; storage period: Article 5(1)(e); security: Article 5(1)(f).
• Informing about whether data is required and the consequences: Article 13(2)(e) GDPR.
• Right to object: Article 21(1) GDPR.
• Special-category data: Article 9(1) GDPR.
• Customer identification: Article 10(1)(3) PPTFPĮ; copy of the document: Article 10(6)(5).
• Employer data for Sodra: Article 17(3) of the Law on State Social Insurance; points 14.2 and 18.1.1 of the Rules for submitting and correcting data on insured persons and insurers (order No. V-243 of the Director of the Fund Board, 2010-06-04).

GDPR read from the official Lithuanian text (OJ L 119, 2016-05-04). ADTAĮ (Law on the Legal Protection of Personal Data), PPTFPĮ (Law on the Prevention of Money Laundering and Terrorist Financing), the Law on State Social Insurance and the Sodra rules read from the consolidated versions in force. English wording of Lithuanian provisions is our translation. This text is general information and is not individual legal advice.