How to Avoid the Hidden Costs of GDPR and CCPA Compliance

GDPR’s “Right to Erasure” or “Right to Be Forgotten” and CCPA’s “Right to Request Deletion” or “Request to Delete” are by far the most challenging requirements imposed by CCPA, GDPR and other privacy regulations. It requires deleting old (or current) customer or consumer records from dozens of Commercial off the Shelf (COTS) and home-grown, custom applications, legacy Mainframe to Datawarehouse and data lakes and any number of operational data stores or databases on-prem and in the cloud (e.g., Amazon Redshift, Snowflake).

Although it sounds simple, Right to Erasure functionality is challenging to implement

Data warehouses, databases, data lakes and other data stores often contain thousands of tables. These tables are intertwined with logical and physical relationships (joins), hence “simply” deleting a customer record spread across multiple tables containing the personal data can break relationships or referential integrity and cause data corruption negatively impacting critical business applications.

Combine this with tracking and complying with the consent management requirements, such as Affirmative authorizations for Opt-In/Opt-Out preferences, authorized communication channel restrictions. etc., and this quickly becomes a monumental task for any organization.

Large organizations are trying to comply with CCPA/GDPR “Right to Erasure”, Consent Management and Affirmative Authorizations utilizing various approaches described later. First, a few all too common examples of initial attempts at achieving compliance.

Go big, boil the ocean approach

Example One:  A Top US Bank decided to start with a data discovery and data flow or data lineage mapping project. The objective was that once they created the “holy map” of client data locations and  data flows upstream and downstream of the discovered data stores they could apply client data erasure, manage data subject access requests and other GDPR and CCPA mandated privacy rights.

Pros:
Sounds like a good plan since knowing where the data resides is an important first step if it could be achieved cost effectively…

Cons:

1. It was quickly discovered that poor data governance practices, no standard naming conventions, lack of reliable metadata and data lineage across applications and data stores all rendered the creation of a sensitive data inventory a major challenge.
2. A comprehensive discovery project on hundreds of data sources across IT siloes took many months – during which time actual compliance actions were delayed and a single client record had not been deleted or “forgotten” with no practical remediation path in sight.
3. Leveraging existing data discovery and classification tools only achieved an accuracy of 75% – 85% (even with the use of AI and machine learning). What to do with the remaining hidden sensitive data? Identifying data lineage had even less accuracy as data flows upstream or downstream are built using various methods and tools created over many years.
4. Discovery of sensitive data at a source does not provide any context on the associated risks – who is accessing the data, from which systems, and for what purpose.
5. With limited budget and IT resources would it not have been a better use of time and effort to start applying the “Right to Erasure” on the primary applications used to access and process customer data at the bank instead?

Kicking the can down the road approach

Example Two:  A large US telecom decided to send emails to hundreds of application owners every time a customer asked to be deleted, putting the responsibility on the application owners to comply within their respective applications.

Pros:

Sending 200 emails is cheap and fast. It does not impose corruption risk on the applications in-scope and does not require any changes to the applications.

Cons:

1. This “kick the can down the road” approach does not scale, provides little or no accountability or compliance audit trail, and resulted in sporadic physical deletion with no points for trying.
2. Even in the situations where a few of these application owners did have an option to delete a customer record, it did not necessarily apply everywhere upstream and downstream in the data flow. All too often the deleted data “reappeared” due to existing data sharing and regular ETL processes propagating the data back in and returning the organization back to square one.

There is a better way…

Consider the following options. Each producing much the same results eventually.  The time required, path to full compliance and costs associated with each option however are very different.

For reference, the UK Information Commissioner’s Office has produced a useful document that helps to clarify differences between physical deletion (irretrievable) and placing the data “Beyond Use” in the interim to better comply with the intent of data privacy regulations.

Data privacy regulators agree and understand that physical deletion of all electronic copies of a customer’s PII can take time while respecting a data subject’s request to be erased or forgotten should be complied with as soon as reasonably possible.

In the end, it comes down to one of the following three approaches and approximate associated costs.

The best approach is clear.  Soft or logical deletion is the clear choice for the following reasons:

• Easiest to implement
• Least expensive
• Least disruptive to business processes and IT operations
• Most flexible
• Quickest path to privacy compliance

When a single, centrally managed, policy-based solution can be used to consistently apply the same rules regarding Right to be Forgotten and consent management across all core applications and data stores, this option becomes even more obvious.

An organization can then progress to full physical deletion of a customer’s record(s) in the most economical and efficient way possible over time without impacting normal business processes.  This approach also supports full data mobility with all access controls and preference management following the data from data repository to data repository on premise or in the cloud regardless of the applications being used to access the data.

SecuPi would be happy to provide an overview and demo of the benefits of leveraging this next generation technology.

The authors:

Alon Rosenthal is the Co-founder & CEO of SecuPi.

Les McMonagle (CISSP, CISA, ITIL) is Chief Security Strategist at SecuPi.

Contact: alon@secupi.com – or – les@secupi.com – or – sales@secupi.com