Graham Thompson

 ·  3 min read

CPRA Compliance: What It Means for Engineering Teams

In this article, we’ll review how regulatory revisions under CPRA impact the use of Production data in development and testing environments, the friction it causes between security, compliance, and engineering, and explore an alternative to strict governance policies using de-identified data snapshots.

New compliance and regulatory requirements have introduced additional complexity to the relationship between engineering, security, and compliance. The most recent wrinkle, which became enforceable last week, is the updated California Consumer Privacy Act (CCPA) which is now the California Privacy Rights Act (CPRA). Under this new law, qualifying companies are required to abide by Data Minimization rules similar to those you may recall from HIPAA.

A summary of CPRA’s Data Minimization requirements:

  1. Information collected must be “reasonably necessary and proportionate to either the purposes for which it was collected or another disclosed purpose.”
  2. The individual’s data cannot be used in another way without notifying and receiving additional consent.
  3. Data retention policies must specify the length of time the data is necessary to retain, and must be reasonable based on the project scope (i.e. no more perpetual retention).

Engineering and Security Leaders Are at Odds

Over the past few years, tools and services aimed at improving the developer experience have exploded. Development environments that mimic Production are foundational building blocks for every engineering team in the world. Regardless of these environments being local or hosted remotely, most projects require some amount of data in order to properly develop and test the new code.

The fastest and easiest way to get this data is to grab a snapshot from Production, and if your team does this, they’re not alone. In the most obvious cases, Personally Identifiable Information (PII) is straightforward to remove, but the constant manual process is time consuming, inconsistent, and error prone. Additionally, not all PII is easy to find. Did you know that gender, zip code, and birthdate are considered personally identifiable when all three are present in a dataset?

As engineering teams grow, so do the number of developer environments with active copies of data - much of which contains PII. This poses obvious security and regulatory risks, both of which can be avoided with de-identified data.

Implementing Data Minimization for a high velocity team

Engineering speed, robust security, and regulatory compliance have long been at odds with one another. This friction was the primary impetus behind founding Privacy Dynamics in 2019. We believed there was an opportunity to bring a novel solution to this problem, and it required improving the data quality and dramatically lowering the cost of de-identified data.

Fully anonymized, or de-identified, data has long been considered inferior and at times utterly useless. Privacy Dynamics’ approach is to only treat data that is contributing to privacy risk, and only by the minimum amount necessary to eliminate that risk. You can learn more about our treatment process here. By using de-identified data in development, training, and testing environments, CISOs are able to eliminate a major source of data breaches. Engineers also get constant access to Production quality data allowing them to reduce project setup time and maintain their current velocity.

More importantly, we knew that in order to satisfy the needs of engineering teams, we needed to make the process a seamless part of their existing workflow. To accomplish this, we’ve released the ability to create de-identified data snapshots that closely mimic the production data residing in any major data store. These snapshots stay updated based on a cron schedule, and can even manage schema changes automatically.

In this new world, we’ve addressed some of the major concerns causing friction between engineering, security, and compliance:

  • Engineers get access to de-identified data that maintains format, analytical and referential integrity.
  • Security Officers reduce their attack surface by eliminating PII and other protected data from development, training, and testing environments
  • Compliance teams can achieve Data Minimization without negatively impacting engineering

We couldn’t be more excited about the latest release of Privacy Dynamics, but we’re still just getting started. If you have a problem providing frictionless access to data while maintaining strict security and compliance standards, we’d love to hear from you!.