The short answer
A mobile app for a Singapore business is a container for personal data — names, emails, phone numbers, locations, sometimes payment details. The moment it holds that data, security stops being optional and becomes a duty under the Personal Data Protection Act (PDPA). The law does not tell you which encryption library to use; it tells you the outcome it expects (protect the data, report breaches, be accountable) and leaves the engineering to you. That is why the smart approach is to design against a recognised threat model from day one, rather than bolting on security after an incident forces the issue.
This guide connects the two halves that teams usually treat separately: the engineering benchmarks (the OWASP Mobile Top 10 and CSA's Safe App Standard) and the legal obligations (the PDPA's protection duty, breach notification, and penalty exposure). Get them aligned before launch and a security review becomes a checklist, not a fire drill.
Why app security is a legal question in Singapore
Most founders think of a security flaw as a bug. Under the PDPA it can also be a breach of the law. The PDPA's Protection Obligation requires an organisation to make reasonable security arrangements to protect personal data in its possession or control against unauthorised access, collection, use, disclosure or similar risks. An app that leaks user data through weak authentication or unencrypted storage is not just insecure — it may have failed a statutory obligation.
The consequences are quantified. Since 1 October 2022, the PDPC's guidance states that it "may impose a financial penalty of up to S$1 million or 10% of the organisation's annual turnover in Singapore, whichever is higher," with the 10% figure applying where annual turnover in Singapore exceeds S$10 million. For a small business the ceiling is S$1 million; for a larger one it scales with revenue. Either way, a preventable app vulnerability is now a line item a board should care about.
The OWASP Mobile Top 10 (2024)
You cannot defend against threats you have not named. The OWASP Mobile Top 10 is the industry-standard, vendor-neutral list of the most common mobile app security risks, refreshed in its 2024 release. It is the baseline threat model any competent mobile team designs against — and a useful shared language when you ask a vendor "how do you handle security?"
| # | Risk | What it means for your app |
|---|---|---|
| M1 | Improper Credential Usage | Hard-coded or poorly handled credentials and API keys that an attacker can extract. |
| M2 | Inadequate Supply Chain Security | Compromised third-party SDKs or libraries pulling risk into your build. |
| M3 | Insecure Authentication/Authorization | Weak login or access-control logic that lets users reach data that is not theirs. |
| M4 | Insufficient Input/Output Validation | Unchecked input opening the door to injection and data-corruption attacks. |
| M5 | Insecure Communication | Data in transit not protected properly, exposing it to interception. |
| M6 | Inadequate Privacy Controls | Collecting or exposing more personal data than the app needs — a direct PDPA concern. |
| M7 | Insufficient Binary Protections | An app that is easy to reverse-engineer or tamper with. |
| M8 | Security Misconfiguration | Insecure default settings, permissions or exposed debug features left in production. |
| M9 | Insecure Data Storage | Sensitive data stored on the device without adequate protection. |
| M10 | Insufficient Cryptography | Weak or misused encryption that fails to actually protect the data. |
Source: OWASP — Mobile Top 10 (2024 release), retrieved July 2026.
Read the list against your own app: M6 (Inadequate Privacy Controls) and M9 (Insecure Data Storage) map almost directly onto the PDPA's protection duty, while M3 and M1 are the classic routes to the unauthorised access the law expects you to prevent. A vendor who cannot discuss where their build sits against these categories is telling you something.
CSA's Safe App Standard 2.0
Singapore has its own benchmark. The Cyber Security Agency of Singapore (CSA) first published the Safe App Standard in January 2024 with four security areas, then released Safe App Standard 2.0 (SAS 2.0) on 15 October 2024, expanding it to eight areas. It is aimed at apps that carry out higher-risk transactions (financial activity in particular), and CSA encourages developers of apps developed and hosted in Singapore to adopt it. If your app moves money or holds sensitive records, SAS 2.0 is the local standard to design toward.
| # | Security area | Focus |
|---|---|---|
| 1 | Network Communication | Protecting data in transit with secure protocols. |
| 2 | Cryptography | Strong algorithms and secure key management. |
| 3 | Code Quality and Exploit Mitigations | Detecting vulnerabilities and coding weaknesses. |
| 4 | Platform Interactions | Securing how the app integrates with OS features. |
| 5 | Authentication | Validating user identity, including multiple factors. |
| 6 | Authorisation | Managing access rights to resources. |
| 7 | Data Storage | Safeguarding sensitive information stored on the device. |
| 8 | Anti-Tampering and Anti-Reversing | Preventing app compromise and reverse-engineering. |
Source: CSA — Safe App Standard Version 2.0 (15 October 2024).
The first four areas were the new additions in version 2.0; the latter four strengthened the original standard. CSA has noted that SAS 2.0 draws on established references including OWASP, so the two benchmarks reinforce rather than contradict each other. Adopting SAS 2.0 does not replace your PDPA duties — it is a practical way to demonstrate that you took the security of user data seriously.
What the PDPA demands of an app
Strip the PDPA down to what it asks of a mobile app and three obligations dominate: protect the data, report a serious breach, and be able to show you did both. Here is how those translate, with the figures stated by the PDPC.
| Obligation | What it requires | The number that matters |
|---|---|---|
| Protection Obligation | Make reasonable security arrangements to protect personal data against unauthorised access, use or disclosure. | No fixed figure — assessed on reasonableness of your safeguards. |
| Data breach — notifiable threshold | A breach is notifiable if it is likely to cause significant harm, or if it affects a large number of individuals. | 500 or more individuals. |
| Data breach — notify the PDPC | Notify the Commission once you have determined a breach is notifiable. | No later than 3 calendar days after that determination. |
| Financial penalty exposure | Maximum penalty the PDPC may impose for a data protection breach (effective 1 Oct 2022). | Up to S$1 million or 10% of annual turnover in Singapore, whichever is higher (10% where turnover exceeds S$10m). |
Sources: PDPC — Guide on Managing and Notifying Data Breaches (15 Mar 2021); PDPC — Guide on Active Enforcement (Oct 2022).
Notice that two of these rows are about what happens after something goes wrong. The protection duty is preventive; the breach-notification duty and the penalty are reactive. A secure app minimises the chance you ever have to invoke the reactive half — but you still need the process ready before launch, because the clock does not wait for you to build it.
The breach clock: three calendar days
The breach-notification duty is the one most app owners underestimate, because it runs on a short, fixed clock. Under the PDPC's guidance, once you have determined that a data breach is notifiable, you must notify the Commission no later than three calendar days. The PDPC's own worked example is blunt: if you determine on 1 January that a breach is notifiable, you must notify the Commission by 4 January. Affected individuals must generally be notified as soon as practicable, at the same time as or after you notify the PDPC.
Three calendar days is not long to assemble facts under pressure, which is exactly why breach readiness belongs in the build, not in the aftermath. That means: logging and monitoring so you can detect an incident, a documented assessment process to decide whether it is notifiable, and a named person who owns the PDPC notification. An app with none of these is not just insecure — it is structurally unable to meet the deadline.
A pre-launch security checklist
You do not need to be a security engineer to hold a build to a sensible bar. Before an app that touches personal data goes live, confirm:
- Data in transit is encrypted — traffic between the app and your backend uses secure protocols (OWASP M5; SAS 2.0 Network Communication).
- Data at rest is protected — sensitive data stored on the device is encrypted or, better, not stored on the device at all (OWASP M9; SAS 2.0 Data Storage).
- Authentication and access control are sound — users can only reach their own data, and credentials and API keys are not hard-coded into the app (OWASP M1, M3).
- You collect only what you need — data minimisation is both a privacy control (OWASP M6) and a PDPA consent-and-purpose expectation.
- Third-party SDKs are vetted — you know what every embedded library does with data (OWASP M2).
- Breach process exists — logging to detect incidents, a documented notifiability assessment, and an owner for the 3-day PDPC notification.
- A current privacy policy — describing what you collect, why, how long you keep it, and how a user contacts you about their data.
None of these is exotic. What separates a compliant app from a risky one is usually not a single missing feature but a team that treated security as a phase to do "later" — and later arrived as an incident.
How Namtech builds secure apps
At Namtech, security is not a bolt-on stage — it runs through our six steps: Discover, Design, Build, Test, Launch, Support. We design against the OWASP Mobile Top 10 from the first sprint, encrypt data in transit and minimise what is stored on the device, and where an app carries higher-risk transactions we align it with CSA's Safe App Standard 2.0. Because Singapore's PDPA applies to any app collecting personal data here, we scope the privacy policy and a breach-notification process as explicit line items, so the three-calendar-day clock is something you are ready for, not surprised by.
Our published starting points are SGD 20,000 for a Starter/MVP, SGD 38,000 for a Business app and SGD 90,000 for an Enterprise platform, and each includes security built in rather than sold as an upgrade. If you want an app you can defend — technically and legally — start with a scoping call or see the full breakdown on our pricing page.