Governance of Processing Personal Data

This article defines rules and limits on the processing of personal data as they apply for participants in the privact framework.

Conditions for accessing, processing and transferral of personal data

  • Any entity can only process personal data with the user’s consent. The user is able to withdraw this consent at any time.
  • Processing of personal data has to follow the principles of the GDPR and other legal regulations. Note that the definition of personal data of privact is broader than that of the these legal regulations.
  • Anonymized transferred data must not be de-anonymizable. For transferal of anonymized data, initial consent by user is sufficient and is not required for each transaction. The user can revoke granted permissions at any time.
  • Services may transfer plain user data. They are forced to limit this to the bare minimum of data which is needed to fulfill the intended service. As default, all calculations on plain user data are performed on the users device.
  • Transferal of plain personal data to a service provider or to third parties requires additional consent from the user for each transfer.
  • Personal data that was transferred must only be stored for a long as is serves the intended purpose of the provided service.
  • Transferal of personal data to third parties is forbidden.
  • Once the user unregisters from a service. Personal data stored with the service provider may only be kept if it is required under the law. Otherwise, personal data has to be deleted.
  • Writing, updating and deletion of personal data in the user’s database by a service requires permission by the user (usually granted at installation time).

Control

privact has the right to investigate any complaints about abuse or violations of the above terms. The service provider has to accept a whistleblower system, which guarantees employees of the service provider to give notice of such issues to privact without fear of retribution. If the investigation turns out to be for just cause, the cost of the investigation have to be born by the service provider.

privact has the right to audit the service provider, in particular its processes, software and handling of user data on a regular basis. The service provider has to bear the costs of this audit.

Violations

Violations can at privact’s discretion lead to actions against the service provider:

  • Violations will be made transparent to the users.
  • For minor cases, it is enough the ensure compliance is achieved within a set time frame.
  • In severe cases, privact may .ban the service from the privact ecosystem completely
  • In cases where the violation has generated incomee, set a fine, which is punative, that is, the fine has to be higher than the generated income. (A predefined system is needed, as the service provider has to contractually agree to this fine to make it bulletproof).

Question:
A user unregisters from a service. What should happen to data written to the user’s personal database? It is her data, so the service has no right anymore to deleted it. On the other hand, that may clutter the database with useless configurational data. But allowing to deleted all fields that the service wrote, may remove important fields, that should be kept. Probably some kind of marker for personal data is required, that indicats, this data is usefull to this service only and when it is gone, the user can opt to delete it. Opinions?

Yes, it is her data and it should not be deleted by default. Perhaps she wants to use that service later again or change to a competing service? She wants her data for that.

On the other hand, we need to maintain the data base schema anyhow. Cleaning up should be part of this maintenance process and be supported by the NGO. However we do this in detail…

Well, if we agree on the data not to be deleted by default (best practice would be, ask the user at time of uninstall), we need some field in the database to represent the origin or persistence of the data. We earlier the have that in the spec, the less hassle later on (migration…).

We will need this anyhow, as services need to able to access the data they wrote.

1 Like