Singapore PDPA FAQ NRIC handling

For private-sector use, PDPC's NRIC FAQs say organisations should collect, use, or disclose NRIC numbers or copies of NRIC only where the collection, use, or disclosure is required by law, or where it is necessary to establish or verify an individual's identity to a high degree of accuracy.

Treat this as a narrow justification test, not a default account-creation field. Before a form, workflow, vendor handoff, or support script asks for a full NRIC, record the legal requirement or the concrete high-accuracy identity-verification reason. If neither reason exists, redesign the process around another identifier.

PDPC's NRIC FAQs extend the same treatment to Birth Certificate numbers, Foreign Identification Numbers, and Work Permit numbers. The same FAQ also says organisations should avoid collecting full passport numbers unless justified, even though passport numbers can be periodically replaced.

In practice, build the same intake check for each identifier: which identifier is requested, whether the full value is required, whether a partial or alternative value is enough, and what notice and access controls apply.

Where full NRIC collection is not justified, replace it with a user-selected identifier, organisation-issued account ID, validated email address, validated mobile number, or a combination of non-sensitive identifiers. PDPC's technical guidance also describes partial NRIC use as the last three digits plus the last alphabet, typically combined with other information, and recommends checking uniqueness before using the new identifier.

For barcode scanning and visitor systems, the technical guidance says systems should not permanently store the complete scanned NRIC number. Convert the scan immediately to the final format, such as a partial, masked, or hashed value, and store only that final format where the full number is not permitted.

No. PDPC and CSA advise organisations against using NRIC numbers to authenticate people. Their joint advisory explains that identification tells people apart, while authentication proves a person is who they claim to be before granting access to protected services or information.

Stop using full or partial NRIC numbers as passwords, default passwords, password fragments, security questions, or proof that a caller or user is the right person. Use risk-based authentication such as strong passwords, tokens, smart cards, biometrics, or multi-factor authentication where appropriate.

If full NRIC handling is justified, apply the PDPA protection and retention obligations like any other personal data obligation, with stricter controls where the risk is higher. The PDPA requires reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal, similar risks, and loss of storage media or devices.

For retention, the PDPA requires organisations to stop retaining documents containing personal data, or remove the means of association with individuals, when the original purpose is no longer served and retention is no longer necessary for legal or business purposes. For physical NRICs and other identification documents containing national identification numbers, PDPC's NRIC FAQs say retention is allowed only when required by law, although checking the physical document is allowed when needed to verify particulars.

Keep records that prove why the full identifier was needed and how the system avoids unnecessary collection, display, retention, and authentication use. PDPC guidance supports the underlying controls: the allowed basis for full NRIC handling, the avoidance of full NRIC as a general identifier, no authentication use, immediate conversion of scanned NRIC values where appropriate, and PDPA protection and retention controls.

The useful record is short but specific: the identifier type, collection point, legal requirement or high-accuracy verification reason, notice text or user-facing explanation, system field storing the value, masking rule, retention rule, access owner, vendor role if any, and date for rechecking whether the full value is still needed.