Challenge
Anyone with the link can open the file, and links get forwarded.
Agnotic approach
Sign-in for every user, and access granted by role to the records each person needs.
PDPA Compliant Software Development
PDPA compliant software development in Singapore
Personal data often starts in shared drives and spreadsheets: easy to share, hard to control. Agnotic Technologies builds software for Singapore teams that turns the PDPA's obligations into working controls, from who can see a record to how long it is kept.
Role-based accessRetention and disposal rulesAccess logsBreach response workflow
Trusted by global innovators
What is PDPA compliant software development?
PDPA compliant software development means building applications that meet the obligations of Singapore's Personal Data Protection Act 2012 in code: consent and purpose records, role-based access, encryption, retention and disposal rules, breach detection and audit logs. Agnotic Technologies builds such systems for Singapore organizations that have outgrown shared drives and spreadsheets.
Software does not make an organization compliant on its own. It makes the right behavior the default and leaves a record that your data protection officer can show the PDPC.
Shared drives and spreadsheets
Why do shared drives and spreadsheets fall short?
Common gaps when personal data, such as test results or customer records, is kept in shared files.
Challenge
A whole sheet is shared when a person needs one row.
Agnotic approach
Record-level permissions, so a reviewer sees only the cases assigned to them.
Challenge
Copies multiply in downloads and email attachments.
Agnotic approach
Data stays in the application, with exports limited, logged and watermarked.
Challenge
Nothing is ever deleted.
Agnotic approach
Retention rules per record type, with disposal that is scheduled, approved and recorded.
Challenge
Nobody can say who looked at a record.
Agnotic approach
Access logs for every view, change and export, kept for review.
Challenge
NRIC numbers double as login IDs or lookup keys.
Agnotic approach
Separate user accounts and internal record IDs, with NRIC numbers stored only where there is a reason to keep them.
Obligations to controls
Which PDPA obligation becomes which software control?
How we turn the PDPC's data protection obligations into features. Exceptions apply to several obligations, so your data protection officer confirms each row.
| PDPA obligation | What it asks of the organization | Software control we build |
|---|---|---|
| Consent | Collect, use or disclose personal data only for purposes the person consented to, and allow withdrawal | Consent records per purpose, with withdrawal that stops further use |
| Purpose limitation | Use data only for purposes a reasonable person would consider appropriate | Purpose tags on data fields and checks before data is reused |
| Notification | Tell people the purposes for which their data will be collected, used or disclosed | Purpose notices built into forms and kept with each record |
| Accuracy | Make a reasonable effort to keep data accurate and complete | Validation at entry and a correction workflow |
| Protection | Make reasonable security arrangements | Role-based access, encryption, sign-in controls and security testing |
| Retention limitation | Stop keeping data once no business or legal purpose remains | Retention periods per record type and recorded disposal |
| Transfer limitation | Transfer data overseas only under the prescribed requirements | Hosting region choices and a register of systems that process data abroad |
| Access and correction | Give people access to their data and correct errors on request | Request handling with deadlines and a history of what was released |
| Data breach notification | Assess breaches and notify the PDPC and individuals when notifiable | Breach records, assessment steps and the timestamps the deadline depends on |
| Accountability | Have policies, a data protection officer and a complaints process | Policy versions, data protection officer contact details and a request inbox |
This is engineering guidance, not legal advice. The PDPC's advisory guidelines explain each obligation and its exceptions.
Roles
Who is responsible: you or the developer?
Your organization decides why and how personal data is processed, so the obligations stay with you. When we build or host software that processes personal data on your behalf, we would usually act as your data intermediary under a written contract.
That contract sets what we may do with the data, the security we must keep and how fast we tell you about an incident, so your own breach assessment can start on time.
What do we build into PDPA compliant software?
Controls that are part of the application, not a policy document beside it.
Role and record access
Roles, record-level permissions and multi-factor sign-in, with no shared accounts.
Data map
Which personal data each screen and table holds, its purpose and its retention period.
Encryption
Data encrypted in transit and at rest, with keys managed outside the application.
Retention and disposal
Scheduled disposal by record type, with approval and a disposal record.
Access and correction requests
A workflow for requests from individuals, with due dates and the response kept.
Access logs
Every view, change and export recorded and reviewable by your data protection officer.
Personal data detection
Checks that flag personal data in uploaded files and free-text fields where it should not be.
Migration off shared drives
Spreadsheets and folders moved into the application, then the old copies closed and disposed of.
Breach response
What does the software do when a breach is suspected?
The software keeps the record and the clock. Your data protection officer makes the decisions.
Detect
Alerts from access logs, such as unusual exports or sign-ins, open a breach record.
Contain
Accounts can be suspended, sessions ended and shared links revoked from one screen.
Assess
The record lists the data and the number of people affected, to help decide whether the breach is notifiable.
Notify
Once it is judged notifiable, the record shows the time of that decision and the three calendar day deadline to notify the PDPC.
Inform individuals
Affected people can be listed and contacted when notification to them is required.
Review
Fixes and lessons are recorded against the breach for future audits.
Facts and sources
Facts from the PDPC
Obligations and advisories the controls are built on, each linked to the Personal Data Protection Commission.
The PDPA's Protection Obligation requires organizations to make reasonable security arrangements to protect personal data in their possession against unauthorized access, collection, use, disclosure or similar risks.
Source: PDPC, Data Protection ObligationsUnder the PDPA's Retention Limitation Obligation, an organization must stop retaining personal data, or dispose of it properly, once it is no longer needed for any business or legal purpose.
Source: PDPC, Data Protection ObligationsThe PDPA's Transfer Limitation Obligation allows personal data to be transferred to another country only according to the prescribed requirements, so that its protection is comparable to the protection under the PDPA, unless the PDPC grants an exemption.
Source: PDPC, Data Protection ObligationsThe PDPC says a data breach is notifiable when it is likely to result in significant harm to individuals or affects 500 or more individuals, and notification to the PDPC must be made no later than three calendar days after the organization determines the breach is notifiable.
Source: PDPC, Report Your Organisation's Data BreachThe PDPC and the Cyber Security Agency of Singapore advise organizations against using NRIC numbers to authenticate people.
Source: PDPC and CSA, Joint Advisory against using NRIC Numbers for Authentication
Rules and guides
Which rules and guides do we build against?
PDPA 2012PDPC obligationsData breach notificationNRIC advisoryOWASP ASVS
Scope
What decides the size of a PDPA compliant build?
We do not publish prices. These are the drivers we price on the scoping call.
Data you hold
How many kinds of personal data, and how sensitive they are.
Current tools
How much data sits in shared drives and spreadsheets and needs migrating.
Users and roles
How many internal users, external users and permission levels.
Hosting
Where the system runs and whether any data goes overseas.
Integrations
Systems that send or receive personal data, such as lab, CRM or billing systems.
Request volume
How many access, correction and withdrawal requests you expect.
Who it is for
Who needs PDPA compliant software?
Singapore teams whose personal data has outgrown the tools it started in.
Lab and genomics reporting teams
Test results and reports moved from shared sheets into an application with per-case access.
Clinics and health services
Patient records and bookings with role-based access and retention rules.
HR and recruitment teams
Candidate and employee data with retention periods and controlled exports.
Membership and customer programs
Consent records per purpose and withdrawal that takes effect across systems.
Engagement
How does a PDPA compliant software project run?
We start from the data you hold today.
1.
Scoping call
We review the personal data you hold, where it lives now and who needs which parts of it.
Scope2.
Data map and first release
A data map approved by your data protection officer, then a fixed-scope first release that moves one dataset off shared files.
Build3.
More datasets and support
Remaining datasets migrated, old copies disposed of, and support after launch.
ScaleFrequently Asked Questions
No software does that on its own. Compliance also depends on your policies, training and decisions. The software makes the right behavior the default and keeps the records your data protection officer needs.
That is a decision for your organization and its data protection officer. Shared files make access control, retention and access logging hard to prove, which is why teams move sensitive data into an application.
You choose. We can deploy to a cloud region in Singapore or another region you approve, and we record any overseas processing so the Transfer Limitation Obligation can be assessed.
It detects unusual access, records what was affected and how many people, and shows the deadline once a breach is judged notifiable. The PDPC requires notification no later than three calendar days after that decision.
The PDPC and the Cyber Security Agency of Singapore advise against using NRIC numbers to authenticate people. We give users their own accounts and use internal IDs for records.
We do not publish prices. The data you hold, migration from current tools, users and roles, hosting and integrations decide the size, and we agree a fixed first release on the scoping call.