Singapore PDPA NRIC handling

Private-sector organisations should not collect, use, or disclose full NRIC numbers or NRIC copies as a default customer identifier. The PDPC FAQ gives two permitted bases: the handling is required by law, or it is necessary to establish or verify an individual's identity to a high degree of accuracy.

Operationally, require the requester to name the exact law or the high-accuracy verification reason 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.

NRIC numbers are permanent identifiers and can unlock or correlate large amounts of information about an individual. 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 internal 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.

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 NRIC numbers to authenticate persons because NRIC numbers identify people and should be assumed to have been disclosed to others.

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.

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 lawful or high-accuracy basis.

Physical NRICs and other identity documents containing national identification numbers should be retained only when required by law. Checking a document to verify particulars is different from keeping the card, image, scan, or copy.

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.