GDPR for Social Enterprises and Community Interest Companies: A Practical Compliance Guide
Social enterprises and Community Interest Companies (CICs) occupy a unique space. You exist to serve communities, often the most vulnerable ones — people experiencing homelessness, addiction, mental health crises, or disability. That mission is your strength. But it also means you handle some of the most sensitive personal data that GDPR recognises: special category data under Article 9.
This guide is written for social enterprise founders and CIC directors who want to get compliance right — not because a regulator is watching, but because the people you serve deserve it.
Why Social Enterprises Are Different Under GDPR
Most GDPR guidance is written for commercial businesses collecting customer email addresses and purchase histories. Your situation is different in several important ways.
You work with Article 9 special category data. Mental health conditions, disability status, addiction histories, immigration status — these are not incidental to your work; they are central to it. Article 9 imposes stricter obligations on this data than standard personal information. You need not just a lawful basis under Article 6, but also a specific condition under Article 9(2).
Your data subjects are often in vulnerable circumstances. A survivor accessing your domestic abuse service, a rough sleeper using your outreach programme, a young person receiving mental health support — these individuals need robust data protection precisely because they are at heightened risk. Breaches can have serious real-world consequences beyond mere inconvenience.
You report to funders, commissioners, and trustees. Grant conditions often require outcomes data, which creates tension between your funders' reporting needs and your service users' right to confidentiality.
You often operate across multiple legal structures. Many social enterprises have a trading arm and a charitable arm, each processing data in different ways.
Lawful Basis Mapping for Common Programmes
You need a lawful basis for every type of personal data you process. Here is how the main Article 6 bases typically map onto social enterprise activities.
Contract (Article 6(1)(b))
Applies when you are processing data to fulfil a contract with the individual. Examples:
- Paid employment support services where the service user has a signed agreement with you
- Social enterprise trading activity where a customer has purchased goods or services
- Supported housing arrangements with a tenancy or licence agreement
Contract is clean and straightforward for commercial activity. It does not apply to free services.
Explicit Consent (Article 6(1)(a) + Article 9(2)(a))
For special category data in voluntary programmes, explicit consent is often the most appropriate basis. This means:
- A clear, granular consent form written in plain English
- Separate consent for each distinct use of data (support planning, sharing with partner organisations, referrals)
- The ability to withdraw consent at any time without detriment to receiving support
- Records of what consent was given, when, and in what form
Explicit consent is meaningful only when it is genuinely freely given. If someone needs your service and withholding consent would deny them access, consent is not the right basis.
Legitimate Interest (Article 6(1)(f))
Legitimate interest is available to social enterprises but requires a three-part test: you have a legitimate interest, processing is necessary to achieve it, and it does not override the individual's interests or rights. Social enterprise examples include:
- Community outcomes reporting to demonstrate impact (aggregated, not individual-level)
- Safeguarding activities where you have a legal or moral duty to act
- Internal quality assurance and service improvement
Legitimate interest cannot be used for special category data on its own — you still need an Article 9(2) condition alongside it.
Legal Obligation (Article 6(1)(c))
If you are required by law to process data — safeguarding referrals under the Children Act, reporting to statutory funders, mandatory DBS checks for staff — legal obligation is your basis. Document the specific legal provision.
Vital Interests (Article 6(1)(d))
If someone is unconscious or otherwise unable to consent, and processing their data is necessary to protect their life or someone else's, vital interests applies. This is a narrow basis for emergency situations, not routine processing.
Beneficiary Data and Confidentiality
Service user trust is the foundation of your work. GDPR gives you a framework to honour that trust formally.
Create a clear data map. Document what data you hold on each service user, why you hold it, who can access it, and how long you retain it. This is not just a compliance exercise — it is a way of ensuring that sensitive information about the people you serve is genuinely protected.
Apply the minimum necessary principle. Collect only what you need for the specific programme. A community fridge does not need to know a visitor's mental health history. An addiction recovery programme may need it, but should not collect it speculatively.
Control internal access. Not all staff need access to all records. A receptionist does not need to see a service user's mental health assessment. Use role-based access controls in your case management systems.
Separate operational records from outcomes data. Your service user files and your outcomes reporting should be distinct. Anonymise or pseudonymise data before it goes into impact reports.
Grant Funding and Data Sharing with Funders
Funders routinely require outcomes data. Many social enterprises have signed grant conditions without fully considering the data protection implications.
Anonymised outcomes reporting is the default. In most cases, you can satisfy funder reporting requirements without sharing personal data. Numbers, percentages, and anonymised case studies protect your service users while demonstrating impact.
Aggregation thresholds matter. If your funder requires a breakdown by gender and disability status for a cohort of eight people, it may be possible to re-identify individuals. Apply statistical disclosure controls — suppress or round cells below a certain threshold.
Check your grant agreements carefully. If a funder's contract requires you to share identifiable personal data, you need a lawful basis for that sharing. This is typically legal obligation (if it is a statutory funder with a legal power to require the data) or the service user's explicit consent (if it is a charitable or trust funder).
Data processing agreements. If your funder is processing personal data you share on your behalf — for example, running a shared database — they are acting as a data processor and you need a formal Data Processing Agreement. If they are using the data for their own purposes, they are a separate controller and you each bear independent compliance obligations.
Volunteer Data Handling
Volunteers are workers for GDPR purposes. You need a lawful basis to process their data.
- Contract applies once a volunteer agreement is signed, for processing necessary to manage that relationship
- Legal obligation covers mandatory DBS checks, right to work verification, and health and safety records
- Legitimate interest can cover reasonable management activities
If your volunteer work involves service users, consider whether volunteers need access to service user records. Many do not. Where they do, volunteers should be subject to the same confidentiality obligations as staff, documented in their volunteer agreement.
Retain volunteer records for a reasonable period after they leave — typically six years, to cover any legal claims — then delete.
Service User DSARs and the Right to Erasure
Service users have the right to request a copy of all personal data you hold about them (a Subject Access Request or SAR). They also have the right to request erasure in certain circumstances.
SAR responses in complex histories. A service user with a long history of involvement with your organisation may have records spanning years, multiple workers, and sensitive third-party information. You have one month to respond. Plan for this: know where your data lives, who can compile it, and how to redact third-party information before disclosure.
Right to erasure is not absolute. You can refuse erasure where you have a legal obligation to retain the data, where the data is necessary for the establishment or defence of legal claims, or where you are processing for archiving in the public interest. Document your retention decisions and your reasons for refusing erasure requests.
Safeguarding records have special status. Records created in the context of a safeguarding concern may be retained beyond the individual's request for erasure. This is a recognised limitation on the right to erasure under UK GDPR. However, you should retain only what is necessary and apply strict access controls.
Trading Arm vs. Charitable Arm Data Flows
Many CICs and social enterprises operate with both a trading arm (selling goods or services commercially) and a programme or charitable arm (delivering social impact work). These often share staff, systems, and premises — but they should not share data indiscriminately.
Treat them as separate controllers unless they are genuinely joint controllers. Customers of your social enterprise café are not automatically eligible to be contacted by your mental health outreach programme. Their data was collected for one purpose; using it for another requires either consent or a clear legitimate interest assessment.
Document internal data sharing agreements. When the trading arm and programme arm do share data — for example, a shared HR system for employees who work across both — document why, on what basis, and with what access controls.
Separate privacy notices. Your café's privacy notice and your supported housing programme's privacy notice should be distinct documents, reflecting different data flows and different processing activities.
Partner Organisation Data Sharing
Social enterprises rarely work alone. Referral networks, multi-agency partnerships, housing associations, NHS trusts, local authorities — data flows across organisational boundaries constantly.
Establish the controller relationship first. Are you and your partner joint controllers (making joint decisions about data)? Or are you each independent controllers receiving a referral? The answer determines what agreements you need.
Referral agreements should address data protection. Any referral pathway should document what personal data is shared, on what basis, and what the receiving organisation does with it. A one-page information sharing agreement is better than no agreement.
NHS and local authority partnerships. Public authorities often have statutory powers to process data. If you are receiving referrals from a local authority, their legal basis under public task (Article 6(1)(e)) does not automatically flow to you. You need your own basis.
Inform service users. Your privacy notice should explain that data may be shared with named partner organisations, and for what purpose. Where referral is with consent, the consent form should identify the receiving organisation.
Compliance Checklist for Social Enterprises
Use this checklist to assess your current position:
Foundations
- [ ] Privacy notice published and accessible at point of data collection
- [ ] Data map (Record of Processing Activities) completed and kept up to date
- [ ] Lawful bases documented for each processing activity
- [ ] Article 9(2) conditions documented for all special category data
Service User Data
- [ ] Consent forms are clear, granular, and evidence genuine free choice
- [ ] Service users are informed of their rights at point of engagement
- [ ] SAR response process documented and tested
- [ ] Retention schedule set for service user records, including special category data
Funder and Partner Data Sharing
- [ ] Grant agreements reviewed for data sharing requirements
- [ ] Outcomes data anonymised before sharing with funders
- [ ] Data Processing Agreements in place where funders act as processors
- [ ] Information sharing agreements in place with key referral partners
Staff and Volunteers
- [ ] Staff privacy notice issued at point of recruitment
- [ ] Volunteer agreement includes data protection and confidentiality obligations
- [ ] DBS and right-to-work records stored securely with limited access
- [ ] Staff trained on data protection and confidentiality
Technical and Organisational
- [ ] Role-based access controls in place for case management systems
- [ ] Incident response process documented (72-hour ICO notification deadline)
- [ ] Data Protection Impact Assessment conducted for any high-risk processing
- [ ] Named person responsible for data protection (not necessarily a formal DPO)
Getting Started
GDPR compliance for a social enterprise does not require a legal team. It requires clear thinking about the data you hold, who it relates to, why you hold it, and what your obligations are to the people who entrusted it to you.
Start with a scan of your website — it is often where the most visible compliance gaps live, from analytics tools running without consent to contact forms without a privacy notice.
Run a free compliance scan at https://app.custodia-privacy.com/scan. Custodia identifies what data your site is collecting, flags gaps, and gives you a plain-English report to work from. No signup required.
This post provides general information about GDPR compliance for social enterprises and CICs. It does not constitute legal advice. For advice specific to your organisation's structure and activities, consult a qualified data protection practitioner or the ICO's guidance for charities and voluntary organisations.
Top comments (0)