Search every question across sub-FAQs

No. PDPC guidance treats de-identification as the removal of direct identifiers, while anonymisation requires a broader risk assessment. A dataset with names, mobile numbers, or NRIC numbers removed may still be personal data if indirect identifiers such as age, postal code, job role, transaction patterns, or other attributes can be combined with available information to identify someone.

Pseudonymisation can help remove a direct identifier by replacing it with an unrelated value, but it does not automatically make the dataset anonymised. If a mapping table, key, algorithm, or other linkable dataset can be used to connect the pseudonym back to a person, that re-identification path must be controlled and assessed.

PDPC guidance says data that has been anonymised is no longer considered personal data for the purposes of the PDPA. That conclusion depends on the facts: the data itself, information the recipient has or is likely to have, the extent of disclosure, the recipient's ability and motivation to re-identify, and the safeguards used to reduce re-identification risk.

Teams should therefore document why there is no serious possibility of re-identification for the specific release model. Internal analytics, controlled external sharing, ongoing data feeds, and public disclosure have different risk profiles; public disclosure generally needs stronger anonymisation because technical controls are limited once data is open.

Keep an anonymisation record that explains the purpose, utility needed, release model, attribute classification, techniques applied, risk calculation or assessment method, residual risk decision, safeguards, approval owner, and review trigger. PDPC guidance states that anonymisation process details, parameters, and controls should be recorded for review, maintenance, fine-tuning, and audits, while also being kept securely because the parameters themselves can assist re-identification.

Safeguards should match the residual risk and access model. Supported examples include limiting recipients and access, imposing use and onward-disclosure restrictions, requiring recipient processes for proper use and destruction, securing mapping tables and keys, using encryption or access controls, revocable or query-only access, releasing subsets, auditing recipients, and regularly reviewing controls.

A Singapore PDPA data breach is notifiable if either threshold is met: the breach is likely to result in significant harm to affected individuals, or it affects a significant scale of individuals. PDPC guidance states that organisations do not need to report every breach, but they must assess whether the breach is notifiable.

In implementation terms, start every incident record with four facts: what personal data was affected, how the breach occurred, how many individuals are affected or likely affected, and whether the data type or circumstances create likely significant harm.

The Notification of Data Breaches Regulations deem a breach to result in significant harm when it involves specified combinations of personal data. The core statutory examples are a full name, alias, or identification number together with prescribed personal data in the Schedule, or account access data such as an account identifier together with a password, security code, access code, security-question response, biometric data, or other account-access credential.

For a working incident triage, classify the affected fields before deciding the notice path. If account access credentials or prescribed identity-linked data are involved, escalate the incident as a likely significant-harm case unless counsel or the DPO documents a supported reason otherwise.

A data breach is of significant scale when it involves the personal data of 500 or more affected individuals. PDPC guidance says the organisation must notify the Commission when a breach affects 500 or more individuals even if the breach does not involve prescribed personal data that would otherwise trigger the significant-harm test.

If the exact count is unknown, use a reasonable initial estimate. PDPC guidance says organisations should notify the Commission when they have reason to believe the affected number is at least 500 and may later update the Commission with the actual number.

Once the organisation has credible grounds to believe a data breach occurred, PDPC guidance says it must take reasonable and expeditious steps to assess whether the breach is notifiable within 30 calendar days. If the assessment cannot be completed within 30 days, the organisation should be ready to explain the time taken or required.

After the organisation determines that the breach is notifiable, it must notify the PDPC as soon as practicable and no later than three calendar days. PDPC guidance states that the three-day period starts on the day after the determination that the breach is notifiable.

PDPC guidance says organisations must notify affected individuals as soon as practicable, at the same time as or after notifying the PDPC. For breaches likely to attract widespread public attention or interest, the PDPC affected-individual guidance says to notify the PDPC first before notifying individuals or issuing a public or media statement.

The affected-individual notice should be practical rather than merely formal. The Regulations require information about how the organisation became aware of the breach, the affected personal data, potential harm, actions taken or planned, steps the individual may take to reduce harm, and business contact information for an authorised representative.

Keep evidence that proves the assessment was timely, source-linked, and based on the data actually affected. PDPC guidance says organisations must document all steps taken in assessing whether a breach is notifiable, and the Regulations require the PDPC notice to include a chronological account of steps taken after awareness of the breach.

The minimum useful record is an incident chronology, data-field inventory, affected-individual count or estimate, significant-harm analysis, significant-scale analysis, notifiability determination time, PDPC notification time, affected-individual notification plan, mitigation actions, and any late-notification explanation with supporting evidence.

A vendor is a data intermediary when it processes personal data on behalf of another organisation and for that organisation's purposes under a contract that is made or evidenced in writing. The label in the contract helps, but the role follows the actual processing arrangement: who decides the purpose, who controls the permitted use, and whether the vendor is acting within that scope.

Treat the same company role-by-role. A payroll provider may be a data intermediary for customer payroll processing while still acting as an organisation for its own employee records, recruitment, billing, security logs, and marketing activities.

For personal data processed on behalf of and for the purposes of another organisation under a written or evidenced contract, a Singapore PDPA data intermediary is directly subject to the Protection Obligation, the Retention Limitation Obligation, and the obligation to notify the organisation of a data breach without undue delay once it has credible grounds to believe a breach occurred.

That limited direct obligation set does not remove the organisation's accountability. The organisation has the same PDPA obligations for personal data processed by its intermediary as if the organisation processed the data itself.

Use the contract as the main control surface. PDPC guidance describes the contract as the primary way for the organisation to ensure appropriate protection and retention by the data intermediary, and the Guide to Managing Data Intermediaries says the scope of outsourced processing should be clearly defined and agreed.

The contract evidence should be operational, not just legal. Keep the processing schedule, security requirements, retention and deletion rules, subcontracting limits, breach reporting route, onboarding material, review meeting records, audit or check results where used, and exit-management evidence.

The data intermediary should notify the organisation without undue delay once it has credible grounds to believe a data breach has occurred. The intermediary's job is to escalate fast, preserve facts, support containment, and provide enough information for the organisation to assess whether the breach is notifiable.

The organisation remains responsible for assessing whether the breach is notifiable and, where required, notifying the PDPC and affected individuals. A service agreement should therefore specify the breach contact route, incident information to provide, evidence preservation, containment responsibilities, and update cadence.

The PDPA guidance identifies three forms of deemed consent: deemed consent by conduct, deemed consent by contractual necessity, and deemed consent by notification. Treat them as separate routes, not interchangeable labels.

Start by documenting which route is being used, the personal data involved, the purpose, and why the surrounding facts fit that route. If the purpose is outside the obvious transaction, outside contractual performance, or a secondary use that needs notification and opt-out, the team should not rely on a generic deemed-consent statement.

Deemed consent by conduct fits narrow, obvious situations: for example, a person provides payment details to pay, proceeds with a health check after being told what tests involve, or gives contact details so a taxi booking can be confirmed. It should not be stretched to unrelated marketing or secondary analytics just because the organisation already has the data.

Deemed consent by contractual necessity covers disclosures and downstream processing that are reasonably necessary to conclude or perform the transaction with the individual. Examples in the guidance include payment processing chains, GIRO and tax-relief processing, and delivery partners needed to fulfil an e-commerce purchase.

Before using deemed consent by notification, the team should write a purpose-specific assessment. PDPC's Annex B checklist says the assessment should minimally cover the purpose, the appropriateness of notification, the reasonableness of the opt-out mode and period, likely adverse effects, and the final decision outcome.

The notification should bring the intended collection, use, or disclosure, the purpose, and the opt-out method and period to the individual's attention. Direct channels such as email, SMS, push notification, portal notice, or regular customer communications are stronger when they are likely to reach the affected individuals; mass communication needs stronger justification.

For deemed consent by notification, the assessment must identify likely adverse effects, mitigation measures, and any residual adverse effects. PDPC guidance describes adverse effect broadly, including physical harm, harassment, serious alarm, distress, and decisions or predictions that may affect individuals.

If residual adverse effects remain after mitigation, the organisation should not rely on deemed consent by notification for that purpose. Keep the assessment for the whole period during which the organisation collects, uses, or discloses personal data based on that deemed-consent route.

For deemed consent by notification, the individual must be given a reasonable way and period to opt out before the processing starts. If the individual opts out within that period, do not start the notified collection, use, or disclosure for that individual.

After the opt-out period has passed, an individual can still withdraw consent. The organisation should allow and facilitate withdrawal, explain likely consequences, cease the relevant collection, use, or disclosure, and cause its data intermediaries and agents to cease unless continued processing is required or authorised under the PDPA or another written law.

No. PDPC guidance states that the Personal Data Protection Regulations 2021 prescribe that deemed consent by notification does not apply to sending direct marketing messages. Teams should use express opt-in consent for direct marketing rather than relying on opt-out or pre-checked boxes.

For specified marketing messages sent to Singapore telephone numbers by voice call, text, or fax, the DNC provisions also apply. The sender must check the relevant DNC Register unless it has clear and unambiguous consent in evidential form from the user or subscriber, and the message must include sender identification and contact information.

A team should check the DNC Registry before sending a specified marketing voice call, text message, or fax to a Singapore telephone number unless it has clear and unambiguous consent in evidential form for that message to that number, or the message is outside the DNC checking duty because a supported exclusion applies.

Do the check at campaign execution time, not only when a lead is first collected. PDPC guidance says the check is tied to sending the specified message, and DNC Registry results are valid for 21 days from receipt. If the campaign will continue after that window, recheck before continuing telemarketing activity.

Treat third-party lead lists the same way: the sender still needs either usable consent evidence for that sender and number, or a current DNC result showing the number is not listed in the relevant register.