Search every question across sub-FAQs

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.

Transfer clauses matter when a Singapore PDPA organisation transfers personal data to another organisation outside Singapore and no longer keeps possession or direct control over that personal data. PDPC guidance gives examples such as transfers to an overseas group company or an overseas data intermediary for processing.

The contract should make the overseas recipient's protection obligations concrete enough to show comparable protection under the PDPA. If the personal data remains under the transferring organisation's own possession or direct control overseas, the organisation still has direct PDPA obligations for that overseas repository instead of treating the transfer as a handoff to a separate recipient.

A transfer clause should impose legally enforceable obligations that give the transferred personal data a standard of protection comparable to the PDPA. PDPC guidance recognises contracts, binding corporate rules, law, and other legally binding instruments as ways to impose those obligations.

For an independent recipient organisation, the clauses should cover purpose limits, accuracy, protection, retention limitation, policies, access, correction, and data breach notification. For a data intermediary processing on behalf of the transferring organisation under a written contract, PDPC's table focuses the minimum transfer-clause areas on protection, retention limitation, and data breach notification to the organisation without undue delay, while noting that processing contracts commonly impose broader safeguards.

Yes. PDPC recognises and encourages use of the ASEAN Model Contractual Clauses to fulfil the PDPA Transfer Limitation Obligation. The Singapore guidance also says businesses may adapt the ASEAN MCCs for transfers outside ASEAN, including to countries with regimes based on the APEC Privacy Framework or OECD Privacy Guidelines, provided the contract remains compliant with the PDPA.

Use the ASEAN MCC module that matches the relationship. The controller-to-processor module fits contractors or vendors processing solely on behalf of the exporter, including downstream processors. The controller-to-controller module fits a recipient that processes transferred data for its own purposes and may have full control after receipt.

PDPC guidance treats a recipient with a valid specified certification as bound by legally enforceable obligations for transfer limitation purposes, but the certification must match the recipient role. A recipient receiving personal data as an organisation can rely on valid APEC CBPR certification. A recipient receiving personal data as a data intermediary can rely on valid APEC PRP or CBPR certification.

For contract drafting, PDPC provides a sample clause for transfers to APEC CBPR and PRP certified organisations. The sample clause acknowledges that the certified recipient is bound by legally enforceable obligations to provide comparable protection and requires the receiving party to maintain certification and notify the disclosing party of status changes.

Onward transfer clauses should prevent the importer from weakening the original transfer safeguards by sending the same personal data to additional parties on looser terms. The ASEAN MCCs say onward transfers by a data importer should be allowed only when the other importer complies with the MCCs, continuity of protection is otherwise ensured, or the data subject consents.

For controller-to-processor transfers, the ASEAN MCCs also call out downstream processors and say onward transfers should be governed by the same contract terms and subject to the same data protection and security requirements. In implementation language, that means sub-processor approval, due diligence, equivalent obligations, and a record of each onward recipient.

Keep evidence that proves the transfer mechanism was selected, drafted, and monitored for the actual recipient role. For a contract route, keep the executed transfer clauses, the countries and territories covered, the comparable-protection mapping, and any due diligence on the recipient. For ASEAN MCCs, keep the selected module and Singapore-specific amendments. For APEC CBPR or PRP, keep certification verification and contract wording requiring maintenance and notification of status changes.

The record should also show ongoing control: sub-processor or onward-transfer approvals, breach-notification routing, exception approvals if the team did not use legally enforceable obligations or specified certifications, and review triggers such as a new country, new recipient role, changed certification status, or new downstream recipient.