Privacy/Procedures - Revision history

Dereckson at 11:46, 26 October 2024

2024-10-26T11:46:41Z

← Older revision		Revision as of 11:46, 26 October 2024
Line 59:		Line 59:
	* Is there a reasonable approach? Ask the requester for advice, especially if it offers to transfer to a third party where you can also contact this third party for coordination.		* Is there a reasonable approach? Ask the requester for advice, especially if it offers to transfer to a third party where you can also contact this third party for coordination.
	* Consider to open a task on DevCentral to analyze publicly the technical feasibility, notify the requester with the link.		* Consider to open a task on DevCentral to analyze publicly the technical feasibility, notify the requester with the link.
	* A nice approach could be to analyze the database structure of the application, and prepare SQL queries to get the data, then prepare a script to run the queries and format them as CSV, JSON or XML. We can then transfer securely the files to the requester: it can ~~open them~~ in Excel, transform them, transfer them to another service after that transformation. Such approach should be shared with upstream project. We don't want to maintain ~~them~~ at each database changes.		* A nice approach could be to analyze the database structure of the application, and prepare SQL queries to get the data, then prepare a script to run the queries and format them as CSV, JSON or XML. We can then transfer securely the files to the requester: the file can then be opened in a spreadsheet software like Excel and the user can transform them, transfer them to another service after that transformation. Such approach should be shared with upstream project. We don't want to maintain the scripts and queries at each database changes.
	* Third party transfer? Check quickly the privacy / security state of the destination, warn the user if there is any issue; if no issue, just notify the requester with privacy / security resources so they are aware of how their data will be handled. Request confirmation afterwards.		* Third party transfer? Check quickly the privacy / security state of the destination, warn the user if there is any issue; if no issue, just notify the requester with privacy / security resources so they are aware of how their data will be handled. Request confirmation afterwards.
	* We can reject request for technical feasibility: “After careful analysis, we don't deem this request processable by lack of technical feasibility: <explanation of the difficulties>. As such, we reject your request.”		* We can reject request for technical feasibility: “After careful analysis, we don't deem this request processable by lack of technical feasibility: <explanation of the difficulties>. As such, we reject your request.”

Dereckson at 11:42, 26 October 2024

2024-10-26T11:42:14Z

← Older revision		Revision as of 11:42, 26 October 2024
Line 32:		Line 32:
	* correct any information they believe inaccurate		* correct any information they believe inaccurate
	* complete the information they believe incomplete		* complete the information they believe incomplete
	\|\| Ask requester the precise application, the data it sees, the data it expects to see.		\|\| Ask requester the precise application, the data they sees, the data they expects to see.

	Can the user edit themself the data?		Can the user edit themself the data?
	* YES -> Answer with procedure to allow them to edit it if suitable		* YES -> Answer with procedure to allow them to edit the data if suitable
	* NO -> Open an issue on DevCentral to make the field editable by user or by a maintenance script		* NO -> Open an issue on DevCentral to make the field editable by user or by a maintenance script

Dereckson: /* Privacy requests */ +link

2024-10-26T11:38:38Z

Privacy requests: +link

← Older revision		Revision as of 11:38, 26 October 2024
Line 7:		Line 7:
	European reglementation allows data protection rights.		European reglementation allows data protection rights.

	Anyone willing to exercice it needs to fill a task on DevCentral. This form allows to do so easily and sorts is like security issue to a private space only for Nasqueron Ops SIG.		Anyone willing to exercice it needs to fill a task on DevCentral. [https://devcentral.nasqueron.org/maniphest/task/edit/form/7/ This form allows to do so easily] and sorts is like security issue to a private space only for Nasqueron Ops SIG.

	Nasqueron Ops SIG is currently responsible to manage those requests. A specific team for privacy issues can be created in the future.		Nasqueron Ops SIG is currently responsible to manage those requests. A specific team for privacy issues can be created in the future.

Dereckson at 22:20, 23 May 2023

2023-05-23T22:20:20Z

← Older revision		Revision as of 22:20, 23 May 2023
Line 1:		Line 1:
	This page documents procedures applicable to privacy.		This page documents procedures applicable to privacy.

	~~Those procedures have never been applied, as we never received any privacy request. They've been established according the ICO handbook for data portability and fee question.~~		== Privacy requests ==

	~~== Privacy requests ==~~		''Those procedures have never been applied, as we never received any privacy request. They've been established according the ICO handbook for data portability and fee question. We're encouraged to document how it went when we do them, so we can refine those procedures.''

	European reglementation allows data protection rights.		European reglementation allows data protection rights.

Dereckson: Procedures

2023-05-23T22:19:34Z

Procedures

New page

This page documents procedures applicable to privacy.

Those procedures have never been applied, as we never received any privacy request. They've been established according the ICO handbook for data portability and fee question.

== Privacy requests ==

European reglementation allows data protection rights.

Anyone willing to exercice it needs to fill a task on DevCentral. This form allows to do so easily and sorts is like security issue to a private space only for Nasqueron Ops SIG.

Nasqueron Ops SIG is currently responsible to manage those requests. A specific team for privacy issues can be created in the future.

When a request is filled, the delay for a response is '''ONE MONTH'''. We can extend the time to respond by a '''further two months''' if the request is complex or if we have received a number of requests from the individual, but we need to warn them during that month.

What can be requested and how to response?

{| class="wikitable"
|+ Privacy requests
|-
! Right !! Description of the right !! What to do?
|-
| Access || Request Nasqueron for copies of personal data || To document, as each application has its own data. Probably worthwhile to ask requester the precise applications the data has been submitted too.

If the request is manifestly unfounded or excessive, reject it: ''The request is manifestly unfounded or excessive; according the article 12(5) of the GDPR, such request may be rejected by the data controller. We've opted to reject it.''.

If an individual requests further copies of their data, and data has been modified, it's probably legit.

If not, request a fee: ''The request is is excessive, as you've already exercised your rights previously: [...]. According the article 12(5) of the GDPR, we may charge a reasonable fee for such request. We've opted to charge you a fee of 80 EUR to cover partly (one hour) of the administrative cost to prepare this request; if any, the remaining time won't be billed to keep the fee small and reasonable. If you agree, please confirm your intent and we'll give you wire transfer instructions. Once your wire transfer received, we'll process your request swiftly.''. Once this request is sent, stop the timer pending payment. Once payment is received, timer runs again to continue the 30 days delay. Use timer on DevCentral so we can track time and demonstrate the fee is reasonable for the time spent.
|-
| Rectification. || Request Nasqueron to:

* correct any information they believe inaccurate
* complete the information they believe incomplete
|| Ask requester the precise application, the data it sees, the data it expects to see.

Can the user edit themself the data?
* YES -> Answer with procedure to allow them to edit it if suitable
* NO -> Open an issue on DevCentral to make the field editable by user or by a maintenance script

Don't edit manually the database but prepare a script published to rOPS with a reference to the issue created. Log on #nasqueron-ops [server] Run ... privacy maintenance script (T... / T...) with two tasks references: the initial request, the maintenance script task if it's a new one.
|-
| Erasure. || Request Nasqueron to erase personal data, under certain conditions ||
* Ask what resource / application
* If the application has a procedure to delete account, give the link and documentation.
* "under certain conditions" = « '''Retention'''. The data is kept as long as the person wishes to keep the account on that service, and then, '''as long there is a legitimate interest to keep the data'''. ». If the person request deletion, they doesn't wish to keep the account, so only the question of legitimate interest to keep the data exists.
* We don't delete account on MediaWiki or Phabricator: PII should be anonymized instead.
* Database is read-only for privacy requests: prepare a script published to rOPS to comply with the request
|-
| Restrict processing. || Request Nasqueron to restrict processing of personal data, under certain conditions || See below, but ask how we CAN and what the restriction is.
|-
| Object to processing. || Object Nasqueron from processing of personal data, under certain conditions || Request how we CANNOT process the request if it's not clear enough on the request.

Then, do we do that?
* YES -> Create a public task on DevCentral to discuss the case (anonymously) so we can amend the policies and see if it's suitable. Notify the requester of the link to the public task.
* NO -> Reply “Nasqueron only process your personal data as stated in our policy. As such we doesn't process your data as indicated in your request”.
|-
| Data portability. || Request Nasqueron to transfer the data to another organisation or to the person ||
* Simplest case is in-app portability: some apps allow to export data, e.g. Mastodon for use elsewhere or for reference
* Is there a reasonable approach? Ask the requester for advice, especially if it offers to transfer to a third party where you can also contact this third party for coordination.
* Consider to open a task on DevCentral to analyze publicly the technical feasibility, notify the requester with the link.
* A nice approach could be to analyze the database structure of the application, and prepare SQL queries to get the data, then prepare a script to run the queries and format them as CSV, JSON or XML. We can then transfer securely the files to the requester: it can open them in Excel, transform them, transfer them to another service after that transformation. Such approach should be shared with upstream project. We don't want to maintain them at each database changes.
* Third party transfer? Check quickly the privacy / security state of the destination, warn the user if there is any issue; if no issue, just notify the requester with privacy / security resources so they are aware of how their data will be handled. Request confirmation afterwards.
* We can reject request for technical feasibility: “After careful analysis, we don't deem this request processable by lack of technical feasibility: <explanation of the difficulties>. As such, we reject your request.”
* We can reject as long as we don't put in place any legal/technical/financial obstacle which slow down or prevent the transmission of the personal data to the individual, or to another organisation -> we aren't responsible of the lack of data transfer in a third party application, we are responsible if we put the obstacles ourselves (e.g. block a portability technical feature already in an app), so no stress, normally we don't do that, those requests can be safely rejected.
|}

For all rejections / fee request, we need to include the following information:
* the reasons to not take action
* the right of the requester to make a complaint to the autorité de protection des données:
** first, by requesting the authority to intervene and act for mediation at https://www.autoriteprotectiondonnees.be/citoyen/agir/demander-une-mediation or another supervisory authority
** secondly, if the mediation doesn't reach a solution suitable by all parties, to make a complaint at https://www.autoriteprotectiondonnees.be/citoyen/agir/introduire-une-plainte or another supervisory authority
** thirdly, their ability to seek to enforce this right through a judicial remedy.