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

Data Protection in SAP Commerce Cloud

14 min read

Data Protection in SAP Commerce Cloud

In most cases, compliance with data privacy laws is not a product feature. However, SAP software supports data privacy, by providing security features and specific data-protection-relevant functions such as, simplified blocking and personal data deletion.

SAP does not provide legal advice in any form. The legal definitions and terms used in this guide are not from a legal source.

Your data protection requirements should outline what is necessary for your solution to be compliant with the requirements of the regions you operate in. This section covers potential data protection topics and how you to implement them.

Table of Contents

Consent Management


When you're tracking a customer’s data on your solution, using cookies, order entries, or other methods, make sure your customer understands their data is being tracked. This requirement applies to registered and anonymous users. If your customer does not consent to tracking, make sure your solution respects their request.

Further, your solution needs to account for merges between anonymous consent tracking and a registered user. With SAP Commerce 6.6 the ability to track anonymous users and then associate them to their registered account is covered in

Requesting Consent

Consent for retaining personal data needs to be an option for customer to agree to whenever data will be collected. These consent entry points , where consent can be provided, should be implemented in the appropriate sections of your solution. Additionally you could use SAP Customer Consent (part of Customer Data Cloud) to simplify the process. For example:

  1. The first time the data is to be collected (typically as part of the registration process).
  2. Whenever the customer decides they wish to have their personal data collected. This can either be done on a case by case basis where you may feel it is appropriate to advertise how collection of data may benefit the customer, or through something like their Account Management settings.

If you have multiple baseStores, it is important to realize that you can potentially have different consent types for each store and ensure your data model is set up to correctly achieve this.

As part of SAP Commerce 6.6, the consent request templates have been incorporated into the registration page as well as part of "My Account". The consent template examples are a part of the storefront code in the b2c_acc recipe. Further, new templates can be created, modified, or removed. For more details on how to adjust the templates please visit the Consent Template page.

Removing Consent/Data Retention

Your customer has the right to remove consent at any moment, which means:

  1. You have to provide a mechanism to display what they’ve consented to.
  2. You must provide an option to remove what they’ve consented to.
  3. You must respect laws around data retention; make sure your customer’s data is removed from your system, after its retention period. See Personal Data Erasure for how this is implemented in SAP Commerce 6.6.

Retention periods vary, depending on the type of data (tickets, orders, addresses and others). Make sure you have the retention periods documented, as part of your business requirements.

When a customer revokes their consent to have their information tracked or wants to close their account, the information should be deleted. Also, data that has past a retention period should be deleted Example cronjobs  are provided in SAP Commerce 6.6 to remove order, tickets, customers, and personal data reports, after a retention period has passed. If you don’t have this version, place an attribute that tracks consent changes and add cronjobs, which remove expired data that has passed the retention period. For older versions of SAP Commerce, you can  potentially leverage the Dynamic Maintenance Job to remove the relevant data

If you're using Data Hub, review how long the data is retained in the pool. In SAP Commerce 6.6 you can specify the retention period for a pool and have it permanently.

Data Anonymization

Most SAP Commerce solutions require integration with at least one 3rd party service. This means that personally identifiable information (PII) can be sent outside your network. One practice to secure PII is to anonymize it, by stripping the PII and replacing it with a hash. A second option is to anonymize or encrpyt the entire data, so that it can only be decrypted by the 3rd party, with the correct key. That way, if the data is intercepted it will not contain the PII or the data will be hard to decrypt.

SAP Commerce does not provide complete data anonymization, but you can use  Transparent Attribute Encryption to encrypt the data for specific item types. 

If you choose to anonymize the data by removing PII and replacing it with a unique identifier, then your SAP Commerce solution  becomes a pure customization because it is not a product feature.

Personal Data Reporting

Although audit trails are important, because they help track who is accessing the data, it is important for a customer to understand what type of data is being collected on them. As part of your data protection requirements you need to outline:

  • how many types of reports you need
  • what data should be displayed in the report
  • how the data should be displayed
  • who can generate and access the report

Using the Data Annotation Framework provided in SAP Commerce 6.5 you can define the reports and the data it generates. Once the report has been defined, we recommend you create at least one consent template to make it easy to read for anybody.

By default, the Personal Data Report can be created through the support ticket process. If you need to generate it elsewhere, you can always call:

// Assuming you have UserService injected by Spring
final UserModel user = userService.getUserForUID("sampleUser");
// Assuming you have AuditViewService injected by Spring and a audit config named 'sampleConfig'
final Stream<ReportView> report = auditViewService.getViewOn(TypeAuditReportConfig.builder().withConfigName("sampleConfig").withRootTypePk(user.getPk()).build());


Authentication is a key aspect of data protection because it verifies the user’s identity. Authentication is not to the same as authorization, which allows the authenticated user to access the system/data they are requesting.

Password Encryption

Passwords are a popular form of authentication. As part of your Account Management requirements you should include the ability for a user to create and change their password. On the backend, these passwords are typically stored and retrieved from the database. Regardless of the password policy you have in place, it is important to consider how the password is stored in your database, especially with the rise of cyber-attacks. We see passwords being stored in plain text, with weak encryption, or being reused. These practices can create issues for multiple solutions

Follow good practice; make sure the passwords you encrypt are hard to decrypt. If you're using a poor form of encryption you should consider Password Encoding Migration.

In addition to passwords, it is important to encrypt sensitive information. Use Transparent Attribute Encryption features within SAP Commerce to better secure your data.

Password Expiration

Having a password is the first step. But, to make your system is more secure and to comply with local regulations, you may need to set an expiration date for some or all of your passwords. This feature is not available in a vanilla version of SAP Commerce, but on a high level it requires you to:

  • Add a password and change date attribute to your User type
  • Modify your login to have a filter that checks if the password has expired and redirects the user to a change password page
  • Re-authenticate, once the password is changed

SAP CX Customer Success and Services has implemented this feature for multiple customers. Please email if you would like more details.

Two-Factor Authentication (2FA)

Two- factor authentication (2FA) is a type of Multi-factor authentication, where the user is asked for a password and a second factor of authentication, to prove their identity. The first factor for most commerce solutions will utilize a knowledge factors (for example, password + PIN). Those solutions implementing a second factor will usually use a generated token which the user retrieves from a mobile authentication app (like Google Authenticator), via mobile call/text or in some cases a physical token. Although the mobile call/text may be the most popular for a commerce solution, it has some drawbacks, including:

  • it requires the user to have their mobile device available when logging in
  • by using cellular technology it opens up the possibility of man in the middle attacks
  • it may require text/roaming fees in order for the user to get their message

Regardless, having a second factor is more secure than just a single password, but it does introduce added complexity for accessing your solution.

2FA is not available as part of SAP Commerce, but at a high level, if you're writing your own service it would require:

  • Modification to the authentication filter, to add the 2 nd factor step after password validation
  • An implementation of AuthenticationProvider to call your 2FA authentication implementation
  • A method to generate a token
  • A way to store the token
  • A way to send the token to the user (email and/or SMS)
  • A form for the user to enter the token
  • A way to validate the token entered by the user, corresponds to the stored token

SAP CX Customer Success and Services has implemented this functionality for multiple customers. Please email if you would like more details.

Integration with an Identity Provider

Another way to authenticate access to your application is to make use of an Identity Provider (IDP). When using the samlsinglesignon extension provides the request flow between the user, an IDP and your application to help achieve single sign-on (SSO). By utilizing an IDP and SAML you can achieve SSO functionality for backofficeassisted service module and C4C. A detailed example of setting up an IDP can be found SAML Single Sign-On Trail.

If you're looking to utilize OAuthfor authentication (typical for webservices) you can investigate whether the Platform as an ID Provider could work for you.

To make your application more accessible and provide a single source to secure and maintain, you can reduce the use of username/passwords and centralize authentication within an identity provider.


In some cases, you will have to restrict data access to users of a specific group, to make sure only business users that require access are able to view it. Having an effective User Management setup is critical to authorization working, as visibility is typically done at the user group level. Once you've defined your user groups appropriately you can set the type system permissions.

Audit Logging

Audit logging stores who performed what action (create, read, update, delete) on an item. Although we covered personal data reporting, we haven't discussed the importance of storing personal data or considerations around logging who creates, reads, updates, or deletes the data. Audit logging can help provide critical information during privacy breach investigation because it reveals when data was accessed. With SAP Commerce version 6.6 the Data Annotation Framework introduced in 6.5 was augmented with additional features to define and track changes for particular data types. A default implementation is provided which can be found in Generic Audit. It is up to you to determine what types need to be audited and configure your solution appropriately. 

Depending on how many types you choose to audit and how often they are changing, the size of your database can grow. Ensure you're configuring only those item types that are required and determine if there is a way to archive older audit data

3rd Party Integrations

In your  data protection requirements you need to identify the integrations that will be processing personal data. It is important to secure any communication with these third parties by limiting  the  PII you send and  minimizing the amount of information you store on the system. When you reduce the amount of PII you store in your system, you reduce the impact a potential data breach could have.  The best example of this practice is credit card information. If the 3rd party is storing certain information that you don't need or you can retrieve the information you need from the third party, then you have no reason to store it. If you are retrieving data from a third party then you should make sure it's non-critical or you should have a workaround, in case the data can't be retrieved.

Secure Communication

As much as possible, make sure any traffic in production between a user's browser and your servers is encrypted, which is most often done via SSL. For lower environments (dev, test, and others) it may not be necessary, but it should be tested in your staging environment, before the go live. The SAP Commerce solution comes with a certificate signed by a self-signed RootCA as explained in HTTPS Traffic Certificate. It is advised not to use this certificate in production because the key is known.

The table below outlines the SAP Commerce application and the version in which SSL connections were provided as default:

Application Version Encrypted
Storefront 5.5.1
Backoffice 6.2
hAC 6.2
Solr 6.6
Data Hub 6.6


While all the details in this article are related to general Data Protection principles, it is important to mention the European Union General Data Protection Regulation (GDPR), which regulates the use of Personal Data by businesses because it may impact your operations.

  • WHAT? – Any information related to a natural person must be protected
  • WHO? – GDPR applies to all companies processing and holding personal data of people residing in the EUregardless of the company’s  location. This means the legislation will have an effect on non EU-based companies IF they have EU-based customers.
  • WHEN? – GDPR came into effect on 25 May 2018 
  • THEN WHAT? – Organizations can be fined up to 4% of annual global turnover for breaching GDPR or €20 Million.

For details around how functionality introduced in SAP Commerce versions can help you with your journey to GDPR compliance, please consult the SAP Commerce Roadmap.

Regardless of what version of SAP Commerce you are on, it will not make you compliant with GDPR. It only offers features and functionality that can be leveraged to be compliant. The Data Controller is accountable for ensuring you are compliant.


Data protection is about protecting your customer's and employees' information. It's your responsibility to secure the data you produce. If you're interested in learning more, we offer a  GDPR Assessment for SAP Commerce.