Problem Statement

Let's suppose you collect phone numbers in three places in your app.

• In your login flow for multi-factor authentication
• In your settings page for text-based alerts and marketing
• In offline analysis for fraud detection

Privacy regulations like GDPR dictate that you must only use data for the processing purposes that each user consents to. You must not send text alerts to phone numbers that have been given to you for MFA, and vice-versa.

Without UserClouds

Without UserClouds, phone numbers are stored in a standard database. Once a phone number is stored, it is not clear how it was gathered, or which processing purposes the user consented to. If consent data does exist, it is kept separately from the user data. This makes it easy for systems and employees to access, use and duplicate the data against consent. As more copies of the data propagate, the risks of consent violation and data breach rise.
To alleviate this, engineers add distributed glue code across teams, systems and languages. Writing, maintaining and updating this is code is costly and error-prone. The code becomes difficult to audit and confidence in the system erodes. The company implements manual approval processes around data access, slowing down the organization even further. Well-meaning employees circumvent access controls to achieve their goals, asking colleagues with access to download data for them. The company loses sight over who accesses data, when and why.

Eventually, an accident happens. A product marketer sends texts to the MFA-only numbers, or an employee's account is hacked. The company is fined for the data breach or consent violation, and customer trust is broken.

With UserClouds

UserClouds makes using and comprehensively protecting the phone numbers possible. The phone numbers are stored alongside granular user consents in the User Store, and are rarely or never stored outside the store. Since privacy and access-related code is centralized at the store boundary, maintenance and update can be performed by a single team, at minimal cost. Data sprawl is minimized and data access can easily be turned off in case of a breach. Security-related code is much more easily audited, so it is easier to identify flaws in the logic. The company has perfect oversight over data access, with an automatic audit log.

Implementation

Implementation takes five simple steps.

1. Configure the store

Firstly, add a column to your user store for phone number. If you anticipate saving more than one phone number per user, you can configure this as an array column to store multiple values. Then, define your three data processing purposes, authentication, marketing and integrity.

2. Define the access policy

For both reading and writing data, use an access policy that limits access to the company's internal servers and to the company's application, using an API key. Call the access policy ApplicationInternalOnly.

3. Define the write APIs

Next, define two mutators (write APIs) to save the data to your store. This is very similar to writing a custom query against a generic API. The two mutators are:

• SetPhoneForAuthentication - this will save phone numbers to the store alongside the user's consented purpose authentication and integrity
• SetPhoneForMarketing - this will save phone numbers to the store alongside the user's consented purpose marketing and integrity

4. Define the read APIs

Configuring access is straightforward too. Simply create three accessors (read APIs), one for each data processing purpose.

• GetPhoneForAuthentication
• GetPhoneForMarketing
• GetPhoneTokensForIntegrity

For each accessor, set the data processing purpose to the relevant purpose (e.g. authentication), and use the same access policy as above. For the first two accessors, use a passthrough transformer. On the final transformer, use a data transformer that tokenizes the phone number, returning a randomly generated, format-preserving phone number that can be resolved back to the actual phone number.

5. Invoke the read/write APIs from your code

Finally, use the UserClouds SDK to invoke the read/write APIs from your code in your application and data pipeline. Nice job! You have now implemented User Store in your online and offline systems.

Outcome

Now, data can be accessed via the three accessors above. The access policies for the three read APIs enforce privacy policy, filtering out phone numbers where consent has not been gathered. When phone numbers do need to be stored outside the User Store (for offline analysis), they are stored as tokens, minimizing data sprawl and enabling centralization of access control. These tokens can be exchanged for the raw phone number data if the resolution access policies are met.

Your team can rest easy, knowing that consents are enforced at the moment of data access.