Your customers have the right to make several types of requests on you. These rights include:
[Right of access](🔗)
[Right to data portability](🔗)
[Right to rectification](🔗)
[Right to erasure](🔗)
[Right to restrict processing](🔗)
[Right to object](🔗)
If a request is made based on these rights you have a month since the day of receipt to respond.
# Receiving a request
In order to be compliant, there should be a clear channel, most commonly email address, through which your customers can send you the requests. You do not need to create an email inbox that will specifically address these, the general contact address will suffice.
If you decide to create a specific communication channel for this purpose, you would still have to respond appropriately to the requests made through the other channels your customers use to communicate with you. Therefore, it is crucial that you ensure that you have a reliable system of recognizing these requests (whose form can vary) and dealing with them within the deadline regardless of through what channel it was made. It is good practice to archive the requests, whether they are made through the mail or phone call or in-person so that you can use it as evidence of compliance in case of a complaint made to your local authority.
# Right of access
Anyone who reasonably believes you are holding their data has a right to raise a subject access request. This can be:
Confirmation that you hold their data
Access to all their personal data you hold
You might be asking what information should be included when you provide the requested data. Bloomreach Engagement makes this very straightforward. All the personal information can be easily downloaded to a .json file as explained below.
Your customers should receive their data in an intelligible and easily accessible form. The line between what is considered intelligible and what is not is, however, not entirely clear. It is, therefore, good practice to convert the .json file into a more accessible format. For this purpose, you can either use software for automatic conversion or you can convert it manually.
## Downloading data
If you need to download customer’s data you have to options on how to do it. Firstly, you can do it directly in their customer profile.
Secondly, you can do it through API. You can either export data of a [single customer](🔗), [all your customers](🔗) or just [events of selected customers](🔗).
## Changing circumstances
It is very likely that personal data will change between the time a customer makes a request and you complying with it. The data will probably change in these two ways:
**Amendment** The customer usually continues their activity on your website even after making the request. New customer data will, therefore, be added and some will be rewritten.
**Deletion** You have had probably set specific retention periods for your events. This means that some of the customer's data will be deleted.
You might be asking then which version of the data are you supposed to provide. The answer is that you should send to the customer the most up-to-date version of their data at the time of complying with their request. It is completely fine that the data changed since the time of the request. However, all of these changes must only be the natural ones which would have happened regardless of whether the request was made. Making intentional adjustments to the data with the purpose of hiding it from the customer would be considered a breach of GDPR.
# Right to data portability
Customers have a right to obtain their data in a format in which they will be able to reuse them on different platforms. To comply with the request you need to download the customer’s data and send them a copy of it. To read about how to download the data go to the [Downloading customer data section](🔗).
As opposed to providing a customer with a copy of their data after a subject access request, you can be sure that do not need to give them the data in a human-readable format. A commonly used and structure machine-readable format is sufficient for this purpose and therefore there is not a need to adjust the exported .json file before you send it to the customer.
# Right to rectification
Customers have a right to have their incorrect data corrected and incomplete data completed. If they ask you to rectify their data you can do so in their customer profile or through API.
If you choose the former, go to the profile of the particular customer and click on `
Edit properties` where you can manually rewrite all of their customer properties. After you finish the changes, click on `
Save and view`.
If you want to know how to rectify the data through API go to the [Update customer properties section](🔗).
# Right to erasure
Your customers have the right to request their PII to be erased. In Bloomreach Engagement, you have two options on how to comply with this request: either you anonymize the customer or you delete them completely. If a customer requests the erasure of their data, anonymization is usually sufficient. However, if you choose it you must be completely sure that all the PII are flagged as such. Otherwise, you risk being in breach of the GDPR.
When you anonymize a customer it means that all of their customer attributes marked as PII will be deleted and new randomly-generated IDs will replace the old ones. This may be useful for analytical purposes that are not connected to the individual. You can anonymize a customer either through their customer profile or through a data API.
### Anonymizing through the customer profile
If you want to anonymize a customer directly in Bloomreach Engagement, go to `
Data & Assets` > `
Customers` and by using the customer [filter](🔗) find the relevant customer. Then enter their profile and in the `
...` click on `
Anonymize customer` and approve the choice.
### Anonymizing through API
If you decide to use an API, you can anonymize a single customer and anonymize multiple customers at once in bulk. Read more on using API to anonymize a [single customer](🔗) or [multiple ones in bulk](🔗).
### Customer Deletion API
We do not recommend an automated deletion process, such as via an API, for a couple of reasons. It increases the risk of accidental deletion through malformed API use (manual customer deletion in the app requires a user to confirm they want to delete records). It destroys the structure of the customer profile, therefore any aggregated tracked data would be lost (e.g. open and click data). Anonymization is a much safer way of deleting - the anonymization essentially deletes the customer (all PII relating to the customer), but leaves the anonymous tracked data available for aggregated reporting.
When you delete a customer it removes all of their attributes and event data. Be aware that this will impact your overall analytics. For example, if you delete a new customer who made a purchase on Monday your overall revenue for that day will drop. Therefore, first, consider anonymization. In Bloomreach Engagement, you can delete a customer in the same way as you can anonymize them through their customer profile.
# Right to restrict processing
Customers have the right to ask you to temporarily restrict the processing of their data. This means that you can continue storing the data, however, you cannot use it for analytics or track any new data for the particular customer. You will need to do this in case your customer either asks you expressly to restrict the processing of their data or when you decide to do so because of a customer’s complaint regarding the lawfulness or accuracy of storage and processing methods. If you need to restrict the processing of certain customers, ask your consultant to set up a suppression list for you.
# Right to object
Customers also have a right to object to their personal data being processed and permanently stop you from doing so. To comply with a request you would [Anonymize](🔗) their data and ask your consultant to set up a suppression list for you.