Singapore PDPA FAQ NRIC handling

For private-sector use, PDPC's NRIC guidelines say organisations should collect, use, or disclose NRIC numbers or copies of NRIC only where the collection, use, or disclosure is required under the law or an exception under the PDPA applies, or where it is necessary to accurately establish or verify an individual's identity to a high degree of fidelity with notification and consent.

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 written-law or PDPA-exception basis, or the concrete high-fidelity identity-verification reason and how notification and consent are obtained. If neither basis exists, redesign the process around another identifier.

PDPC's NRIC guidelines extend the same treatment to Birth Certificate numbers, Foreign Identification Numbers, and Work Permit numbers. The same guidelines also say 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 not to use 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.

The joint advisory is security guidance, not wording that converts every NRIC authentication design into a separate automatic statutory offence. Remove full or partial NRIC numbers from passwords, default passwords, password fragments, security questions, and caller-verification scripts. 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 guidelines say retention is allowed only when required under the 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, written-law or PDPA-exception basis or high-fidelity verification reason, notice and consent record, 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.