IBM Support

WebSphere Application Server - Considerations for GDPR Readiness



This document provides information about features that you can configure and aspects of product use that you should consider to help your organization with GDPR readiness.


WebSphere Application Server Liberty Core, Express, Base, ND , Z/OS , Hypervisor Editions(including Docker images and Microservices Builder), IBM WebSphere Application Server Patterns , IBM WebSphere Application Server Network Deployment Patterns, IBM WebSphere Application Server Liberty Core Patterns - Considerations for GDPR Readiness

For PID(s): 5724-J08, 5724-H88, 5655-W65, 5725-L29, 5724-I63,5725-A25,5725-A12, 5725-A11, 5725-X89, 5725-A26, UT:32AEI


This document is intended to help you in your preparations for GDPR readiness. It provides information about features that you can configure, and aspects of the product's use that you should consider to help your organization with GDPR requirements. This information is not an exhaustive list, due to the many ways that clients can choose and configure features, and the large variety of ways that the product can be used in itself and with third-party applications and systems.

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 are in compliance with any law or regulation.

Table of Contents

  1. GDPR Overview
  2. Product Configuration for GDPR
  3. Data Life Cycle
  4. Data Collection
  5. Data Storage
  6. Data Access
  7. Data Processing
  8. Data Deletion
  9. Data Monitoring
  10. Responding to Data Subject Rights

GDPR Overview

What is GDPR?

  • General Data Protection Regulation. The GDPR has been adopted by the European Union ("EU") and will apply from May 25, 2018.

Why is GDPR important?

  • GDPR establishes a stronger data protection regulatory framework for processing of personal data of individuals. GDPR brings:

    • New and enhanced rights for individuals
    • Widened definition of personal data
    • New obligations for companies and organisations handling personal data
    • Potential for significant financial penalties for non-compliance
    • Compulsory data breach notification

Read more about GDPR:

Product Configuration - considerations for GDPR Readiness

Configuration to support data handling requirements

The GDPR legislation requires that personal data is strictly controlled and that the integrity of the data is maintained. This requires the data to be secured against loss through system failure and also through unauthorized access or via theft of computer equipment or storage media.

Data Life Cycle

GDPR requires that personal data is:

  • Processed lawfully, fairly and in a transparent manner in relation to individuals.
  • Collected for specified, explicit and legitimate purposes.
  • Adequate, relevant and limited to what is necessary.
  • Accurate and, where necessary, kept up to date. Every reasonable step must be taken to ensure that inaccurate personal data are erased or rectified without delay.
  • Kept in a form which permits identification of the data subject for no longer than necessary.

What are the lawful bases for processing?

The lawful bases for processing are set out in Article 6 of the GDPR. At least one of these must apply whenever you process personal data:

  1. Consent: the individual has given clear consent for you to process their personal data for a specific purpose.

  2. Contract: the processing is necessary for a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract.

  3. Legal obligation: the processing is necessary for you to comply with the law (not including contractual obligations).

  4. Vital interests: the processing is necessary to protect someone’s life.

  5. Public task: the processing is necessary for you to perform a task in the public interest or for your official functions, and the task or function has a clear basis in law.

  6. Legitimate interests: the processing is necessary for your legitimate interests or the legitimate interests of a third party unless there is a good reason to protect the individual's personal data which overrides those legitimate interests. (This cannot apply if you are a public authority processing data to perform your official tasks.)

Explicit requirements:

  1. Ensure the appropriate consent is in place - contract, service, explicit Data Subject consent
  2. Understand where the data resides in the application/solution
  3. Ensure the data is secured through:
  4. encryption,
  5. access control,
  6. additional controls
  7. Ensure the retention period of this data is clearly defined
  8. Ensure the data is deleted at the end of the retention period
  9. Ensure all the Data Subject rights can be fulfilled:
  10. Higher standards for privacy policies and statements and for obtaining consent
  11. Easier access to personal data by a data subject
  12. Enhanced right to request the erasure of their personal data
  13. Right to transfer personal data to another organization (portability)
  14. Right to object to processing now explicitly includes profiling

Product considerations:

There are two types of users who access a WebSphere environment: administrators who manage the WebSphere environment, and users of applications deployed in a WebSphere environment. Administrators generally are configured to login with their business, not personal accounts. Data collected from administrators may include user id, password, and audit trail of administration actions that may include IP address, and administrative interfaces, parameters, and results. Data may be persisted in logs files, and audit logs, and are generally required for security audit and forensic analysis.

Users who access applications hosted on WAS may be configured to login with their own personal accounts. Personal data collected by applications are defined by the application, and it is the responsibility of the application to comply with GDPR. However, during the normal course of running the application, personal data may be captured by the WAS infrastructure, and additional configurations may be needed to ensure readiness for GDPR. For example,

  • WebSphere logs and traces may capture personal data as a side effect of writing logs for diagnostic purposes.
  • Java dumps may contain personal data stored in memory.
  • Security audit logs may contain user ID and IP address of users.
  • SIBus temporary storage in files or database may contain user data stored in messages.
  • Web Services uses temporary storage files for large attachments.

Data Collection

WebSphere collects audit logs, operational logs and trace for service purposes which are persisted to disk as described in the "Data Life Cycle" section. Some communication facilities can also persist messages to disk, such as SIBUS message queues. Java heapdumps can also collect operational state and information about customer applications and WebSphere itself.

Considerations for managing this data are given in the following sections.

Data Storage

User identity data is normally not kept in WebSphere, but in some separate repository such as a database or LDAP server. However it is possible to configure a file-based user registry.

To protect access to this information, consider the following:

  • Prefer an external user registry that enforces password and auditing policies over WebSphere's file based registry.
  • If a WebSphere file-based registry is used on Liberty, use password encryption.
  • Use password encryption to protect passwords to external resources, such as databases.
  • Do not use a personal account when configuring access to external resources, such as databases.
  • If using the WebSphere Liberty bluemixUtility tool, the tool can cause Bluemix account credentials to be stored in the Liberty Server configuration.
  • Don't create WebSphere administrative or operational accounts where personal information is stored. Use business accounts that don't contain personal information.

In general, it is recommended that data that may be captured as a side effect of using the WAS infrastructure be configured with a retention period just long enough for the business purpose of capturing such data, such as problem diagnosis, or security audit, such that data is automatically purged beyond the retention period. If necessary, additional efforts may also be undertaken by the application to reduce the amount of personal information captured by WAS. These may include:

  • Encryption of logs: file system level, per-file level, or upon archival. (This capability would be provided by the underlying compute resources, not by WebSphere.)
  • Sanitizing captured logs and audit records before they are archived, or sent to WebSphere support.
  • Protecting Java artifacts such as heap dumps. There is no automatic way to rotate or purge old java dumps. Consider implementing a retention policy for java dumps.

WebSphere Traditional logfile rotation configuration: Java virtual machine (JVM) log settings

In WebSphere Liberty, automatic rotation of log records requires the use of the binary logging feature: Configuring binary logging in Liberty

SIBus database message store configuration, Traditional WebSphere only: Data store [Settings]

SIBus file message store configuration: File store [Settings]

JVM custom properties affecting webservices temporary storage files: Java virtual machine custom properties

  • org.apache.axiom.attachments.tempfile.expiration

Data Access

WebSphere operational data might contain some personal information such as usernames or network addresses. WebSphere operational data can be accessed through a defined set of product interfaces, some of which are designed for access through a remote connection, and others for access through a local connection. Access can also be obtained by direct access to the compute resources on which WebSphere is running.

The interfaces should be secured, such that a user must first be authenticated and then checked for authorized roles before obtaining access to data.

Network communication for remote connections can be encrypted by using HTTPS.

Operational logs and trace might be read by product support personnel.

Consider the roles of operational and support staff. Limit their access to data so they do not have wider access than their roles require.

If transmitting log and trace files to IBM or other product supporters, consider sanitizing them for sensitive data prior to transmission.

Customer applications might write data into WebSphere logs. If this is the case, protect the logs as appropriate for the type of data being written.

At the operating system level, consider restricting access to the system and permissions to WebSphere files. Consider using operating system level logging and auditing capabilities to track security events that occur on the operating system, since WebSphere logs and data can be accessed directly from the operating system.

The following topics provide additional details on setting up security event auditing, and setting up WebSphere administrative users with restricted visibility to logs.

Configuring WebSphere for security event auditing:

Configuring WebSphere administrative roles:

  • WebSphere Traditional security roles for various actions are documented in a table here:
  • Fine-grained administrative security
  • Note that even the lowest level role (monitor) can view the system logs. The trace log cannot be accessed remotely through the administrative console.
  • WebSphere Liberty users that are mapped to the administrator role can manage Liberty remotely using the adminCenter-1.0 feature. As of April 2018 this does not include remote viewing of the logs.
  • Setting up Admin Center

Data Processing

  • It is the responsibility of applications running on WebSphere to provide the ability for clients to control how their personal data is processed.

  • In addition to application capabilities, consider use of encryption and access controls to protect personal data in motion and at rest.

  • Encryption in motion

    • Encrypted communication protocols (HTTPS) can be used to encrypt communication between WebSphere and support staff or end users.
    • Access to private encryption keys should be tightly controlled.
  • Encryption at rest

    • Log and trace files can be kept on an encrypted volume or directory. (This capability would be provided by the underlying compute resources, not by WebSphere.)
    • Access to private encryption keys should be tightly controlled.

Securing communications using SSL:

Protecting messages transmitted between buses:

Data Deletion

WebSphere Application Server runs customer applications. The data these applications collect and how it is deleted are determined by the applications themselves.

Some personal data might be recorded in the operational logs produced by WebSphere, as well as any heapdumps. Limit retention of such data to just long enough for the business purpose of capturing such data, such as problem diagnosis, or security audit, such that data is automatically purged beyond the retention period. If it becomes necessary to delete logs and dumps before the retention period, additional administrative actions may be required.

Data Monitoring

WebSphere Application Server runs customer applications. The data these applications collect and how application users can monitor its use are the responsibility of the applications. The WAS audit infrastructure may be used in conjunction with application monitoring to provide coverage for audit data at the infrastructure level, such as login/logout events.

Responding to Data Subject Rights

WebSphere Application Server runs customer applications. The data these applications collect and how to respond to data subject rights are the responsibility of the applications.

The following rights should be considered when developing applications that run on WebSphere. It is recommended that the user ID's used to administer Websphere be business ID's not containing any personal information.

  • Right to Access
    • Can the client provide individuals access to their data?
    • Can the client provide individuals information about what data the client has about the individual?
  • Right to Modify
    • can the client allow an individual to modify or correct their data?
    • can the client correct an individual's data for them?
  • Right to Restrict Processing
    • can the client stop processing an individual's data?

Document information

More support for: WebSphere Application Server

Software version: 8.5.5, 9.0,,,,,,,,

Operating system(s): AIX, HP-UX, IBM i, Inspur K-UX, Linux, OS X, Solaris, Windows, iOS, z/OS

Software edition: Base, Liberty, Network Deployment, Single Server

Reference #: 2016599

Modified date: 23 May 2018

Translate this page: