How Charlotte Tilbury Beauty uses Google Cloud to respond to customer data requests

Editor’s note: Today we hear from global beauty brand, Charlotte Tilbury Beauty, on how they use Google Cloud Workflows and Sensitive Data Protection to respond quickly and at scale to customer data requests.

Launched in September 2013 by iconic beauty entrepreneur Charlotte Tilbury MBE, Charlotte Tilbury Beauty was born out of Charlotte’s long-held desire to empower everyone to feel like the most beautiful version of themselves, helping people around the world gain the confidence to achieve their biggest and boldest dreams.

Through Charlotte’s vision and leadership, at Charlotte Tilbury Beauty we continue to break records across regions, channels, and categories. We now sell more than 500 products across color, complexion, and skincare, we have a physical presence in over 50 global markets and 42 countries via charlottetilbury.com, as well as over 2,000 points of distribution worldwide including department stores and travel retail.

We are a customer-obsessed brand that strives to build a direct, emotional, and trusting relationship with our customers and partners. Our products and experiences are even better and more tailored to our customers when they choose to share their information with us, and trust us to appropriately redact and forget their information should they wish. Organizations that collect customer data have a responsibility to respond to customer data requests, be it a Right-To-Be-Forgotten (RTBF) or Data Subject Access Requests. Below, we focus on the data that resides on our Google infrastructure and explore how Google Cloud Workflows and Google Cloud Sensitive Data Protection (formerly Cloud Data Loss Prevention) have made it easier to respond to customer data deletion requests, and enabled our data team to develop an automated RTBF process.

To provide some context to the problem, our tool selection was driven by several needs and challenges:

• A desire to have complete visibility over what, where, and how much PII is being stored in our Google Cloud environments
• Data deletion from our data warehouse being heavily dependent on the deletion status in source systems
• The existing process being highly manual and unscalable for future volumes as well as having a limited audit trail
• A need for the solution to be independent from data warehouse processing workloads
• A need for the solution to integrate with our consent management platform (OneTrust) whilst being able to perform complex BigQuery procedures and statements
• The language used in our product or marketing-specific content containing names that could be mistaken as PII

Google Cloud Sensitive Data Protection (SDP) provides us a way to scan the entirety of our BigQuery data and apply business-specific rules and edge cases to tune the performance of data profiling. This has significantly increased our understanding of our PII footprint, not just within our data warehouse but across the business. SDP scans for sensitive data at either daily, weekly, or monthly intervals, triggered by schema changes or changes in rows of data. These results, called data profiles, can be pushed to a number of destinations including Security Command Center, Chronicle, Dataplex, Pub/Sub, and BigQuery. In our case, we pushed to BigQuery for simplicity of consumption as part of our data deletion process.

As well as data discovery, SDP has the ability to encrypt and mask data based on the type of sensitive data identified.

Cloud Workflows gives us the ability to rapidly deploy a process that orchestrates multiple services in order to:

1. Retrieve the most recent open customer requests
2. Scan our SDP data profiles for customer occurrences
3. Apply business rules to determine the course of action
4. Fulfill the deletion request via the BigQuery API
5. Provide a post-deletion report for manual checks

By using serverless infrastructure, we bypassed the burden of setting up development environments, SDKs, and API clients. This freed us to focus on meticulously defining and automating the data deletion request process through workflow YAML files and BigQuery SQL. Ultimately, Workflows fulfills the need to orchestrate and control the sequence of API requests to OneTrust, BigQuery (for routine execution and consuming SDP Data Profile results), and Cloud Functions (for processing of OneTrust API JSON response bodies), which allows us to automate a process that must consider dependencies between several systems.

The combination of Google SDP and Cloud Workflows provides simplicity to a complex problem. It has automated PII discovery in our BigQuery assets and has simplified the automation of data redaction through easy-to-define interactions with the BigQuery API and Consent Management System API. This approach has future-proofed our solution, where new data products or assets are automatically included in future SDP data profiles, and the redaction of the data product only requires a new BigQuery routine definition and a new routine invocation defined in the Workflow yaml.

It is worth mentioning that our infrastructure state is managed in Terraform Cloud, which means our automated deployments are made consistently in a declarative manner. There are still opportunities for continuous improvement, but these tools have given us a strong foundation on which to continue building trust with our customers when it comes to their data.