Skip to main content

Configuring your Privacy Computation Engine

For the PCE to give you recommended actions adapted to your specific architecture and needs, you first need to configure it via its configuration API.

This API allows you to define:

  • General information about your Organization and its' data processing policies (Equivalent to a RoPA - Record of Processing Activities)
  • Mappings of your data structures to PRIV Data Categories
  • Few choices you have to make about when to authenticate the user (before or after they make a Privacy Request), and when to deliver automatic responses and when to wait for validation

General Information​

API

General information can be set in the PCE using PUT /configure/general-info, retrieved using GET /configure/general-info, as detailed in the related GeneralInformation schema.

Your audience needs access to the full picture of your organization's data processing policies easily and at all times. Not only because it is a legal requirement, but also and more importantly because people need such information to trust your organization enough so they can give you access to their sensitive data.

📜Legislation

Article 30 of the GDPR requires controllers and their representatives to maintain a precise information set called Record of Processing Activities (ROPA).

Configuring the general information in the Privacy Computation Engine helps your organization to meet this requirement by using other components of the DevKit (e.g. interfaces).

While such information is mostly composed of a set of static text, it can rapidly get difficult to maintain. Moreover, transforming such data into intelligible and unambiguous content for your audience isn't straightforward.

Here, using the blindnet devkit can greatly help you to solve both problems:

  1. the PCE infers as many pieces of information as possible to minimize the volume of data to configure and maintain
  2. other components of the devkit are here to provide such data to the user in an intelligible form without extensive implementation effort
caution

This general information describes the entities legislatively responsible for sensitive data and privacy-rights protection. Therefore, it shouldn't necessarily represent only your organization if you are processing sensitive data on behalf of others.

For example, the organization field holds information about the organization processing the data and its representative, be it your organization or your organization and the organization(s) on behalf of which you are processing data.

The same logic applies to the dpo field, which holds information about your DPO or the DPO(s) of the organization(s) on behalf of which you are processing data.

Selectors​

API

Selectors can be set in the PCE using PUT /configure/selectors as detailed in the related CreateSelectorPayload schema.

Sensitive data you capture on a regular base can often be complex to categorize.

The blindnet devkit gives you a clear set of data categories you can use to qualify collected sensitive data for efficient privacy management.

A selector can be defined as a subcategory of any of these data categories, using dot notation, to qualify any captured data.

For example, you can define a FINANCIAL.BANK-ACCOUNT.IBAN, as a subcategory of the predefined FINANCIAL.BANK-ACCOUNT category, to identify and retrieve an IBAN number collected for regular payment.

Refer to the definition of Data Capture Fragments in PRIV for more details.

caution

Each selector is defined by its full dot notation ({data_category}.{subcategory}).

Using just {subcategory} will lead to an error.

{subcategory} can however be optional, as any data category can be used as a selector.

API

Legal Bases can be set in the PCE using PUT /configure/legal-bases, retrieved using GET /configure/legal-bases, as detailed in the related CreateLegalBasePayload schema.

Both law and your users require any capture of sensitive data and any manipulation of such data to be clearly justified. In other words, you need to define and expose a legitimate (i.e. legal) foundation (i.e. base) before conducting any operation on sensitive data. You need, at all times, to record and explain why you need to conduct such operations.

The blindnet devkit helps you to easily define such Legal Bases for your whole system.

Thanks to this configuration, all contracts, legitimate interests and necessary legal bases are clearly defined and easily maintained for your whole system in a single place. This not only allows you to avoid any ambiguity or omission but also to be ready for change at any time. Legislations, organizations' rules, product features, and any other aspects of data privacy, can indeed change often and quickly. Such changes can lead to extensive and tedious data manipulations and communications to people from which you collected data. Thanks to your legal bases configuration, the PCE will greatly ease this process, by recommending and even allowing you to automate related operations.

Refer to the legal bases lifecycle and format definition in PRIV for more details.

As with selectors, Legal Bases' Types can be defined via a dedicated set of terms.

By default, a legal base is defined without a specific scope. This means it refers to all data, processing and purposes.

However, most legal bases are only bound to specific contexts. Such contexts can be defined by three aspects:

  • Categories of Processing: what you intend to do with the data, e.g. COLLECTING
  • Data Categories: what type of data is used during the operation, e.g. CONTACT
  • Purpose of Processing: what type of data is concerned, e.g. PERSONALIZATION
tip

You can phrase a privacy scope in a sentence of the form:

« We need Processings of/on Data Categories for Purposes. »

Here again, these three parameters can be set using specific sets of terms with dot notation:

Retention Policies​

API

Retention policies can be set in the PCE using PUT /configure/retention-policies as detailed in the related CreateRetentionPolicy schema.

Retention policies are here to help you track and automate all required operations on sensitive data you hold.

They define how long you can or must keep each data after a specific event occurs.

tip

You can phrase a retention policy in a sentence of the form:

« Keep Data Category for no longer / less than duration after Event Type. »

You can define a retention policy in the PCE by associating:

  • a type of event (after), using the associated predefined set of terms
  • with a certain category of data (data_category), using a pre-configured selector
  • for a specific point in time, defined by:
    • a before/after operator (policy) called "retention term" (NO-LONGER-THAN, NO-LESS-THAN, or any of their subcategories defined according to dot notation as defined in PRIV)
    • and a duration (using the ISO 8601 format)

For example, the following defines contact data shouldn't be kept more than 30 days after the associated service ended:

{
  "data_categoy": "CONTACT",
  "policy": "NO-LONGER-THAN",
  "duration": "P30D",
  "after": "SERVICE-END"
}

Based on your Retention Policies configuration, the PCE will:

  • recommend deletion of data belonging to a category associated with a NO-LONGER-THAN retention policy when this policy expires;
  • deny deletions following a DELETE privacy request if the targetted data belongs to a category with a still active NO-LESS-THAN policy.

Refer to retention policies in PRIV for more details.

Provenances​

API

Provenances configuration can be set in the PCE using PUT /configure/provenances, and is detailed in the related CreateProvenancePayload schema.

Provenances represent the possible origins of each data.

For the blindnet devkit, we define a provenance by combining:

  • a specific category of data (data_category), using a pre-configured selector
  • a provenance term, with an associated predefined set of terms
  • a URL, used as a unique ID to identify the privacy system which has either:
    1. collected the data (if it has been collected from a user or derived)
    2. OR initiated its transfer
tip

You can phrase a provenance in a sentence of the form:

« Data Category is provided by / has been provenance (USER, TRANSFERED, ...) via system. »

For example, the following indicates contact phone numbers are provided by users of the https://blindnet.io system:

{
  "data_category": "CONTACT.PHONE",
  "provenance": "USER",
  "system": "https://blindnet.io"
}

Refer to Provenance in PRIV for more details.