GDPR Compliance -> purge terminated identities
One key requirement of GDPR is that identity related data needs to be purged. But IGL stores collected identities which got terminated forever by default. We currently run on 7.0.2. Will 7.1 or 7.1.1 offer in the data purge section to delete terminated identities entirely after predefined dates? (E.g. delete all terminated users which are terminated > 365 days?)
If 7.1 / 7.1.1 will not offer this feature how do other ensure compliance with this GDPR requirement?
Thanks in advance.
- Community Thread
- Forum Thread
- Identity G&L
- Identity Governance & Lifecycle
- RSA Identity
- RSA Identity G&L
- RSA Identity Governance & Lifecycle
- RSA Identity Governance and Lifecycle
- RSA IGL
I can tell you that there are no plans to allow purging identity information in the near future.
Though I am not sure how this would impact GDPR, what slightly confuses me is that RSA IG&L is not the source of information on identity data, meaning it is always collected from some place (probably an HR system or Active Directory). So I would say, wiping those details from the source should reflect into our application.
I can also tell you that it should be fairly simple to tweak your Identity collector to not collect unwanted data for terminated users (even your same example above where terminated > 365 days). If your IDC is a database/csv collector, you can incorporate that logic into the collector query itself so that it performs conditional collection of attribute values based on the termination status.
Thanks for your reply Mostafa Helmy,
but what you have wrote is exactly the case: our HR Feed will remove identities which got terminated so they are no longer delivered in the data feed and IGL will no longer collect them in IDC. But still the entries of the terminated users will be kept in the IGL database forever.
The only idea i have is to override all terminated users with plain data. But this seems to be a big effort in preparing the data merging in with the existing file or creating a second IDC for purging.
You are correct, I was assuming you still get the lines of terminated users and did not take into consideration that if the identity line is completely removed from source it will be marked deleted/terminated but kept in the final state.
In that case, I see two ways to achieve this:
- Ask the HR team to just keep only the User ID record of terminated users with empty values in the remaining fields.
- You can create a second loopback IDC that basically points to IG&L's own database. Have it collect only terminated User IDs from PV_USERS having the criteria required for purging and force null values into all the remaining attributes. You can then join this secondary IDC on your main IDC from the unification configuration and also make sure the create users checkbox is unchecked here so that it never creates duplicate identity entries.
Mostafa Helmy thank you very much, this workaround will help but will require some effort to establish. Still it would be great if this feature could be offered in IGL OOTB in future to purge terminated users.
The reason we do not get rid of such data is mainly for audit purposes. So if you ever look back at an old review, change request or any user-related event, you would see the who was involved in the event.
I would recommend you submit this to RSA Ideas for RSA Identity Governance & Lifecycle , or vote the idea up if it was already submitted by someone else.
Ok, thank you I have voted for the existing idea:
Sure, we need to keep the identity data for audit reasons but GDPR comes with legal requirements we have to statisfy, too.
As Jasmin stated, although having the data for auditing purposes are fine overall. There is a time frame where an organization no longer needs to retain specific data for auditing purposes and where we have to be compliant for GDPR. This feature would have been very beneficial for us as we had another issue come to us from the legal department that required me to wipe and restart the identities using a different data set in my lower regions. Not being able to delete identities, I was forced to rebuild all of my whole lower region from scratch to ensure the lower regions were compliant as well.