6 engineering implications from the California Privacy Rights Act (CPRA)

California’s Proposition 24 has now passed, bringing amendments to California’s landmark California Consumer Privacy Act (CCPA) in the form of the California Privacy Rights Act (CPRA). Below we break down the biggest areas that can impact the privacy engineering projects at your company, and how you handle personal data.

You can use this cheatsheet in the review of your future strategy, but it’s worth noting there’s still a fair amount to be worked out on the legislative front ahead of a January 2023 enforcement timeline.

Many are also watching to see what pressure CPRA could exert on a push for federal U.S. legislation in 2021 and beyond.

Read on if you’re responsible for privacy engineering at a company with more than $25M in revenue or sells, buys or shares the data of more than 100,000 California residents or derives at least 50% of annual revenue from sharing or selling California data (and even if this doesn’t describe you, a lot of other states are looking at CA as a model, so it’s worth getting up to speed on the kinds of changes that may be on the horizon for every US company).

What is the CPRA?

• CPRA stands for the California Privacy Rights Act and is a California legislative initiative that was passed by the California ballot proposition system (“Prop 24”) as part of the 2020 U.S. elections.
• CPRA is modeled after Europe’s GDPR—so it has broader rights and protections than the original California legislation.
• CPRA is an amendment to the CCPA, or “California Consumer Privacy Act of 2018”, which is part of the California Civil Code under Section 1798.100.

1. Changes to consumer data rights will impact workflows

The CPRA calls for more robust and nuanced data rights controls for consumers, which will have downstream effects on what your internal privacy infrastructure and schemas will be required to handle. Specifically, companies will need more precise inventory and classification of all data in every datastore — and the ability to restrict access and use by specific internal systems.

Of note, the CPRA includes an expanded list of the type of information consumers are able to limit for commercial use (e.g. you can’t use that information), including “government identification numbers (e.g., Social Security numbers, driver’s license numbers, and passport numbers); debit card and credit card numbers in combination with required security or access codes, passwords, or credentials; a consumer’s precise geolocation, religious beliefs, racial or ethnic origin, biometric information, sex life or sexual orientation information; and contents of a consumer’s mail, email, or text messages unless that business is the intended recipient.”

Note that precise geolocation information is now included in the data that consumers can limit. “‘Precise geolocation’ means any data that is derived from a device and that is used or intended to be used to locate a consumer within a geographic area that is equal to or less than the area of a circle with a radius of one thousand, eight hundred and fifty (1,850) feet, except as prescribed by regulations.”

Precise geolocation data (equal or less than 1,850 feet radius) is now included in the data that consumers can limit under CPRA. (Image via mapdevelopers.com, Map data Copyright Google 2020)

Additionally, CPRA extends the current 12-month window that California consumers are able to request access to all categories of personal information collected by companies to a time period of ‘indefinitely’ (beginning January 1, 2022). This timeframe change requires that businesses provide access to all categories of personal information collected “unless doing so proves impossible or would involve a disproportionate effort.”

2. An expanded definition of “sale” of personal information

With CPRA, users will now be able to opt-out of the “sale or sharing of their personal information.” A couple of implications here: (1) The obvious is that your frontend opt-out features will need to now include the expanded language. (2) On the backend, this likely means you’ll have to build more opt-out suppression logic. (3) Additionally, you may have to include more of your third party SaaS vendors in the scope of your user data suppression logic.

On point three, let’s look at an example. Your company may currently operate with the guideline that user data shared with a SaaS vendor for “cross-context behavioral advertising” (think Google or Facebook ads) does not meet the current requirements of a “sale” under CCPA (this is a common legal interpretation that dictates engineering structures). Thus, it is not a scenario that you’ve had to configure suppression logic for to date.

Looking forward, under CPRA and the expanded definition of “share,” your input guidelines may change and you’ll likely need to create individual opt-out flows for any vendor that you share user data with for behavioural advertising reasons (Facebook, Snap, Google Ads, etc).

3. “Correct my data” will bring new requirements to your privacy request infrastructure

Perhaps the most impactful on your company’s privacy infrastructure is the requirement under CPRA that consumers be able to “correct” certain personal information that businesses have about them—from gender to government-issued identifiers. If your data privacy flows include accessing and deleting data, be prepared to consider the engineering systems and features necessary for giving users the ability to “correct” data in your datastores. This will likely take significant time and resources to build, so start now to secure the staff and technical investments you’ll need.

4. New scrutiny for companies that hold data of minors

If your organization holds user data on minors, which is defined by CPRA as individuals under 16 years of age, there’s a tripling of the penalties for intentional children’s privacy violations, with a fine of $7,500. Expect increased requests from your legal colleagues on making sure that the data of minor users are handled appropriately and ready for access, deletion, opt-out or correct requests across your tech stack, including internal data stores and in all of your SaaS vendor systems. This is another area where accurate and complete data inventory and labeling are critical.

5. The impacts of a dedicated enforcement agency

There will now be a dedicated privacy enforcement agency, the California Privacy Protection Agency, to implement and enforce the new legislation. The new enforcement agency is likely to increase scrutiny of data privacy processes and overall adherence to UX and process requirements. The agency is expected to include technical experts to help with enforcement, which marks a difference in oversight knowledge of the enforcers when compared to the current legislation’s reliance on the Attorney General’s office for prosecution.

6. Website UX implications on opt-in and consent

If your team oversees website optimization, there’s an increased push on transparency and user experience in the CPRA.

Specifically, companies will need to update the display of a “do not sell or share my data” button prominently on the website homepage. You’ll also need to review or enhance signals to honor a user’s web browser setting (or other mechanisms) that expresses an opt-out preference. You’ll also need to add paths for allowing consumers to “Limit the Use of My Sensitive Personal Information.”

Additionally, if your company currently uses website “cookie banners” that have misleading or dark patterns to encourage a web visitor to click “accept,” you’ll need to build a new UX that is more transparent.

In addition to the six elements noted above there are a number of other impacts to the engineering department, including increased audit and security requirements, as well as various UX and process components.

Key takeaways

• Having an accurate and complete understanding of your data inventory will become even more critical under the CPRA.
• Establishing safe abilities for users to access and interact with data in your systems will be a priority.
• Building logs and auditable documentation of how you’re meeting these requirements in your backend is likely next on your list.

Transcend is known for our third party data privacy integrations and advanced data privacy infrastructure. Let’s talk if you are scoping out the internal engineering resources required to build download or deletion logic, vendor deletion processes, or consent logic to ensure coverage.