IBM Cloud Docs
General Data Protection Regulation (GDPR)

General Data Protection Regulation (GDPR)

The GDPR seeks to create a harmonized data protection law framework across the EU. It aims to give citizens back the control of their personal data, while it imposes strict rules on the ones who host and "process" this data, anywhere in the world. The Regulation also introduces rules that relate to the free movement of personal data within and outside the EU.

With the General Data Protection Regulation, IBM® Cloudant® for IBM Cloud® customers can rely on the IBM Cloudant team's understanding and compliance with emerging data privacy standards and legislation. Customers can also rely on IBM's wider ability to provide a comprehensive suite of solutions to assist businesses of all sizes with their own internal data governance requirements.

How do I audit access to IBM Cloudant?

You can find information about auditing in Audit logging.

Supported classifications of Personal Data

The following categories of Personal Data are supported by IBM Cloudant for GDPR:

  • Identity and civil status
  • Personal life
  • Professional life
  • Location data
  • Connectivity and device data

Sensitive Personal Data is restricted to the following category:

If you store healthcare data, you must notify IBM Cloudant before you write any data.

For more information about supported classifications of Personal Data, see the Data Sheet Addendum (DSA) under 2. Personal Data.

Data about me

IBM Cloudant records some data about its users, and is a Data Controller for said Personal Information (PI) data. The data that IBM Cloudant records depends on the type of account you have.

If you have an IBM Cloudant Dedicated Cluster or IBM Cloudant Enterprise Cluster, IBM Cloudant records data about you and are considered a Data Controller for your data within the context of GDPR. If you have an IBM Cloudant Dedicated Cluster or IBM Cloudant Enterprise Cluster, IBM Cloudant stores the following information about you:

  • Name
  • Email

The data that IBM Cloudant holds can be viewed and updated through the IBM Cloudant Dashboard.

If you have an account that is provisioned by IBM Cloud (including a dedicated instance), IBM Cloudant does not collect the personal data that was discussed earlier. This data is held by IBM Cloud.

Do not use sensitive data for IBM Cloudant instance names when you provision by using IBM Cloud, such as: Personal Information (PI), Personal Identifying Information (PII), and Customer-specific Data.

IBM Cloudant processes limited customer PI in the course of running the service and optimizing the user experience of it. IBM Cloudant uses email for contacting customers. Monitoring customer interactions with the IBM Cloudant Dashboard is the other way IBM Cloudant processes PI.

Restriction of processing

IBM Cloudant sends dashboard interaction data to Segment. It's possible to ask IBM Cloudant to restrict processing of customer PI in this way with an IBM Cloudant support request through the IBM Cloud Support portal. Upon receipt of such a request, IBM Cloudant deletes information that is associated with the customer as sent to Segment, and prevents further data from being sent. IBM Cloudant needs to retain the ability to contact dedicated customers by email. IBM Cloudant provides an interface for customers to keep this information up to date either directly, or by using customer configuration of their contact details with their IBM Cloud account details.

Is the IBM Cloudant database encrypted?

All clusters have an encrypted file system (encryption at rest) that uses Linux™ Unified Key Setup (LUKS). Data in the database is visible to the operations and support teams (see the following paragraph).

For sensitive data, that you determine must remain invisible to IBM Cloudant, you must encrypt or otherwise protect (pseudonymize) your data before you send it to us. Do not use PI as a document _id in your URLs, for example, https://$ACCOUNT.cloudant.com/$DATABASE/$DOCUMENT_ID, since PI is always visible and written to the access logs.

Data locations

Locations where IBM Cloudant processes personal data are made available, and kept up to date, through the DSA.

For more information about data locations, see the DSA under 7. IBM Hosting and Processing Locations.

Service security

Using IBM Cloudant securely

As a user of IBM Cloudant, you must follow these guidelines:

  • Use the default CORS configuration to prevent unexpected access.
  • Use API keys liberally, since components can have least privileged access, which is coupled with the audit log. This practice helps you understand who accessed which data.
  • Encrypt or otherwise protect (pseudonymize) sensitive data that you determine must remain invisible to IBM Cloudant.

Physical and environmental security measures

Physical security of our data centers is handled by the infrastructure providers: IBM Cloud®, AWS, and 21Vianet. All hold externally audited certifications for their physical security. IBM Cloudant doesn't provide further details of the physical security controls in place at our data centers.

Physical security of the office locations that are used by our personnel is handled by IBM Corporate. Certification details and attestation reports (that is, ISO and SOC2) can be provided to the customer upon request.

Technical and Organizational Measures

Technical and Organizational Measures (TOMs) are employed by IBM Cloudant to ensure the security of Personal Data. IBM Cloudant holds externally audited certifications for the controls IBM Cloudant employs. Certification details and attestation reports (that is, ISO and SOC2) can be provided to the customer upon request.

Service access to data

IBM Cloudant operations and support staff have access to customer data and can access it during routine operations. This access is only done as required in order to operate and support the service. Access is also limited to a need to know basis and is logged, monitored, and audited.

Deletion of data

Deleting a document

When a document is deleted, the database creates a "tombstone." What the tombstone includes depends on how you delete it:

  • If you make a DELETE call, the tombstone includes the _id, _rev, and _deleted fields.
  • If you delete by updating the document with a _deleted: true field and add a PUT or POST request to it, the tombstone includes what you set in the document body. This practice can be useful in some circumstances, for example, when recording why a document was deleted in its tombstone.

For more information, see Simple removal of "tombstone" documents.

When is a deleted document removed?

Compaction runs automatically and periodically removes old revisions (deleted or otherwise) from the database, by writing out only "leaf" revisions to a new file. IBM Cloudant keeps a history of _id and _rev to enable replication, but not old document bodies.

IBM Cloudant doesn't expose the CouchDB compaction API.

IBM Cloudant doesn't guarantee that a database is compacted in a specific time. Compaction is done as a background process across the storage tier. Databases are always being compacted. It isn't guaranteed that the data compacted is the data that you deleted or changed.

IBM Cloudant is accepting the right to be forgotten requests through the IBM Data Privacy Office (DPO). When a right to be forgotten request is made from the IBM DPO, IBM Cloudant verifies the request, explicitly triggers database compaction, and verifies that compaction occurred. At the end of this process, the only version of the document is its tombstone ( _id, _rev, _deleted, and any fields your application includes there).

Removal of tombstones

IBM Cloudant can completely remove all references and data for a document when required. This task is an operator-managed process called purging. Before you request that documents be purged, it's important to understand that purged documents cannot be recovered by IBM Cloudant once the process is complete.

The CouchDB purge API is not supported by IBM Cloudant.

In the context of GDPR, purging is only required if PI is used in a document ID. It's a bad idea for an _id to store PI for lots of reasons, but a handful of semi-valid use cases exist (for example, a unique email). If possible, encrypt or pseudonymize data so it's opaque to IBM Cloudant.

If a document needs removal through a right to be forgotten request, follow these steps:

  1. File a request with the IBM DPO to request purging of specific document _id values along with the reason.
  2. On receipt of a formal request by the IBM DPO, IBM Cloudant operations verifies the request to confirm the id contains PI. IBM Cloudant doesn't purge data that doesn't have PI in the _id.
  3. IBM Cloudant triggers the purging action to permanently remove the requested data.

This process is only to be used for emergency deletion requests (for example, right to be forgotten) and must not be relied upon long term. If your application is intentionally using PI in document IDs, then it must be changed to either pseudonymize that PI, or not use PI in document IDs. You cannot rely on regular purging by the IBM Cloudant operations team to avoid this situation. Therefore, IBM Cloudant rejects the following purge requests:

  1. The request is for regular purging, for example, every 30 days.
  2. The request is for over 100 documents.

Even with purge, PI in the _id field leaks into places you don't want it, such as IBM Cloudant logs, so it must be avoided. IBM Cloudant has a business reason to keep those logs and doesn't remove log lines that include document _id values.

What about deleting a database?

Deleting a database adds it to the trash for up to 48 hours. After which time, the database is removed from the file system. The IBM Cloudant team does not make back ups of your databases; this task is the responsibility of the customer. You must ensure that all copies of your database are removed from your system. For more information, see IBM Cloudant backup and recovery.

If you need more help, go to the IBM Cloud Support portal.