Why all data-encryption GDPR/CCPA projects will fail
Encryption and tokenization of data fail to meet the dynamic and scale of data protection imposed by GDPR/CCPA. Here is why:
With the fast evolution of privacy compliance requirements, more data types are and will be considered sensitive in the future. In fact, one of our German customers recently labeled 30,000 columns as sensitive in their Teradata. This sensitive data needs to be anonymized somehow, and organizations are not bound to specific methods for doing so.
One natural way to go about it would be to use encryption as a method for stripping away the meaning of the data and, thereby, anonymizing it. However, companies fail when trying to implement data encryption on the database level or the application.
- High implementation cost and DBA/development skills required for building database UDFs & changing application source-code (to call encryption/decryption APIs for every encrypted column)
- Inability to monitor, control and protect sensitive data that is not encrypted for performance, technical or business reasons (e.g., COTS applications cannot be encrypted).
- Performance degradation and complexity where encrypted columns are used (e.g., wildcard (‘*’) search, ‘like’ and ‘between’ conditions on an encrypted column impose full column decryption).
Encryption is undoubtedly a time and CPU resource-consuming process required to create database UDF for each column to encrypt every insert and update call while decrypting every read. Consider how much time and cost it would take to encrypt 100 sensitive columns across hundreds of data stores and applications. Now imagine how much it would take to encrypt a 1000 columns!
In addition to the challenges of inevitable scaling up, implementing encryption is a complex task that requires technical skills. Code changes are required for each relevant application call to encrypted data element using API or JDBC/ODBC wrappers in addition to creating and maintaining database UDF’s for encrypting direct database access by numerous DBAs and developers. This practice is costly and affects future database and application upgrades and performances. In cases where APIs cannot be coded or when those are overlooked, false business results arise and data corruption consequences will occur.
From performance degradation and inability to monitor data that is not encrypted to high implementation cost and development skills required for building database UDF, it’s clear that database encryption cannot scale up to protect hundreds of applications and thousands of personal data items.
Being aware of the industry and the challenges that it is currently facing with privacy regulations, it’s clear that a more suitable technology needs to be used. In-motion encryption and Dynamic Data Masking coupled with disk-level encryption provide an alternative anonymization method that can used without encountering the obstacles of encryption at-rest.