Security of Customer Data

Exchange Pre-configured Maestro services.  |   Platform Developer |  All versions   This feature is related to v5.1 and higher.

When developing solutions for the Temenos Journey Manager it is critical that personally identifying informationPersonally Identifiable Information (PII) is information about an individual that can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and any other information that is linked to an individual. In Europe, PII is known as personal data. (PII) provided by users in the process of completing a form are kept secure. This is an area that will receive close scrutiny during the certification process.

As a general rule, any type of storage of customer data outside of the form data payload should be avoided or at least minimized, but we recognize that there are some situations where customer data is required to be stored elsewhere for auditing, debugging and reporting purposes. This article describes the practices that should be avoided and provides recommended strategies to accommodate some common use cases.

Unacceptable practices

The following practices are considered high security risks and will result in a certification failure if identified:

• Logging of PII to the Journey Manager Event Log using EventLogger.
• Logging of PII to the Journey Manager Error Log using EventLogger.
• Logging of PII to the Journey ManagerService Call Log using TxnUpdater.addServiceCallLog()

Storing customer data in these these logs is considered high risk as the contents are used for monitoring and operations and are often stored for long periods in off-site databases. Storage of customer data in these logs will not be accepted under any circumstances.

Common use cases

1. Sensitive 3rd Party Data - where information about an individual has been retrieved from 3rd parties (such as credit agencies, fraud services, banks etc.) and the sensitivity of this data requires that it is not returned to the client browser where it can be interrogated and manipulated by savvy users.
2. Audit Logging - where the information used in certain actions during an application process needs to be retained for audit purposes (e.g. an audit of each call made to an identity verification service and the resulting response from that service).
3. Debug Logging - often when trying to locate unexpected behavior in your solution the ability to activate and access detailed debug information helps to identify the issue and resolve it. This type of information is usually only required during the period of debugging and should not be always activated.
4. Reporting - where information gathered from many related submissions can be quickly loaded into a CSV for simple reporting purposes.

Acceptable practices

The following practices may be used to accommodate the use cases where storage of customer data outside the form data payload is required:

1. Submission Properties - Data can be stored in submission properties using the TxnUpdater.setProperty() function in the Fluent SDK. These submission properties are subject to the same purge rules configured for the submission XML data. Submission properties can be accessed by authorized Manager administrators via the Admin Console by viewing the submission record and selecting the Properties tab.
2. Submission Data Extracts - Where reporting of form data across all transactions for a particular form is required you are able to create submission data extracts and quickly generate CSV reports on demand. Like submission properties, this extract information is accessible by authorized Manager administrators and is subject to the same purge rules as the submission XML data.
3. Groovy Logging - using GroovyLogger.debug() function in the Fluent SDK. Note that the all debug() statements are ignored by the Groovy Logger unless you have enabled Groovy Debug Logging for your Groovy service. This supports the use case where you would like to enable additional logging for the period of investigation only, then disable that logging when the investigation is complete.

See also Data Retention Management