CCPA: The ultimate guide for SAP systems

Comparing CCPA with GDPR

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.

Being a business and selling data

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?

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?

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

What is considered personal information?

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.

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.

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.

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.

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

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:

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:

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

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:

Filter for the age of consumers

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

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.

More than just a privacy policy

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.

Of definition, discrimination and incentives

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:

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

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.

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:

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.

...and the conversation is based on a relationship

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:

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.