PDPA for Web Applications: What Singapore Businesses Need to Know
If your web application holds personal data about customers, staff, patients or students, your business has obligations under Singapore's Personal Data Protection Act (PDPA). Hiring a developer or using a cloud provider does not hand that responsibility over to them. Small businesses are covered too, although the security a simple enquiry system needs is very different from what a platform holding patient records needs.
For a business commissioning an application, these obligations shape practical decisions: what information to collect, who can access it, how long to keep it and which services receive it. Settling those questions while the scope is being defined is far easier than changing live records and workflows later. Some of them, particularly roles and permissions, are among the early decisions covered in our guide to custom web application development.
This article focuses on the application decisions. It is general guidance, not legal advice, so check the PDPC's resources or speak to a lawyer about how the rules apply to your business.
Who is responsible for the personal data?
When your business collects and uses personal data through its application, it is the organisation responsible under the PDPA. A vendor processing that data on your behalf may be a data intermediary, which can include a hosting provider or a maintenance team, depending on what it actually does with the data.
A data intermediary processing data on behalf of an organisation and for its purposes under a written contract is directly bound by three obligations: protection, retention limitation and data breach notification. Your business stays responsible for the data processed on its behalf. If a vendor starts using the information for its own purposes, the wider obligations apply to that processing as well. The PDPC explains the distinction between organisations and data intermediaries in more detail.
Access to a production database does not on its own decide a vendor's role, so the contract should spell it out: what the vendor may process, why it needs access, how the data is protected, how incidents are reported and what happens when the arrangement ends. The PDPC's guide to data protection clauses is a starting point. Agree confidentiality and data-processing terms as part of the contract, including what happens to vendor access and retained copies when the work ends.
What the PDPA means inside a web application
The PDPC's overview of the obligations sets out the legal requirements. The table below shows the decisions they usually raise during development.
| Area | Application decisions to discuss |
|---|---|
| Consent, notification and purpose | Explain the purposes as required and limit collection, use and disclosure to appropriate purposes. Establish whether consent or another permitted basis applies. Record consent where relied on and support withdrawal with reasonable notice. |
| Access and correction | Support access to a person's records and information about use or disclosure in the preceding year. Correct errors and notify relevant recipients where required, subject to applicable exceptions. |
| Accuracy | Make reasonable efforts to keep records accurate and complete when likely to be used for decisions affecting the individual or disclosed to another organisation. Validation and correction workflows help. |
| Protection | Decide on safeguards that match the data and the risks, including authentication, permissions and operational security. |
| Retention | Decide when records stop being needed for their original purpose and for legal or business reasons. Include exports and backup expiry in the plan. |
| Overseas transfers | List overseas recipients and put a recognised mechanism in place so they protect the data to a standard comparable to the PDPA. |
| Accountability | Appoint a DPO, publish their business contact information and set out policies and responsibilities. |
| Breach notification | Agree an assessment and reporting process, backed by useful logs and clear escalation from vendors. |
A consent checkbox cannot decide whether the collection is justified, and a delete button cannot decide the right retention period. Those calls belong to the business. The developer then builds the features and safeguards that carry them out.
Data Retention
Under the Retention Limitation Obligation, organisations must stop retaining personal data, or remove its association with identifiable individuals, once its original purpose is no longer served and there is no legal or business need to keep it. The PDPA does not set a single retention period for every type of record.
An application can delete an old customer record while copies survive in downloaded spreadsheets, email attachments and backups. Set retention periods for the relevant records and decide how those copies expire or get removed. Your backup restoration procedure should also deal with records that were deleted after the backup was taken, so a restore does not quietly bring them back.
NRIC authentication phased out by 31 December 2026
The Government has announced that private organisations must phase out NRIC authentication by 31 December 2026. From 1 January 2027, the PDPC will step up enforcement against this practice. The existing duty to make reasonable security arrangements already applies today.
An identifier lets a system tell one person from another. Authentication verifies that someone is who they claim to be before granting access to an account, document or service. Knowing an NRIC number alone is not reliable evidence that the person entering it is its owner.
The joint PDPC and CSA advisory, first issued in June 2025 and updated in May 2026, covers uses such as:
- Full or partial NRIC numbers used as default passwords.
- Passwords combining NRIC characters with easily found information, such as a name or birth date.
- Account access, document access or customer service checks that treat knowing an NRIC number as proof of identity.
Check password resets and account recovery as well as the login screen. Replacing an NRIC password achieves little if someone can reset the new password by entering the same NRIC number.
The replacement should match the account and its risks. Options include properly managed passwords, one-time codes sent to a verified phone number or email, multi-factor authentication, or Singpass login where the use case supports it. Plan how existing users will move across, how account recovery will work and how you will tell users about the change.
Collecting NRIC numbers?
The authentication deadline concerns how NRIC numbers are used to grant access. The PDPC's NRIC guidance separately restricts their collection, use and disclosure. Collection is permitted where the law requires it or where you need to establish or verify someone's identity to a high degree of accuracy, and some PDPA exceptions may also apply.
Using an NRIC number as a convenient customer reference does not, by itself, meet that bar. If your workflow does not need an NRIC number, use a customer ID generated by the application. Where collection is permitted, limit who can see the number and protect it accordingly.
Reasonable security in practice
The PDPA requires reasonable security arrangements. What counts as reasonable depends on the nature and volume of the data and the consequences if someone gets unauthorised access. The PDPC's Guide to Data Protection Practices for ICT Systems splits its recommendations into basic practices for everyday data and enhanced practices for larger volumes or more sensitive records.
When you are buying software, ask which safeguards have been implemented and how they will be maintained. A proposal that simply says "PDPA compliant" gives you little to assess without details of the controls and responsibilities.
Include safeguards in the scope of work
Specify the hosting arrangements, access controls, encryption coverage and events that need logging. Agree who manages those controls and how they will be checked before launch. The implementation needs to reflect the records and workflows the application handles.
This also matters when taking over an existing system. At retroXpect, we request staging access or clone the production system to staging so we can inspect it before proceeding. We take backups before work and explain the proposed work and estimate to the client.
Role-based access needs according to the workflow
Map what each role needs to view, change, approve and export. A driver may need a passenger's pickup details and have no use for the finance dashboard. An administrator may need to correct a booking without being able to download the whole customer database.
Permissions have to be enforced on the server, including when someone requests records directly through an API. Plan for staff departures, shared accounts and privileged access too. Multi-factor authentication is worth having for administrators and any account with broad or sensitive access, because a stolen admin password is one of the most direct routes to a large leak.
Routine development and maintenance safeguards
Most applications holding personal data should cover the following:
- HTTPS/TLS for data travelling between users and the application.
- Validation of incoming data and safe handling of database queries.
- Passwords, API keys and database credentials kept out of the source code and properly protected.
- Security updates for frameworks, libraries and other dependencies.
- Limits on login attempts and a secure account recovery flow.
- Protected backups, with restores tested.
- Collection limited to the information the workflow needs.
These tasks need an owner after launch. Agree who applies updates, monitors failures and responds when a component needs urgent attention. Our guide to web app maintenance costs explains how that work fits into ongoing support.
Encryption and logging scope
Encryption in transit and encryption at rest deal with different risks, so agree what each covers: databases, uploaded files and backups, and who controls the encryption keys. The PDPC's Guide to Data Protection by Design for ICT Systems is a useful reference here.
For logs, decide which events to record: logins, permission changes, access to sensitive records, exports and deletions. Keep passwords and unnecessary personal data out of them and restrict access to the logging system. Where stronger protection against alteration is needed, assess tamper-resistant or immutable storage, including its configured retention period.
Logs can help identify the accounts and records involved in an incident, provided the relevant events were captured and the logs remain trustworthy. They do not guarantee a complete account, so agree the logging scope before development.
Extra safeguards for higher-risk features
Sensitive records, bulk exports and file uploads can justify further measures such as masking sensitive fields on screen, alerts on large exports, malware scanning of uploads or independent security testing before launch. Upload features deserve a look even in small applications, because the risk comes from what people can upload, whatever the size of the user base.
Use synthetic or anonymised data for testing where you can. Where real personal data is needed for testing, protect it and limit who can reach it. Write down why you chose the controls you did, then check that they actually work. If the PDPC ever looks into an incident, being able to explain your reasoning helps, and working safeguards are what keep the records safe in the first place.
Overseas hosting and connected services
Hosting outside Singapore is allowed. Organisations need to make sure overseas recipients protect the data to a standard comparable to the PDPA, through legally enforceable obligations or another recognised mechanism, and contractual terms are the usual route.
A Singapore hosting region can reduce overseas transfers, but the main database is only one part of the system. Email delivery, analytics, error tracking, AI APIs, backups and vendor support can all involve processing elsewhere.
List the services that receive personal data, what each one receives and where it is processed, then read their terms and subprocessor lists. A well-known provider or a Singapore server does not settle the question by itself. Configure integrations to send only what they need: error reports, for example, should exclude customer details that are unnecessary for investigating the error.
What happens when there is a data breach?
Mandatory breach notification took effect in February 2021. A breach is generally notifiable to the PDPC if it results in, or is likely to result in, significant harm, or if it affects 500 or more individuals. The PDPC's Guide on Managing and Notifying Data Breaches explains the assessment process.
The regulations list particular data, and combinations of data, that are deemed to cause significant harm. An account identifier leaked together with a password or other information that allows access is one example. A bank account number alone does not automatically meet the test, so assess the specific information affected against the listed criteria.
The main timing requirements are:
| Step | Timing |
|---|---|
| Assess the breach | Once there are credible grounds to believe a breach occurred, assess it reasonably and expeditiously. PDPC generally expects completion within 30 calendar days. This is not a statutory maximum or a grace period; delays need explanation and the assessment steps should be documented. |
| Notify PDPC | As soon as practicable, and no later than three calendar days after the day you determine the breach is notifiable. |
| Notify affected individuals | Where the breach is likely to cause them significant harm, as soon as practicable, at the same time as or after notifying the PDPC. Some exceptions apply. |
| Data intermediary informs its client | Without undue delay after discovering a breach involving data it processes for the client. |
The scale threshold can require reporting to PDPC even without significant harm, but scale alone does not require notification to affected individuals. Applicable exclusions must still be considered: for example, certain breaches involving unauthorised handling of data entirely within an organisation are not notifiable. Missing logs can make assessment harder without automatically requiring notification to everyone.
The maximum financial penalty is S$1 million for organisations whose annual turnover in Singapore is S$10 million or less, and 10% of annual turnover in Singapore for those above it. These are upper limits, and the actual penalty in any case depends on the facts. The PDPC's enforcement announcement explains the framework.
Prepare an incident process before you need it. Name who is responsible for containment, preserving evidence, talking to vendors and deciding on notification. Make sure someone can reach your providers quickly and get the records needed to investigate.
What remains your business's responsibility
Your business needs a Data Protection Officer with public business contact information, policies and procedures for handling personal data, staff who understand their part, and a process for access requests, corrections and incidents.
Some of this can be outsourced. The PDPC allows operational DPO functions to be outsourced, though the organisation stays responsible for meeting its obligations. A developer can build the technical features that support these processes, such as exportable records for access requests and logs for breach assessment. Agree that support in the scope so nobody assumes it is included.
Questions to ask your developer
Before signing off the scope, ask the following questions:
- What personal data will the application hold, and why is each field needed?
- Who can view, edit, approve and export it?
- How do login, password reset and account recovery verify the user?
- Which providers receive personal data, and where is it processed?
- What is encrypted, what is logged and how are keys and logs protected?
- How will retention work across live records, exports and backups?
- Who handles updates and incidents after launch?
- What production access will the development team need, and what happens to that access when the work ends?
A good developer can name the control, its limitations and who maintains it. Put the important commitments in the scope and contract so both sides can refer back to them.
Frequently asked questions
Does the PDPA apply to small businesses?
Yes. There is no general exemption for small businesses. The safeguards you need depend on the data and the risks, so a small business holding sensitive information may still need strong protection.
Is a website contact form covered?
In most cases, yes. Names and contact details submitted through a form are personal data. Business contact information can fall outside the PDPA's data protection provisions, depending on why it was provided, and the PDPC's Key Concepts guidelines explain the distinction.
For covered submissions, explain the purposes, restrict access and remove records when they are no longer needed for their original purpose or legal or business reasons. HTTPS protects the data in transit, and the database, inbox or service receiving the submissions requires protection too.
Can my application still store NRIC numbers?
Only where collecting and using them is permitted under the PDPC's NRIC guidance. Separately, full or partial NRIC numbers must stop being used to authenticate users by 31 December 2026, and that includes recovery checks and protected documents as well as passwords.
Does PDPA compliance require Singapore hosting?
No. Overseas hosting is allowed when the transfer requirements are met. A Singapore region can reduce transfers, but connected services, backups and support access still require your due diligence.
Does the PDPA require every application to use encryption?
The PDPA requires reasonable security arrangements. PDPC guidance recommends encryption as a safeguard, with its implementation assessed against the data and risks. Assess its coverage for data in transit and at rest, including how keys are controlled, against the risks.
Am I responsible if my developer or host causes a breach?
Your business remains accountable for personal data processed on its behalf, and a data intermediary has its own obligations as well. Who bears responsibility for a particular incident depends on the facts. A vendor's involvement does not automatically excuse the business, and it does not mean both parties will be penalised.
Plan the safeguards your application needs
If you are commissioning a web application, bring personal data, access, hosting, logging and retention into the scope discussion from the start. For an existing system, establish which controls are already in place, what needs improving and who will maintain the application after the work is done.
retroXpect builds custom web applications and takes over the maintenance of existing systems. We can help define the workflow and user permissions for a new build, or assess an existing application before proposing fixes, updates and improvements. Message us on WhatsApp with what your application does and what you want to improve, and we will discuss the scope and next steps.
