Why Data Erasure Actually Might Not Leave A Blank Cell

Why Data Erasure Actually Might Not Leave A Blank Cell

Erasure requests are a key component of privacy regulations worldwide. To meet the growing requirements, teams must be able to effectively erase a requesting user’s data. That erasure actually might not leave a blank cell in the database, and that’s a good thing.

Data Erasure, Explained

The EU’s General Data Protection Regulation (GDPR) has set the global standard for privacy, including in the rights it grants to users. Among them, a right to erasure: a user can request that a company remove all personal data they hold on them. In recent years, this right to erasure – sometimes called “right to delete” or “right to be forgotten” – has cropped up in privacy regulations worldwide, from Virginia’s CDPA to Brazil’s LGPD. Teams worldwide must understand and be ready to fulfill erasure requests alongside other data subject requests.

The basic concept of an erasure request is simple enough. An erasure request in action, however, does not always look like putting null values in your databases. In fact, just clearing your database cells could spell trouble for your data systems. Here, we explain the variety of methods for implementing erasure requests. We also point out why a data erasure is not always the same as pushing “delete.”

How to Erase Data

It might seem like a hard delete is always the best option for erasure in a business database. But there are some instances where a hard delete simply isn’t possible. What if there are complex downstream data processes that will begin to throw errors if they encounter an empty cell? What if some aspect of the data in question must be retained due to overriding legal imperatives? While clearing a database cell is one means of erasing personal data, this approach can quickly spell trouble for your business intelligence. Our VP of Product Kelly Huang explains:

“Most engineers and architects of an enterprise data system don’t normally consider the impact of a simple deletion from a database row. Even the most minimally complex data ecosystem has very complex processes that power the business. ETLs, ELTs and other replication processes and pipelines keep your business intelligence robust. Deletion of data — whether by an internal tool, an off-the-shelf SaaS product, or a direct deletion by a DBA — could break the relationships the ecosystem relies on to keep the business moving.”

Your data systems might require more complex approaches to erasure, so it is important to understand the options.

Data Erasure Using Fixed or Random Values

Instead of clearing all data cells associated with a requesting user, it may be more appropriate to replace those values with placeholders that have nothing to do with that user. For instance, you could replace data fields with the string “MASKED.” In doing so, you have erased the user’s information while leaving a string in each of the cells. This approach is worth considering if you run applications that validate the formatting of database entries. Whereas deleting an email address could trip up a downstream application because the empty cell fails the format validation, a fixed string could satisfy those requirements without using the user’s personal information.

An animation of a database row being replaced with the string

Alternatively, you may wish to provide a unique placeholder for every time you delete a user’s data. In this case, a randomized value such as a combination of letters and numbers would suffice.

Data Erasure Using Company-Specific Hashed Values

Many data systems today need more sophisticated erasure techniques than hard deletes or basic substitutions. For instance, you might run an application that requires each of your database entries to maintain referential integrity. That is, you must preserve the relationships between data-points, but you cannot leave the information in plain text. To quote Kelly once more:

“When you delete or anonymize personal information that’s used as the primary key in a database, all relationships across the schema break unless you’ve employed a strategy that maintains the referential integrity.”

To solve this challenge, you could encode the value using cryptography methods. The end result is a value that only those with the right key can decode. You maintain referential integrity while removing the personal information of the requesting user.

When to Erase Data

In specific situations, the appropriate response to an erasure request might be to erase nothing at all. This approach is only appropriate when you are obligated to retain information for business purposes. For instance, you may be required for tax purposes to hold onto customer’s payment information. It is important to communicate this limitation to your customers, providing them with an accurate picture of their personal data in your systems.

Precise and Simplified Data Erasure

Compliance with privacy regulations should not obstruct your data systems from their core business functions. In fact, privacy compliance cultivates long-term business growth. By using the right data operations to fulfill erasure requests, you keep your data systems in healthy condition while demonstrating to your users that you respect their data. In earning users’ trust, you can focus on growing your business.

Ethyca simplifies erasure requests for companies and users alike, while also providing companies with the nuance to choose the right erasure methods for their data systems’ needs.