A volunteer coordinator at a community organisation recently discovered that the participant database she'd been maintaining for three years was a shared Google Sheet — with edit access granted to seven current staff members and, on closer inspection, two former volunteers whose access had never been revoked.
The spreadsheet contained names, phone numbers, home addresses, and in several rows, notes about family circumstances and presenting needs.
She hadn't thought of it as a data protection issue. It was just how they'd always done it.
Under Singapore's Personal Data Protection Act, it was a problem she needed to fix.
This post is educational and does not constitute legal advice. For specific PDPA compliance guidance for your organisation, consult a qualified legal professional or refer to the Personal Data Protection Commission's guidelines directly.
What the PDPA Covers
The Personal Data Protection Act applies to the collection, use, and disclosure of personal data — any data that identifies, or could reasonably identify, an individual. For social service agencies, this covers nearly everything the organisation handles: intake forms, case notes, contact details, consent records, programme attendance, medical or family history shared during assessments, photographs from events, volunteer and staff records.
There are limited exceptions. The PDPA does not apply to public agencies operating under a separate statutory framework, and it treats business contact information used strictly for professional purposes differently from personal data. But for voluntary welfare organisations, community organisations, social enterprises, and charities operating outside the government agency framework, the PDPA applies in full.
The key obligations are not complicated in principle. They become complicated in practice when organisations have accumulated years of informal data handling habits — and most social service agencies have.
The Obligations Most Organisations Don't Have a Clear Handle On
Consent — what it actually requires
The PDPA requires personal data to be collected, used, and disclosed only with the individual's knowledge and consent, unless an exception applies. Consent must be informed: the person needs to understand what they're agreeing to.
For many organisations, consent exists on paper but isn't consistently meaningful in practice. The intake form has a consent clause, but it was written for a programme that no longer exists in the same form. Existing clients weren't asked to re-consent when new data uses were added. A community event generated a photograph posted to social media without asking whether participants were comfortable being identifiable online.
In a social service context, consent also requires particular care where clients may be in vulnerable or pressured circumstances. The PDPC's guidance is worth reading directly, but the practical question is whether consent was genuinely voluntary and informed — not merely whether a form was signed.
Purpose limitation — using data for what you collected it for
Data collected for one purpose should not be used for a materially different purpose without fresh consent. Client data collected during intake should not be shared with a partner organisation for their outreach programme, incorporated into a research project, or used to populate a donor management system, unless the person agreed to those uses when the data was collected.
Small organisations often have limited technical separation between their systems — the same spreadsheet that holds case notes also feeds the mailing list. That overlap is a PDPA concern, even when it's accidental.
Retention — not keeping data longer than necessary
The PDPA requires personal data to be kept only as long as it is necessary for the purpose it was collected for. Once it is no longer needed, it should be disposed of securely.
In practice, social service organisations tend to keep data indefinitely. Case files from closed programmes sit on old hard drives. Spreadsheets grow new sheets that nobody deletes because nobody is sure whether they might still be needed. Archive folders hold records from clients who have not been in contact for years.
The PDPA does not specify a universal retention period — the standard is what is "necessary", which requires the organisation to make a considered judgement and document it. Many organisations would benefit from a simple, explicit policy: case records retained for X years after case closure, programme attendance records for Y years after the programme ends, then reviewed and disposed of securely. Having a policy and following it is the standard the PDPC looks for.
Protection — reasonable security for sensitive data
The PDPA requires organisations to implement reasonable security arrangements to prevent unauthorised access, disclosure, or loss of personal data. What's "reasonable" depends on the sensitivity of the data and the scale of the organisation.
For social service agencies, the data is often highly sensitive — family circumstances, health information, financial difficulties, involvement with statutory services. The bar isn't enterprise-grade security infrastructure. It is that the organisation has thought carefully about who has access to what, has removed access for people who no longer need it, and has made considered decisions about how data is stored and transmitted.
Shared spreadsheets accessible to anyone with the link, former staff with active accounts in shared systems, client records stored on unencrypted personal devices — these are the patterns that have featured in enforcement action. None of them require sophisticated attack to exploit.
Mandatory breach notification — the obligation most organisations don't know they have
Since the mandatory data breach notification regime came into force, organisations are required to notify the PDPC of breaches that are likely to result in significant harm to affected individuals. Notification is required within three calendar days of the organisation determining that the breach meets the notification threshold.
Most small organisations don't have a breach response procedure. They aren't certain what constitutes a notifiable breach, who is responsible for assessing whether notification is required, or what the process involves. The consequence is that when something goes wrong, the response is improvised — rarely a good outcome.
What Consent Actually Means in a Social Service Context
Consent for social service purposes has specific considerations that general-purpose guidance doesn't always capture.
Where receiving a service is conditional on signing a consent form, the genuinely voluntary nature of that consent is worth examining. The PDPC has published guidance on this. The general principle is that where data collection is a condition of service access, the data collected should be proportionate to and necessary for that service — and clients should understand what they're agreeing to in plain terms.
For sensitive information — family history, health circumstances, financial situation, involvement with the legal system — the threshold for meaningful consent is higher. Many organisations use tiered consent frameworks that clearly separate data required for the service from data that is helpful but not essential, and from data collected for aggregate reporting or research purposes. Each category is explained separately and consented to separately.
Plain language is not a formatting consideration. A consent clause that requires a legal background to interpret does not produce informed consent in a meaningful sense, even if the form is technically compliant.
Compliance as Habit, Not Paperwork
PDPA compliance is not satisfied by producing a privacy policy. A well-drafted document that describes practices the organisation doesn't actually follow provides no real protection — and in an enforcement context, the gap between what the policy says and what actually happens is itself a problem.
The practical elements that matter are: access control (who can see which data, whether that access is reviewed and updated regularly as staff and volunteers change), retention practices (whether data is being kept beyond what's necessary, and whether there's a process for disposal), staff awareness (whether the people handling client data understand the basic principles), and incident response (whether there's a documented plan for when something goes wrong, however unlikely).
For small teams, this does not require a dedicated data protection officer or a formal compliance programme. It requires that someone has thought through each of these areas, made reasonable decisions, recorded those decisions somewhere, and ensures they're followed in practice.
The volunteer coordinator who found nine people with access to a spreadsheet of client data fixed it in an afternoon. She removed the former volunteers, restricted the spreadsheet to view-only for most staff, moved sensitive notes to a separately controlled sheet, and scheduled a quarterly access review. That's compliance as a working practice — not compliance as documentation.
This post is educational and does not constitute legal advice. For specific PDPA compliance guidance, consult a qualified legal professional or the PDPC's guidance directly.
Socianote is built with PDPA obligations in mind — role-based access control, a full audit trail, consent tracking, and hard delete that removes personal data across all records when requested. Learn more about our approach to data protection or start free.