The email arrived on a Tuesday morning. It was politely worded — a former programme participant asking to know "everything your organisation holds about me." The coordinator who opened it had been running the charity's family support service for eleven years. She knew every case file in the cabinet. She knew which clients had moved on, which were still in touch, which had ended badly. What she did not know was that this email was a Subject Access Request — a legal right enshrined in data protection law — and that she had thirty days to respond to it.
She forwarded it to the programme manager with a question mark. The programme manager forwarded it to the board chair. The board chair searched the term online and found something alarming. They had obligations they had never been told about. The clock was already ticking.
This scenario plays out more often than most nonprofit leaders realise. And it is not a failure of good intentions — the organisation genuinely cared about the people it served. It is a failure of information. Data protection law is frequently described in language built for corporate legal teams, and small charities absorb the impression that it must not apply to them. It does.
Why Nonprofits Often Think the Law Does Not Reach Them
There are three assumptions that lead organisations astray, and none of them hold up.
The first is "we're not a company." Legal structure has nothing to do with it. Whether you are a registered charity, an incorporated association, an NGO, or an informal community group, if you hold personal information about living individuals, data protection law applies to you. The General Data Protection Regulation in Europe and the UK, and Singapore's Personal Data Protection Act, both define their scope by the nature of the data processing activity — not the organisation's tax status.
The second assumption is "we're not selling data." This misunderstands what data protection law is for. It is not primarily about commercial exploitation of personal information. It is about the right of individuals to have some control over information that belongs to them. A charity that holds a client's mental health history, housing status, and family circumstances is holding some of the most sensitive personal data that exists. The fact that it was collected for good reasons does not reduce the obligation to handle it carefully.
The third assumption is "we're too small to be noticed." This may have been practically true once. It is becoming less so. Regulators have increasingly signalled that sector and size are not mitigating factors in serious cases — and more importantly, Subject Access Requests and breach notifications are triggered by individuals, not regulators. A single unhappy client can set the process in motion.
What GDPR and PDPA Actually Require
Despite the different regulatory regimes — GDPR for organisations handling data of EU and UK residents, PDPA for organisations operating in Singapore — the two frameworks share a common architecture. If you understand one, you are most of the way to understanding the other.
A lawful basis to hold personal data
You cannot simply collect data because it is useful. The law requires a lawful basis for every category of data you hold and every purpose for which you hold it. Under both GDPR and PDPA, the main bases for a nonprofit are consent, legitimate interests, and legal obligation.
For sensitive categories of data — which explicitly include mental health information, health records, information about children, and data about criminal history — the bar is higher. GDPR requires both a lawful basis and a separate condition for processing special category data. PDPA similarly imposes stricter requirements around deemed consent and the need for explicit acknowledgement.
This matters practically for case management work. A service provider holding detailed case notes about a client's mental health, their relationship with a child at risk, or their history with the justice system needs to be able to point to its lawful basis and document it. "We needed it to provide the service" is the intuition behind legitimate interests — but it needs to be written down, not just assumed.
A privacy notice your clients can actually find
A privacy notice is the public-facing document that tells the people you work with what you collect about them, why you collect it, how long you keep it, who you share it with, and what rights they have. Under GDPR it must be provided at the point of data collection. Under PDPA there is a similar requirement to notify individuals about the purposes of collection before or at the time of collection.
Most small charities either do not have a privacy notice at all, or have one buried on an intake form that nobody reads. The notice does not need to be long, but it does need to exist, to be accurate, and to be findable.
The right to access, correct, and sometimes delete
The Subject Access Request at the opening of this piece is one expression of a cluster of individual rights that data protection law creates. Under GDPR, individuals have the right to access all data held about them, to have inaccurate data corrected, and in some circumstances to have their data deleted. PDPA provides analogous rights.
The thirty-day response timeframe under both frameworks is not aspirational. It is a legal deadline. Failing to respond — or responding incompletely — is a breach in itself.
Breach notification within defined timeframes
If personal data is compromised — whether through a cyberattack, a misfiled document, an email sent to the wrong recipient, or a lost device — you are required to assess whether the breach needs to be reported to the relevant regulator. Under GDPR, a notifiable breach must be reported within 72 hours of discovery. Under PDPA, the equivalent threshold is three calendar days.
Most small charities have no breach response procedure. This means that in the moment of discovery — which is always stressful and often confusing — there is no checklist to follow, no designated decision-maker, and no clock running consciously. The result is that reportable breaches go unreported, which compounds the legal exposure.
Retention schedules and the obligation not to keep data forever
Both frameworks require that data be kept only for as long as it is necessary for the purpose for which it was collected. This implies the existence of a retention schedule that specifies, for each category of data, how long it is kept and when it is deleted or anonymised.
For case records, this is genuinely complex. Legal considerations, safeguarding obligations, and funding requirements all affect how long records should be kept. The answer varies by jurisdiction and service type. But the question must be asked and documented. "We keep everything forever just in case" is not a defensible retention policy.
Where GDPR and PDPA Diverge
The geographic scope of GDPR is broader than many organisations realise. It applies to any organisation — anywhere in the world — that processes personal data of EU or UK residents. A Singapore-based charity running a programme that serves beneficiaries in the UK, or that receives referrals from a European partner, may find itself subject to GDPR even though it is not based in Europe.
PDPA applies to organisations operating in Singapore. For organisations subject to both, the practical approach is to comply with the stricter requirement where they differ — and the two frameworks are close enough that this is usually achievable without separate compliance tracks.
Penalty structures differ. GDPR's maximum fines are significant — up to €20 million or 4% of global annual turnover, whichever is higher — though regulators consistently exercise discretion, and small charities that can demonstrate genuine effort and prompt response have generally been treated proportionately. PDPA fines operate on a different scale. In both cases, the reputational damage and the cost of managing a breach incident typically exceed the direct financial penalty.
The Three Documents Every Nonprofit Needs
If you are reading this and realising your organisation has gaps, the most useful question is not "how do we get fully compliant this week" but "what is the most important thing to do next."
There are three foundational documents that cover most of the ground.
A privacy notice. This is the most visible gap for most organisations, and often the easiest to fix. It should cover what you collect, why, who you share it with, how long you keep it, and how individuals can exercise their rights. It should be accessible to the people you serve.
A data register. This is an internal document — sometimes called a Record of Processing Activities — that maps every category of personal data your organisation holds, the purpose for which it is held, the lawful basis, the storage location, and the retention period. Its operational value is enormous. When a Subject Access Request arrives, this document is how you know where to look. When a breach occurs, this document is how you assess what was affected.
A breach response procedure. A short document that specifies who is notified internally first, how the breach is assessed for severity, when the regulator is notified, and how affected individuals are informed. It should be written before a breach happens, not during one.
Subject Access Requests in Practice
Subject Access Requests are more common in social services contexts than in many other sectors. They often follow a relationship that has ended badly — a case closed against a client's wishes, a referral a participant disagreed with, a record a former service user suspects contains something inaccurate or unfair.
A compliant response means locating all data held about the individual across every system and paper file; redacting information that would identify third parties (a case note that mentions a family member, for example); and providing the information in a clear, accessible format within the legal timeframe.
Organisations without a data register find this extremely difficult. They may know broadly where data lives, but not comprehensively — and "comprehensively" is what the law requires. An individual who suspects their data is held somewhere and does not appear in a SAR response has grounds for a complaint.
Where to Start if You Are Not Compliant Today
The honest answer is one document at a time. Attempting full compliance in a single sprint is how organisations produce documents that nobody understands and procedures that nobody follows.
Start with the privacy notice — it is the most visible gap and affects the people you serve directly. Then build the data register — it is the most operationally useful internal document and enables everything else. Then write the breach procedure — short, practical, tested with the people who would actually need to use it.
Neither GDPR nor PDPA expects perfection. Both expect demonstrable, good-faith effort. An organisation that has documented its lawful bases, has a privacy notice, and has a breach procedure it actually follows is in a fundamentally different position — legally and practically — than one that has none of these things.
The email on a Tuesday morning does not have to be a crisis. With the right documents in place, it becomes a task: locate the data, redact the third-party information, write the response. Thirty days is enough time to do that well.
Socianote is designed for organisations with real data protection obligations — built-in audit trails, role-based access controls, retention settings, and hard-delete for right-to-erasure requests. Start a free trial →