We are working on certain enhancements to the product where in customers using SDP would be able to be GDPR compliant. I will list down the activities we would be doing as part of this in phase I,
Personally Identifiable Information (PII) data :
In SDP, the PII information can be stored in the following places,
- Basic Requester information ( in the form of email, phone number )
- Additional Requester information ( through requester additional fields in the form of SSO number, account number etc... )
- Incident & Service additional fields
- Asset additional fields ( in the form of IMEA number of mobile etc... )
As of now, we have no means to identify a field on whether it contains PII data or not.
So to address this, we are coming up with an option in all the additional fields section to specify whether a field would contain PII information or not. This would be available for the single line, multi line, numeric and date fields. For now we do not see any usecase for pick list additional fields to contain PII data. If there are any valid use cases for this, let us know and we would try to bring that in.
Encryption at Rest :
We are also bringing in option to encrypt an additional field if required. This would be available for single line and multi line fields. We are not looking to provide encryption for numeric and date fields. The above screen shot would have this information in the additional fields section.
Right to Forget :
When a user leaves an organization and if the administrator deletes him from SDP, we do the following as of now,
- Move the user to 'Resigned' state
- Remove the login, email Id and phone number information
In the proposed solution, there will be a new admin section on privacy settings which will have a provision to enable anonymize option and also list down all the fields that have been marked as PII in the various modules. Here the admin will be able to select those fields which needs to be removed when a user is deleted.
If the above settings is enabled, then while deleting a user or multiple users ( the below image is with the assumption that the admin has selected a few requester's and has clicked on 'Delete user' ), an option to anonymize the user would be displayed. If the admin prefers to anonymize the user, he can provide the anonymous name and proceed.
In this case, the following things will happen,
1. The requester name would be changed in all places like request details, archived request, change etc... with the one provided. For ex : Anonymous User 18
2. The users Email ID present in various tables would be replaced by a dummy Email ID or set to empty string. ( like recipient table, approval tables, notification tables etc... )
3. Any PII data present in requests, changes, projects etc that have been raised by him would be removed. For ex, if the user has raised a service request to update his bank account number and if the old account number and new account number are provided as additional fields and if they are marked as PII, then this information alone would be removed from the ticket. The ticket and the other properties would be left as such.
4. Login, email and contact info of the deleted user would be removed.
Also, the email of the deleted user will not be allowed back into the system through conversations. ( If his email Id is present in the cc and if such a mail comes in as a conversation, the removed email ID will not be considered ).
If the administrator does not want to anonymize, he can chose to do so. In such case, only point number 4 would be done while deleting the user.
For existing customer's for whom there could be requester's who are already deleted and if the email that is present in notification, approval etc... needs to be removed now, we will be providing a option similar to this where all the email ID's that are not associated to any user would be fetched and displayed. The admin will have an option to remove these from the SDP database.
There might be cases where the customer's want to retain the information for a certain period of time since the user was deleted, say 3 months and then anonymize the user. We are thinking on providing an option for that too where in, the administrator would be able to do a normal delete now and then after some time would be able to select these deleted users and anonymize them.
These are some of the items which we would be taking in the initial phase.
We would like to hear your feed back on this.
Thanks
Shanmugam PL