General Data Protection Regulation (GDPR) support

The GDPR has been adopted by the European Union’s 27 member countries (“EU”). It establishes a stronger data protection regulatory framework for processing of personal data of individuals, impacts IBM and IBM's client contracts, policies and procedures when handling personal data.

GDPR brings:
  • New and enhanced rights for individuals
  • Widened definition of personal data
  • New obligations for processors
  • Potential for significant financial penalties for non-compliance
  • Compulsory data breach notification

IBM Sterling® Order Management System provides GDPR support through SDF service layer. The application provides a set of SDF services to process personal data. However, it is your responsibility to handle the personal data in your application UI according to your business needs. Additionally, if you want to view GDPR-related data in application-provided UI, you need to customize the application-provided UI according to your business needs.

Note: Clients are responsible for ensuring their own compliance with various laws and regulations, including the European Union General Data Protection Regulation. Clients are solely responsible for obtaining advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulations that may affect the clients’ business and any actions the clients may need to take to comply with such laws and regulations.

The products, services, and other capabilities described herein are not suitable for all client situations and may have restricted availability. IBM does not provide legal, accounting or auditing advice or represent or warrant that its services or products will ensure that clients follow any law or regulation.

IBM Sterling Order Management System provides SDF services to support the processing of personal data in accordance with GDPR. Learn more about IBM's own GDPR readiness journey and our GDPR capabilities and offerings here: https://ibm.com/gdpr.

Pseudonymisation

‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organizational measures to ensure that the personal data are not attributed to an identified or identifiable natural person.

As a consequence, when your customers call up a CSR to get their information on the application or request to forget their information or stop processing further, the Customer Service Representative (CSR) should ask appropriate questions to ensure that the details provided by the caller matches the customer records in the system. Questions can be related to address verification, last ordered item, date when the last order was placed, last 4 digits of credit card, and so on.

Assumptions and limitations of GDPR implementation

  • The SDF services are called for an individual, uniquely identified in the IBM Sterling Order Management System application. It can be a guest, a registered user, or a business organization. However, the service can be called only after a thorough verification by the Customer Service Representative (CSR) or other means of customer relationship.

  • The verification and authorization protocol for an individual is not covered as part of this feature and is based on custom implementation.
  • The deletion of the requesting individual’s personal data is done by erasing personal identification information fields in the existing data such that IBM Sterling Order Management System still retains the remaining fields that are required for existing statistical analysis. Therefore, the deletion applies only to sensitive fields and the data retained with IBM Sterling Order Management System would be anonymous.
  • The selective deletion or restriction of the fields from personal data must be carried out only if the requesting authorized individual does not have any business data in need that depends on the personal data. Therefore, the deletion or restriction SDF services must be called only if the authorized individual does not have any business data in need required for orders or opportunities. GDPR services find business data in need based on the following criteria:
    • Orders associated with the personal data, which are not complete (i.e. OrderComplete flag is not equal to Y), continue as required business data in need.
    • Opportunities associated with the personal data continue as business data in need.
  • After deletion of customer’s personal data, if the same customer needs to return one of his or her orders, the customer’s email address and phone number are no longer available in the system to identify his or her orders. In such a case, customer should provide the actual order details. However, the customer record deletion does not occur when there is at least one order in non-complete status.
  • The non-personal information captured either during customer’s registration in the system or with customer’s order will be purged as per the Enterprise policy. This would not be impacted by the GDPR guidelines.
  • Before restricting personal data for a registered customer, it is recommended that the manageCustomer API is executed to change the customer status to ‘Inactive’. This ensures that new orders are not created for the customer with restricted data.
  • For an unregistered customer with restricted personal data, a new order can be created by capturing the customer information again so no removal of restriction is required for an unregistered customer .
  • IBM provides back-end services to support your GDPR activities. You can invoke these services for relevant GDPR use cases through any external UI or portal for applications that are built on IBM Sterling Order Management System.

Recommended guidelines

Recommended guidelines to support GDPR.
  • When debug or verbose trace is enabled, the API input and output XMLs are sent to the log files. Besides that, an API adds sufficient information to the log files so that the generated log can be used for analysis and solving problems. The input and output of certain APIs have sensitive personal data. Similarly, the troubleshooting content added to the log file also may have the sensitive personal data. These log files are outside the purview of the GDPR services mentioned above. Therefore, it is recommended that you mask such sensitive personal data during logging itself to avoid storing sensitive information in any files. Learn more...
    Note: It is recommended that all the personal data or sensitive personal data that is included in the extended fields or tables is masked.
  • As per the GDPR requirement, it is recommended that the person info data is regularly purged.
  • Any audit and access monitoring requirements that need to be maintained around customer information should be implemented on the AFTER_CREATE_CUSTOMER, AFTER_MODIFY_CUSTOMER and AFTER_DELETE_CUSTOMER events so that the data is stored in a secure and encrypted repository which is compliant with the client's privacy office.
  • Sterling™ Order Management System UI framework allows reorganization of forms and panels with access controls for individual panels. Client's wishing to enforce auditable access trails are advised to use this framework along with HTML UI events to preserve access information in a secure and encrypted repository which is compliant with the client's privacy office.
  • Customers should not include any personal data in the customization packages.

Sample use case

Adriana is from Genoa, Italy. She is a fan of Toga products and has bought things from their store. She wants to know what information Toga is storing about her. She walks into a Toga store and tells a that she wants this information.

Here are the steps which a CSR needs to be follow to retrieve Adriana's data for GDPR:
  1. She walks into a Toga store and tells a CSR that she wants this information.
  2. CSR asks her for basic details such as first name, last name or customer ID, to validate her in the system.
  3. The application passes this information to the APIs, getPersonInfoList or getCutomerList, to find the matching customer records existing in the system.
  4. The CSR then asks her for more details such as phone number, email address, or the last order placed to validate her identity. This step is important to ensure that she has rights to access the data.
  5. She provides necessary data for validation. Once the CSR has confirmed that she is the owner of the data, the CSR passes the information gathered in Step 2 to the GDPR_Get_Data service to get the appropriate personal data and dependent business data from the system.