CX Works

CX Works brings the most relevant leading practices to you.
It is a single portal of curated, field-tested and SAP-verified expertise for SAP Customer Experience solutions

SAP CPQ & GDPR Compliance

8 min read

The question of data privacy is often posed at all phases of an SAP CPQ project - sales cycle, design & implementation, post-go live & issue tracking.

This article will focus on describing features that SAP CPQ offers; meeting GDPR (General Data Protection Regulation) requirements and also what you can additionally configure to extend the scope of data protection on your project. The features list was extended in the last few years and the administration was reorganized to enable users to have firmer control over their private data.

Table of Contents

In General on SAP CPQ and GDPR

GDRP is a wide set of regulations that, since the roll out in 2018, enforces rules aiming to protect data privacy for end users. The clauses mostly relate to data controllers (companies that own data-processing infrastructure) and processors (those who eventually process data on their behalf).

SAP CPQ does not just deal with data which every application standardly protects, like end user data - it performs data processing for client customers and keeps sales records, which all qualifies as confidential. Hence, it was important to provide an infrastructure that out of the box protects access to private data and also enables administrators to include lots more into this category.

Not all GDPR clauses are dealt with in the way that the client administrators have access or obligations in regards to it. For example, regulations that enforce data controllers to store private data of EU (European Union) citizens inside of EU are implemented through our operations procedures and are already stated as part of initial contract. No actions are required from client administrators or project implementation teams regarding this. A data center is chosen according to location and its operational standards are already neatly structured.
Some of the GDPR requests are met with the code structure itself: for example, one that demands that all data encryption is executed locally or that encryption keys are kept only by data owner if a cloud service is used for the purpose.

This article will deal with SAP CPQ GDPR compliance from the aspect of project implementers and client administrators.

Treatment of Private Data

Now, let us talk about how the actual fields with private data are treated inside of the application:

  • If a data field is not private and by that does need to be protected, the field can be used regularly and its changes, together with the old and new values will be recorded by Audit Trail and be available to all administrators.
  • If a data field needs to be protected and its access highly limited than it is treated as being PII (Personally Identifiable Information). 

As stated, many basic SAP CPQ functional objects contain data that is private per se. Hence, user and customer data is flagged as PII by the application itself. But, it is quite expected that other objects inside of SAP CPQ are marked as PII also. For example, custom database tables with user or customer data are often created as part of standard processes (e.g. for needs of a pricing routine). 

The same can apply for the content of quote custom fields, quote tables, attributes... For all those you can tick "Contains Personally Identifiable Information" flag and make the object or its property PII:

GDRP demands that records are maintained for all processing activities of personal user data.
So when a data field is marked as PII, change tracking will not be recorded by the standard Audit Trail feature, but in a different module available inside of SAP CPQ setup, named Personal Data Log.

Do note that by default, Personal Data Log is accessible for every tenant administrator and that you need setup from "Access control" section below to narrow down the access rights. 

If data is deemed sensitive and not just private (PII), then just moving its tracking records to a different location in setup would not be enough. The reason is that, by default, if no configuration is applied, all menu sections are accessible to all administrators, including Personal Data Log.

Sensitive data must not be visible to administrators, but only to data owners. By rule, only after a field is flagged as PII, it can additionally be marked as Sensitive.
This further implies that when its change records are traced to Personal Data Log, empty values will be used in the place of field values.

Data Export

As one of the obligatory clauses of GDPR, a portable copy of private data collected by a controller, must be provided to a data owner on his demand. There is a section inside of SAP CPQ setup that provides exports for this purpose. It is called View/Export PII and it is also located in the Security group in the menu.

There, administrators can select individual users or customers and export all data in Excel or PDF format. An extended filtering module is added to the page to enable administrators to provide exports of meaningful data subsets too.

Data Removal

GDPR also contains "Right to erasure" which enables data owners to request removal of all their data within 30 days if noncompliance has been observed on a number of different grounds. The first option for data deletion in SAP CPQ is manual remove, which is available for all object pages in the setup. Administrators can, accordingly, remove individual data points.

As GDPR also demands that the length of data keeping is clearly communicated to data owners and that it can be stored only with their consent, features have been introduced to enable automatic data removal. If you go the section Security and choose Data Deletion, you will be able to work with a module that allows you to define automatic delete periods for the most data-sensitive objects in SAP CPQ : users, customers and quotes.

Access Control

In the sections above, you have probably noticed, that even though some data or field was marked as sensitive, it was still readily available to regular administrators if they maintain the specific object page. For example, an administrator can see the value of a sensitive user custom field if he is able to administer the particular user page.

This can be further restricted with one of the latest SAP CPQ access-control features: Access Rights.

The feature allows you to start from an individual administrator or a permissions group and define which setup sections he/it can access. This enables you to tighten access rules for setup pages and allow data access only to people who need to maintain it directly.

Pay attention that the feature is not available in the application menu by default. You have to create a request for SAP Support to get it activated for your tenant and then proceed with configurations in an unhindered manner.

As an example, if you apply the following setup in Access Rights, for a certain administrator account (and for the db table from above):

Then, the screen the administrator would see, upon entering the setup the next time, would be like this:

Security Features in General

Although GDPR deals mostly with owner's rights over data collected by data controllers, SAP CPQ includes other general security features which protect against data breach and by that further enhance protection of data privacy. Several of them you will find in the Security section of the menu. For example, you can use Certificate Management to secure web services communication or use DKIM to add digital signatures to outgoing emails.

These features are not directly tied to GDPR, but in general, by elevating the application security and by prohibiting intrusions and data tempering, data privacy protection gets strengthened further.


Multiple features were introduced to SAP CPQ in the last few years to provide GDPR compliance and make sure private data is protected. The features will automatically handle data which is marked as personal by default, but you have to flag all other data of yours that you consider personal or sensitive.

Use the article above as a quick guide for all functionalities exposed for the purpose, though you can always navigate to the official SAP CPQ documentation to get more details about each of those.

If, for the purposes of your project, you need a document which deals with our operations infrastructure in the context of GDPR compliance, do open a ticket with your official SAP Support channel. Missing information about organizational details pertaining to GDPR, like SAP data protection officer, you can ask for, through the same channel.

Do not skip to read the whole series of articles that deals with different SAP CPQ functional topics of utmost interest for your project implementation.