IBM Dependency Based Build considerations for GDPR readiness

For PIDs: 5755-A05, 5655-AC6, 5900-A8N, 5737-K80, 5737-I22, 5737-N86, 5737-K80

Notice:

This document is intended to help you understand how IBM Dependency Based Build can assist you to comply with your requirements under the European Union (EU) General Data Protection Regulation (GDPR). It provides information about features of IBM Dependency Based Build that you can configure and aspects of the product’s use that you should consider to help your organization with your GDPR readiness. This information is not exhaustive as there are many ways that clients can choose to configure features and to use the product by 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 ensure that clients are in compliance with any law or regulation.

Table of contents

  1. GDPR

    • Why is GDPR important

    • Data lifecycle and GDPR

    • Read more about GDPR

  2. How IBM Dependency Based Build handles data in the context of GDPR

    • Data collection

    • Data storage

    • Data access

    • Data deletion

    • Data monitoring

  3. Product configuration considerations for GDPR readiness

    • Offering configuration

    • Configuration to support data handling requirements

  4. Summary of GDPR considerations

GDPR

The GDPR has been adopted by the EU and applies 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 processors

  • Potential for significant financial penalties for non-compliance

  • Compulsory data breach notification

Data lifecycle and GDPR

GDPR requires that personal data is processed in accordance with the following data principles. This section lists those data principles and explains in what way IBM Dependency Based Build may be subject to the GDPR regulation.

  • Lawfulness, fairness, and transparency: processed lawfully, fairly, and in a transparent manner in relation to individuals.

  • Purpose limitation: collected for specified, explicit, and legitimate purposes.

    • The customer needs to define business processes to comply with this principle.

  • Data minimization: adequate, relevant, and limited to what is necessary.

    • The customer needs to define business processes to comply with this principle.

  • Accuracy: accurate and, where necessary, kept up-to-date. Every reasonable step must be taken to ensure that inaccurate personal data is erased or rectified without delay.

  • Storage limitation: kept in a form that permits identification of the data subject for no longer than necessary.

  • Integrity and confidentiality: processed in a manner that ensures appropriate security of the data, including protection against unauthorized or unlawful processing and against loss, destruction, or damage.

Read more about GDPR

How IBM Dependency Based Build handles data in the context of GDPR

Overview

IBM Dependency Based Build (DBB) provides the capabilities to build traditional z/OS® applications that are developed in programming languages such as COBOL and PL/I. It provides a modern scripting-language-based automation capability that can be used on z/OS. DBB is a stand-alone product that does not require a specific source code manager or pipeline automation tool.

IBM Dependency Based Build provides the ability to run Groovy on z/OS. You can run MVS, TSO, or ISPF commands as part of the Groovy scripts. This gives engineers that are new to the platform a more familiar way to automate tasks. With DBB, engineers can use Groovy scripts that were written for other platforms in the z/OS pipeline.

The first and primary task that you can use DBB for is compiling and link-editing programs. For this, DBB provides a dependency scanner to analyze the relationship between source files, as well means to store the dependency information and build reports within an IBM Db2® database.

You can also use DBB to automate testing to be added to the pipeline, or any other system administration task that you might write JCL for.

DBB is constituted of the following primary components:

  • The DBB z/OS toolkit, which provides:
    • APIs to be used in Groovy or other scripts for z/OS build activity in a scripted fashion. More details are provided in later sections.
    • A set of Command-Line Interfaces (CLI) that enable a user to search, read, and delete build data stored in the IBM Db2 database. More details are provided in later sections.
  • The DBB database repository. The IBM Db2 database is used to store build reports (for example, details of successful or failed compilations) and program relationships (for example, source program A embeds COBOL copybook B). The only user information stored are the user IDs of the creator, owner, and last modifier of a given database entry to provide the ability to isolate and manage access. More details are provided in later sections. The database repository is not readable on disk and is accessible only with authorized credentials.

Because DBB scripts run natively on z/OS, RACF management of resources applies, that is, script users are only able to access resources or files that they are allowed to based on RACF permissions.

Data collection

The following explicit requirements need to be considered with respect to the different types of data that are stored and/or collected by IBM Dependency Based Build:

Types of data collected

User ID information

  • IBM Dependency Based Build can be set up for test or demonstration purposes to use the local z/OS UNIX file system to store the DBB build metadata. All the build metadata in this test or demonstration scenario is written out in plain text to the file system. It includes the user ID of the build owner.

  • In a production environment, IBM Dependency Based Build is configured to store the build metadata in a Db2 database. The data stored in Db2 can be encrypted and includes the user ID of the build owner.

  • Access credentials for the configured data sources can also be obfuscated.

Log information

For debugging purposes, the IBM DBB support team might need to collect customer log files. The log files are designed not to contain personally identifiable information when possible, but they may contain information like the IP addresses or user IDs of the script users. The IBM DBB support team uses ECuRep for customer data management. ECuRep archives the PMR or case data when the PMR is closed.

Personal data used for online contact with IBM

You can submit online comments/feedback/requests to contact IBM about IBM Dependency Based Build subjects in a variety of ways, primarily:

  • Public comments area on pages of the IBM Dependency Based Build documentation in IBM Documentation

  • Public comments in the IBM DBB GitHub repository

  • Public comments in the IBM Dependency Based Build (DBB) user group of the IBM Z and LinuxONE Community

  • Data on how you use the product may be collected if you give your consent within the tool. You can request the deletion of that data.

It is your responsibility to make sure that no personal data is provided in any public spaces or groups. Typically, only the client name and email address are used to enable personal replies for the subject of the contact, and this use of personal data conforms to the IBM Online Privacy Statement.

Data storage

The following data storage mechanisms are used by IBM Dependency Based Build, which users might want to consider when assessing their GDPR readiness.

  • Storage of account data

As previously stated, IBM Dependency Based Build stores the service account credentials used to connect to data sources as obfuscated entries in UNIX file permission protected files.

  • Storage of client data

IBM Dependency Based Build database records include user ID fields, which are used to distinguish data ownership and sharing between users and record the last user to modify the data. Specifically, the creator, current owner, and last updater user IDs are stored.

Data access

IBM Dependency Based Build has three defined roles as described in the IBM Documentation: Permission Details.

These roles may have read access to the records that contain the user IDs previously mentioned, but this access can be limited by the creator at creation time to allow access only to certain users or groups, similar to the way UNIX files and directories are protected. These permissions can be changed by any user with write access to the record.

Data deletion

Right to Erasure

Article 17 of the GDPR states that data subjects have the right to have their personal data removed from the systems of controllers and processors - without undue delay - under a set of circumstances.

Data deletion characteristics

  • Local account information deletion

IBM Dependency Based Build uses the z/OS account control system called RACF. The creation and deletion of accounts and account information is controlled by RACF.

Data monitoring

  • Activity monitoring

IBM Dependency Based Build does not explicitly provide activity monitoring. However, access to z/OS machines can be audited by RACF.

Product configuration considerations for GDPR readiness

Offering configuration

The following sections provide considerations for configuring IBM Dependency Based Build to help your organization with GDPR readiness.

Configuration to support data handling requirements

The GDPR 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 in motion between the IBM Dependency Based Build toolkit and the Db2 data store is controlled by the Db2 JDBC drivers and how the user configures the driver. End-to-end encryption can be configured.

Summary of GDPR considerations

The following list summarizes GDPR considerations for IBM Dependency Based Build:

  1. Obtain appropriate consent, where required.

    Consent needs to be obtained and administered outside IBM Dependency Based Build.

  2. Understand where the data resides in the application/solution.

    This document contains a detailed description of the data that is stored in IBM Dependency Based Build.

  3. Secure the data through the following means:

    Encryption – Data at rest and in motion is encrypted if IBM Dependency Based Build is configured properly for production use.

    Access control – IBM Dependency Based Build provides different user roles that can be used to control access to the stored and sampled data. You need to configure the different roles for each user as needed and ensure that access is managed and revoked appropriately.

  4. Clearly define the retention period of this data.

    IBM Dependency Based Build does not maintain retention periods but normal SQL queries and commands could be used to delete data. The owner and permissions can be updated at any time by anyone with RW access to that object. Last updated by is updated with the ID that is updating the object. Created by ID can only be changed by using SQL.

  5. Delete the data at the end of the retention period.

    IBM Dependency Based Build does not maintain retention periods but normal SQL queries and commands can be used to delete data. The owner and permissions can be updated at any time by anyone with RW access to that object. Last updated by is updated with the ID that is updating the object. Created by ID can only be changed by using SQL.

  6. Fulfill all data subject rights:

    • Higher standards for privacy policies and statements and for obtaining consent

    • Easier access to personal data by a data subject

    • Enhanced right to request the erasure of their personal data

    • Right to transfer personal data to another organization (portability)

    • Right to object to processing now explicitly includes profiling

All of these requirements need to be implemented outside of IBM Dependency Based Build.