If you buy or build PDPA compliant software Singapore teams can actually operate, “privacy later” is already too late. Singapore product, procurement, and security leads need PDPA by design Singapore controls wired into requirements, architecture, build, UAT, and operations—not a policy PDF bolted on before go-live. This article is a copy-paste software PDPA checklist: SDLC phase × PDPA / PDPC theme → design control → evidence artefact. Educational only—not legal advice. Confirm obligations with your counsel and the live PDPC and Personal Data Protection Act 2012 texts.
Who this is for — and who should skip
For: Singapore product owners and engineering leads scoping custom platforms that collect or process personal data; procurement and vendor-risk teams scoring build partners on data protection by design; security / DPO counterparts who need artefact-backed evidence, not slideware. Complements our software vendor due diligence (PDPA, security, IP) questionnaire and, for AI logging specifics, LLM output logging and retention for Singapore buyers.
Skip if: you only need a marketing “PDPA ready” badge with no system design; you want invented fine amounts or “PDPC-certified software” claims (that is not how the regime works); you are buying a pure commodity tool with no personal data in scope; or you already shipped without purpose inventories and need remediation counsel—not a build-phase checklist.
Direct answer: bake PDPA into the SDLC, prove it with artefacts
Under Singapore’s Personal Data Protection Act 2012, organisations that collect, use, or disclose personal data must meet the Data Protection Provisions. For software projects, three statutes buyers should map early (without inventing extras) are:
- Purpose Limitation (section 18) — collect, use, or disclose personal data only for purposes a reasonable person would consider appropriate in the circumstances and that the individual has been informed of under section 20, if applicable (SSO s18).
- Protection (section 24) — make reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification or disposal (and loss of storage media/devices) (SSO s24).
- Retention Limitation (section 25) — cease to retain documents containing personal data, or remove the means of association with individuals, when the collection purpose is no longer served and retention is no longer necessary for legal or business purposes (SSO s25).
PDPC’s Advisory Guidelines on Key Concepts in the PDPA elaborate these obligations for organisations. For ICT build and run practices, use PDPC’s Guide to Data Protection Practices for ICT Systems (page published 20 July 2026 on PDPC’s site)—a compilation of practices and breach lessons for ICT policies, systems, and processes. Treat older “data protection by design” phrasing as the same buyer outcome: data protection by design Singapore custom software means controls and evidence across the lifecycle, not a single privacy sprint.
If your stack includes AI features, pair this matrix with WC1’s AI automation Singapore delivery path and the LLM logging Insight above—do not collapse “PDPA-by-design for the whole product” into log retention alone.
Original element: SDLC × PDPA / PDPC design-control matrix
Copy this matrix into your PRD annex, architecture review pack, or vendor SOW. Columns map an SDLC phase to a PDPA / PDPC theme, a concrete design control, and the evidence artefact a Singapore buyer should keep. Mark Owner, Due date, and Status (Compliant / Partial / Non-compliant / N/A) per row. Partials without artefacts score as Non-compliant for production data.
| # | SDLC phase | PDPA / PDPC theme | Design control | Evidence artefact |
|---|---|---|---|---|
| 1 | Requirements | Purpose limitation & notification (PDPA ss 18, 20; Key Concepts) | Every personal-data field maps to a named, appropriate purpose; no “future analytics TBD” columns in MVP scope | Purpose inventory in PRD; draft notice / privacy-policy snippets; stakeholder sign-off that purposes are product-true |
| 2 | Requirements | Data minimisation & accountability (Key Concepts; ICT practices guide) | Justify each attribute; drop nice-to-have PII; mark sensitive classes and lawful basis / exception notes where used | Data dictionary with “need” rationale; ROPA / processing-register inputs; DPO or privacy-owner review record |
| 3 | Architecture | Protection obligation (PDPA s 24) | Trust boundaries, encryption in transit/at rest defaults, secrets out of code, environment isolation for prod personal data | Threat model or security design review; architecture decision records; network / tenancy diagram with data stores labelled |
| 4 | Architecture | Access control & least privilege | Role/attribute matrix for staff, vendors, and support break-glass; MFA on admin paths; no shared standing prod passwords | RBAC/ABAC matrix; privileged-access design; joiner–mover–leaver hooks in identity provider |
| 5 | Architecture | Purpose limitation in system behaviour | APIs and batch jobs enforce purpose-scoped use; secondary use (marketing, model training) gated or blocked by design | API purpose tags / policy checks; feature-flag rules; “forbidden secondary use” test cases in acceptance criteria |
| 6 | Architecture | Logging, monitoring & PDPA hygiene | Log taxonomy forbids raw NRIC/full card data in app logs by default; admin access and export events are auditable | Log field catalogue; SIEM retention mapping; sample redacted log extracts; alert list for anomalous access |
| 7 | Build | Secure development / ICT controls (PDPC ICT practices guide themes) | SAST/DAST/dependency scans gated before release; secrets scanning; secure coding standards for personal-data handlers | Pipeline gate screenshots; vulnerability SLA; last release evidence for a comparable service |
| 8 | Build | Data intermediary / vendor processing | Subprocessors that touch personal data are named; contracts cascade confidentiality, purpose limits, and deletion | Subprocessor register; draft DPA / processing schedule; flow-down clause pack |
| 9 | UAT / pre-prod | Test data & accuracy risk | Prefer synthetic or properly masked data; forbid unmanaged production clones on laptops; document residual risk if prod-like data is essential | Test-data policy attestation; masking runbook; environment access list; exception ticket with expiry |
| 10 | UAT / pre-prod | Individual rights readiness (access / correction themes) | Support tooling can locate, export, and correct in-scope personal data within agreed SLAs without engineering heroics | Request runbooks; UAT scripts for access/correction; screen recordings or ticket evidence from dry-run |
| 11 | Operations | Retention limitation (PDPA s 25) | Per-purpose retention clocks; automated purge or de-identification; backups included in the story | Retention schedule table; job config / IaC excerpts; last purge report; backup lifecycle note |
| 12 | Operations | Security monitoring & incident readiness (s 24 + ICT practices) | Detect misuse of personal data stores; incident RACI with customer/PDPC notification paths your counsel approved | Incident runbook; tabletop summary (redacted); on-call roster; breach-cooperation SLA with vendors |
How to run the checklist on a Singapore custom software buy
Step 1 — Scope personal data before you scope sprints. List entities, fields, purposes, and who (staff, vendor, AI feature) can touch them. If the purpose inventory is empty, pause vendor shortlists. WC1’s custom software Singapore engagements start here so PDPA controls are priced into the SOW—not change-ordered after UAT.
Step 2 — Score the matrix early. Issue rows 1–12 as a scored annex (Compliant / Partial / Non-compliant / N/A) with a hard evidence column. Keep commercial scoring separate so a low day-rate cannot buy missing retention or access design. For vendor-side paper, reuse the diligence questions in our PDPA / security / IP vendor pack.
Step 3 — Architecture gate before build volume. Rows 3–6 should be green (or explicitly accepted with residual-risk owners) before you fund a large build tranche. Purpose-scoped APIs and log hygiene are cheaper in design than in remediation.
Step 4 — UAT proves rights and test-data discipline. Rows 9–10 fail closed if engineers still copy production databases to unmanaged machines. Synthetic data and dry-run access/correction tickets are buyer-visible evidence.
Step 5 — Operate with clocks, not slogans. Rows 11–12 need retention jobs and incident paths that still work after the project team demobilises. Put owners in Singapore business hours where your customers expect response.
Budget and delivery models in SGD belong in the commercial pack—see our broader Singapore build pages for software development company Singapore context when you compare partner shapes. When you want a working session on the matrix, use Contact WC1.
Worked example (illustrative — not a regulatory determination)
A Singapore healthcare-adjacent marketplace scopes a custom booking + CRM layer. The 12-row matrix surfaces: marketing wants “all fields for later AI” with no purpose (row 1 blocker); staging clones hold live NRIC-like identifiers on shared laptops (row 9 blocker); admin logs print full contact payloads (row 6 Partial→fail until redaction); retention is “keep forever for analytics” with no purge job (row 11 blocker). Award of the build tranche waits until Partials become Compliant with artefacts—board pack lists open conditions and owners, not a fake “95% PDPA complete” percentage. AI features, if any, get a separate logging/retention annex rather than hiding inside a vague “innovation” epic.
Mistakes and traps
- Policy theatre — a privacy policy rewrite with no purpose inventory, RBAC matrix, or retention jobs.
- Certificate collecting — accepting an ISO/SOC logo without reading scope boundaries for your tenant and personal-data stores.
- Logging everything “for security” — storing full personal data payloads in logs and calling it protection; that often worsens section 24 / retention risk.
- Vendor hope — assuming the build partner’s “we follow PDPA” slide replaces a DPA, subprocessor list, and deletion on exit.
- UAT with live PII — unmanaged production clones as the default test strategy.
- Retention folklore — “keep for AI later” without a section 25 story for purpose expiry and backup lifecycle.
- Collapsing the whole topic into LLM logs — necessary for AI features, insufficient for the rest of the product lifecycle.
- Skipping Singapore buyers’ evidence culture — verbal assurances in SGD negotiations without artefacts procurement can file.
Decision framework: five yes/no gates
- Can you name every personal-data purpose in the product and show where the individual is notified (if applicable)? If no, stop coding collection fields.
- Does architecture document trust boundaries, access control, and encryption defaults for those stores? If no, do not fund the main build tranche.
- Are pipelines and vendors contractually and technically unable to silently widen purpose or fork data to shadow tools? If no, treat secondary use as open risk.
- Can support execute access/correction dry-runs without engineering war rooms? If no, you are not launch-ready.
- Do retention clocks and incident paths cover apps, logs, and backups with named owners? If no, production personal data stays blocked.
All five must be yes before production personal data moves. Speed without gates is how “agile delivery” becomes a PDPA remediation programme.
FAQs
Is “PDPA compliant software” a certification I can buy?
No single off-the-shelf certificate makes a custom system “PDPA compliant.” Compliance is about how your organisation collects, uses, discloses, protects, and retains personal data under the PDPA, with PDPC guidance as the practical lens. Buy evidence across the SDLC—not a badge.
Where should we start if the vendor already wrote code?
Run rows 1–2 and 11 first (purposes and retention), then 3–6 (architecture and logging). Gaps become remediation backlog with severity—not a retrospective slide. Pair with the vendor diligence Insight linked above.
How does this relate to PDPC’s ICT systems guide?
Use the Guide to Data Protection Practices for ICT Systems for ICT control themes (policies, technical controls, lifecycle operations). This matrix translates those buyer expectations into SDLC artefacts for custom software projects.
What about generative AI features inside the product?
Keep this lifecycle matrix for the whole product, then add AI-specific logging, training-data, and output-retention controls. See our LLM output logging Insight and PDPC materials on generative AI where they apply to your use case—without treating AI guidance as a substitute for sections 18, 24, and 25 on the core system.
Can WC1 implement these controls in a fixed SGD SOW?
Yes when purpose inventories and environment constraints are clear enough to estimate. Start from custom software Singapore or contact with your data-flow sketch and which matrix rows are already green.
For sector views of this checklist, see healthcare software in Singapore: PDPA and operational realities and fintech delivery patterns that survive MAS review. The same controls apply whether you are building a web application or a mobile app.
Sources
- Personal Data Protection Act 2012 (Singapore Statutes Online) — including s18, s24, s25
- Personal Data Protection Commission (PDPC)
- Advisory Guidelines on Key Concepts in the PDPA
- Guide to Data Protection Practices for ICT Systems (PDPC page dated 20 July 2026)
- PDPC overview of the PDPA
Next step
Paste the 12-row matrix into your next architecture review or RFP annex, score evidence honestly, and block production personal data until the five gates are yes. For a Singapore-scoped build partner conversation—controls designed in, artefacts included—reach WC1 Contact or review custom software Singapore and software development company Singapore.