Overview
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.
Let's focus on the features that SAP CPQ offers; meeting GDPR (General Data Protection Regulation) requirements and also what you can configure additionally to extend the scope of data protection on your project. The CPQ administration has been reorganized to enable users to have firmer control over their private data.
In General on SAP CPQ and GDPR
GDPR is a wide set of regulations that, since its introduction 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 qualify as confidential. Hence, it is important to have an infrastructure that protects access to private data as standard and also enables administrators to mark additional data as private in the system.
Not all GDPR clauses deal with the access client administrators have in the system or the obligations they have with regard to the data of their customers. For example, regulations that enforce data controllers to store private data of EU (European Union) citizens inside the EU are implemented through SAP's operations procedures and are already stated as part of the initial contract an organisation signs with SAP. No actions are required from client administrators or project implementation teams regarding this. A data centre is chosen based on location and its operational standards are already neatly structured.
Some 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 the 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 the application:
If a data field is not private and therefore 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 the Audit Trail and be available to all administrators.
If a data field needs to be protected and its access highly limited, then it is treated as being PII (Personally Identifiable Information).
As stated in the introduction, many basic SAP CPQ functional objects contain data that is private per definition. Hence, user and customer data is flagged as PII by the application itself. But, it is expected that other objects inside SAP CPQ are also marked as PII. 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 and so on. For all those, the "Contains Personally Identifiable Information" flag can be added and make the object or its property PII.
GDPR 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 rather in a different module available inside the SAP CPQ setup, called the Personal Data Log.
Note that by default, Personal Data Log is accessible for every tenant administrator and that you need additional setup in the "Access control" section to narrow down the specific access rights.
Furthermore, if data is not only private (PII) but deemed sensitive, 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. As a rule, only after a field is flagged as PII can it additionally be marked as Sensitive.
This further implies that when its change records are viewed in the Personal Data Log, empty values will be used instead of the actual field values.
Data Export
One of the obligatory clauses of GDPR requires that a portable copy of private data collected by a controller must be provided to a data owner upon request. There is a section inside of SAP CPQ setup that provides exports for this purpose, 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 to 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 the 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 removal, 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 time data is kept 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 to the section Security and choose Data Deletion, you will be able to work with a module that allows you to define automatic deletion 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 fields were 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 they can access. This enables you to tighten access rules for setup pages and allow data access only to the people who need to maintain it directly.
Note that the feature is not available in the application menu by default. You have to create a request to SAP Support to get it activated for your tenant, after which the necessary configuration can be carried out.
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 breaches, thereby further enhancing the data protection and privacy. Several of them can be found 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.
Conclusion
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 that you consider personal or sensitive.
If you want to know more about the features listed above, let us know! Our experts are eager to help you.