Purpose and consent

Summary

Purposes are used to track, enforce and audit user consent in User Store. Purposes have names like marketing, analytics and operations that map to the data processing purposes described in your privacy policy and terms of service.

When users share data with you, they consent to a set of purposes for each piece of data that they share. For example, they might consent to using their email address for personalization, but not marketing. User consent is granular: it is stored per piece of data.

Purpose checks are always enforced on data accessors to ensure that user data is never extracted from the User Store for a purpose which its owner has not consented to. For example, if an end user has not consented to an address being used for shipping, a purpose check will be used to filter out that user's address from an accessor like GetAddressesForShipping.

How to define your data processing purposes

You can define and describe your own set of purposes in the Purposes table of the User Store page in Console. The purposes and their descriptions should correspond to the purposes listed in your Privacy Policy and Terms of Service. They will be used to enforce consent and build an auditable paper trail of that enforcement.

How users consent to purposes

Users can share and revoke consent to process their data for a particular purpose (or set of purposes) when:

• They sign up for your service
• They share a new piece of data with you
• They complete flows authorizing or revoking authorization for particular uses of their data, e.g. a sign-up for a weekly newsletter

Consent is granular: it is stored per piece of data. For example, an end user might consent to using their email address for marketing, but not their phone number. When a user consents to a particular data processing purpose for a particular piece of data, this is tracked in User Store as a consented purpose.

How user consents are stored

Consented purposes are stored per data value in User Store.

• Single value columns are associated with a single set of consented purposes per user. For example, an email column with one email per user is associated with a single set of purposes for each user's email (e.g. operations and marketing).
• Array columns, which store multiple values per user in one column, are associated with a corresponding purpose array column. This array column stores an array of sets of consented purposes for each user - one set of consented purposes per data value stored for each user. For example, an array column storing two addresses for a user, would store two sets of consent for that user - one for the first address (e.g. operations and shipping) and another for the second (e.g. operations, billing and marketing).

How to edit consents via the API

Consents must be specified for all mutator operations (creates, updates and deletes). Consents are passed to the User Store in the context at execution time. If a data value is authorized for multiple purposes, deleting a data value for a single specified purpose will remove that consented purpose (only).

(Coming soon) UserClouds is building off-the-shelf integrations with consent management solutions like OneTrust and PrivacyArc to pass consent data collected by third party services into User Store.

How user consent is enforced

In User Store, data accessors (read APIs) are used to retrieve a pre-specified set of columns of data for 1+ users. Every accessor is associated with a purpose at creation time.

At execution time, the accessor runs a purpose check, which filters out all user records and all individual data values for which the user has not consented to the specified purpose.

The purpose check works as follows:

• If a user has consented to the specified purpose for at least one value in all columns specified in the accessor, the purpose check will pass for that user. Assuming the accessor's access policy also passes, the accessor will return all data values in those columns for which the user has given consent.
• Conversely, if the user has not consented to the accessor's purpose for all values in at least one column specified in the accessor, the purpose check will fail and the accessor will filter out that user.
  See the example below for more information.

Illustrative Example

Let's suppose:

• The user store has two columns: a single-value column storing Name and an array column storing multiple Addresses per user
• An accessor GetAddressesForShipping retrieves addresses for the purpose shipping
  The user store has three user records, with data and consents as listed below

Then:

• Alice has not consented to shipping for any of her addresses, so the purpose check would fail. The accessor would not return any data for Alice.
• Bob has consented to shipping for one of his addresses, so the purpose check will pass. If the access policy also passes, the accessor will only return address B2 (for which Bob has consented to shipping)
• Chhavi has consented to shipping for both address, so the purpose check will pass. Both addresses will be returned by the accessor.

Note that no accessor that (1) retrieves address data and (2) has purpose shipping would return any data for Alice. That is to say, even if Alice had consented to her name being used for shipping, the purpose check for GetNameAndAddressesForShipping would fail for Alice and return no data. The user must have consented to the specified purpose for at least one value in all columns specified in the accessor for the accessor to return _any _data for that user.