The right to access and delete data are close to universal requirements for privacy regulations across the globe. While the two federal data privacy regulation bills recently introduced in the US Congress differ widely on whether consumers should have a private right of action for privacy violations and whether CEOs should be held responsible for data breaches, they concur tightly on the centrality of individual data rights – access, notice, and deletion.

Even before these competing federal privacy bills were promulgated, privacy officers (as well as IT and security stakeholders responsible for operationalization) have been quietly anxious about the EU GDPR’s Right to Be Forgotten provision. With more regulation now on the horizon and the deadline approaching for the California Consumer Privacy Act with its data deletion rights, the dismay about complying with data deletion requests is intensifying.

The reason for this concern is that data deletion rights are distinct from other data access rights. Rather than require enterprises only assemble a report on whose data they data collect and process, data deletion fulfillment actually requires a degree of ongoing specificity, insight, and context into actual data processing.

Companies might be able to more or less manually fulfill a DSAR with enough resources – for a few enough data sources at a low volume of data access requests (DSARs). That’s simply not a feasible solution for data deletion rights.

One of these things is not like the others

If data deletion processes are not effectively operationalized, enterprises face a few unpalatable outcomes:
– Firstly, a single data deletion request can consume time and resources if enterprises don’t have a clear idea of what data should be deleted, and where it is.
– Secondly, organizations face penalties if they don’t go through a comprehensive and auditable process to at least remove the data from processing within the timeline stipulated by the relevant regulation.
– And lastly, they run the risk of customer dissatisfaction, as well as negative brand impact, if a consumer that made a request manages to determine that their data wasn’t deleted.

But, wait there’s more: enterprises must be able to determine that they aren’t collecting new data once they have received a deletion request on an ongoing basis – for these specific individuals that have made a deletion request.

For instance, the California AG stipulates that enterprises subject to the California Consumer Privacy Act (CCPA) responding to a data deletion request “need not delete from archived or backup systems (until they actually access or use that system)”. However, how can covered enterprises ensure that the data covered by a deletion request is not processed if transferred from back up, or is accessed by a marketing or analytics application?

Putting a Plan in Place

To efficiently respond to a data deletion requests, data owners and IT teams have to know where the data is actually stored with a high degree of specificity, correlate the data to an individual and incorporate business, regulatory and business context to be able to determine whether a specific data element needs to be deleted.

And, enterprises need to be able to determine with which third parties that individual’s data has been shared.

To avoid disaster, it’s advisable to have a plan in place before you receive your first data deletion request. But what does that plan look like? In our experience engaging with some of the largest enterprises in the globe, the typical flow looks like something along these lines:

– Determine whether the data deletion request is legitimate
– Verify the identity of the requestor, and validate their request
– Determine what data categories and attributes are deleted
– Determine where the data is stored
– Determine who are the technical and business data owners
– Define how to delete the data
– Determine with whom the data is shared and issue a deletion request
– Define intervals for validation that no new data is processed
– Define a timeline for the conclusion of data deletion request

Of course, any plan should delineate how to respond to the request, who is responsible for managing the process, and who is accountable at each stage of the request from the point of intake to the actual deletion of the data.

However, data deletion rights can’t be solved by policy or a report – they require a technical solution that fits into a broader privacy management program, with orchestrated data discovery, customer engagement, and governance.

BigID’s Approach

BigID automatically builds (and updates) an inventory of personal information across the enterprise, leveraging correlation and machine learning algorithms to classify and index findings by individual. This foundation allows analysts to first quickly identify whose data is covered by a data deletion request, integrate business and regulatory context to determine what data should be deleted, and then where the data is physically located.

Analysts can then define task delegation workflows for data owners to cover all applicable consumer information eligible to be purged or staged for deletion: including specific attributes, data category details, and physical locations. BigID’s API first architecture allows for automated integration with ticketing systems to track and manage tasks associated with individual data elements that must be masked, encrypted, redacted or permanently deleted.

And lastly, through a configurable, individualized inventory query, enterprises can validate that no new data is being processed – whether through third party data transfers, transfers from backups or access by applications.

Data deletion requests, therefore, shouldn’t be seen as an isolated challenge but instead, as one aspect of a broader privacy management initiative that spans multiple domains and is supported by privacy-aware data intelligence that operates at scale.

Download our datasheet to learn more about how BigID enables automated fulfillment of data access rights and facilitates ongoing validation of individual data deletion requests.