CCPA: The Ultimate Guide for SAP Systems

Disclaimer

This guide is not intended as legal advice and should not be construed as such.  Its purpose is to provide information for educational purposes only and makes no claims or guarantees with regards to efficacy, accuracy or full compliance with the law discussed herein.

Please consult with an appropriate legal advisor before implementing any part of a CCPA compliance project.  EPI-USE Labs will not take any responsibility for misinterpretation or incorrect application of practical measures towards compliance resulting from the use of this guide.

There is a global wave of data privacy legislation that affects the way in which companies do business. We can all agree that having control over our private data is important from an individual’s perspective, but with decades of freedom in using personal data, businesses are now forced to rethink their approach, and sometimes even their business models. In many cases, personal data used to be considered an asset, but has now become a liability or a toxic asset.


This guide is designed to provide you with insight and practical tips on compliance with the California Consumer Privacy Act, or the CCPA as we will refer to it throughout. We are not your lawyers (see our disclaimer), and as every system is unique, we cannot guarantee that you will be compliant after following this guide. But what we aim to achieve is that you will have a deeper understanding of the law and the way it compares to GDPR. We have also suggested a number of practical actions you can take towards compliance.


About the California Consumer Privacy Act (CCPA)

The California Consumer Privacy Act, or CCPA, is a bill that enhances privacy rights and consumer protection for residents of California in the United States. It provides Californian consumers with several rights regarding their personal information. In broad terms, the law does the following:

  1. It gives Californian residents, referred to as ‘consumers’, the right to know what information is being collected on them, both on and offline.
  2. It gives Californian consumers the right to know whether their information is being sold or shared, as well as with whom.
  3. It gives the consumers a right and practical means to stop the sale of their personal information.
  4. It gives consumers the right to request the deletion of their personal data (with some exceptions). 
  5. It prohibits preferential treatment of consumers who willingly share their data, as opposed to those who opted out or made alternative choices regarding their personal data.

In this guide we explore this further, including applying the law to specific phases of a typical data privacy compliance project.

DOWNLOAD CCPA: THE ULTIMATE GUIDE FOR SAP SYSTEMS
CCPA Chapter Icons-01
Chapter 1

CCPA vs GDPR - The key differences

It isn’t the same thing

Let’s get this out of the way: GDPR compliance does not equal CCPA compliance. There are some similarities between the two laws, but the CCPA has a different focus to GDPR, making compliance different in most respects. This chapter gives a quick overview of the key differences between the two laws.

Comparing CCPA with GDPR

  CCPA GDPR
Who must comply? CCPA
For-profit entities that engage Californian consumers and households.
GDPR
Processors and Controllers that interact with EU Citizens.
Who is protected? CCPA
‘Consumers’ who are natural persons and California residents.
GDPR
Identifiable natural persons who are EU nationals or residents.
What is protected? CCPA
Personal information, broadly defined to include any identifier that can be linked to a consumer.
GDPR
Personal information that can be used to identify a natural person.
How are they protected? CCPA
Consumers can opt out of the sale of their personal data.  There are penalties for breaches. A broader definition of “consumer” makes anonymization far more challenging.
GDPR
Data subjects must opt into the processing of their data.  Clear security directives. A narrower definition of data subject makes anonymization of personal data simpler.
What are the consequences of non-compliance? CCPA
Penalties of up to $7500 per violation.
GDPR
Penalties of 4% of annual global revenue or €20m, whichever is higher.

 

Who must comply?

The CCPA requires any entity defined as a ‘business’ that has any activities related to ‘consumers’ within the borders of California to comply, given three specific thresholds (see Chapter 2). Similar to GDPR, this applies regardless of physical location.

The GDPR is broader than the CCPA as it includes any person or entity that engages EU residents, regardless of their physical location, and is not limited to businesses.


Who is protected?

The CCPA protects ‘consumers’ who are defined as California residents. This will include employees* and customers, so even if you are a B2B company, you will need to comply.

GDPR protects ‘data subjects’ that are natural persons who are EU residents, identifiable, and to which the personal data that you collect relates.

* Amendment AB25, aimed at restricting the way in which employee data is managed under the CCPA, will provide limited rights to employees as consumers.  Regardless of these possible future restrictions, employee data is still subject to compliance.


What is protected?

For both the CCPA and GDPR, ‘personal information’ is protected. The CCPA has a broader definition of what that means, specifically including any information that can be linked to a person, up to household or device level. The implication is that data like IP addresses is included as ‘personal information’ for the purposes of the CCPA.

GDPR focuses purely on information that will allow you to identify a given person directly, and includes a number of special categories of data that are prohibited from processing.


How are they protected?

The CCPA puts the emphasis on the sale of personal information, giving consumers the right to opt out of having their data sold (which is also broadly defined; see Chapter 4). There are penalties for data breaches, although there aren’t any explicit data security requirements. As a consequence of the way in which personal information is defined, anonymization is much more complicated to achieve.

GDPR is explicit about the extent to which data controllers and processors need to secure their systems as well as implement appropriate organizational measures to protect personal data.  Different from the CCPA that provides the right to opt out, GDPR requires specific and informed opt-in to the different ways that personal data is used.  


What happens when you don’t comply?

When it comes to a private right of action (private individuals suing the organization in breach), both GDPR and the CCPA provide avenues. The CCPA is generally more prescriptive as to the monetary value that can be claimed in civil cases for statutory damages ($100 to $750 per violation). GDPR is not prescriptive in this sense.

Beyond civil cases, there are also administrative or civil penalties to consider.  The CCPA gives the Attorney General the power to penalize an offender with $2 500 per violation, or up to $7 500 per violation if it was intentional. When violations are noted, offenders get 30 days to fix the issue before any actions take place.

GDPR also contains heavy administrative fines of 4% of company turnover or €20 million, whichever is higher.

CCPA Chapter Icons-01
Chapter 2

Should I comply with the CCPA?

A few of us won’t have to. (But just a few).

The good news is that not everybody has to comply with the new CCPA law. The bad news is that there are very few companies that will be so lucky. In this chapter, we look at who needs to comply with the CCPA and give you a simple-to-follow flowchart to determine whether you need to do so.

Being a business and selling data

Being a business and selling data_white


Compliance with the CCPA boils down to two questions, namely:

  1. Is my operation regarded as a business with activities in California?
  2. And do my revenue-generating activities include the use of personal data of consumers?

Of course, if you are using personal data to generate revenue, you automatically qualify as a business, which means that it is likely that you are required to comply.


1. Is my operation a business?

CCPA_Ultimate_Guide_graphics_V2-02_Updated

In California Civil Code 1798.140, we learn that you are a business if 

a) you operate with the aim to generate profits, 
b) require personal data as part of your operations, and 
c) have any business activity in California.

The implication is that your physical presence is irrelevant; the moment you collect personal information from any Californian resident as part of doing any form of profit-making activity, you are regarded as a business.


2. Do my revenue-generating activities include the use of personal data of consumers?

Do I sell personal data-rev1.1


The CCPA does provide some leeway by adding certain thresholds that would qualify a business for compliance in 1798.140(c)(1):

(A) Has annual gross revenues in excess of twenty-five million dollars ($25,000,000), as adjusted pursuant to paragraph (5) of subdivision (a) of Section 1798.185.

(B) Alone or in combination, annually buys, receives for the business’s commercial purposes, sells, or shares for commercial purposes, alone or in combination, the personal information of 50,000 or more consumers, households, or devices.


(C) Derives 50 percent or more of its annual revenues from selling consumers’ personal information.

 

Don’t get too excited about these thresholds though. The CCPA uses a broad definition of ‘personal information’.


What is considered personal information?


In 1798.1409(o)(1) we learn that:

Personal information means information that identifies, relates to, describes, is capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household.



Are you collecting IP addresses for web analytics? Are you using cookies? Does the information you collect link not just to individuals, but perhaps to households or even single devices? Even though a 50 000 consumer threshold looks like a lot, it only takes 137 unique visitors from California to your website per day to fill up that quota and relates to any identifiers that can link back to a consumer or household.

Then there are the profits on the sales of this information, which is more specific to data brokers who make money by selling personal data. If you earned $100 this year, and $50 of that was generated by selling consumers’ data, you will have to comply.  

But even ‘selling’ here isn’t a simple concept.


According to Code 1798.140(t)(1):

‘Sell’, ‘selling’, ‘sale’ or ‘sold’ means selling, renting, releasing, disclosing, disseminating, making available, transferring, or otherwise communicating orally, in writing, or by electronic or other means, a consumer’s personal information by the business to another business or a third party for monetary or other valuable consideration.


 


So, who won’t have to comply?

Code 1798.145 provides some exceptions for compliance, most notably when a business’ activities take place ‘wholly outside of California’ and does not process any personal information of a California resident.

The challenge here, specifically to businesses that operate on the Internet, is to know whether or not a visitor is from California. But if you are running a fish tackle shop in Arkansas where no Californians ever have, or ever will, set foot, and you operate without a website, and don’t collect any personal information, then it is likely that you are not required to comply.

Other exceptions noted in this Code relate mostly to organizations that collect medical and other forms of sensitive personal information, which are already subject to specific privacy laws for their particular contexts.


Broadly speaking...

One might say that the devil is in the details, but in the case of the CCPA the devil is really in the broad definitions. Some businesses may want to find a way to avoid the burden of compliance, but with a number of other similar laws developing in other states, as well as across the globe, it is a safer approach to ensure compliance.

CCPA Chapter Icons-01
Chapter 3

Planning your CCPA project

It gets complicated really fast

A compliance projects can get complicated. It requires time and dedication from specific team members across different departments, including legal/compliance, business owners and IT. Due to imminent deadlines for implementation, it typically runs over shorter periods of time.

Managing a complex, high-pressure project is a challenge, and like any challenge, it begins with proper planning. In this chapter, we provide a few tips on planning for your CCPA compliance project.

You can only change what you know

A CCPA compliance project plan broadly consists of four stages, namely:

  1. Scope & Plan
  2. Identify & Assess
  3. Evaluate & Respond
  4. Implement, Monitor & Adjust

Scope & Plan

The first step is to understand the scope of the project. In the case of the CCPA, the scope will relate to all of the processes that touch consumer data, which will help you to identify:

  1. All of the systems (electronic and otherwise) that may contain consumer data
  2. All of the people that participate in data-related processes (including management)
  3. All of the applicable policies and legal documents

Once you have identified all of the elements that you will include for compliance, you can create your project plan:

  1. Specify a deadline for compliance
  2. Identify milestones with due dates
  3. Identify tasks with due dates
  4. Identify responsible persons and assign them the tasks

With your scope and project plan in hand, you can kick the project off with your team.  Pro-tip: Ensure that you have buy-in from your leadership team before launching the compliance project. With their support, you will have the necessary leverage to get tasks completed.


Identify & Assess

The first project phase will relate to identifying the data and how it flows throughout the organization. Consider using a combination of flowcharts and tables (see Chapter 4) to map out the data that will be included for compliance.

Once the data is mapped out you can assess it for risk, specifically as it is used within certain processes. Understanding which sections of data have a higher risk for non-compliance will allow you to prioritize any actions you need to take towards compliance.


Evaluate & Respond

In this phase, you will evaluate your findings to understand the impact. For each finding, you then develop a response, which is typically in the form of a control for specific risks, or a fundamental system or process change where non-compliance is systemic.

Combine your responses into an implementation plan that can be tracked against the project deadline.


Implement, Monitor & Adjust

In this final phase, you implement all the changes required for compliance. However, this is not just a “lock up and go” situation; every implemented change will need some form of monitoring.

It is the result of your monitoring activities that will allow you to make adjustments and improvements.

CCPA Chapter Icons-01
Chapter 4

Step 1: Map your data

“You don’t know what you got till it's gone”

Before implementing any changes, you need to know what your data looks like. In this section, we’ll look at the practical steps you’ll need to take to map your data and assess the extent of your CCPA compliance requirements.

Give them what they ask for

The motivation for mapping your data relates to the right the consumer has to ask for disclosure of the data you are collecting, where you are getting it and to whom you are selling it.


Code 1798.110. (a) reads as follows:


A consumer shall have the right to request that a business that collects personal information about the consumer disclose to the consumer the following:

(1) The categories of personal information it has collected about that consumer

(2) The categories of sources from which the personal information is collected.

(3) The business or commercial purpose for collecting or selling personal information.

(4) The categories of third parties with whom the business shares personal information.

(5) The specific pieces of personal information it has collected about that consumer.”

 


Not only does a map with this profile assist in developing disclosure and deletion processes, but it will also indicate the overall compliance risk your business faces.


CCPA vs GDPR: It’s a matter of scope

The geographic scope of GDPR forced many businesses to take a more blanket approach that would make an initial mapping less practical. Instead, many opted to simply implement the various privacy measures across all their data sets, the geographic origin notwithstanding.  

Moreover, the comprehensive nature of GDPR required fundamental changes to systems which would make separate technological standards cumbersome and costly to implement and maintain.

Finally, GDPR compliance surrounds a single data object, namely a ‘data subject’ which is a natural, identifiable person. The CCPA includes both households and devices beyond individuals, which makes data mapping a necessity.

The CCPA is focused solely on Californian consumers and is not prescriptive on how systems must be secured or data should be managed towards data privacy. Instead, it requires specific knowledge of your Californian consumers which makes data mapping more important.

If you haven’t mapped your data for GDPR, this may be a good exercise to understand your greater compliance risk as more regions implement data privacy laws.


Practical steps to take

Practical steps


Identify data objects (residents, households, devices)

The CCPA’s underlying premise is that data on households and devices links back to individual consumers, which makes it personal information by extension.  

Consequently, mapping your data will start with mapping the data objects you maintain, specifically individuals, households and devices.


Identify data sources and source categories

Where do you get this data? Typically data can originate from the following, among others:

  1. Active submission by consumers
  2. Automated collection by systems (such as web analytics or algorithm-derived data)
  3. Other forms of observation
  4. Inferences from existing data 
  5. Acquisition from other businesses or third parties
  6. Acquisition from public sources (both from government and private sources)

Be as detailed as possible in identifying specific sources that will allow you to identify and map them to categories like the list above.


Map data fields to field categories and identifiers

The CCPA indicates 11 different categories of personal data, including a long list of identifiers that relates to people, households and devices. In this step, map your data fields to these categories and where possible, identifiers.

The categories include:

Category Example/Description from Applicable Law
Identifiers Real name, alias, postal address, unique personal identifier, online identifier, Internet Protocol address, email address, account name, social security number, driver’s license number, passport number, or other similar identifiers.
Any categories of personal information described in Cal. Civ. Code 1798.80(e) ‘Personal information’ means any information that identifies, relates to, describes, or is capable of being associated with a particular individual, including, but not limited to, his or her name, signature, social security number, physical characteristics or description, address, telephone number, passport number, driver’s license or state identification card number, insurance policy number, education, employment, employment history, bank account number, credit card number, debit card number, or any other financial information, medical information, or health insurance information. ‘Personal information’ does not include publicly available information that is lawfully made available to the general public from federal, state, or local government records.
Characteristics of protected classes

Protected classes include:

  • Race
  • Color
  • Sex
  • Age (40 and older)
  • Religion
  • National origin
  • Disability
  • Citizenship status
  • Genetic information
Commercial information ‘Biometric information’ means an individual’s physiological, biological or behavioral characteristics, including an individual’s deoxyribonucleic acid (DNA), that can be used, singly or in combination with each other or with other identifying data, to establish individual identity. Biometric information includes, but is not limited to, imagery of the iris, retina, fingerprint, face, hand, palm, vein patterns, and voice recordings, from which an identifier template, such as a faceprint, a minutiae template, or a voiceprint, can be extracted, and keystroke patterns or rhythms, gait patterns or rhythms, and sleep, health, or exercise data that contain identifying information.
Internet or other electronic network activity information Including, but not limited to, browsing history, search history, and information regarding a consumer’s interaction with an Internet Web site, application, or advertisement.
Geolocation data Longitude, latitude or any other geographic positional information expressed in any format that can be directly associated with a person, household or device, including graphical maps.
Audio, electronic, visual, thermal, olfactory, or similar information

Voice recordings
Photos

Professional or employment-related information

Work History
Qualifications

Education information

Information that is not publicly available personally identifiable information as defined in the Family Educational Rights and Privacy Act (20 U.S.C. section 1232g, 34 C.F.R. Part 99)

Inferences drawn from any of the information identified in this subdivision to create a profile about a consumer

Reflecting the consumer’s preferences, characteristics, psychological trends, predispositions, behavior, attitudes, intelligence, abilities, and aptitudes.

 


Understand Data Flows

Now that you know where the data comes from and what categories it falls into, you can assess where the data is going. This important step clarifies what data is regarded as being ‘sold’ or ‘disclosed’ as defined by the CCPA:



‘Sell’, ‘selling’, ‘sale’ or ‘sold’ means selling, renting, releasing, disclosing, disseminating, making available, transferring, or otherwise communicating orally, in writing, or by electronic or other means, a consumer’s personal information by the business to another business or a third party for monetary or other valuable consideration.



Typically data will be shared:

  1. Internally between individuals or departments
  2. Externally with trusted partners
  3. Externally with buyers 
  4. Externally with the general public

Data flows

For example, you will collect personal data on your employees, but you won’t share it with buyers or the general public. If you use a third-party payroll system in the cloud then you are sharing it with a trusted vendor, who in turn has a number of obligations to maintain the privacy of the data.

Your end goal is to generate two lists using the categories in the previous step, one with categories that are sold, and one with categories that are disclosed, but not sold, for example:

Object Object Description Category Status Recipient Recipient Category
Object: Consumer Object Description: Website Visitor Category: Internet or other electronic network activity information Status: Disclosed Recipient: Google Analytics Recipient Category: Web Analytics
Object: Household Object Description: Customer Address Category: Geolocation data Status: Sold Recipient: GeoRus Recipient Category: Client
Object: Consumer Object Description: Employee Category: Biometric information Status: Disclosed Recipient: BioAccess Systems Recipient Category: Security Vendor
Object: Device Object Description: IP Address Category: Internet or other electronic network activity information Status: Disclosed (internal use only) Recipient: Hubspot Recipient Category: CRM

 


Filter for the age of consumers

Consumer age is important for all pieces of privacy legislation, but specifically so for the CCPA. 



In Code 1798.120(c) the issue of age is dealt with as follows:

a business shall not sell the personal information of consumers if the business has actual knowledge that the consumer is less than 16 years of age, unless the consumer, in the case of consumers between 13 and 16 years of age, or the consumer’s parent or guardian, in the case of consumers who are less than 13 years of age, has affirmatively authorized the sale of the consumer’s personal information. A business that willfully disregards the consumer’s age shall be deemed to have had actual knowledge of the consumer’s age. This right may be referred to as the “right to opt-in.



The important implication here is that by ignoring age, and then selling consumer data that may contain children under the age of 16, you are by default contravening the law and may face maximum penalties.

For this reason, when preparing for CCPA compliance you will need a clear classification of your consumer data by age. When filtering for age you will initially have the following brackets:

  1. Older than 16: consumers in this age bracket have the right to opt out of having their data sold
  2. Between 13 and 16: consumers in this age bracket must opt into having their information sold
  3. Below 13: consumers in this age bracket will require a parent or guardian to opt them into having their data sold
  4. Unknown: if you have age-related data, consumers in this bracket needs to be excluded from any sales until you can confirm their age

Important note: When it comes to age verification it is better to err on the side of caution.  Section 1798.100(d) notes that data gathered for a one-time transaction, or data that wouldn’t under normal operating circumstances be maintained, is not required by the CCPA. The possible implication here is that should one not normally maintain age-related information, the CCPA wouldn’t require it. However, the fact that the law emphasizes age verification means that it should be seen as data that must be maintained for the sake of compliance.


Filter for Californian residents (consumers)

With a fully mapped data set, the final step is to filter for Californian residents. Outside of the borders of California, your data might contain website visitors or customers who reside in California.

Filtering for consumers from California can be on the basis of any address records, or on the basis of geolocation or IP location.

Important note regarding employee data: At this time there are still debates as to the extent  to which employee data will be subject to the CCPA. Without any amendments, the law extends fully to employees, however, a recently proposed amendment (AB25) will restrict the way in which employee data is managed under the CCPA. Regardless of whether employee data is subject to the CCPA, it is good practice to ensure maximum privacy protection for this type of data.

CCPA Chapter Icons-01
Chapter 5

Step 2: Update your legal documents

Your first line of defense

Love them or hate them, legal documents are critical when it comes to compliance. This is one of the first places regulators will look, and they act as a guide to ensure further compliance. More importantly, should your business ever be challenged in court for non-compliance, your legal documents will play an important role in your defense.

More than just a privacy policy


The CCPA makes specific mention of privacy policies and the ways in which they need to reflect information specific to California residents or households in Code 1798.135(a)(2) and (3):


(a) A business that is required to comply with Section 1798.120 shall, in a form that is reasonably accessible to consumers...

(2) Include a description of a consumer’s rights pursuant to Section 1798.120, along with a separate link to the “Do Not Sell My Personal Information” Internet Web page in:

(A) Its online privacy policy or policies if the business has an online privacy policy or policies.

(B) Any California-specific description of consumers’ privacy rights.

(3) Ensure that all individuals responsible for handling consumer inquiries about the business’s privacy practices or the business’s compliance with this title are informed of all requirements in Section 1798.120 and this section and how to direct consumers to exercise their rights under those sections.

 


CCPA vs GDPR: It’s a matter of detail

GDPR is a more verbose law than that of the CCPA. However, they both require that legal documents of various flavors are updated to include the data privacy rights of the data subject or consumer.

The content of these changes will differ in line with the requirements of the specific law, and in the case of the CCPA, this would be focused on the sale of data and the rights of the consumer to opt out of this process.


Practical steps to take


Privacy policy

The key document that will need your attention is the privacy policy. You can opt for a California-only section or integrate the various parts into your privacy policy as a whole. Some areas to consider include:

  • Paragraphs on requesting data disclosure, deleting data and opting out; be sure to include a direct link to the “Do Not Sell My Personal Information” page
  • Identifying broad usage categories that personal data falls into
  • Identifying third-party categories to whom data may be sold
  • Explaining the right and process to opt out of third parties selling the data on
  • Including applicable definitions from the CCPA 1798.140
  • Indicating applicable exclusions from CCPA 1798.145
  • Clearly stating your commitment to data security and explaining the breach procedure

Cookie policy

The changes are not limited to your privacy policy. Presuming that you have a cookie policy in place (which is a good idea for GDPR compliance anyway), this too will need to reflect information on the rights of Californian residents.

Cookies are designed to track behavior on websites, and any data, even the consequent insights associated with the data, is considered personal information within the context of the CCPA. When updating your Cookie Policy, consider adding a specific section for Californian residents.


Employee contracts

You may need to update employee contracts in two different ways:

The first is to include clauses that cover the responsibility of the employee to honor the various data privacy laws with which the company is required to comply. In the contracts itself, these may be broadly stated to include all the relevant laws, but make sure to back it up with proper training on each of the specific regulations. Training or awareness is specifically required by the CCPA and should not be neglected.

Secondly, for companies that operate within the borders of California and have residents as employees or subcontractors, there may be a need to update the relevant employment contracts to indicate the rights afforded to them by the CCPA as it relates to the personal information you collect. You should also consider including the limitations of their rights, for example, they may not be able to request deletion of their data as you are practically and legally obliged to maintain their records to operate.

Important note regarding employee data: At this time there are still debates as to the extent  to which employee data will be subject to the CCPA. Without any amendments, the law extends fully to employees, however, a recently proposed amendment (AB25) will restrict the way in which employee data is managed under the CCPA. Regardless of whether employee data is subject to the CCPA, it is good practice to ensure maximum privacy protection for this type of data.


Third-party agreements

Any agreements with third parties may need to be updated to reflect the rights of the Californian consumers that are transferred along with data that is being sold. This should include a notice that third parties may not resell the data they bought without an explicit notice to the consumer, and giving them a clear means to opt out.

If you are collecting consumer data from California-based vendors as part of your operation, you may also need to include some information on their rights as related to the CCPA.

CCPA Chapter Icons-01
Chapter 6

Step 3: Assess data sales processes

What’s in a name?

The CCPA in its current format is a broad-strokes type of law. Instead of providing detailed definitions for terms, the authors decided to rather apply a single term across a broad range of functions or activities.

A core right given to consumers by the CCPA is that of opting out of the sale of their data, and due to the broad definition for the term ‘sell’, the requirement to review all the processes related thereto is a priority.

Of definition, discrimination and incentives


In Section 1798.140(t)(1), the CCPA states the following:


'Sell’, ‘selling’, ‘sale’ or ‘sold’ means selling, renting, releasing, disclosing, disseminating, making available, transferring, or otherwise communicating orally, in writing, or by electronic or other means, a consumer’s personal information by the business to another business or a third party for monetary or other valuable consideration.

 


This section provides us with a definition of what the law looks at when it talks about the selling of personal information. Section 1798.125 highlights two aspects of the sales process, namely that businesses can’t discriminate against consumers who exercise their CCPA rights, and that businesses are allowed (within reason) to incentivise data collection.


CCPA vs GDPR: To sell or not to sell – that is the difference

With its focus on general data protection, GDPR makes no direct mention of the sale of data.  Instead it focuses on processors and controllers, and giving the data subject the right to opt in to different business activities. This means that the selling of data under GDPR is a matter of proving that the data subject

a) was informed that their data may be sold when they provided it and 
b) gave consent that the data may be used for these purposes.

The CCPA places heavy emphasis on the sale of personal information as a specific business function, but generally reflects the idea that the consumer must be informed that their data may be sold. Different to GDPR however, the consumer must be given a clear path to opt out, rather than provide initial consent.


Refine the list

In the first step you mapped your data and ended up with a list that indicates which data objects are sold, and which data is disclosed, but not sold.

Using the definition provided by the CCPA, you can now add additional depth as follows:

Object Object Description Category Status Sale Type Discrimination? Incentive?
Object: Consumer Object Description: Product Preferences Category: Behavioral Status: Sold Sale Type: Partner Data Exchange Discrimination? Yes Incentive? Yes
Object: Household Object Description: Customer Address Category: Geolocation Data Status: Sold Sale Type: Renting Discrimination? No Incentive? No


During this exercise, you will need to be very honest about the differences in the nature of the product or service that the consumer gets when their personal information is available, versus when they opted out. The law will allow a difference in what you deliver if you can show that the personal information is a necessary component to provide the given enhancements. However, if you can deliver precisely the same product or service regardless of personal information, then by law you will need to do so.

Here you will also have the opportunity to think through any incentives that you may incorporate in your request for personal data. On the one hand you may consider new ways to entice people to provide their personal information, but on the other hand you will need to make sure that any incentives are legally acceptable.

Using the enhanced mapping you can devise strategies for:

  1. Compliance where discrimination in products or services can’t be justified
  2. Compliance, and improvements, where incentives apply
CCPA Chapter Icons-01
Chapter 7

Step 4: Implement consumer processes

Time to do something

With your data properly mapped out and the data sales processes clearly identified, you can implement updated consumer data processes. This is the first practical step towards measurable compliance which means that this part of the project should get adequate attention.

In this chapter we will look at the major consumer processes required by the CCPA, and what it will take to implement them.

Processes to verify, share and delete data

There are two sections of the CCPA that speaks to business processes, namely Sections 1798.130 and 1798.135.  What we can deduce from these sections is that the following processes need to be in place:

  1. Data request (Right to Know) and data portability, including consumer verification and authorization
  2. Process to opt out of the sale of data (Right to Opt Out)
  3. Consumer data deletion process, including appropriate decision trees to determine if deletion is warranted and can be executed
  4. Various notification processes, including breach notifications
  5. Where applicable, age verification and parental consent

CCPA vs GDPR: One critical difference

GDPR is explicit about the need for data subject processes, which makes it very similar to the CCPA:

  1. Data subjects have the right to request their information from processors and controllers
  2. They have the “Right to be Forgotten” (have their data removed) under specific circumstances
  3. Notifications are required for breaches and critical changes to the data processing systems of procedures
  4. Age verification is required given certain circumstances

The critical difference between GDPR and the CCPA is that of opting out versus opting in.  Where the CCPA requires a business to establish an opt-out process only for the sale of data, GDPR requires an explicit opt-in process, not just for processing of data, but also for different types of communications. This makes the GDPR more complex to implement and, at face value, more restrictive in the ways that data can be used.


Getting the processes right


Data request and data portability

The CCPA allows consumers to request a report on the data you hold and sell. Before you divulge this information, however, you must be able to positively verify the identity of the consumer and match them to the data on your system. As a first step you should plan and implement such a verification process.

As a general rule, compliance is determined by the extent to which an auditor can find proof that you did whatever the law requires. When it comes to the verification process, keep in mind that logging of the steps within the data request process will allow you to show auditors how you verified such consumer identities. If your process isn’t secure enough, you may have false positives and divulge personal information without consent. But if your process is too controlled it may block legitimate requests and possibly require excessive resources to perform what ought to be a relatively simple task.

Be sure to align your process with the requirements of the law. It must be delivered free of charge, and where possible within a 45-day period. There is some leeway regarding both points, but getting this right will be the first step to practical compliance. Also note that at a minimum you need a toll-free number and a website link as channels through which such requests can take place.


Opt-out processes

A primary purpose of the CCPA is to provide consumers with a way to opt out of the sale of their information. As a result, there must be a supporting process for consumers to opt out of any processes that constitute ‘selling’ their information.

Opt-out processes require positive verification either of the consumer submitting the request, or of the authority given to the person who is opting out on behalf of a consumer.

Data of consumers who opted out must then be excluded from any activity that the law defines as ‘selling’ (See Chapter 6).


Deletion requests

As with data and opt-out requests, deletion requests require positive verification of the consumer submitting the request.

Different to other processes, however, the deletion process must consider the purpose of the data and whether or not the request to delete it is legitimate. For example, if an employee requests that you delete their information, that would impede on your ability to process their salaries. The CCPA allows you to then retain their information because it is an integral part of your business operations.

Once the verification is successful and the data is found not to be required for your business to operate or fulfill its function, you should delete the information.


Notification processes

The CCPA wants to ensure that consumers remain informed about what you are doing with their data. You will need to provide notifications in the following situations:

  1. On collection of their data regarding the categories of data you are collecting, and the purpose for which you are collecting the information. This may also be a notification displayed at the collection point, such as a clearly visible paragraph underneath a web form.
  2. On selling the data to a third party who will be reselling the data. Consumers need to get the opportunity to opt out of the secondary sale of their data by the third party.
  3. On offering financial incentives related to the acquisition of consumer data.
  4. On the extension of the 45-day deadline for the provision of data, explaining the reason why the request for data could not be completed within the allotted period.
  5. On the transfer of consumer data as an asset during a business merger or acquisition.
  6. When the new owner of the data assets intend to change the way in which the data will be used (related to the previous point).
  7. When a data breach occurs.
  8. When refusing requests by consumers, such as in the case of excessive or unfounded requests for data.

A good rule of thumb is to make sure that any notices are clear and easily accessible, and provide the consumer with a way to respond, especially in those cases where they need a way to opt out.


Age verification and parental consent

In Chapter 4, we touched on the issue of age verification. The CCPA states that you wouldn’t need to gather data that you wouldn’t normally gather in an effort to become compliant. However, the law also states that there can be severe penalties for selling data for consumers under the age of 18, where opt-in is required.

It is better to err on the side of caution if you are likely to store the data of younger consumers.  Age confirmation and opt-in are required below the age of 18, and parental consent below the age of 13, specifically for the sale of data.

CCPA Chapter Icons-01
Chapter 8

Step 5: Update your systems

Systems are process tools

Whenever a process changes, the system must follow, otherwise you would never achieve the expected results. So in that way a system is a reflection of the process, or a process tool. In this chapter we look at the fundamental changes that a system needs to improve compliance.

Relevant sections from the law

Sections 1798.115 and 1798.120 should be read in conjunction with Sections 1798.130 and 1798.135 in Chapter 7. The essence of the sections is that the consumer has the right to request a report on their data, and be given the opportunity to opt out of the sale thereof, among other things. In the previous chapter we looked at the processes that would be required for compliance, and in this chapter we will apply those processes to typical systems.

These are the processes and their related systems that will require updating:

Process Systems
Data request and portability
  1. Consumer identity verification system
  2. Data copy and transfer system
Opt-out of sales of data
  1. Consumer identity verification system
  2. Automated opt-out system
  3. Manual opt-out system
Consumer data deletion
  1. Consumer identity verification system
  2. Deletion request validation system
  3. Data deletion system
Notifications
  1. Consumer identity verification system
  2. Data copy and transfer system
  3. Automated opt-out system
  4. Manual opt-out system
  5. Deletion request validation system
  6. Data deletion system
  7. Data capturing system
  8. Age verification system
Age verification
  1. Data capturing system
  2. Age verification system

 


CCPA vs GDPR: Think like an auditor

With both the CCPA and GDPR, the key is to set up your systems so that there is a clear and unambiguous audit trail. Every action taken on the system must be recorded, or you must retain some form of proof that actions were completed, or were not completed as they were otherwise interrupted. GDPR requires that systems do what the law requires, and the proof sits with auditable log files and system reports.


Four quick wins

Due to the variability of the systems out there, this guide can’t share all the changes that need to be implemented. But there are a number of quick wins that any team can take to get on the road to compliance.


Quick Win 1: Add “Do not sell my personal information” link to the website

One of the first, and most visible, changes that you can make is to add a link on your website that allows consumers to opt out of the sale of data. In the CCPA, this is known as the “Do not sell my personal information” link.

The link should lead consumers to a web page that provides a toll-free number for consumers to opt out of the sale of their information. The page should also provide a way for consumers to submit an opt-out request by completing a form or by an appropriate alternative electronic way.

Keep in mind that you will need to be able to manage these opt-out requests on your system.  Normally this entails the addition of an opt-out field on a database that can be checked automatically or manually by your support staff.


Quick Win 2: Implement updated policies on the website

Include a section in your privacy policies that specifically deals with the CCPA. In this section you should make note of the rights of the consumer in California, as well as the processes by which consumers can exercise those rights on your website. You should include a link in this section to the “Do not sell my private information” page.

It is also a good idea to include timeframes for handling data requests, and indicate any costs that may be incurred for requests that exceed the annual limits of free requests set by the CCPA.


Quick Win 3: Mask data where applicable

Masking data is a powerful way to ensure that data is secure in certain circumstances. Data masking is effective because it decreases the value of data to intruders, and ensures that any data breaches have a smaller potential footprint for damage.

This is particularly important in test environments where developers have full system access, but data may not be as secure as within a production environment. Masking data allows developers to work with full data-sets without the risk of exposing personal information.


Quick Win 4: Apply encryption

With its focus on the sale of data, security of data in transit is of critical importance for CCPA compliance. As yet another quick win, you should implement encryption where possible to ensure that data is rendered inaccessible by outside attacks.

CCPA Chapter Icons-01
Chapter 9

Step 6: Communicate with your consumers

Data privacy is a conversation...

The general attitude to private information used to be the same as any other piece of data found on the internet: if you found it, you can keep it. The complete freedom of sharing information is what makes the internet great, but it is a double-edged sword, as this freedom comes at the risk of the individual.

...and the conversation is based on a relationship


In its preamble, the CCPA states the following:


(h) People desire privacy and more control over their information. California consumers should be able to exercise control over their personal information, and they want to be certain that there are safeguards against misuse of their personal information. It is possible for businesses both to respect consumers’ privacy and provide a high level transparency to their business practices.

(i) Therefore, it is the intent of the Legislature to further Californians’ right to privacy by giving consumers an effective way to control their personal information, by ensuring the following rights:

(1) The right of Californians to know what personal information is being collected about them.

(2) The right of Californians to know whether their personal information is sold or disclosed and to whom.

(3) The right of Californians to say no to the sale of personal information.

(4) The right of Californians to access their personal information.

(5) The right of Californians to equal service and price, even if they exercise their privacy rights.




 

Without open lines of communication, you won’t comply with the spirit or letter of the law.  To communicate effectively, you need to see the consumers on your database as real people that will now have a say in how you can use their information.


GDPR shares the CCPA spirit

The same underlying motivation applies to GDPR and the CCPA. The intent is not to block businesses from doing business, but rather to open up the channels through which consumers or data subjects can manage their relationship with businesses. In fact, GDPR clearly states that the “free movement of personal data within the Union shall be neither restricted nor prohibited for reasons connected with the protection of natural persons with regard to the processing of personal data.”

Privacy laws are not intended to restrict, but rather to empower the consumer or data subject.  Before these laws came into practice, the relationship between data subjects and processors were skewed to the data processor who had free access to personal information without needing to take much responsibility for how it is used.


Make the first move and tell them what changed

A great way to get your CCPA conversation started is to let the consumers on your database know what changes you made towards compliance, and how it affects them. Here are some key points you should raise in your communications with them: 

  1. What the CCPA is, and what it means to them
  2. What you did to ensure that you are compliant
  3. Links to all the necessary mechanisms they will need to manage their privacy (including opt-out forms, data request and deletion request systems).

Finally, give them the opportunity to provide you with updated information. For example, if knowing their age is important, they need to provide a date of birth to help you manage your compliance in this regard.

Here is a sample email you can adapt for your own purposes:


Dear Consumer,

The California Consumer Privacy Act (CCPA) is a law that is designed to give you more control over your personal data. Since this law applies specifically to you as a resident of California, we thought you might find the following information useful.

We have worked hard to ensure that our systems are updated to comply with the law. What this means is that we have made the following changes:

  1. We have updated our Privacy Policy to give you clear information on your rights
  2. We have created special pages for you to opt out of the sale of your information, as well as requesting what data we have about you, and finally requesting that we remove your data from our systems if you wish us to.
  3. We have scrambled any personal data that we don’t need. For example, some personal data like IP addresses may have been used for statistical purposes in the past. However, now these addresses are permanently hidden.
  4. We have added additional security by upgrading our encryption. If hackers can’t read your data, they can’t use it.

The result is that you now have more control over the personal data that is on our systems, and it is much safer too.

We do have one favor to ask: For the best protection of your information, we need to confirm your age. Please click on the link below that best describes how old you are, so that we can make sure to manage your data in the best way. This information will only be used in accordance with the law and not for any other purpose.

I am younger than 13

I am between 13 and 18

I am older than 18


Regards,
The Data Privacy Director

CCPA Chapter Icons-01
Chapter 10

The CCPA and SAP: Things you can do right now

CCPA compliance on SAP is double the complexity

The power of SAP is its incredible flexibility on enterprise scale. In an ironic twist, the flexibility that SAP provides is also its Achilles heel: to be more flexible, SAP requires complexity. With a myriad of data tables interlinked in a nearly endless number of possible ways, trying to implement even basic compliance can be a tough job.

Where complexity brings flexibility in SAP, the same can’t be said of compliance legislation. Not only do compliance officers need to understand the nuances of laws across different geographies that are often vague, they need to know how these laws affect processes and systems in practice.

The bad news is that no tool on earth can currently guarantee full compliance with all privacy laws in all jurisdictions. The good news is that there are a number of things your organization can do to get your SAP systems closer to compliance.

In this chapter we will look at the practical steps you can take to extend your CCPA compliance project to your SAP systems, and provide you with a few tools that you can use to help you along the way.


Know your data and flows

As outlined in Chapter 4, you have to understand exactly where your CCPA-related data resides and how it flows through systems. It is highly likely that your SAP systems don’t live on an island, and interface with many other systems and providers, like your vendors, banks and client-facing systems. SAP ERP often acts as a central nervous system that interacts with many other external systems through various interfaces. Understanding this data movement is key to knowing what data you have, how it’s used, and where it should be protected. Step through your business processes to ensure you’ve covered the end-to-end flows. For SAP systems, also note that sensitive data might be duplicated over numerous tables and systems throughout your landscape. Examples might be CRM, ERP and BW systems spread over development, QA and production landscapes.  


Limiting access

One of the easiest ways to lose control of how data is used is to give people access to it. An overeager new hire might not know what the company policy states with regard to data usage. Or a malicious insider could download customer records and sell it to a competitor (something that happened at a previous employer of a close family member of mine). It makes sense to review your SAP authorizations and roles, and maybe even do a redesign of everything that can touch sensitive data. You should ensure that only people with ‘a need to know’ have access to this data. This brings us into traditional SAP GRC territory, which many people shy away from due to its complexity. Fortunately, there are simplified solutions available to identify and correct data access risks, like Soterion’s Access Risk Manager. Instead of a multi-month GRC project, you can nearly instantly audit your access risk specifically as it relates to GDPR and POPIA.


Security beyond GRC

People often think narrowly of SAP security as roles and authorizations. However, breaches in SAP security can happen in a myriad of other ways, like unpatched systems, bad Basis and systems configuration parameters, custom code, and  “debug hacks” that most seasoned ABAPers know about. You can have the best roles and authorizations money can buy, but it won’t protect you from any of the other vulnerabilities. The attacker has many possible paths, and only needs one to work to be successful.

Companies need to do a comprehensive information security risk analysis on their SAP landscapes and understand the full spectrum of vulnerabilities. Once this is done, the most vulnerable areas can be prioritized for remediation. There are numerous SAP specific security products that can perform a vulnerability analysis efficiently, if you don’t want an army of auditors to spend months looking for them manually. Some useful products are the Onapsis Security Platform for systems security and Virtual Forge’s CodeProfiler that finds vulnerabilities and back doors in custom ABAP code.


Dealing with deletion requests

SAP is a powerful system because business processes are integrated through ERP, CRM, SRM, HR and more. It also means deleting data is not simple. You can’t just delete a single field or record, as this will break SAP’s data models and your systems will become inconsistent. For example, let’s say you delete a client from your system due to a deletion request. You might still have invoices related to the client and CRM interaction data, which will now be orphaned, and probably break some standard functionality.

If you decide to archive data as a means of complying with data deletion requests, you have to keep in mind that archiving is still a form of data storage and doesn’t necessarily comply with data deletion requirements.

You might also consider SAP UI masking. But is it sufficient to address the consumers’ data deletion requests? SAP UI masking doesn’t actually alter the records in the database, it merely masks portions of the data displayed to end users. In our opinion this is not sufficient for compliance, since the actual data is still stored. If the database itself is compromised, UI masking will not protect the sensitive data. We can’t imagine that the data protection authorities would look kindly on personal data leaked after the data subject explicitly asked to be forgotten.

At EPI-USE Labs, we’ve created Data Redact™ specifically to address compliance with the ‘Right to be Forgotten’. This is the only solution we currently know of that actually forgets data, as opposed to archiving or hiding it from end users. With Data Redact, you can selectively redact sensitive fields, without deleting the whole record. For example, you might replace Name, Email and Address fields with “REDACTED”, but keep financial, geographic and gender information for reporting purposes. As long as a record can no longer be used to identify a specific individual, this seems to meet the spirit of the law. The redaction settings are all highly configurable, and we’ve done all the hard work for you of mapping data between tables and systems. For example, when we redact a person’s record in ERP, we’ll also do so consistently across CRM.


Implementing retention policies

Agreeing on detailed data retention policies is one of the areas that companies struggle with the most during privacy compliance projects. You have to balance the business need for data with the consumer’s rights to privacy. It’s important that this is part of your project as a foundational step. Once the business rules have been captured in a policy, solutions like EPI-USE Labs' Data Redact and Data Retain can be used to help automate the selective redaction of sensitive data to ensure compliance.


Preparing for the worst

A comprehensive information security risk analysis of SAP landscapes should take into account Preparation, Detection, Response, and Recovery strategies. It’s easy to focus on Preparation, in other words preventing breaches, but early Detection, a co-ordinated, practised Response and efficient Recovery could ultimately mean the difference between a minor and catastrophic incident. You need to think about post-breach activities before the breach happens. In the SAP world, you can think about the following:

Detection:

  • Are your SAP systems integrated with your organization’s Security Information and Event Management (SIEM) systems?
  • Does your organization’s cybersecurity team understand SAP?
  • Do you have a mechanism to detect when data loss happens, for example when someone downloads an unusual amount of sensitive data, even if they are authorized to do so?

Response:

  • Do you have a security incident response plan that is tested on a regular basis?
  • Can your legal team, SAP technical experts and cybersecurity blue team work in an integrated and efficient way to respond to SAP-related incidents?
  • Do you know how to report incidents to data protection authorities and consumers?

Recovery:

Slow incident recoveries can hurt organizations tremendously. This is no different from any other unplanned downtime. Due to the uncertainty and stakes involved, security incident recoveries typically take much longer than recovery from other types of technical incidents. You have to plan, practice and improve. There is no shortcut.


Now is the time to act

Data privacy legislation is becoming increasingly complex as new laws bring unique nuances into organizations. The CCPA is no different; it was written with specific outcomes in mind that differ from those of GDPR.

Compliance projects take time to plan and execute, and with the implementation deadline looming, getting your proverbial data privacy ducks in a row is becoming more urgent than ever. 

If you followed this guide, you should have:

  • A better understanding of the CCPA and how it compares to GDPR
  • Clarity on the major steps required for a compliance project
  • A guide to four quick wins you can implement
  • An outline of how to manage the CCPA requirements for SAP

We hope you enjoyed the guide. If you have any questions, or would like further guidance on how the law applies to your business and how we can help, please contact us.


Download the CCPA Guide in PDF

  Table of Contents