How UK GDPR applies to community platforms and subject access requests

What to take away

How UK GDPR applies to a community platform's processing

A community platform processes personal data every time someone registers, posts, reacts or is moderated. UK GDPR applies to that processing when the controller is established in the UK, or when the platform targets UK members. The platform itself may be a controller, a processor, or both, depending on the service it provides.

The ICO publishes detailed guidance on these core obligations, and it is the starting point for any community software review. UK GDPR guidance and resources covers the principles, lawful bases and individual rights that apply to member data.

Community platforms often hold more categories of data than buyers expect. A typical instance stores account details, posts, private messages and moderation notes. Device data and payment records usually sit alongside them. Each category needs a lawful basis and a retention rule.

Special category data can appear in community content. Health, ethnicity, religion and political opinions may be shared in posts or support forums. That raises the risk level and may require an appropriate policy document and a condition for processing under Article 9.

Children's data is another common issue. If a community is likely to be accessed by under-18s, the ICO's age-appropriate design expectations apply, and the platform should have age assurance and default privacy settings.

UK GDPR sets out seven data protection principles in Article 5. They begin with lawfulness, fairness and transparency. Purpose limitation, data minimisation and accuracy come next. Storage limitation, integrity and confidentiality, and accountability complete the set. The ICO's Data protection principles - guidance and resources | ICO explains how these apply in practice.

For a community platform, storage limitation is the principle most often breached. Old posts and moderation logs sit in the database for years because no one set a deletion rule. That is a governance failure, not a technical one.

Data minimisation matters at sign-up. Collecting a full postal address when a display name and email would do is hard to justify. Each field should be tied to a purpose the member would recognise.

Transparency is usually handled through a privacy notice, but the notice must match what the platform actually does. If analytics or profiling is switched on, the notice has to say so in wording members can understand.

The platform's role matters for contracts and liability. A supplier that only hosts data on instruction is a processor. A supplier that decides why and how data is used, for example by running its own analytics or marketing, is a controller for that activity.

Mixed roles are common. The same vendor may be a processor for the community's content and a controller for its own billing and fraud prevention. The contract should separate those roles clearly.

A UK data protection review should start with a purpose map. That means listing each processing activity, the data it uses, the lawful basis, the recipients and the retention period. Our guide to UK data protection sets out that mapping approach in more detail.

Data processing agreements between controller and processor

A data processing agreement is required whenever a processor handles personal data on a controller's behalf. Article 28 of UK GDPR sets out what the agreement must contain. The ICO's Controllers and processors | ICO guidance explains the distinction and the contract terms.

The agreement must state the subject matter and duration of the processing, plus its nature and purpose. It must name the type of personal data and the categories of data subjects. It must also set out the controller's obligations and the processor's instructions.

The processor must only act on documented instructions, ensure staff confidentiality, assist with individual rights, and help with breach notification and impact assessments. Sub-processors need written authorisation.

The processor must delete or return data at the end of the contract, and provide audit information. These clauses are not optional. A community platform that cannot show them is a compliance risk.

International transfers need attention. If member data leaves the UK, the agreement should identify the transfer mechanism, such as the UK International Data Transfer Agreement or the UK Addendum to the EU standard contractual clauses.

Sub-processors are a common gap. A community platform may use a cloud host, an email provider and an analytics tool. Each one is a sub-processor, and each needs to be listed and approved.

The agreement should also cover security measures, breach notification timelines and liability. The controller remains responsible to members and the ICO, even when a processor causes the breach.

Buyers should not accept a supplier's standard terms without checking the processing schedule. The schedule should name the data categories and the retention periods, not just repeat the regulation.

Contract clauses often decide who really controls moderation data and member exports. Our article on contract clauses looks at the commercial terms that shape operational control.

A practical test is to ask the supplier three questions: what data do you process as a processor, what do you process as a controller, and where does it go? If the answers are vague, the agreement is not ready.

Retention schedules for posts, moderation logs and member records

A retention schedule is a document that states how long each category of personal data is kept and what happens at the end of that period. UK GDPR does not set fixed retention periods. The controller must justify them.

Community platforms need separate rules for different records. Member account data, posts, private messages, moderation logs and payment records each carry a different risk. Reports and appeals also need their own rule.

A workable retention schedule for a UK community platform might look like this:

These periods are examples, not legal requirements. Each controller should set its own and record the reasoning. The ICO's data protection principles guidance is the reference point for storage limitation.

Deletion must reach backups, caches and search indexes. A post removed from the live site but still present in a backup is still personal data. The retention schedule should say how backup deletion works and on what cycle.

Moderation logs deserve special attention. They often contain free-text notes about member behaviour, which may include health or safeguarding details. Access should be restricted and the retention period kept short.

Member records should be exportable. If a member asks for a copy of their data, the platform must be able to produce it in a structured format. That requirement sits alongside the retention rules.

Retention schedules should be reviewed at least annually, and whenever the platform adds a new feature. A new direct messaging tool or AI moderation feature changes the data map.

Handling a subject access request under ICO guidance

A subject access request is a request from an individual for a copy of their personal data, plus other information such as the purposes of processing and the recipients. It is a right under Article 15 of UK GDPR.

The ICO's Subject access requests (also known as SARs or right of access) | ICO guidance sets out how to recognise, verify and respond to a request. The Right of access | ICO page covers the detail of the right itself.

A request does not have to use the words subject access request. It can be made verbally, by email or through a social media message. It can be made to any member of staff, not just the data protection officer.

Community managers are often the first to see a request. They should forward it to the privacy team the same day and log it. Delay is the most common cause of missed deadlines.

Here are the steps to follow for a community platform subject access request:

The one-month deadline can be extended by two further months for complex requests, but the controller must tell the requester within the first month and explain why.

There is no fee in most cases. A reasonable fee can be charged for manifestly unfounded or excessive requests, or for further copies, but the bar is high.

Exemptions are narrow. Legal privilege, crime prevention and some confidentiality rules may apply. Blanket refusals are not acceptable, and each redaction should be justified.

Community platforms often hold data in third-party tools. The processor must assist the controller with the request, which is why the data processing agreement includes that duty.

A refused or mishandled request can lead to a complaint to the ICO. The ICO can issue reprimands, enforcement notices and fines. It also publishes guidance and decision notices that show how it interprets the rules.

Lawful basis and individual rights for community members

Every processing activity needs a lawful basis. For community platforms, the common bases are consent, contract, legitimate interests and legal obligation.

Consent works for marketing emails and optional analytics. It must be freely given, specific, informed and unambiguous, and as easy to withdraw as to give.

Contract is the basis for running the account and delivering the service. It covers account creation, posting and moderation needed to enforce the terms.

Legitimate interests can cover fraud prevention, safety and some analytics, but a legitimate interests assessment is needed. The assessment must balance the community's interest against the member's rights and expectations.

Legal obligation covers tax, VAT and some safety reporting. HMRC requires certain records to be kept, which is why payment data sits outside the general retention rule.

Individual rights include access, rectification, erasure, restriction and portability. Objection and rights around automated decision-making also apply. Not all rights apply to all processing.

Erasure is the right most often raised by community members. A member may ask for their posts to be deleted. The controller should balance that against freedom of expression and the rights of others, and record the decision.

Rectification matters when a moderation log contains an inaccurate note. Members can ask for corrections, and the platform should have a route to review and update records.

Objection can apply to profiling and direct marketing. If the platform uses member data to target promotions, an objection must be honoured.

Automated moderation is increasingly common. If a decision has a legal or similarly significant effect, members have rights around it. Most moderation decisions do not meet that threshold, but the platform should still offer a human review.

A privacy notice should list the rights and explain how to exercise them. It should also name the ICO as the supervisory authority for complaints.

Documenting accountability and governance for community software

Accountability is a principle in its own right. Controllers must be able to demonstrate compliance, not just claim it. For community software, that means records, policies and evidence.

The starting point is a record of processing activities. It lists each processing purpose, the data categories, the recipients, the retention period and the security measures. Article 30 sets out the detail.

A data protection impact assessment is required for high-risk processing. Large-scale profiling, systematic monitoring and processing of special category data can all trigger one. A community platform with AI moderation and health forums is likely to need a DPIA.

A data protection officer may be required for public authorities and for large-scale monitoring. Even when not required, a named privacy lead helps.

Staff training should cover subject access requests, breach reporting and moderation data handling. Community managers and moderators are often the people who create the records, so they need to understand the rules.

Breach response is part of accountability. A personal data breach must be reported to the ICO within 72 hours if it is likely to result in a risk to rights and freedoms. Members must be told when the risk is high.

Vendor management is part of the same picture. Our guide to vendor due diligence covers the checks that sit alongside the data processing agreement.

Here is a checklist for community platform accountability:

Governance should also cover the Online Safety Act, which Ofcom regulates. Safety duties and data protection duties overlap, and the same records often serve both.

BSI standards for online communities can provide a framework for moderation and records. They are not law, but they help show that the platform follows recognised practice.

The Institute of Community Management and the UK Community Management Association provide training and networks for community professionals. Data protection should be part of that professional development.

Finally, accountability is easier to demonstrate when the evidence is stored in one place. A compliance folder with contracts, schedules, DPIAs and training records turns a vague claim into a defensible position.

Common questions