Determining the means
Home » The GDPR » Main Concepts » Data Protection by Design and by Default (DPbDD) » Analysis of Article 25. Data protection by design » Determining the means

In its guidelines on the concepts of controller and processor in the GDPR[1], the European Data Protection Board provides a legal analysis of what it means to determine the means of processing. The discussion here is more technically oriented. The Board distinguishes between “essential” and “non-essential means”; the latter can also be determined by processors. The present text does not make such distinction and just provides a technical interpretation of what decisions the determination of the means entails.

Determining the means is a phase that predates the operational use of a processing system and prepares and sets up everything that is necessary for the actual processing operations. This means, that guided by the purposes, a controller has to plan, design, and implement everything necessary to enable the processing itself. This includes at least the following tasks:

  • Determine the human and technical resources necessary for the processing;
  • Determine the instructions that define the authorized processing and are suitable for the resources;

What this entails in more detail is described in the following.

Determining human resources entails at least the following:

  • Planning that determines what human resources are necessary, selecting suitable human resources and bringing them under the authority of the controller or processor. This is typically done through employment that establishes a contractual relationship between the employee and the controller.
  • Setting the human resources in a condition in which they can translate the instructions in a manner that constitutes authorized processing. This can entail things such as
    • the undersigning an agreement to refrain from disclosing personal data,
    • the commitment by the human resource to certain general policies or codes of conduct, and
    • training of the human resource to acquire knowledge and skills necessary for executing the instructions in the desired way.

Determining technical resources entails at least the following:

  • Planning, selecting and acquiring the necessary technical resources.
  • Bringing the technical resources in a condition that they can execute the necessary processing operations. This can entail things such as
    • physical installation,
    • configuration,
    • integration in the used infrastructure, and
    • installing the necessary software.

Determining instructions for resources in general: After having discussed the determination of resources, the following analyzes the determination of instructions. Looking at Figure 1, it is clear that the following kinds of instructions exist:

  • Instructions that determine the behavior of a single resource,
  • instructions that determine the interaction between multiple resources,
  • instructions that determine the interaction between resources and data subjects, and
  • instructions that determine the disclosure of personal data to third party recipients.

These different types of instructions are discussed in more detail in the following while distinguishing between human and technical resources.

Determining the instructions for human resources are discussed in the following:

  • Instructions for individual human resources can be expressed in two different styles:
    • Defining the required outputs, products, and effect the activity of the human resource shall result in. This constitutes declarative instructions that focus on the what aspect and relying on the resource’s capability to fill in the how aspect of the instructions.
    • Detailed descriptions of the way in which an activity has to be executed. This constitutes imperative instructions that focus on the how aspect, require less intelligence and autonomy from the executing resource, and often define the what aspect in a more implicit way.
  • Instructions on how human resources interact among each other: This includes designing and specifying business processes, work-flows and data-flows. There are various formal languages[2] and graphical notations[3] to support such activities.
  • Instructions on how human resources interact with technical resources: Technical resources are not autonomous. They are controlled by humans (i.e., human resources). Even the most autonomous technical resource needs to be switched on. Usually, human resource exercise a further-reaching control over the technical resource through user interfaces and via human machine interaction (HMI). A common way to model such interactions are use case diagrams. These are often also used for the specification of functional requirements of software. Instructions on how humans interact with technical resources also define which human resources are authorized to access which technical resources for what purposes. These kinds of instruction thus also determine the responsibility human resources have for operating certain technical resources.
  • Instructions on how human resources interact with data subjects determine what interactions data subjects can have with the controller. This includes the manual processing of data subject right invocations (see Chapter 3 GDPR) and foreseen interactions with the data protection officer (see Art. 38(4) GDPR).
  • Instructions on how human resources interact with third-party recipients determine which personal data is manually disclosed to third party recipients.

Determining the instructions for technical resources entails the following:

  • Instructions for individual technical resources potentially encompasses the following aspects:
    • Procurement[4] of Software which usually constitutes machine instructions which are expressed in some formal (imperative or declarative) programming language. The behavior of the software may depend on parameters that can be determined at a later point of time; such parameters are typically called configuration. The decision whether configuration is possible and what parameters it entails is built into the software. There are two types of configuration,
      • the one determined by the controller, and
      • the one controlled by the data subject (for example preferences and settings supported by an appropriate user interface).
    • Configuration of the software by the controller.
    • Specification of default values for configurations performed by the data subject. This is obviously the subject of Data Protection by Default that is regulated in Art. 25(2) GDPR (see section 1.3.2 below).
  • Instructions on how technical resources interact among each other: Technical resources can interact with each other when they have interfaces that are connected by communications channels. The communications that can take place are typically determined by protocols. Communications can be represented, for example, by interaction diagramssuch as UML sequence diagrams and UML communication diagrams. Such communications typically involve the exchange of (personal) data. These can be represented graphically in data flow diagrams. This kind of instructions also determines which technical resources are authorized to interact with which others and for what purposes. The aspects determined by these kinds of instructions are often related with the concept of technical (component) architecture.
  • Instructions on how technical resources interact with data subjects are typically used for configuration by data subjects (see Art. 25(2) GDPR and its discussion below) and for the automated support of data subject rights (see Chapter 3 GDPR). Both require appropriate user interfaces. Again, use case diagrams can be used to represent these. Again, authentication and access control is necessary for the technical resource to determine whether the user is indeed the claimed legitimate data subject.
  • Instructions about automatic transfer of data to third party recipients determinewhich (personal) data are disclosed, under which conditions, and how. This typically requires interfaces for humans or machines and appropriate channels of communications. Data can be pushed to recipients or disclosed on request. Authentication (of humans or machines) and access control are typically relevant also here.

Identifying appropriate technical and organizational measures: As was discussed in section 1.3.1.1 above, Art. 25(1) mandates controllers to implement appropriate technical and organisational measures which are designed to implement data-protection principles also at the time of determining the means. It has been reasoned above, that determining the means consists of determining the resources and the instructions. Also, together, resources and instructions constitute a processing system able to execute the authorized instructions on actual personal data.

It is clear that the required measures must be integrated with this processing system. Namely, they must be integrated into its instructions and applied to its resources. In other words, such measures cannot be determined independently. Much rather, they need to be determined together with the determination of instructions and resources. In every step of determining a part or aspect of the processing system, the principles of data protection have to be taken into account in order to identify and integrate adequate measures.

For this reason, the aspects of a processing system that were distinguished in the above discussion directly identify the areas where appropriate measures have to be found and implemented. This section is therefore instrumental in providing a structure for the detailed discussion of measures in section 1.1.4 below. It also serves to achieve a certain completeness by systematically considering all aspects and each principle.

 

References

1European Data Protection Board, Guidelines 07/2020 on the concepts of controller and processor in the GDPR, Version 2.0, Adopted on 07 July 2021, https://edpb.europa.eu/system/files/2021-07/eppb_guidelines_202007_controllerprocessor_final_en.pdf (last visited 2/12/2021). ↑

2These formal languages include for example the XML Process Definition Language (XPDL) and the Business Process Execution Language (BPEL). ↑

3These graphical visualizations include for example the Business Process Model and Notation (BPMN), Activity Diagrams, flow charts, and Petri Nets. ↑

4Procurement is here used as a collective term that encompasses both, custom development and acquisition of software from the market. In both cases, controllers are responsible for an adequate requirements analysis and specification. ↑

 

Skip to content