PDPC guidanceSingaporeNRIC handling

Singapore PDPA NRIC handling

Treat full as restricted identifiers: collect, use, or disclose them only when required under the law or a PDPA exception applies, or when high-fidelity identity verification is necessary and notification and consent are obtained.

Use alternatives for routine accounts and public-facing systems, phase out NRIC-based by 31 December 2026, mask or hash scanned values where appropriate, and keep full NRIC data only while a legal or business purpose remains.

Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
Overview

This page translates current PDPC NRIC guidance into implementation checks for product, privacy, security, support, and operations teams handling Singapore and comparable national identification numbers. The existing collection, use, disclosure, and physical-retention guidelines remain valid while PDPC updates them. Separately, PDPC says private organisations have until 31 December 2026 to phase out full or partial NRIC numbers for and will step up enforcement from 1 January 2027.

Section 1

When full NRIC collection, use, or disclosure is allowed

Private-sector organisations should not collect, use, or disclose full or NRIC copies as a default customer identifier. The PDPC guidelines allow the handling when it is required under the law or an exception under the PDPA applies, or when it is necessary to accurately establish or verify an individual's identity to a high degree of fidelity with notification and consent.

Operationally, require the requester to name the exact written law or PDPA exception, or the high-fidelity verification reason and how notification and consent are obtained, before a form, workflow, API, ticket, or vendor process accepts a full NRIC value. If the need is only account lookup, queue management, loyalty membership, event registration, building access, or customer support routing, design the workflow around a less sensitive identifier.

  • Law-required or PDPA-exception handling: record the written law or PDPA exception that permits the full NRIC number or copy.
  • High-fidelity verification: record why names, email addresses, mobile numbers, customer IDs, partial identifiers, or in-person sighting are insufficient for the risk, and how notification and consent are obtained.
  • Comparable identifiers: apply the same treatment to Birth Certificate numbers, FINs, and Work Permit numbers; avoid full passport numbers unless the use is justified.
  • Physical checks: checking a physical NRIC, Foreign Identity card, or passport may be allowed to verify particulars, but retaining the physical document is a separate and narrower question.
Section 2

Use alternatives for routine identification and accounts

are permanent personal identifiers, not shared secrets. For websites, apps, memberships, kiosks, visitor systems, and other public-facing systems, replace NRIC-based usernames or primary identifiers with an identifier that is unique, memorable where needed, not sensitive, and not easily guessed.

Good replacement options depend on the workflow. User-selected usernames work for account logins; organisation-generated customer IDs work for evidence records; validated email addresses or mobile numbers can work where contact control is part of the customer journey; combinations of non-sensitive data can reduce collisions; and partial NRIC values should only be used with other data where a full NRIC is not permitted.

  • For new systems, block full NRIC fields unless the intake form records a written-law or PDPA-exception basis, or a high-fidelity verification need with notification and consent.
  • For existing systems, inventory every screen, database field, report, export, and downstream integration where the NRIC is displayed, stored, or used as a key.
  • When replacing identifiers, notify affected users and support teams, test lookup and account-recovery flows, and confirm related CRM, access, billing, and reporting systems accept the replacement.
  • When a partial NRIC is used as an identifier, use the last three digits plus final alphabet only in combination with other data and check the resulting identifier for uniqueness.
Section 3

Do not use NRIC numbers for authentication

Do not treat knowledge of a full or partial NRIC number as proof that a person is the genuine user. PDPC and CSA advise organisations against using to authenticate persons because NRIC numbers identify people and should be assumed to have been disclosed to others.

PDPC says private organisations have until 31 December 2026 to phase out NRIC . From 1 January 2027, PDPC will step up enforcement; an organisation using to authenticate access to personal data may be found in breach of the PDPA . Remove NRIC values from passwords, default passwords, file passwords, customer-service challenge questions, and combined secrets such as partial NRIC plus date of birth. Choose authentication controls based on the value and sensitivity of the protected service or information, the threat model, and the accessibility of the method.

  • Stop any login, reset, phone-support, document-opening, or account-recovery flow that accepts a full or partial NRIC as a secret.
  • Do not set as default passwords for accounts or password-protected files.
  • Prefer stronger factors such as strong passwords, tokens, smart cards, biometrics, and two-factor where appropriate to the risk.
  • Train support teams that a caller who can state an NRIC number has identified a person, not authenticated as that person.
Section 4

Mask, hash, and avoid permanent full-NRIC storage

Systems that scan NRIC or FIN barcodes can receive the complete number even when the business process does not need to retain it. Convert scanned full NRIC values immediately into the final permitted format and avoid permanent storage of the complete number unless the full value is permitted under the NRIC rule.

For display, show a masked value when the complete NRIC is not strictly required. For matching, use a one-way hash where the system only needs to recognise a returning person or compare against a previous scan. Keep logs, analytics, exports, screenshots, and support transcripts out of scope for full NRIC exposure unless they have the same written-law, PDPA-exception, or high-fidelity verification basis.

  • Scanning rule: do not permanently store the complete scanned NRIC number when the workflow only needs identification or matching.
  • Masked display: expose only the characters needed for confirmation, such as a partial NRIC format, when full display is unnecessary.
  • Hashing rule: hash before storage when the system needs repeat matching but does not need the original NRIC value.
  • Migration check: delete or anonymise old full-NRIC database values, backups, exports, and test datasets once they are no longer required for a legal or business purpose.
Section 5

Retention and evidence records

Physical NRICs and other original identity documents containing national identification numbers should be retained only when required by law. A copy, image, or scan is subject to the separate rules for collecting full or copies and the PDPA retention obligation; it is not the physical card itself.

For NRIC values stored in systems, apply the PDPA retention limitation rule: stop retaining documents containing personal data, or remove the means of associating the data with individuals, once the original purpose is no longer served and retention is no longer necessary for legal or business purposes. The PDPA does not give one universal retention period; the record should explain the purpose, legal or business need, and deletion or anonymisation method.

  • Keep an NRIC handling record with the field name, system, purpose, permitted basis, display format, storage format, access roles, vendor location, and deletion trigger.
  • For each full-NRIC field, keep the written-law citation, PDPA exception, or high-fidelity identity-verification rationale and consent record that justified collection, use, or disclosure, plus the legal or business purpose that justifies retention.
  • For physical NRIC handling, record whether the team only checked the document or retained the original card, and the law requiring any original-card retention. Record copies, images, and scans separately with their permitted collection basis and retention rationale.
  • For removal, record whether the organisation returned, destroyed, deleted, anonymised, masked, or hashed the data, and whether agents or data intermediaries also lost access.
Primary sources

References and citations

pdpc.gov.sg3 citations
Referenced sections
  • Primary source for when private-sector organisations may collect, use, disclose, or retain full NRIC numbers, NRIC copies, and physical identity documents.
  • Supports the two permitted bases for full NRIC collection, use, or disclosure and the treatment of related national identification numbers.
  • Supports the rule that physical NRICs and comparable identification documents may be retained only when required by law.
"required under the law"
More quoted passages
"physical NRIC unless the retention of the physical NRIC is required under the law"
pdpc.gov.sg3 citations
Referenced sections
  • Supports replacing NRIC identifiers, masking displays, hashing scanned values, and migrating existing systems.
  • Supports replacement identifiers, public-facing-system migration, masked displays, and hashed values.
  • Supports replacement identifiers, scanned-barcode handling, immediate conversion to a permitted final format, masking, and hashing.
pdpc.gov.sg2 citations
Referenced sections
  • Primary PDPC page for collection, use, disclosure, and retention guidance; it states that the existing guidelines remain valid while they are updated and repeats the warning against NRIC authentication.
  • Supports the page focus on collection, use, disclosure, and retention of NRIC numbers and links the NRIC advisory materials.
"collection, use and disclosure of NRIC"
pdpc.gov.sg2 citations
Referenced sections
  • Supports removing full or partial NRIC numbers from passwords, default passwords, challenge questions, and other authentication secrets.
  • Supports the implementation rule against using full or partial NRIC numbers as passwords, default passwords, or authentication secrets.
"NRIC numbers should not be used as passwords"
sso.agc.gov.sg2 citations
Referenced sections
  • Official statute source for the PDPA retention-limitation framing used for stored NRIC personal data.
  • Supports the statutory retention-limitation basis for ceasing retention or removing the link between personal data and individuals.
"Personal Data Protection Act 2012"
Show all related guides (37)

Singapore PDPA Consent and Deemed Consent Workflow

Choose express consent, deemed consent by conduct, contractual necessity, notification, or the legitimate interests exception under Singapore PDPA with fact-based intake fields and evidence records.

Singapore PDPA Consent, Notification and Purpose Rules

How Singapore PDPA consent, notification, purpose limitation, deemed consent, withdrawal, and consent exceptions should be handled in product and privacy workflows.

Singapore PDPA Cross-Border Transfers

Source-cited Singapore PDPA guidance for overseas personal data transfers, comparable protection, ASEAN MCCs, APEC certifications, vendor roles, and evidence records.

Singapore PDPA Data Breach Notification Thresholds

Source-cited Singapore PDPA breach notification thresholds covering significant harm, the 500-individual significant-scale test, assessment records, and notification timing.

Singapore PDPA Data Intermediary Responsibilities

Practical Singapore PDPA guide to data intermediary role boundaries, organisation accountability, protection, retention, breach escalation, and contract evidence.

Singapore PDPA Deadlines and Compliance Calendar

A Singapore PDPA compliance calendar for breach notification, DNC checks, access and correction requests, enforcement responses, retention reviews, and DPMP maintenance.

Singapore PDPA Deemed Consent and Legitimate Interests

How to apply Singapore PDPA deemed consent by conduct, contractual necessity, notification, and legitimate interests with opt-out, adverse-effect, disclosure, and assessment records.

Singapore PDPA DNC and Marketing Messages Guide

A source-cited Singapore PDPA guide to DNC checks, specified marketing messages, Singapore telephone numbers, consent evidence, opt-outs, sender duties, and excluded messages.

Singapore PDPA DNC Marketing Checks

Operational checklist for Singapore PDPA DNC marketing checks: account evidence, register status, 21-day result validity, consent evidence, and campaign owner records.

Singapore PDPA DNC Marketing Workflow

Workflow for Singapore PDPA DNC marketing campaigns: classify specified messages, check Singapore telephone numbers, document consent, suppress opt-outs, and approve sends.

Singapore PDPA DPMP Accountability Guide

Build a Singapore PDPA Data Protection Management Programme with DPO ownership, policies, data inventories, DPIAs, training, monitoring, breach logs, and review records.

Singapore PDPA FAQ: scope, DPO, consent, breaches and DNC

FAQ answers for Singapore PDPA implementation, covering scope, accountability, consent, access and correction, security, retention, transfers, data intermediaries, breach notification, and DNC checks.

Singapore PDPA Penalties and Enforcement Cases

How PDPC enforcement under Singapore's PDPA works: directions, voluntary undertakings, published decisions, financial penalty caps, and implementation lessons from cases.

Singapore PDPA Penalties and Fines

Singapore PDPA penalty ceilings, PDPC directions, undertakings, breach notification context, and practical controls based on official PDPC and Singapore Statutes sources.

Singapore PDPA Privacy Policy Template

A Singapore PDPA privacy policy template for writing notices, DPO contact details, access and correction routes, retention, transfers, protection, withdrawal, and complaint handling without overclaiming compliance.

Singapore PDPA Requirements: Core Obligations

Map Singapore PDPA obligations across consent, notification, access, security, retention, transfers, accountability, breaches, DNC checks, and data intermediaries.

Singapore PDPA Scope, Exclusions, and Data Intermediaries

Classify Singapore PDPA coverage, business contact information, personal or domestic activity, employee acts, and data intermediary obligations using cited statutory boundaries and processing records.

Singapore PDPA Transfer Assessment Workflow

A Singapore PDPA workflow for assessing overseas personal data transfers, comparable protection, ASEAN MCCs, APEC CBPR/PRP certifications, vendor due diligence, onward transfers, and evidence records.

Singapore PDPA Transfer Clauses

Draft Singapore PDPA transfer clauses for overseas vendors, affiliates, data intermediaries, onward transfers, ASEAN MCCs, and APEC or Global CBPR and PRP evidence.

Singapore PDPA Vendor Outsourcing and Contracts

Contract and operating checklist for Singapore PDPA vendor outsourcing: data intermediary status, written terms, security, retention, breach, transfers, sub-contracting, and exit evidence.

Singapore PDPA vs GDPR Comparison

Compare Singapore PDPA and EU GDPR rules for legal bases, DPOs, intermediaries and processors, transfers, breaches, marketing objections, rights, retention, and penalties.

Singapore PDPA anonymisation FAQ

FAQ on anonymisation under the Singapore PDPA: de-identification, pseudonymisation, re-identification risk, when PDPA may no longer apply, and evidence records.

Singapore PDPA breach notification thresholds FAQ

FAQ on Singapore PDPA notifiable data breach tests: significant harm, significant scale, 500 affected individuals, assessment timing, PDPC notices, and affected-individual notices.

Singapore PDPA Data Intermediaries FAQ

FAQ guidance on Singapore PDPA data intermediary roles, direct obligations, organisation accountability, contracts, retention, protection, and breach escalation.

Singapore PDPA Deemed Consent FAQ

FAQ on Singapore PDPA deemed consent by conduct, contractual necessity, notification, opt-out periods, adverse-effect assessment, withdrawal, and direct-marketing limits.

Singapore PDPA DNC checking FAQ: when to check the DNC Registry

FAQ guidance on Singapore PDPA DNC checking: when to check the DNC Registry, which registers apply, 8-digit numbers, 21-day result validity, consent evidence, on-behalf checks, opt-outs, and supported exclusions.

Singapore PDPA DPIAs: when to run and what to document

FAQ-style implementation guidance on Singapore PDPA DPIAs, including when PDPC guidance recommends them, data-flow mapping, risk treatment, DPO review, and evidence records.

Singapore PDPA DPMP Accountability FAQ | DPO, Policies, Evidence

FAQ for implementing Singapore PDPA accountability through a DPMP: DPO designation, policies, evidence, training, monitoring, incident logs, and review records.

Singapore PDPA legitimate interests FAQ

FAQ guidance on Singapore PDPA legitimate interests: assessment fields, adverse effects, mitigation, balancing, disclosure, records, and marketing limits.

Singapore PDPA NRIC Handling FAQ

FAQ guidance on when Singapore organisations may collect, use, disclose, retain, mask, or replace NRIC and other national identification numbers under PDPC guidance.

Singapore PDPA transfer clauses FAQ

FAQ guidance on Singapore PDPA transfer clauses, comparable protection, ASEAN MCCs, APEC CBPR and PRP certifications, onward transfers, and evidence records.