Register of information treatments
Draft version.
Purpose
Step 1: This feature aims to carry thorough a register of the information treatment. This functionality is an add-on which can be used by a standard user. The functionality is available by risk analysis, so it’s not common for all the risk analysis for one client.
Step 2: The final goal is to facilitate the realisation of a DPIA and a link between the register and the objects involved in the DPIA has to be made.
Front End Specifications
It's important that the UI is friendly to avoid errors. The UI has to provide a lot of tooltips to help users to fill his register.
images/cdc_registre_layout.PNG
- The list of all treatments will be accessible via the contextual menu of MONARC.
- The list of treatment is managed simply like the tab of a web browser, click on the + to add a treatment.
- In this part, there is all the information concerning the controller. All the information which has to be here is described in the back end specifications.
- In this part, there is all the information concerning the processor. All the information which has to be here is described in the back end specifications.
The interface to encode will be as usual friendly, and will take account all the optional fields.
MONARC will propose from the second treatment to reuse the information already processed.
Back End Specifications
Prerequisites
No new development has to be done before to have the register.
But to have an interaction with the objects in the risk analysis and to avoid a double charge of work, the modification concerning the database and especially the multilingualism one in MonarcAPPFO#7 has to be done. A uniqid has to be also set.
Modification in the DB (non-exhaustive list)
In the first step, there are only new addition of fields in the DB which are not linked to the data in the actual DB.
In the second step, a mechanism will be in place to link the register and existing objects.
The register
All the fields which have to be stored on the database for one entry of the register are defined in the Article 30 of GDPR "Records of processing activities". We have :
- for all treatment :
* the name and contact details of the controller
* optional: the joint controller
* optional: the controller's representative
* optional: the name of the data protection officer (DPO)
* the purposes of the processing;
* a description of the categories of data subjects and of the categories of personal data
* a list of the categories of the different recipients
* optional (linked to a checkbox if third country or internation organisation are recipient): ID of the recipient.
* optional: (Checkbox in the case of transfers referred to in the 2nd subparagraph of Article 49(1)): the documentation of suitable safeguards
* the envisaged time limits for erasure of the different categories of data;
* a general description of the technical and organisational security measures referred to in Article 32(1).
- A list for all processor containing :
* the name and contact details of the processor(s) and of each controller on behalf of which the processor is acting, and, where applicable, of the controller's or the processor's representative, and the data protection officer;
* the categories of processing carried out on behalf of each controller;
* optional (linked to a checkbox if third country or internation organisation are recipient): ID of the recipient.
* optional: (Checkbox in the case of transfers referred to in the 2nd subparagraph of Article 49(1)): the documentation of suitable safeguards
* a general description of the technical and organisational security measures referred to in Article 32(1).
Export of the register
The register will be exportable in a word document and in a csv file.
Link between the register and the existing objects
Priority in the dev.
The project can be cut in different phases which do not have the same priority.
