PDPA Checklist for Custom Business Software in Singapore

PDPC sets out the data protection obligations every organisation must meet. Most of them translate directly into software requirements:

• Notification and consent: tell people why you collect their data, use it only for those purposes, and let them withdraw consent.
• Purpose limitation: do not require more personal data than a reasonable person would consider appropriate for the service.
• Access and correction: let individuals see and correct what you hold about them.
• Accuracy: keep data correct where it is used to make decisions about people.
• Protection: make reasonable security arrangements against unauthorised access, loss or disclosure.
• Retention limitation: stop keeping personal data once it is no longer needed for legal or business purposes.
• Transfer limitation: when data goes outside Singapore, make sure it receives a comparable standard of protection.
• Data breach notification: assess suspected breaches and report notifiable ones.
• Accountability: appoint someone responsible for data protection, keep policies, and be able to show what you do.

Your software vendor matters here too. A vendor that processes personal data on your behalf acts as a data intermediary, subject to the Protection, Retention Limitation and Data Breach Notification obligations, while your organisation remains responsible for compliance overall.

Collection and consent checklist

• Purpose shown at collection. Each form states why the data is needed, close to the fields, with a link to the full notice.
• Consent records. Store who consented, to what, when, through which channel and which version of the notice they saw.
• Separate marketing consent. Keep consent for marketing apart from consent needed to deliver the service, and never pre-tick it.
• Withdrawal that works. A self-service way to withdraw consent, which also stops downstream use in email tools and CRMs.
• Minimum fields. Remove fields nobody uses. Data you never collect cannot leak.
• No NRIC by default. PDPC's advisory guidelines on NRIC numbers say organisations should generally not collect NRIC numbers or copies unless the law requires it or it is necessary to establish or verify identity to a high degree of fidelity. Use a customer number, email or phone number as the identifier instead.

Authentication: stop using NRIC numbers by 31 December 2026

PDPC has told private organisations to stop using NRIC numbers for authentication by 31 December 2026, and will step up enforcement from 1 January 2027 against organisations that use full or partial NRIC numbers this way. The joint PDPC and CSA advisory gives NRIC numbers used as default passwords, alone or combined with names or birthdates, as a common example of misuse.

For software, that means:

• No NRIC-based logins or password-reset flows that ask for a full or partial NRIC number as proof of identity.
• No default passwords derived from personal data. Issue random, single-use setup links instead.
• Proper authentication factors: passwords with one-time codes, authenticator apps or passkeys.
• An audit of existing systems now. Search your code, forms and help-desk scripts for every place an NRIC number is used to confirm who someone is.

Protection: the security controls

The Protection obligation asks for reasonable security arrangements. In a custom system that usually means:

• Role-based access, so staff see only the records their job needs, with admin actions logged.
• Multi-factor authentication for all staff and admin accounts.
• Encryption in transit and at rest, including database backups.
• Secrets kept out of source code, in a managed secrets store.
• Masked or synthetic data in development and testing, never a copy of production.
• Patching and dependency updates on a schedule, not only after an incident.
• Security testing before launch and after major changes.
• Rate limits and lockouts on login and password-reset endpoints.

PDPC also publishes guidance on data protection practices for ICT systems, with basic and enhanced practices that make a useful second checklist for your developer.

Retention and deletion

• A retention schedule per data type: leads, customers, employees, job applicants, CCTV footage and support tickets.
• Automated purge or anonymisation jobs that run on that schedule and log what they removed.
• Backups that expire, so deleted records do not live on for years in old snapshots.
• Controlled exports. Log who downloaded spreadsheets of personal data, and restrict that permission.

Transfers, hosting and integrations

The PDPA does not require data to be hosted in Singapore, but transfers outside Singapore must meet the Transfer Limitation Obligation. List every place personal data goes: your cloud region, email and SMS providers, CRM, analytics tools, and any offshore developer with production access. Each of those flows should be covered by a contract that binds the recipient to comparable protection.

When several systems exchange data, system integration work should include a data-flow map showing which personal data moves where, and why. That map doubles as evidence for the Accountability obligation.

PDPC's guide on managing and notifying data breaches sets the timelines. Once you have credible grounds to believe a breach has occurred, you have 30 calendar days to assess whether it is notifiable; if it is, you must notify PDPC no later than three calendar days after making that determination. A breach is notifiable if it is likely to result in significant harm to the individuals affected, or if it affects 500 or more people.

Those deadlines are only achievable if the software helps:

• Audit logs that record who viewed, changed or exported which records, kept long enough to investigate.
• Queries that list affected individuals quickly, by record type and date range.
• Alerts for unusual exports, repeated failed logins and access outside working hours.
• A contact path so your vendor, as a data intermediary, can tell you about a breach it detects without delay.

Using the checklist with your developer

Turn each item above into an acceptance criterion and test it before go-live, the same way you test invoices or approvals. Ask whoever is responsible for data protection in your organisation to sign off on the consent screens, retention schedule and breach procedure. Review the list once a year, and after any major change to the system.

Working with DipanshuTech

DipanshuTech builds custom software for clients in 15+ countries from Greater Noida, India. If you bring us a Singapore project, ask for this checklist to be written into the scope during discovery, so consent, retention and access rules are priced and tested like any other feature. You get a written scope and fixed quote, working software on a staging server every two weeks, source code and accounts in your name, and an NDA on request.

Does the PDPA apply to a small business?

Yes. It applies to organisations of any size that collect, use or disclose personal data in Singapore, with exclusions such as public agencies.

Is our software vendor responsible under the PDPA?

Partly. A vendor processing data for you acts as a data intermediary, with protection, retention and breach notification duties. Your organisation remains responsible for compliance overall.

Can we still collect NRIC numbers?

Only where the law requires it or where you must verify identity to a high degree of fidelity. Even then, do not use NRIC numbers to authenticate users; PDPC's deadline to stop is 31 December 2026.

Do we need to host our data in Singapore?

Not necessarily. Overseas hosting is possible if the Transfer Limitation Obligation is met, typically through contracts that bind the recipient to comparable protection.

If you are commissioning new software or reviewing an existing system before the NRIC deadline, talk to us about your project. We will reply with a written scope and fixed quote.