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's technical guide gives techniques such as attribute or record suppression, character masking, generalisation, swapping, perturbation, synthetic data, and aggregation. A team may combine techniques to preserve the utility it needs, but applying a named technique does not settle the legal question; the release model and residual re-identification risk still control the conclusion.

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.

PDPC's basic guide is introductory and limited to structured, textual, non-complex datasets. It says the recommendations are not exhaustive and adopting them does not by itself establish PDPA compliance. Large longitudinal datasets, sensitive data, and non-textual material such as audio, video, images, or biometrics may require different techniques and specialist assessment.

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.

Notification to the PDPC and notification to affected individuals are separate decisions. A breach that is notifiable only because it affects 500 or more individuals must be reported to the PDPC, but that scale threshold alone does not trigger individual notification. Notify affected individuals when the breach is likely to result in significant harm, unless a statutory exception, prohibition, waiver, or other written law changes that result.

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 guidance strongly encourages organisations to notify and seek advice from the PDPC first; it does not state a separate universal legal rule that every public statement must wait for PDPC approval.

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, cited, 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. 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. Contract clauses do not transfer the organisation's PDPA responsibility to the intermediary; they define instructions, safeguards, assistance, and evidence for the outsourced processing.

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.