Managing Personal data in iTop

If you have to comply with RGPD, here are some tips to help you…

Most of the personal information in iTop is stored in the Person object. In the standard iTop datamodel, these data consist of:

Due to the relational nature of iTop, the information stored in the Person object is not supposed to be duplicated elsewhere. The few exceptions to this principle are listed below:

All modification to the Person object are recorded in the history of this Person object, thus storing some personal information. You can list all the changes made to a given Person object using the following OQL query:

SELECT CMDBChangeOp WHERE objclass='Person' AND objkey=:person_id

Where :person_id is the identifier of the Person object. All the modifications performed by the user account associated with the contact also keep track of the name (i.e. friendlyname) of the contact who made the changes.

SELECT CMDBChange WHERE userinfo=:person_name

Where :person_name is the complete name (i.e. friendlyname) of the Person, for example “Claude Monet”.

Each Case Log field in iTop stores information about the person who created each entry in the case log (in the current version of iTop it is not possible to modify a case log entry). The information recorded in the case log (for each entry) contains:

• The date and time of the modification
• The full name (at the time of the modification) of the Person who made the modification
• The identifier of the Person object who made the modification

For example, if the user associated with the Person “Claude Monet” (id=3) created two case log entries, the content of the case log will be stored in the database as follows:

========== 2018-05-09 11:38:45 : Claude Monet (3) ============
<p>This is the second entry of the case log</p>
========== 2018-05-09 11:38:27 : Claude Monet (3) ============
<p>This is the first entry of the case log</p>

Whenever a notification is sent by iTop as an eMail, the information is recorded in the EventNotificationEmail object. This object records the email sent to the mail server. This object contains the email addresses of the person it was addressed (in TO, CC or BCC) and the content of the message sent. The EmailNotification object also stores the date at which it was emitted.

One of the important topics when dealing with personal data is to document the flow of personal data within your organization. This document (and iTop itself) cannot document this flow for you since each use case is specific and depends on the processes and integrations put in place when operating iTop. However, iTop provides several features which can help you document and control this flow of information.

You can audit the operations performed via the REST/JSON services by setting the configuration parameter ‘log_rest_service’ to true in the iTop configuration file. Once this parameter is set, every REST/JSON operation will create an EventRestService object in the iTop database. This object records:

• The date/time of the operation
• The user account used to perform the operation
• The JSON input parameters
• The output of the operation (code, message and – a trimmed version of the - JSON output)

Using all the information you can determine the flow of personal information via REST/JSON webservices (if any).

You can easily list all Synchro Data Sources which import of update Persons by search searching for Synchronization Data Sources which “Target Class” is “Person”. This search can be performed through the “Admin tools / Synchronization Data Sources” or by running the following OQL query:

 SELECT SynchroDataSource WHERE scope_class='Person' 

Each data source keeps track of a complete log of its operations, including the date/time it was run and the summary of the operations executed for each run (creations/updates/deletions).
Note that if a “User” is specified for a Synchronization Data Source, then only the specified user account can execute this synchronization.

• Only the user accounts having the capability “Bulk Read” on Persons can perform exports of a list of persons.
• Similarly, only the user accounts with the capability “Bulk Modify” on Persons can perform a CSV import of Persons.
• These capabilities can be viewed using the “Grant matrix” tab on the details of each user account.

To completely cleanup the data related to a person, one has to:

1. Delete the Person object corresponding to this person, this will also remove the history information about this Person.
2. Delete the case log entries created by this person
3. Delete the EmailNotification objects corresponding to emails sent to this person

But there are limitations to those actions:

• Depending on the relations between the targeted Person object and other objects in the iTop Database, the deletion of the Person object may not be possible without specifying a replacement Person on some other objects in order to respect the database integrity constraints.
  
• Deleting the case log entries is currently not implemented in iTop, and is non-trivial to achieve with SQL queries since the case log text must be kept consistent with another field called the case log index.
  
• Updating the CMDBChange objects to replace the references to the contact name can be done in one single SQL query, since there is only one field ‘userinfo’ to anonymize in the table. Since this field is only displayed to the end-user and not user for any reference in iTop, there is no integrity constraint and any value can be put in the field.
  
• Since one email notifications may be addressed to several persons (in TO, CC and BCC), deleting one such notification will affect other users than just the targeted person.

Due to the limitations mentioned above the “pseudonymization” approach seem more realistic to implement than a complete wipe of the personal data.

• Anonymize the Person object by replacing the values in all its mandatory fields by anonymous values (constant or random)
• Empty all non-mandatory fields (like Location, Manager, Phone number, n:n relations)
• Pseudonymisation of the case log entries, by removing all references to the person, without altering the length of the text, to preserve the consistency with the case log “index” field.
• Deletion of the Person’s history (CMDBChange / CMDBChangeOp) to delete the “previous values” of the fields, which would help recover the values.
• Anonymization of the CMDBChange “userinfo” fields containing the name of the Person.
• Deletion of all EmailNotification objects past a (short) retention period (3 months ??)

• Person details can be exported using the standard export feature of iTop.
• Case log entries can be exported by searching each class of object containing a Case Log (i.e. each class of tickets and searching for “Public Log” contains “Name of the contact”.

This can be achieved using the “Run Query” menu and an OQL like:

 SELECT UserRequest WHERE (public_log LIKE :name OR private_log LIKE :name) 

specifiying the value of the :name parameters as %contact_friendlyname%.

For example to export all the User requests with an entry by Claude Monet in a case log, the OQL query would be:

 SELECT UserRequest WHERE (public_log LIKE '%Claude Monet%' OR private_log LIKE '%Claude Monet%') 

Notification emails can be listed and exported using the OQL query:

SELECT EventNotificationEmail WHERE 
      TO = 'email_address' 
   OR cc LIKE '%email_address%' 
   OR bcc LIKE '%email_address%'