Deploy for GDPR readiness
This document is intended to help you in your preparations for European Union General Data Protection Regulation (GDPR) readiness. It provides information about features of DevOps Plan that you can configure, and aspects of the product's use, that you should consider to help your organization with GDPR readiness. 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 (GDPR). 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 warrant that its services or products will ensure that clients are in compliance with auditing advice or represent or any law or regulation.
GDPR
General Data Protection Regulation (GDPR) has been adopted by the European Union ("EU") and applies from May 25, 2018.
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
- ibm.com/GDPR website: https://ibm.com/GDPR
- EU GDPR Information Portal https://www.eugdpr.org/https://ibm.com/GDPR
Product Configuration for GDPR
The following sections provide considerations for configuring DevOps Plan, to help your organization with GDPR readiness.
DevOps Plan stores records generated by its users. DevOps Plan may also store metadata (also stores metadata (user account identifiers, time stamps, and similar) recording the history of changes to records.
Review the DevOps Plan security considerations topic in the product documentation to learn how to deploy DevOps Plan securely:Security Considerations for DevOps Plan
A DevOps Plan local client deployment should be operated inside a local area network protected by firewalls. The service ports used by DevOps Plan Web server can be opened up to access from beyond the firewalls.
Data Life Cycle
This offering processes the Types of Personal Data listed below:
- Authentication credentials (such as operating system, identity management or products' username and password, integration OAUTH tokens)
- DevOps Plan accounts may contain email addresses or phone numbers.
- Technically Identifiable Personal Information (such as device IDs, usage based identifiers, static IP address, language settings, etc. - when linked to an individual)
This offering is not designed to process any Special Categories of Personal Data.
The processing activities with regard to personal data within this offering include:
- Receipt of data from Data Subjects and/or third parties
- Computer processing of data, including data transmission, data retrieval, data access, and network access to allow data transfer if required.
- Storage and associated deletion of data
Technical support for this offering is provided by HCL Technologies, Ltd.
- BIRT
- HP ALM
- Microsoft Visual Studio
- Microsoft SQL Server Enterprise
- Microsoft SQL Server Standard Edition
- Oracle Database Standard Editions
- Oracle Enterprise Editions
What is the end-to-end process through which personal data go through when using our offering?
A user's locale (language setting) is not stored in the DevOps Plan system. It is used only while the user is active to select appropriate translated messages and code pages.
Usernames and passwords are one-way hashed and stored in a database. When integrated with other OSLC providers, username and password are collected directly by those providers and never seen by DevOps Plan.
When records are submitted or modified in DevOps Plan, history records will record who performed the action and when it was performed. Customers may design schemas that collect additional information when records are submitted or changed.
Technical data identifying computer systems and/or users may be logged as part of normal system operation or as part of additional logging/tracing when diagnosing a problem or analyzing a system for improvements. This data may include, for example, IP address, protocols used and other settings related to the communication mechanism, such as browser levels and settings.
Personal data used for online contact with IBM
- Public comments area on pages on IBM developerWorks
- Public comments area on pages on IBM Documentation
Typically, only the client name and email address are used, to enable personal replies for the subject of the contact, and the use of personal data conforms to the IBM Online Privacy Statement.
Data Collection
- Authentication credentials (such as operating system or identity management or products' username and password, integration OAUTH tokens)
- DevOps PlanDevOps Plan accounts may contain email addresses or phone numbers.
- Technically Identifiable Personal Information (such as device IDs, usage based identifiers, static IP address, language settings, etc. - when linked to an individual)
Data Storage
Storage of account data
DevOps Plan usernames and passwords are one-way hashed with a per-database random salt and are stored in the database.
- Storage of client Data
DevOps Plan stores client-provided data in DevOps Plan records or in clients during active sessions. Data in clients is transient and disappears when the session ends. Data stored in DevOps Plan records persists until it is deleted or changed.
- Storage in backups
DevOps Plan does not provide its own backup mechanisms. Clients should establish their own backup procedures.
- Storage in archives
DevOps Plan does not provide an archive mechanism.
Data Access
- Dynamic List Administrator: This grants access to changing dynamic lists (used in field choices)
- Public Folder Administrator: This grants access to administering the public folder workspace where queries can be created and shared.
- SQL Editor: This allows users to create raw SQL queries. It bypasses security context (see below).
- User Administrator: This allows the user to create, remove, subscribe, unsubscribe, edit, users and groups.
- Schema Designer: This allows the user to see and edit the schema, including any hook code in the schema.
- Security Administrator: This allows the user to modify security settings in DevOps Plan, including brute-force protection from password guessing bots.
- Super User: This user has all the privileges.
Access Control
In addition to user bits, there are additional access controls in DevOps Plan.
- Security Context on Records
DevOps Plan allows administrators to control access to records based on contexts. A context is determined by a field on the record, and contexts can be used to control which groups have access to the records. If users don't have access, they never even see that the record exists. This is useful, for example, to allow customers to see only their records and not other customers records.
You can read more about Security Context here: Security Considerations for DevOps Plan.
- Workspace Security
The Public Folder Administrator (PFA) grant the user the ability to create, edit and remove queries, charts and reports in the Public Queries folder. The PFA and Security Administrator (SA) bits also grant the ability to create access control lists for folders in the Public Queries.
You can grant non-PFA and non-SA users the ability to add or remove queries in certain folders.
You can hide folders from everyone except certain groups.
- Logs
DevOps Plan has extensive tracing for diagnostics. This includes all parameters passed in to the external APIs (e.g. CQPerlExt). However, passwords are always marked out with asterisks.
- Records
DevOps Plan allows creation of fully customized record workflows. As part of this, the administrator can write hooks that grant access to perform actions only to certain people and for records only in certain states or with certain field values. There is extreme flexibility in controlling control access to adding, changing and of deleting records.
Data Processing
- Encryption in motion
The DevOps Plan Web server can be configured to use TLS/SSL protection for its communication with its browser clients. Refer to details in the "Encryption" section of the security considerations document linked above.
DevOps Plan uses an external database for storing data. This database might be an Oracle, DB2, or SQL Server database. Connections to Oracle and SQL Server databases can be configured to use TLS/SSL for encryption.
- Encryption at rest
All persistent DevOps Plan data is stored in external databases. Consult database vendors for steps to encrypt storage. DevOps Plan applications do not encrypt record data loaded from the database.
Data Deletion
How can the client control the deletion of personal data?
- Client Data deletion
DevOps Plan does not log data unless explicitly told to log data. This is usually in the case of diagnosing a problem. Once the problem is resolved diagnostic data can be deleted.
Trace data are retained indefinitely. The DevOps Plan administrator should delete trace files after completing the troubleshooting activities.
- Account Data deletion
Normally, DevOps Plan users may edit their profile data to remove phone numbers and email addresses.
Deactivating a user will not remove the user from the DevOps Plan application, because that user object may still be referenced by other records. This information is retained to allow historical analysis of the records. The email and phone numbers of deactivated users can be removed from the database.
Data Monitoring
Customers should regularly test, assess, and evaluate the effectiveness of their technical and organizational measures to comply with GDPR. These measures should include ongoing privacy assessments, threat modeling, centralized security logging and monitoring among others.
Logging and monitoring capabilities embedded within IBM software products should be clearly described within product documentation and deployment manuals.
- Include successful and unsuccessful logon events, privileged activities and security events.
- A security event should be logged and investigated if a potential attempted or successful breach of access controls is detected.
- Ensure logs contain sufficient information about the event. For example, include the type of event, when the event occurred, where the event occurred, the source of the event, the outcome (success or failure) of the event, and the identity of any user/subject/device associated with the event. 2. Retain logs on the system for at least 90 days.
- Protect logs against unauthorized access.
- Keep system clocks synchronized with a common reference time source to improve log accuracy.
- If the product does not have integrated capability, consider providing guidance on the implementation of a separate SIEM (security information and event monitoring system) or DLP (data loss prevention) system.
How could the client monitor the processing of personal data?
- Log monitoring
DevOps Plan can be configured to write diagnostic tracing for troubleshooting purposes. In addition core dumps may be generated to help with debugging. These logs and dumps may have sensitive information so they should be stored in a secure location. Once troubleshooting is done, the diagnostic logs can be deleted from the system. If log files need to be archived for operational/audit requirements then consideration should be given to encrypting any archived logs.
Responding to Data Subject Rights
- Basic Personal Data (e.g. usernames and passwords used for authentication and Name/ID)
- Authentication credentials (such as operating system, identity management or products' username and password, integration OAUTH tokens)
- Technically Identifiable Personal Information (such as device IDs, usage based identifiers, static IP address, language settings, etc. - when linked to an individual)
Basic Personal data is stored in the user's profile and can be modified by the user in most cases. In other cases, a request may be made to a user administrator to have the data updated. Authentication credentials are only transiently handled by DevOps Plan, and are generally not retained. However, valid OAUTH access tokens persist in the process. These OAUTH tokens can be used to access the users resources on an external service, as long as the user has already been authenticated in DevOps Plan. The period that the OAUTH tokens are valid is configured by the external service. There is no way to remove individual OAUTH tokens, but you can clear all OAUTH tokens by restarting the DevOps Plan Web Server. Technically Identifiable Personal information persists in the process and can be cleared by restarting DevOps Plan Web Services. Some of this data might end up in diagnostic logs. See previous section for ensuring these logs are stored in a secure location and are disposed of or encrypted long term storage.
DevOps Plan is a record-based system. Any kind of data can be stored in records, including personal data. Most data in records can be removed, but it depends entirely on the custom schema employed. For example, some fields may be configured to be read-only after initially setting it. Or some fields are read-only to certain groups. In general an administrator can remove data from the database, bypassing the schema, if it is necessary to remove or correct data that can not be corrected using the DevOps Plan clients.