Retention management for Envers audit table

Hibernate ORM
6

I’m not exactly well versed on all the permissible ways to work with GDPR or what you absolutely must do in order to remain compliant, specifically when a request is received to erase private data of individuals. That said, I believe the same steps you’d take in your main database hold true for the audit schema.

  1. Identify rows to be removed or made anonymous.
    Maintain this list of row primary keys per table.

  2. Use the primary keys of tables in step 1 to find audit rows for those identifiers.
    In this step you basically look at the associated _AUD tables based on the rows you’ve modified or deleted in step 1 and get all entries regardless of the revision. You would either elect to update columns to make the data anonymous (if that’s permissible, removing the person’s identity) or you would delete the rows entirely.

  3. For all rows deleted in step 2, maintain list of revision numbers to review.
    After all the _AUD_ tables have had their GDPR request rows purged, you’ll want to review the revisions that were touched to see if any valid foreign-key references still exist per revision.

    If a revision in REVINFO no longer has any rows in any corresponding _AUD table, you’ll likely want to consider deleting the row from the REVINFO table as well or perhaps use a custom revision entity for REVINFO where you add a new column that your purge process can mark accordingly so that you can see there was once entries associated to that revision but due to GDPR requests, those have since been purged from record. Knowing how strict certain audit requirements can be, doing the latter is probably the most ideal and optimal choice, but that’s entirely up to your situation.

Hope that sheds some light on it from the GDPR perspective at least.

Chris