Describe your business, leave with a checklist you can assign

Obtain valid consent before collecting, using or disclosing personal data (or confirm that deemed consent or a statutory exception applies), and notify the purposes at or before collection; notify any new purpose before that use. Do not make consent to processing beyond what is reasonable for the product a condition of supply, and confine purposes to those a reasonable person would consider appropriate.

Evidence: Privacy notice text with version history; Screenshots and event logs of the consent capture flow; Records of consent given and withdrawn; Purpose inventory and reasonableness assessment memo

Deploy physical, technical, process and contractual controls proportionate to data sensitivity and processing scale, to prevent unauthorised access, collection, use, disclosure, copying, modification or disposal. Data intermediaries are directly subject to this obligation.

Evidence: Inventory of security controls with a responsibility matrix; Access-review records; Penetration test or security assessment report; Encryption and key management policy

Before transferring personal data outside Singapore, take appropriate steps to ascertain and ensure that the recipient is bound by legally enforceable obligations providing a standard of protection at least comparable to the PDPA. Legally enforceable obligations include law, contract, binding corporate rules or any other legally binding instrument; a recipient holding a recognised specified certification is treated as bound. Where consent is relied on instead, the individual must first receive a written reasonable summary of the protection available in that country, and consent must not be a condition of supply unless the transfer is reasonably necessary to provide the product or service.

Evidence: Data-flow map and transfer inventory; Data processing addendum containing legally enforceable obligations; Assessment record of the recipient’s standard of protection; If relying on consent: the written reasonable summary and consent records

Open tool: Transfer Matrix

Conduct a reasonable and expeditious assessment on becoming aware of a possible breach; once assessed as a notifiable data breach, notify PDPC as soon as practicable and in any case no later than 3 calendar days after making that assessment, then notify affected individuals (required for the “significant harm” limb). The prescribed “significant scale” threshold is 500 or more affected individuals. Notification to individuals is excused where remedial action, or a technological measure already in place, makes significant harm unlikely.

Evidence: Incident response plan with escalation path; Breach assessment record with timestamps and conclusion; Acknowledgement of the notification filed with PDPC; Notice text sent to affected individuals and proof of dispatch; Contractual notification-deadline clause with data intermediaries

AI incident and serious incident reporting record (register plus report drafts)

Develop and implement written policies and practices covering every PDPA obligation, designate at least one Data Protection Officer and publish their business contact information, run a complaints-handling process, and make information about those policies available to individuals on request.

Evidence: Data protection policy and internal operating procedures; DPO appointment letter and screenshot of the published contact details; Log of data protection complaints and queries; Staff data protection training records

Stop retaining documents containing personal data, or remove the means by which the data can be associated with particular individuals, once the collection purpose is no longer served and retention is no longer necessary for legal or business purposes. In AI contexts this must expressly cover training sets, prompt and inference logs, vector stores and model checkpoints.

Evidence: Retention schedule covering training sets and logs; Deletion and de-identification execution records; Written justification for any extended retention; Minutes of periodic retention reviews

On request, provide an individual with their personal data and information on how it has been used or disclosed in the past year, and correct errors or omissions within a reasonable time. Data held by a data intermediary but under the organisation’s control must be included. Refusals must fall within a statutory exception and be explained.

Evidence: Register of access and correction requests; Identity verification records; Response letters with any exception relied on; Records of retrieval instructions issued to data intermediaries

For every scraped corpus used in pre-training or fine-tuning, assess whether the personal data in it is publicly available. A digital barrier does not by itself defeat public availability, but the assessment must weigh the barrier’s purpose and effect, the number and complexity of steps needed to reach the data, and whether the data is obtainable without restriction elsewhere. Where it is reasonably arguable that the data behind a barrier is not publicly available and the organisation nonetheless relies on the exception, it must record the assessment and reasoning in a DPIA or other written record and produce it if PDPC asks.

Evidence: Inventory of scraped sources annotated with barrier type; Per-source public-availability assessment records; Data protection impact assessment (DPIA); Record of robots.txt and terms-of-service compliance checks for the crawl

Data Card — datasheet for a training, validation or test dataset

Where User Data is used for large-scale training or fine-tuning of generative AI models, a general “new product development” statement is not sufficient consent: para 4.4 states that organisations must provide AI-Specific Notifications for this purpose. The form and wording are for the organisation, but individuals must be able to understand the types of personal data affected, how they will be used to train or fine-tune the model, and the functions of those models. Para 4.6 goes on to say organisations are encouraged to provide, to the extent practicable, four items — the model functions requiring personal data, a clear description of the types of personal data used, how the data will be used to train or fine-tune the model, and how individuals can decline or withdraw consent. Those four are best practice rather than a mandatory checklist, but should be treated as PDPC’s review baseline. Layered notification is acceptable, as is a single notification covering several models; consent to processing beyond what is reasonable to provide the product must not be a condition of supply.

Evidence: AI-Specific Notification text with version history; Privacy policy update announcement and in-product notice screenshots; Opt-out and withdrawal mechanism plus execution records; Reconciliation records between training datasets and users who withdrew consent

Determine, per business line, whether the company is a Model Provider, System Provider or System Deployer, and whether in that capacity it is an organisation or a data intermediary, then configure the obligation set accordingly. A Model Provider that processes personal data for its own purposes — including harvesting downstream prompts and inputs for model development — is an organisation subject to all PDPA obligations; when running inference or hosting data for downstream customers it is a data intermediary owing at least the protection and retention-limitation obligations. The same entity may switch roles between scenarios, and each must be documented in policy.

Evidence: Business-line to role to obligation mapping table; Contract clauses distinguishing organisation and data intermediary capacity; Internal policies and procedures per role; Statement of downstream data-access boundaries for open-weight releases

System Deployers must identify and register the new data sources their systems create — end-user prompts and inputs, generated outputs, agent or tool activity data, and connected internal enterprise data — assign responsibility for each, implement matching safeguards, and educate internal and external users on what categories of personal data may be entered and how it will be processed. Where systems have agentic functionality, deployers must regularly review the sufficiency of safeguards and be transparent about the privacy-utility trade-off. Model and System Providers should disclose downstream the safeguards implemented, testing and performance metrics such as the likelihood of data leakage, and incident response and breach-notification procedures.

Evidence: Register of new data sources with assigned ownership; Guidance on data types permitted in prompts plus staff training records; Access controls and redaction configuration for prompt logs; Downstream-facing safeguards information sheet including data-leakage test metrics; Privacy-utility trade-off assessment for agentic use cases

Access and correction obligations apply to personal data collected, used or disclosed for model or system development and deployment. Organisations must accede unless a PDPA exception applies — for example where the burden or expense of access would be unreasonable to the organisation or disproportionate to the individual’s interests, or where there are reasonable grounds that a correction should not be made. Data transferred to a data intermediary remains under the organisation’s control and must be covered in the response. The guidelines acknowledge the technical difficulty created by embeddings and context windows, but this is not an automatic exemption.

Evidence: Searchable index or data-lineage records for training corpora and User Data; Register of access and correction requests; Written justification and technical-limitation explanation where an exception is relied on; Records of retrieval and correction instructions issued to data intermediaries

The Business Improvement Exception lets an organisation use, without consent, personal data it previously collected in accordance with the PDPA, for improving or enhancing existing goods and services or developing new ones; improving or developing methods or processes for business operations relating to those goods and services; learning or understanding individuals’ behaviour and preferences, including for segmented groups; and identifying, personalising or customising goods and services for individuals. Before relying on it, confirm and record that the purpose cannot reasonably be achieved without the data in individually identifiable form.

Evidence: Written applicability assessment relying on the Business Improvement Exception; Traceability record of the lawfulness of the source collection; Technical justification that the purpose cannot be met with non-identifiable data; Statement linking the training purpose to the organisation’s goods and services

For R&D without immediate product application, the Research Exception is available only if all of the following hold: the research purpose cannot reasonably be accomplished unless the data is in individually identifiable form; there is a clear public benefit; the results will not be used to make any decision affecting the individual; and any published results do not identify the individual. Disclosure to another party under the exception — including joint development of new AI systems — additionally requires an assessment that obtaining consent would be impracticable.

Evidence: Point-by-point assessment of the four Research Exception conditions; Public-benefit justification and research protocol; Internal undertaking and technical segregation ensuring results are not used in decisions affecting individuals; Data-use restriction clauses in the joint research agreement

When deploying a product with AI recommendation or decision features, explain so far as practicable: the product function requiring collection and processing of personal data; a general description of the types of personal data collected and processed; how that processing is relevant to the product feature; and the specific data features most likely to influence the feature’s output. Delivery may be through pop-up notifications or publicly accessible written policies, as the organisation judges appropriate.

Evidence: AI feature explanation text including the features influencing outputs; Screenshots and delivery logs of the notification surface; Consistency check between feature-importance analysis and public statements; Accessibility verification of the published policy page

Section 12 of the PDPA requires organisations to develop policies and practices to meet their obligations. Organisations using AI systems should set out in written policies the practices and safeguards adopted to achieve fairness and reasonableness, at a level of detail proportionate to the risk of the use case — potential harm to the individual and the AI system’s degree of autonomy. Section 12(d) requires disclosure on request, but the guidelines recommend proactive publication on the organisation’s website, including a short-form version.

Evidence: Written AI governance policy covering fairness and reasonableness safeguards; Record of per-use-case risk tiering and the resulting level of disclosure; Public-facing page and short-form policy; Minutes of the annual policy review

ISO/IEC 42001 AI management system implementation and certification readiness checklist

Service providers that build bespoke or fully customisable AI systems and thereby process personal data as data intermediaries should, at the pre-processing stage, use data mapping and labelling to track what enters the training dataset, and maintain provenance records identifying the source of training data and how it was transformed during data preparation. These records support assessment of unauthorised access or modification of the training set, and let the deploying organisation judge whether a notifiable data breach has occurred and the scope of impact of any change to the training set.

Evidence: Training-data mapping and labelling inventory; Provenance records tracing source to transformation to inclusion; Training-set integrity checks and change audit logs; Records identifying sensitive personal data and the calibrated handling applied

Data Card — datasheet for a training, validation or test dataset

Under the Data dimension, govern the source, licensing status, quality and bias risk of training data, and be able to explain how the data was obtained and processed. In the Singapore context this links directly to PDPC’s requirement to document reliance on the Publicly Available Exception.

Evidence: Training-data inventory with licensing status; Provenance records of source and transformation; Data quality and bias assessment report; Dataset admission approval records

Data Card — datasheet for a training, validation or test dataset

Under the Trusted Development and Deployment dimension, run baseline evaluations of model capabilities, known risks and limitations, and disclose the scope, method and results to downstream integrators and deployers through a model card or equivalent, so they can judge the boundaries of appropriate use.

Evidence: Model card or system card covering evaluation method and results; Safety evaluation and red-teaming reports; List of known limitations and out-of-scope uses; Version change and re-evaluation records

Model Card

Under the Incident Reporting dimension, put in place monitoring capable of detecting anomalous model behaviour, misuse and harm events, define internal escalation paths and criteria for external notification, and retain records of how incidents were handled. The mechanism must interlock with the PDPA breach-notification deadline of three calendar days after assessment.

Evidence: AI incident severity criteria and response plan; Incident register with closure records; Misuse monitoring and content moderation logs; Documented interlock with the PDPA breach-notification workflow

AI incident and serious incident reporting record (register plus report drafts)

Under the Accountability dimension, define the responsibility boundaries of model developers, application integrators and end deployers, reflect them consistently in customer contracts and internal governance documents, and place each risk with the party best placed to control it.

Evidence: AI governance responsibility matrix (RACI); Responsibility allocation clauses in customer contracts; AI governance committee charter and meeting minutes

ISO/IEC 42001 AI management system implementation and certification readiness checklist

Under the Content Provenance dimension, apply labelling, watermarking or metadata so that downstream users and platforms can identify machine-generated content. Where the same product also enters Korea, note that Art. 31 of the Korean AI Framework Act makes labelling of generative output a statutory duty.

Evidence: Technical description of the content-marking scheme; Watermark or metadata implementation and robustness test records; Screenshots of the user-facing indication

Model Card

Under the Testing and Assurance dimension, supplement self-assessment with independent third-party testing to raise the credibility of external claims. Singapore has built a testing ecosystem around the AI Verify testing framework and toolkit, including tester accreditation, and participation is commonly probed in tenders and large-customer due diligence.

Evidence: Third-party test report with scope statement; Remediation closure records for test findings; Consistency check between public claims and test conclusions

ISO/IEC 42001 AI management system implementation and certification readiness checklist