Article 87: Processing of the national identification number

Article 87 requires you to process national identification numbers (and similar universal identifiers) only under “appropriate safeguards,” and to follow any stricter Member State rules that define when and how those identifiers may be used. Operationalize it by mapping where IDs are collected and stored, validating the local legal conditions, and implementing strict access, minimization, and disclosure controls. (Regulation (EU) 2016/679, Article 87)

Key takeaways:

• Treat national ID numbers as a “special handling” identifier: minimize collection, tightly control access, and prevent unnecessary reuse across systems. (Regulation (EU) 2016/679, Article 87)
• Check country-by-country conditions; Article 87 is explicitly designed to be tightened by Member State law. (Regulation (EU) 2016/679, Article 87)
• Keep an evidence packet that shows decisions, safeguards, and operating controls across intake, storage, sharing, and retention. (Regulation (EU) 2016/679, Article 87)

“National identification number” processing is a recurring failure point because it looks like ordinary personal data operationally, but it behaves like a high-impact identifier in risk terms: it enables account takeover, identity fraud, and cross-context linkage if mishandled. Article 87 gives Member States room to set more specific conditions, which means your program cannot stop at “GDPR compliant” policy language. You need a repeatable method to determine: where these identifiers exist, why you process them, which systems and third parties touch them, what the local rules require, and what safeguards you have in place to protect data subject rights. (Regulation (EU) 2016/679, Article 87)

For a CCO, Compliance Officer, or GRC lead, the practical goal is simple: you should be able to answer, on demand, “Which national identifiers do we process, under what legal conditions in each country, who can access them, how are they protected, and how do we prevent unnecessary propagation?” This page gives requirement-level implementation guidance you can assign to owners and test quickly, with audit-ready evidence outputs.

Regulatory text

Text (verbatim excerpt): “Member States may further determine the specific conditions for the processing of a national identification number or any other identifier of general application. In that case the national identification number or any other identifier of general application shall be used only under appropriate safeguards for the rights and freedoms of the data subject pursuant to this Regulation.” (Regulation (EU) 2016/679, Article 87)

What the operator must do (what regulators expect to see in practice):

1. Identify whether you process a national identification number (or similar universal identifier) at all, including in logs, exports, tickets, scanned documents, and third-party workflows. (Regulation (EU) 2016/679, Article 87)
2. Determine the country-specific “conditions” that apply to your processing context (e.g., employment onboarding, customer verification, government reporting) because Article 87 allows Member States to narrow or condition use. (Regulation (EU) 2016/679, Article 87)
3. Implement “appropriate safeguards” that reduce unnecessary use and protect data subject rights and freedoms across the lifecycle: collection, access, sharing, retention, and deletion. (Regulation (EU) 2016/679, Article 87)

Source: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#art_87 (Regulation (EU) 2016/679, Article 87)

Plain-English interpretation (requirement-level)

If you process national ID numbers, you need two things:

• Local rule alignment: confirm whether each relevant EU/EEA country has extra conditions for using national ID numbers (or other broadly applicable identifiers) and build those conditions into your operating procedures. (Regulation (EU) 2016/679, Article 87)
• Safeguards you can demonstrate: apply stricter controls than you might for ordinary identifiers, and keep evidence that the controls operate consistently. (Regulation (EU) 2016/679, Article 87)

A useful mental model for teams: national ID numbers are often treated as “high-linkability” identifiers. Your controls should prevent unnecessary re-use as a universal key across unrelated purposes, systems, or third parties, unless the relevant legal conditions support that use. (Regulation (EU) 2016/679, Article 87)

Who it applies to (entity and operational context)

Applies to: any organization acting as a controller or processor that processes national identification numbers or “any other identifier of general application.” (Regulation (EU) 2016/679, Article 87)

Common operational contexts where Article 87 shows up:

• HR and workforce: hiring, payroll, benefits administration, background checks, right-to-work verification, contractor onboarding.
• Customer identity and fraud controls: KYC-style checks, account recovery, high-risk transactions, age/eligibility verification.
• Regulated reporting: tax, social security, health insurance, or other statutory reporting streams.
• Third party processing: payroll providers, background-check firms, benefits brokers, identity verification providers, ticketing/BPO providers.

Controller vs. processor note: Your control design changes based on whether you decide purposes/means (controller) or act on instructions (processor). Start by writing down the role per processing activity so the team can assign accountability and contract controls correctly. (Regulation (EU) 2016/679, Article 87)

What you actually need to do (step-by-step)

Step 1: Build a “national ID inventory” that is system-and-workflow specific

Create a register that answers:

• Which identifiers qualify (national ID number; other general identifiers used widely in the country). (Regulation (EU) 2016/679, Article 87)
• Where they are collected (forms, document upload, call center, API, batch file).
• Where they land (databases, CRM, HRIS, document storage, analytics, logs).
• Where they leave (exports, emails, data warehouse, third parties).
• Which teams and roles access them.

Output artifact: “National ID Processing Register” (can be a view of your ROPA plus extra fields for Article 87 handling). (Regulation (EU) 2016/679, Article 87)

Step 2: Determine Member State “specific conditions” and document the decision

Article 87 is explicit that Member States may set conditions; your operational control is to make those conditions discoverable and actionable. (Regulation (EU) 2016/679, Article 87)

Create a short decision record per country/use case:

• Country and identifier type.
• Purpose(s) for processing.
• Whether processing is necessary for that purpose.
• Which internal policy/standard applies.
• What additional restrictions or approvals apply in that country.
• Legal/Privacy sign-off (who approved, when, and scope).

Practical approach: establish a “trigger” that forces review when you expand into a new EU/EEA country, add a new IDV provider, change onboarding flows, or add a new analytics use case that would copy IDs into another system.

Step 3: Implement “appropriate safeguards” as concrete controls

Article 87 doesn’t list safeguards; you have to choose safeguards that protect rights and freedoms in your environment. Use a control set that is testable and maps to the lifecycle. (Regulation (EU) 2016/679, Article 87)

Minimum safeguard set most teams can implement quickly:

Lifecycle point	Control	What “good” looks like
Collection	Minimization	Only collect national ID when a documented purpose requires it; avoid “optional” fields that become de facto mandatory.
Storage	Segmentation	Store IDs in a dedicated field/table/vault; avoid copying into notes fields, free-text tickets, or analytics events.
Access	Least privilege	Default deny; limit to named job roles; require approval for new access; periodic access review.
Use	Purpose limitation guardrails	Block reuse as a universal key across products unless a decision record exists and safeguards are in place.
Sharing	Controlled disclosure	No ad hoc emailing of IDs; use secure transfer, contractual controls, and data minimization with third parties.
Retention	Retention rules	Keep IDs only as long as needed for the documented purpose; implement deletion or irreversible redaction where feasible.

Step 4: Translate into operating procedure with named owners

Write a procedure that a manager can execute without interpreting legal text:

• Intake checklist for any workflow that collects IDs.
• Required approvals (Privacy/Legal/Security) when introducing a new use case or third party.
• Standard storage pattern (approved systems only).
• “Don’t do this” list (e.g., don’t paste IDs into ticket notes).
• Exception process with time-bound remediation.

This is where many programs fail: the policy exists, but there is no operational pathway for product, HR, or customer operations to follow consistently. (Regulation (EU) 2016/679, Article 87)

Step 5: Add monitoring and test steps

Pick controls you can verify:

• DLP or log scanning rules for national ID patterns (where feasible).
• Access review evidence for the systems storing IDs.
• Spot checks on support tickets and document stores for improper storage.
• Third party data flow checks (what fields are actually sent).

Daydream tip (earned mention): teams often lose time stitching together evidence across security, privacy, and operations. Daydream can act as the system of record for the Article 87 role-and-scope register, decision records, and recurring evidence packets so you can respond to audits and customer diligence without rebuilding the story each time.

Required evidence and artifacts to retain

Keep an “Article 87 evidence packet” per business unit or processing domain:

1. Role-and-scope register: controller/processor role by activity; systems; categories; third parties.
2. National ID Processing Register: data flow map + system list + access points.
3. Member State conditions decision record: country-by-country determinations and approvals.
4. Safeguards mapping: control matrix tied to collection/storage/access/sharing/retention.
5. Access control evidence: role mapping, approvals, and access review outputs for in-scope systems.
6. Data sharing evidence: third party inventory entries and data field lists for transfers.
7. Exceptions and remediation log: what deviated, risk acceptance (if any), and closure proof.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me where national IDs exist, including unstructured repositories and exports.”
• “Which countries’ rules apply to your workforce/customer base, and who approved your interpretation?” (Regulation (EU) 2016/679, Article 87)
• “Why do you need the national ID for this purpose? What breaks if you don’t collect it?”
• “Who can access national ID data today? Prove it with system permissions and access review output.”
• “Which third parties receive IDs, and what prevents onward sharing or repurposing?”

Common hangup: teams answer with policy language. Auditors ask for system-level proof.

Frequent implementation mistakes and how to avoid them

1. Treating national IDs as “just another field.”
   Fix: enforce a storage pattern (approved systems only) and block free-text capture.

2. Copying IDs into analytics, logs, or support tooling by default.
   Fix: define redaction rules; require a design review when IDs could appear in telemetry.

3. No Member State conditions workflow.
   Fix: add a launch gate for new countries/use cases. If the gate is missing, teams will ship first and ask later. (Regulation (EU) 2016/679, Article 87)

4. Third party sprawl.
   Fix: maintain a data-field-level transfer inventory; force minimization and secure transfer methods for any ID sharing.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific cases.

Risk still concentrates in predictable places:

• High impact from disclosure: national IDs are durable identifiers that can facilitate identity fraud and cross-service linkage.
• Regulatory defensibility risk: Article 87 explicitly anticipates local conditions; failing to assess those conditions creates an avoidable compliance gap. (Regulation (EU) 2016/679, Article 87)

Practical 30/60/90-day execution plan

Numeric timelines aren’t required to run this well. Use phases tied to deliverables and control operation.

Phase 1 (Immediate): stop unknown processing and gain visibility

• Assign an owner (Privacy or GRC) and a technical co-owner (Security or IT).
• Stand up the National ID Processing Register for priority systems (HRIS, CRM, IDV tooling, document stores).
• Add an interim rule: no new collection or new third party sharing of national IDs without Privacy approval. (Regulation (EU) 2016/679, Article 87)

Phase 2 (Near-term): lock in safeguards and approvals

• Complete Member State conditions decision records for the countries you operate in.
• Implement least-privilege access and an access request workflow for in-scope systems.
• Update forms and onboarding flows to remove optional/duplicative ID collection.
• Implement secure transfer and field-level minimization for third parties.

Phase 3 (Ongoing): prove operation and handle change

• Run recurring access reviews and store outputs in your evidence packet.
• Add monitoring (pattern scanning/DLP where feasible) and triage workflows.
• Bake Article 87 checks into change management: new country, new onboarding flow, new IDV provider, new data warehouse ingestion.
• Review exceptions and close them with documented remediation.

Frequently Asked Questions

Does Article 87 ban processing national identification numbers?

No. Article 87 permits processing but allows Member States to set specific conditions, and it requires appropriate safeguards to protect data subject rights and freedoms. (Regulation (EU) 2016/679, Article 87)

What counts as “any other identifier of general application”?

Article 87 covers national ID numbers and other broadly used identifiers that can function as universal keys in a country. Treat any widely accepted government-issued or general-purpose identifier the same way until you document the local conditions. (Regulation (EU) 2016/679, Article 87)

We’re a processor. Do we still need Article 87 controls?

Yes. You still need safeguards and you need to ensure your processing aligns with Member State conditions applicable to the processing context, typically through instructions and contracts plus your own security and handling controls. (Regulation (EU) 2016/679, Article 87)

Can we store national ID numbers in support tickets for troubleshooting?

Avoid it. Free-text systems create propagation and access-control problems; route IDs into an approved secure system and store only a reference token in the ticket where possible.

What safeguards are “appropriate” if we must collect IDs for legal reporting?

Minimize collection fields, restrict access to a small set of roles, segregate storage, control disclosure to third parties, and enforce retention/deletion tied to the reporting purpose. Article 87 requires safeguards but leaves selection to you; your job is to implement controls you can prove. (Regulation (EU) 2016/679, Article 87)

What evidence should we be able to produce in an audit?

A register of where IDs are processed, documented Member State conditions decisions, your safeguard/control matrix, access control evidence, third party sharing records, and an exceptions/remediation log. (Regulation (EU) 2016/679, Article 87)