Privacy/Procedures: Difference between revisions

From Nasqueron Agora
(Procedures)
 
No edit summary
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.

Revision as of 22:20, 23 May 2023

This page documents procedures applicable to privacy.

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.

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?

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: