GDPR for EU Project Platforms: Consent, Newsletters and Participant Data Across Borders

GDPR for EU project platforms means knowing what personal data you collect, why you collect it, who can access it, how long you keep it and which partners or providers process it. Consent matters, but it is only one part of the pattern. A coordinator should run the platform like an operated service: map the data, write plain notices, collect clear permissions where needed, sign provider agreements and keep evidence of decisions.

Start with a data map, not a banner

A cookie banner does not make a project platform compliant. Start with the system itself. List each place where a person gives data or appears in data: the public website, event registration form, newsletter signup, survey, contact form, member area, community directory, discussion space, helpdesk inbox and analytics tool.

For each place, write down:

• What data is collected, such as name, email, organisation, country, role, access logs, comments, photo, video or survey answer.
• Why the project needs it, such as event access, reporting, community support, dissemination or evaluation.
• Who sees it, such as the coordinator, work package lead, event host, platform provider or all logged-in members.
• How long it stays in the platform after the activity ends.
• How a participant can ask for access, correction, export or deletion.

This map should be short enough for the project team to use. It should also be detailed enough for a new partner to understand the platform before they upload a contact list or publish event photos.

Consent: photos, events, surveys and member areas

Consent should be specific, recorded and easy to refuse. Do not hide several permissions inside one checkbox. A person can register for an event without agreeing to a newsletter. A person can join a workshop without agreeing that their portrait will be used in future promotion.

For photos and video, separate practical recording from promotional reuse. At an event, the team may need photos for documentation or reporting. Public use is different. Good event forms ask for permission in plain language, then give people a visible way to opt out on site, such as a badge or registration note for the photographer. Group shots are still personal data when people are identifiable.

For surveys, collect the least data that answers the evaluation question. If you do not need a name, do not ask for it. If the survey asks sensitive questions, explain who will read raw answers and how results will be aggregated.

For member areas, the key issue is visibility. Tell users which profile fields are private, which fields are visible to other members and which fields may appear in public outputs. Default to limited visibility. Let members edit their own profile, leave groups and request deletion without sending a chain of emails.

Newsletters and mailing lists

Project newsletters often fail because they mix project operations with dissemination. Operational emails are messages a participant reasonably needs, such as event joining instructions, agenda changes, platform access, survey follow-up for a workshop they attended or partner coordination. Newsletter emails are promotional or informational updates sent over time. Treat them separately.

A clean mailing list pattern uses a dedicated signup form, a clear description of content, a confirmation email where practical and an unsubscribe link in every mailing. Do not add every event registrant to the general newsletter by default. Offer the newsletter during registration, but keep it optional and separate from event participation.

Partner contact lists need care. A partner should not upload its old stakeholder spreadsheet into a shared tool unless it can explain where those contacts came from and why the project may email them. If partners promote a project through their own lists, that can be safer than pooling contacts in one shared account.

Keep the mailing tool documented in the data map. Include the provider, admin users, export rules, suppression list handling and the person who answers privacy requests.

Partners, providers and cross-border work

EU cooperation projects involve many organisations, and platforms make that visible. A coordinator should define who is controller for which activity, who acts on whose instructions and which providers process data for the project. This is not only a legal label. It decides who answers a participant, who approves exports and who may invite new administrators.

With your platform provider, sign a data processing agreement before launch. It should cover hosting, support access, backups, sub-processors, incident handling, deletion at the end of service and instructions from the coordinator. If the provider operates your website, member area, event tools or AI assistant, support access is also personal data access.

Across borders, use role-based access. A partner running an event may need registrants for that event. They do not automatically need every contact, survey answer or private member profile. Shared drives and spreadsheets are common risk points, because copies escape the platform controls.

In the proposal ethics section, write practical commitments instead of generic GDPR text:

• The consortium will maintain a data map for the website, events, surveys and member area.
• Consent will be collected separately for newsletters, photos and optional community visibility.
• Participant data will be shared with partners on a need-to-access basis.
• Provider agreements will be in place before personal data is processed.
• Participants will receive clear contact points for privacy requests.

If you need a build partner for this, StrandsUnited designs and operates EU project platforms with these controls built into the member area, knowledge base and communication workflows. You can see the type of systems we build on our platforms page.

Where this comes from

This checklist comes from our work operating community and knowledge platforms for EU cooperation teams, including Impactful and private member areas. We also maintain our consortium graph and grant intelligence engine, which keeps us close to how multi-partner projects really move data between coordinators, work packages and public outputs. Our usual advice is simple: before launch, run one privacy review with the coordinator, platform provider and the partner who manages dissemination. Then turn the review into platform settings, consent text and admin rules that the project team can actually follow.