Skip to main content

Configuring your Privacy Computation Engine

For the PCE to work in your specific situation, you first need to configure it via its configuration API.

This API allows you to define what is usually called RoPA - Record of Processing Activities, a way to comply with the requirements of Article 30 of GDPR but also with various CCPA requirements.

In blindnet DevKit defining a RoPA means configuring the following:

  • General information about your Organization, its representatives, its server's locations and policies
  • Selectors - additional PRIV Data Categories, subcategories of the existing ones, to describe the data you are processing.
  • Legal Bases for processing of particular Data Categories for Particular Purposes
  • Retention Policies specifying minimal and maximal retention times for particular Data Categories
  • Provenances defining where your system gets the data from

In addition, you can configure how you want the PCE to behave:

  • Demand Resolution Strategy : when (for what kind of Privacy Requests) to deliver automatic responses and when to wait for human validation
  • Regulations: add additional rule sets specific to certain regulations

In order to follow through this section of the tutorial, you might want to either set-up your own instance of PCE or use the PCE isntance provided by blindnet for testing at In the followign examples we'll use this instance.

If you are using the instance provided by blindnet you will need to reach out to us to get your app_id and app_key. Once you have got those, you can use our Token Generator to generate the credentials that you will need in order to authenticate your calls to our APIs.

In the following examples replace the blindnet's testing instance URL with your URL, where you are hosting your PCE instance, and replace the the auth-token with your token generated using the Token Generator.

General Informationโ€‹

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.

You will need the following information.

General Info schema fieldInformationRelated Legislation ArticlesUsage by blindnet DevKit
organizationThe name of your organization and its representative representative...GDPR Art. 30.1.a, GDPR Art. 30.2.aTo reply to any TRANSPARENCY.ORGANIZATION Privacy Request
dpoThe name and contact of your data protection officerGDPR Art. 30.1.a, GDPR Art. 30.2.aReply to any TRANSPARENCY.DPO Privacy Requests
data_consumer_categoriesThe categories of recipients to whom the personal data have been or will be disclosed including recipients in third countries or international organisationsGDPR Art. 30.1.a, GDPR Art. 30.2.a, CCPA 1798.115.1.2, CCPA 1798.110.1.4Reply to any TRANSPARENCY.WHO Privacy Request
data_security_infoa general description of the technical and organisational security measuresGDPR Art. 30.1.d, GDPR Art. 30.2.d
countriesCountries where user data is being storedGDPR Art. 30.1.e, GDPR Art. 30.2.cReply to any TRANSPARENCY.WHERE Privacy Requests
privacy_policy_linkURL to your Privacy PolicyGDPR Art. 13, GDPR Art. 14, GDPR Art. 15Reply to any TRANSPARENCY.POLICY Privacy Requests. Make sure your Privacy Policy includes the information listed in relevant GDPR articles

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.

Resolution strategyโ€‹


Resolution strategy for each of the demand actions can be set using PUT /configure/demand-resolution-strategy. Two strategies are supported - automatic and manual.

If automatic is set for a demand action, demands of that action will be processed automatically, producing the result based on the recommendation created by the Privacy Computation Engine. Results can't be manually altered.

If manual is set, a demand needs to be validated by a human, and is available in GET /consumer-interface/pending-requests

Example request body for setting the resolution strategy:

"transparency": "manual", // Manual resolution of TRANSPARENCY demands
"access": "auto", // Automatic resolution of ACCESS demands
"delete": "manual", // Manual resolution of DELETE demands
"revoke_consent": "auto", // Automatic resolution of REVOKE_CONSENT demands
"object": "manual", // Manual resolution of OBJECT demands
"restrict": "auto" // Automatic resolution of RESTRICT demands

Resolution strategies set for your application can be obtained with GET /configure/demand-resolution-strategy.



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

Setting the selectors is important in order to reply to any `TRANSPARENCY.DATA-CATEGORIES` Privacy Request, and comply with several regulations (GDPR Art. 30.1.c, GDPR Art. 15.1.b, CCPA 1798.100.1, CCPA 1798.110.1.1, CCPA 1798.115.1.1, 1798.115.1.2, CCPA 1798.115.1.3). They are also used to idnetify particular user data relevant for a particular request and execute operations over the data storage.

Sensitive data you capture 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, corresponding to a particular field in your database, can be defined as a subcategory of any of these data categories. This is done using dot notation.

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.

If you are using an automatic data cataloging tool, you may want to consider our mappings to vocabularies used by major software vendors.


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

Using just {subcategory} will lead to an error.


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.

To configure Legal Bases means to inform the PCE about which kinds of data (Data Categories) are being processed in which way (Processing Categories) for which Purpose and under which Legal Base for that processing.

This describes, in a nutshell, every operation over user data that your system performs. PCE uses this information to both inform the data subjects (in the context of requests of type TRANSPARENCY.LEGAL-BASES, TRANSPARENCY.DATA-CATEGORIES, TRANSPARENCY.PROCESSING-CATEGORIES, TRANSPARENCY.PURPOSE), and determine possible reponses to OBJECT, RESTRICT, and DELETE Privacy Requests.

E.g. If you operate a promotional mailing list to which users subscribed and gave consent, you are likely to be processing (Processing Categories: COLLECTING, STORING, and USING) users' data (Data Categories: CONTACT.EMAIL, NAME) for marketing purposes (Purpose: MARKETING) with users consent (Legal Base Type : CONSENT). If a user signed a contract with you / subscribed to a service you provide, then it might be legitimate to process their data, regardless of consent, for the purposes of delivering the service to them (Legal Base Type : CONTRACT). In some cases you might be in a situation to simply have to collect user's data for compliance with financial regulations (Legal Base Type : NECESSARY.LEGAL-OBLIGATION), etc. You may have more than one legal base for the same data.

Provding information about Legal Bases and Purposes of processing is made mandatory by GDPR (Art. 12, Art. 13, Art. 15, Art. 30.1.b, and Art 30.2.b), CCPA (1798.100.1, 1798.110.1.1, 1798.110.1.3, 1798.115.1.1, 1798.115.1.2, 1798.115.1.3) and other relevant regulations.

Our metadata language, PRIV, is designed for exhaustive coverage of a variety of situations while at the same time making configuration easy in most common situations. It contains pre-defined terms inspired from texts of major privacy regulations. While you can extend the PRIV vocabulary to fit your needs, we recommend using pre-defined categories whenever possible in order to maximize interoperability and leverage built-in PCE rules.

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

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

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โ€‹


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

Retention policies define how long you can or must keep each data after a specific event occurs. The PCE uses this information to inform the data subjects when responding to TRANSPARENCY.RETENTION requests and to prevent DELETE requests from being accepted as long as the data must be kept.

Provding information about your Retention Policies is made mandatory by GDPR (Art. 13.2.a, Art. 14.2.a, Art. 15.1.d, Art. 30.1.f) and other relevant regulations.

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 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.

Provding provenance information is made mandatory by GDPR (Art. 14.2.f, Art. 15.1.g), CCPA (1798.110.1.2) and other relevant regulations.

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

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 system:

"data_category": "CONTACT.PHONE",
"provenance": "USER",
"system": ""

Refer to Provenance in PRIV for more details.

Demand Resolution Strategyโ€‹


Demand Resolution Strategy can be set in the PCE using PUT /configure/demand-resolution-strategy as detailed in the related DemandResolutionStrategy schema.

Demand Resolution Strategy allows you to set to "auto" the processing of certain of types of Privacy Request Demands.



Regulations can be set in the PCE using PUT /configure/regulations as detailed in the related Regulations schema.

Regulations allow to load additional, regulation-sepcific rules that you want your PCE to apply.

For instance, under GDPR, processing certain categories of data (e.g. biometric...) is prohibited even with data subjects' consent. PCE can enforce those rules.

For convenience, we provide a pre-defined set of GDPR rules that we advise you to load if you want to comply with this regulation.