SAP CPQ & GDPR; a Match Made in Data-Privacy Heaven

Data privacy continues to grow in popularity as a topic both consumers and businesses are deeply concerned about. 

During each phase of an SAP CPQ project; from sales cycle, to design and implementation, to post-go live and issue tracking, data privacy questions come up. 

This article will discuss how GDPR (General Data Protection Regulation) requirements are met by SAP CPQ seamlessly, and also describes additional configurations which will enhance the scope of data protection on any given project. In the past few years SAP has added to the features list, and users can now have better control over their data due to reorganization of the administration. 

CPQ and GDPR: A Brief Overview of Their Interrelation 

GDPR refers to General Data Protection Regulation which is a broad set of laws set by regulatory bodies regarding data privacy for consumers and end users. Clauses of these laws are set in relation to data controllers (parties or companies which own data-processing infrastructure) and processors (those who process data on the companies’ behalf). 

SAP CPQ is a special case given that it not only deals with user data, but executes data processing for client customers and maintains sales records, all of which is confidential under GDPR’s regulatory standards. Given this, providing an OOTB (out of the box) infrastructure which protects access to private data, while enabling administrators to include more, was a necessity. 

GDPR clauses are not all handled similarly by CPQ. While administrators have access or obligations pertaining to some of the regulations, some that enforce data controllers to store private data of EU (European Union) citizens are implemented upon commencement of initial contract. In this case, no action is required from client admins or project implementation teams. Data centers respectively are neatly structured and selected or assigned based upon location. 

Code structure itself can handle some of the regulations, specifically execution of data encryption, and encryption keys being kept by data owners if cloud service is used. 

This article will cover compliance with GDPR as it pertains to CPQ from the viewpoint of project implementers and clients administrators. 

Treatment of Private Data

When it comes to fields with private data, they’re treated thusly inside of CPQ 

 – Data fields that don’t require privacy or protection can be used regularly. Audit Trial records existing and new values, and all admins will have access

-Data fields which need protection have their access limited and are treated as PII (Personally Identifiable Information) 

On the whole, most SAP CPQ projects by their nature contain data which is private and subject to GDPR. Customer and user data is typically marked as PII by the application automatically. Other objects inside of SAP CPQ need to be marked as PII manually – such as custom database tables with user or customer data, and those datas created within standard processes like pricing routines. 

This would also apply to quote custom fields, quote tables, and attributes. The manual setting involves selecting “Contains Personally Identifiable Information” to designate these objects or any of their properties as PII. 

GDPR’s dictates demand the maintenance of records for all the ways in which personal user data is processed. 

Marking a data field as PII will not enable change tracking to be recorded by the standard Audit Trail feature, but in a different module available inside of CPQ which is the *Personal Data Log* (bold) module. 

Personal Data Log is accessible for every tenant administrator by default. Within the “Access control” section you can edit access rights and permissions. 

Data that is designated as sensitive rather than simply private (PII) will require more than simply moving tracking records during setup. A configuration must be applied, or all menu sections remain accessible to all administrators, including Personal Data Log. 

Administrators cannot view sensitive data, which is only permitted to be viewed by its owners. Data can only be flagged as “Sensitive” after it has been flagged as PII.

Thusly, when its change records are tried to Personal Data Log, empty values are put in place of field values. 

Data Export 

Portable copies of private data collected by controllers are mandated to be provided to data owners at their request. This is an obligatory clause of GDPR. Within SAP CPQ’s setup, there is a section; View/Export PII (bold) which enables exports for this purpose. This is located in the Security Group in the menu. 

View/Export PII can be used to select individual users or customers, and export all data in Excel or PDF format. An extended filtering module can be added to the page which will allow admins to also export other data sets which customers and users are likely to demand. 

Data Removal

“Right to erasure” is another GDPR dictate. This gives data owners the ability to request the removal of all their data within 30 days in the event of noncompliance, or on other grounds. Manual removal is the first option for data deletion, available for all object pages within setup. Removal of individual data points is then permitted to administrators. 

Duration of data keeping must be clearly communicated to data owners per GDPR. Data can only be stored with owners’ consent. Therefore, features which enable automatic data removal have been added to CPQ. Within the Security section, under Data Deletion, there is a module which allows definition of automatic deletion periods for the most data-sensitive objects; users, customers, and quotes. 

Access Control

Regular administrators still have access to data fields marked sensitive when they’re maintaining specific object pages. I.e., admins can see values of sensitive custom fields if they have access to particular user pages. 

Further restrictions can be applied via Access Rights, an SAP CPQ access-control feature. 

The Access Rights feature allows you to begin with permissions groups or individual administrators to define the setup sections that can be accessed. This will enable you to place tighter access rules for setup pages, only giving data access to those who need to directly maintain it. 

Note that this feature is not available in the application menu by default. SAP Support must be contacted via request for activation, for the tenant, in order to move ahead with configurations unencumbered. 

See the following setup in Access Rights, for a certain administrator account:

Next, the administrator sees a changed view when they enter the setup the following time:

Security Features Overall

Owner’s rights with regards to data collection are the main concern of GDPR. However, SAP CPQ also includes general security features that offer protections from data breach broadly, and so offer the end users and consumers, along with the org, another layer of data privacy. Most of these can be found in the menu’s Security section. Certificate Management is one such tool, which is used to secure web services communication. DKIM is another which will automate digital signatures onto outgoing emails. 

While these are not directly correlated to GDPR, they prohibit invasion and data tampering, and generally enhance the application’s security, thus strengthening data privacy protection. 

Summation 

In the past few years, an array of features has been added onto CPQ in order to comply with GDPR and ensure data protection. Features automate the handling of sensitive data for the most part given that it is marked as personal. You will only need to discern which data needs to be marked, and CPQ will do the rest. 

Additional navigation of the CPQ system can be found in the official SAP documentation

You can always open a ticket with your official SAP Support channel for further assistance with securities features. And get in touch with ASAR if you have queries on the implementation, integration, or use of CPQ. 

Share Article

Share on facebook
Share on twitter
Share on google
Share on linkedin

Recent Topics