Data privacy policy statement compliance

Target release
Epic
Document status	DRAFT
Document owner	Paul Smits
Designer
Developers
QA

Goals

Make the OMS compliant with AEGEE-Europe's Data Privacy Policy Statement and the General Data Protection Regulation of the EU.
Ensure effective collection of statistics
Protecting privacy of members through consent and effective shielding

Background and strategic fit

AEGEE-Europe has a Data Privacy Policy Statement which purpose it is to secure the right to privacy of AEGEE members, with regard to: the gathering and automatic processing of personal data relating to them, and generally information and all relevant data about the Association, its work and its members. In the present day environment of GDPR oversight and privacy sensitive digital world, our systems should comply with our internal regulations as well as the legal framework of applicable legislation. Additionally, AEGEE-Europe has certain interest in statistics about AEGEE-Members that need to be collected while respecting this privacy.

Personal data undergoing automatic processing shall be:
1) obtained and processed fairly and lawfully;
2) stored for specified and legitimate purposes and not used in a way incompatible with those purposes;
3) adequate, relevant and not excessive in relation to the purposes for which they are stored;
4) accurate and, where necessary, kept up to date; keeping in mind the obligation of individual members to update their data.
5) preserved in a form which permits identification of the data subjects for no longer than is required for the purpose for which those data are stored.

Certain personal data may be published online in a system open to AEGEE members only in case the member gives its consent.

Assumptions

OMS project will replace intranet and thus become the primary tool for automatic processing of personal data of all AEGEE members, as well as most events and activities.
OMS project will be the central membership database of AEGEE-Europe and most AEGEE locals.
OMS can provide adequate authentication for different types of users
Adequate security measures are applied relating to the process of storage and automatic data processing
Permission system of OMS allows AEGEE-Europe to restrict the use of personal data of each AEGEE member only for those purposes as agreed on by the Agora.

Requirements

#	Title	User Story	Importance	Notes
1	Mandatory collection of members' data.	When a user creates an account, the system should require the following information for communication and statistics purposes: real name/surname; email; AEGEE local/contact; date of birth (year+exact date) nationality; field of studies; gender. If a user fails to fill in name, email, exact date of birth, their account can exist but needs to be suspended. If a user fails to fill in the AEGEE local, year of birth, nationality, field of studies, gender, the account cannot be created. If the user attempts to empty these fields, the change shall not be saved.	Must have	Straight from DPPS Saving local might be tricky, because of the architecture. Maybe we can just add their local body/circle membership to their profile and keep track of their local membership history somehow? (up to 5 years)
2	Optional collection of members' data	The user can decide to provide additional information, such as home address or social network/messenger identifiers. The Comité Directeur may specify further which optional data fields are desired.	Must have	Needs CD opinion, or just whatever feels cool
3	Processing deletions	When a data subject wants to delete their account, or withdraws their permission to store its personal data, they are suspended. AEGEE local, year of birth, nationality, field of studies, and gender are not deleted from their anonamised profile.	Must have
4	Filtered permissions for personal data visibility	AEGEE officials (CD,commissioners) do not need insights into nationality, field of studies or gender. AEGEE officials need only see contact information and information that the data subject gave permission for publishing this information internally. Local boards need only insights into contact	Good to have	Superadmins and certain processing responsibles may need access to ensure functioning of the data and validity of the data. Local boards need
5	User consent (membership)	User needs to see different check-boxes when creating or updating their account. Users should be able to give consent for: To adhere to provisions the statutes of the local and the convention d'adhesion and to agree with the provisions of the data privacy policy of AEGEE-Europe and any system-specific privacy policy (mandatory) The collection of their personal data for the purposes of processing their membership registration (mandatory) Email preferences subscribe to ML (announce, aegeenews, aegee,etc) (optional) agree to receive up to ten commercial messages a year (optional, opt-out) Internal publication of certain types of personal information (optional). Be it Contact details only Contact details and certain personal information Local publication of certain types of personal information (optional, opt-out). Be it Contact details only Contact details and certain personal information Local-defined additional consents (optional)	Partly must have Must Must Good to have Good to have Nice to have Bonus	Consent can only be given if a user is logged-in (with their own credentials) Consent meta-info needs to be stored for future reference. 3b is formally a must-have, but only makes sense if it will actually be implemented by the CD. Local consent, especially related to internal publication opt-out, would be a nice extra, but also requires the possibility to shield local members from other local members.
6	Finishing accounts on first logon	If it is possible for a user to be generated without their own doing (e.g. by a board member or through some API), the user should be asked for consent and missing information on their first log-on.	Must have?
7	User consent (events)	User needs to see different check-boxes when creating or updating their account. Users should be able to give consent for: Sharing contact and membership information with the organisers (mandatory) Sharing any other information with the organisers? (if any?)(optional) Standard "pictures for promotional purposes consent" (optional, opt-out) Organiser-specified additional consents (optional)	Partly must have must nice? nice bonus	Consent can only be given if a user is logged-in (with their own credentials) Consent meta-info needs to be stored for future reference. Not sure what to do with sharing year of birth, nationality, gender. We need a DPC opinion on this matter.
8	Internal visibility of AEGEE members to AEGEE members	All AEGEE members (Members of AEGEE Antennae and Contact Antennae) can be allowed to see other members' information, of users that have given their consent to be internally visible. What is visible for others should depend on the consent given under 5.3.	Good to have	"Certain personal data may be published online in a system open to AEGEE members only in case the data subject gives its consent."
9	Export all data belonging to one data subject	A data subject (AEGEE member) has the right to request all its personal data that is stored. It would be nice to have a feature to extract that information by the member themselves, as well as a possibility to extract such information by an official (e.g. CD/DPC)	Nice to have	We must have a possibility to gather this information. So without a feature for it, there should still be a relatively easy way to compile a machine-readable overview of personal data the OMS has on a person.
10	Contracts of confidentiality.	A regular administrator wants to give additional rights to another person. In order to activate those rights, they have to upload a signed contract of confidentiality before they are granted access to the databases. Alternatively, the person has to sign an equivalent of such a contract in the system before the rights are activated. It should be possible for CD and other privileged organs to later review the agreement and its meta-data.	Nice to have	The contract is a must-have. There HAS TO BE A CONTRACT BEFORE a person gets any privileges. Uploading requirement is a nice-to-have. Local boards and local officials are except from this requirement for the administration of their own local. Although we could at some point offer them functionality to implement the same, but this depends on the local work-flow. Some body, e.g. medcom, dpc, jc, cd, should maybe validate the upload or online agreement within a certain time-frame
11	Automatic account reminders	Our members have a responsibility to keep their data up to date and make the needed changes when necessary. It would be pretty cool if we could send out an automated message to all active accounts to ask them to review their membership data. This could e.g. be a yearly reminder in September	Bonus	Watch out for phishing risk if we send out automated emails with links in it to login pages.
12	Privacy policy	Any platform-specific privacy policy needs to be readable to the user. There also should be a human readable version of the DPPS and applicable privacy policy, and a link to the entire DPPS.	Must-have	User can already read simple legal info. Simple legal info needs to be adjusted to DPPS and complex info needs to be added.

User interaction and design

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Question	Outcome
Can everything be implemented in the OMS design?
What are the main challenges for implementation?
Do we need to propose regulatory changes to match the OMS design?
How much of these services (opt-ins etc.) do we offer to locals?
(DPC/CD/EQAC/MedCom) What info should we send to event organisers?
(CD) What info do you want to additionally gather from members who are willing to give it to ya?

Helpdesk