Developer Guidelines for Data Privacy

Overview

The General Data Protection Regulation (GDPR) in Europe

The GDPR was approved in April 2016 and replaces the existing Data Protection Directive as of May 25th, 2018. The regulation’s aim is to protect data privacy for all European citizens.

Data protection requirements

The GDPR ensures, among other things, the following data subject rights:

• The right to access and the data portability requirement ensures the data subject’s right to request information about all personal data that the data controller stores about them, and to receive a copy of the whole data set in a readable, electronic format, free of charge.
• The right to be forgotten ensures the right of data subjects to request erasure of their personal data.
• An audit trail provides documentary evidence of the sequence of activities, such as data changes, relating to the personal data of a data subject.

If your service collects or processes personal data, even potentially, follow these detailed guidelines to ensure the service meets the requirements using the mechanisms provided in YaaS.

YaaS provides data protection support in a unified way for:

• transparency
• deletion
• auditing

YaaS serves multiple types of users, therefore you must consider multiple scenarios:

• Users with YaaS accounts
  • Platform internal users, such as security and data protection officers and service developers
  • Users or organizations developing their own solutions based on YaaS, such as administrators, data protection officers (DPOs), and product managers without admin rights
• Customers, belonging to organizations, without YaaS accounts
  • People who have a record with personal data in the Customer service

For users with YaaS accounts, YaaS acts as a data controller, while for customers, YaaS is only a data processor.

Services based on YaaS

Services in YaaS must comply with data protection laws in the country or area they operate in, such as Europe. Therefore, any service that processes personal data in the name of a data controller must comply with the local laws. If a YaaS service never collects or processes personal data, the service is automatically compliant.

A service has specific actions in regard to personal data and the data controller, such as allowing access to the data for a specific data subject. YaaS provides the tools to enable the data controller to fulfill these actions.

Considerations

You must consider a couple of things with YaaS services and data protection. If your service provides data container functionality such as a database, and you do not know the type of data it collects or processes, define that the data controller is responsible for meeting the requirements in the Security section of your service documentation. For example, define that the audit logs must meet the data protection laws when storing personal data in the database, not the service itself.

Also, if your service uses another service, refer to the specific security guidelines provided in the Security section of the documentation for that service. For example, if your service uses the Document service, refer to the Security section of the Document service.

YaaS Support for Data Privacy

If your service collects or processes personal data, you can meet data protection law requirements, especially those defined in the GDPR, in a user-friendly and centralized way using the steps in the following sections.

General

Using the YaaS transparency and deletion solutions, enable your service's users to use a central user interface that allows them to see and request the deletion of personal data across all YaaS services. To contribute to the YaaS transparency and deletion solutions, first register your service as having personal data to protect using one of these methods:

• Use the API Management service's /projects/{projectID}/services endpoint and provide a list of regions where the service stores personal data.
• Use the interface provided in the Builder. Navigate to the service form and toggle Personal Data Protection, located below the service's URL:

After you register the information, the service responds to transparency and deletion events published using the PubSub service.

Overview of the solution

This image shows a broad overview of the YaaS solution supporting data privacy.

Services involved

You can learn more about the services involved in the YaaS data privacy solution by reviewing the documentation for each service.

• Transparency service
• Deletion service
• Audit Ingestion and Audit Retrieval

Transparency

YaaS provides a central approach to transparency in regard to personal data protection. It fulfills an individual's rights to access personal data, and to inform individuals about the data the system keeps. YaaS uses the Transparency service for data portability across all registered services. Use and contribute to this solution to fulfill the requirements instead of creating a custom solution. This method provides a unified user experience from the data controller perspective.

This image shows an overview of the process for listening to transparency events:

As shown on the diagram, when a user triggers a request to the Transparency service, the service sends an event through the PubSub service to all services registered as personal data-relevant services. Every one of these services must listen to that event and react to it by pushing relevant personal data back to the Transparency service. Based on the responses from the services, the Transparency service generates a transparency report for the initial caller. The following sections describe those phases in detail.

Listen to transparency events

As explained, every service dealing with personal data, identified by registration in the API Management service, must listen to the events that the Transparency service emits, and must respond with a payload so the Transparency service can provide the user with the results. To do so, subscribe to the related topic at the PubSub service and decide which mechanism to use to receive the events. You can choose either a pull or push approach.

For more information, refer to the PubSub service documentation and also the Events section of the Transparency service documentation for more specific details.

Respond to transparency events

The transparency service sends an event containing the dataSubjectType, dataSubjectId, and the requestId. Map the identifiers to the related personal data in your service, and it responds to the request by performing a POST request to the Transparency service. As part of that request, provide the personal data and its metadata, such as purpose and retentions. The service responds to the event in a certain amount of time to avoid negative credits and subsequent penalties. See the Transparency service documentation for more details on responses. To check the latest schema and payload example, see the Events section of the Transparency service documentation.

Deletion

YaaS provides a central approach to deletion in regard to data protection requirements. It fulfills individuals' rights to erase their data across all services registered in YaaS using the Deletion service. Use and contribute to this solution to fulfill the requirements instead of creating a custom solution. This method provides a unified user experience from the data controller perspective.

This image shows an overview of the process for deleting personal data:

As shown on the diagram, when a user triggers a request to the Deletion service, the service sends an event through the PubSub service to all services registered as personal data-relevant services. Every one of these services must listen to that event and react to it by deleting or blocking relevant personal data.

The following sections describe the process in detail.

Considerations

If legal regulations require you to keep personal data entries for a specified time, you must:

• Implement in your service an option to configure retention policies per tenant and per market, and block personal data in response to a deletion event:
  • Attach the retention time information to the data record(s).
  • Do not return the data through the regular API.
  • Serve transparency requests with data marked as "blocked until date and time".
  • Delete the data at the end of the retention period.

• Implement data expiration handling:

  • For personal data collected for a temporary purpose, such as a customer request, ensure its deletion when the purpose expires using these steps.
    • Provide an option to configure the residence period per tenant.
    • When the request is processed, mark the data with the residence period.
    • At the end of the residence period, trigger the data deletion.
  Do not perform personal data erasure in platforms and applications using only logical deletion, merely marking the data as erased. Instead, ensure the physical deletion of the data.

Listen to deletion events

Every service dealing with personal data, identified by registration in the API Management service, must also listen to the events that the Deletion service emits, and must respond with a status to the Deletion service and react by deleting or blocking the data. To do so, subscribe to the related topic at the PubSub service and decide which mechanism to use to receive the events. You can choose either a pull or push approach.

For more information, refer to the PubSub service documentation and the Events section of the Deletion service documentation for more specific details.

Respond to deletion events

When the system triggers an event callback, the event contains the dataSubjectType, dataSubjectId, and the requestId. Map the identifiers to the related personal data in your service, and the system reacts to the request, depending on the type of event received.

• The service responds with a status to the Deletion service for a can-delete request.
• The service deletes or blocks the data, and then responds with an operation status to the Deletion service for a delete request.

The service responds to the event in a certain amount of time to avoid negative credits and subsequent penalties.

See the Deletion service documentation for more details on responses. To check the latest schema and payload example, see the Events section of the Deletion service documentation.

Audit logs

For accountability reasons, YaaS provides a central solution for the creation and retrieval of audit events.

This image shows how the Audit Ingestion and Audit Retrieval services work within the YaaS system to handle logging requirements.

Considerations

• Audit logs must contain the information about the user who triggered the change. In cases of a chain of calls to different services, where only the service serving the first request has this information, that service must log the user entry. The other services involved must log the change.
• Logs must not contain passwords.
• Change logs for data erasure cannot disclose the content of the erased data.
• Creation and deletion events are also considered changes, and require logging.

Log personal data-related events, especially events for changes to that data or changes to user configuration. The data subject has a central point to look up changes to its data. To create audit events, use the Audit Ingestion service.

Create configuration change events, relevant for business configurations, such as:

• Changes to roles, scopes, and project and organization membership
• Changes to order flow

Also, create security events such as unauthorized attempts to retrieve or change the personal data of a data subject, for example:

• When the tenant header does not match the tenant in the URL
• When the scopes in the header do not match the scope requirements of the API

To access your audit events, use the Audit Retrieval service.

Additional Steps

Services that collect or process personal data which do not have central tooling have some additional requirements. Each system fulfills these requirements individually. This document lists some tips on how to meet those requirements.

Rectification

At any time, a data subject has the right to rectify its personal data. A YaaS service provides an API allowing the rectification by the data controller. For example, provide a PUT or a PATCH method in the public API to allow modification of the relevant personal data.

Restriction of processing

A data subject has the right to restrict the processing of its personal data at any time. In this case, implement logic that localizes the relevant data in your service, and blocks it from processing. For example, add a flag that indicates the system blocked or restricted the data, and the service does not process the data marked in this way.

Consent and objection

In order to process personal data, the system requires a legal basis. You do not need explicit consent when collecting data for your contractual duties. If there is no implicit basis, such as a contractual purpose, you must collect the consent explicitly. Services in YaaS provide a mechanism to capture the end user's consent. This gathers the consent in an affirmative and interactive way. For example, the individual checks a certain checkbox. The default value never indicates consent, but instead it must be turned on. The individual can also disable it. For example, a checkbox for "Do not ask again" or "Always allow". For more information, see the Automated Decisions and Profiling section.

The consent mechanism logs the individual's consent including name, point in time, and the version of privacy statement. Ensure that you can view the current privacy statement and consent. Also, provide the user an option to revoke the consent at any time, for example, by using a checkbox or setting. The consent mechanism allows re-consent in case you release a new version of a privacy statement, with the capability to retain the previous privacy statement and user consent. Every YaaS service must ensure personal data deletion when user revokes their consent, or when all applicable retention periods expire.

Automated decisions and profiling

If a service records and analyzes an individual's characteristics, such as behavioral, to categorize them to a user model, the individual must have access to the resulting data, and the ability to delete or change it.