## 2 Materials and Methods
### Decomposing a DPIA  
Looking more into the details of DPIAs: German data protection supervisory authorities refer to the \"Standard Data Protection Model\" (SDM) as a method to ensure a consistent privacy consulting and auditing practice, specifically for determining technical and organizational measures by the GDPR [20]. The essential component of the SDM consists of a concept called \"seven elementary warranty objectives\", which are anchored in the principles of Article 5 of the GDPR [21]. These warranty objectives include ensuring confidentiality, integrity, availability, transparency, intervenability, and non-linkability of personal data processes, along with the requirement of \"data minimization\". These warranty objectives represent the core of each DPIA. In addition to the aforementioned warranty objectives, there exist subgroups of risks that are attributable to specific data processing stages, thus reflecting the data lifecycle. For instance, the subgroup includes aspects such as patient consent/notification, documentation, utilization, erasure, and so forth. A comprehensive listing of these subgroups can be found in Table 1. The data life cycle, which is shown in Table 1, represents the chronologically structured steps for every project concerning data handling in general. The cycle thus facilitates the assessment of risks regarding completeness. To associate individual risks with their respective subgroups, it is crucial, unless already undertaken as part of the project, to generate a data flow diagram and systematically scrutinize it from inception to completion to identify potential sources of risk. Consequently, each identified risk is given a risk source code, e.g., Doc01, Usa03, and Era04 for documentation, usage, and erasure, respectively. These codes are used to describe the risk in greater detail and to make a risk table within the DPIA, depicting the risk code and a short explanation of the risk at hand. Both the subgroups as well as the individual risks are crucial parts of a DPIA. Subsequently, to attribute the ascertained risk to an appropriate warranty objective, a determination must be made regarding the primacy of the specific risk concerning the given warranty objectives, and whether any concurrent warranty objective is of negligible relevance. For instance, in cases where a consent withdrawal is executed but fails to reach the IT administration, resulting in the persistence of patient data within the system for research or analogous purposes, both the confidentiality and intervenability warranty objectives are contravened. Yet, it merits highlighting that the breach of confidentiality is to be perceived as substantially more hazardous than the intervenability violation. Alternatively, when a singular risk yields non-negligible consequences in divergent dimensions, it could potentially implicate two distinct warranty objectives. For instance, in the event of the theft of the data server, there exists the possibility of the pseudonymized data falling into unauthorized hands, thereby transgressing the confidentiality warranty objective. Conversely, the availability warranty objective may also be compromised, rendering the data inaccessible. Consequently, a single risk source can engender divergent potential consequences. Simultaneously, distinct risks can result in the same harm; for instance, an attacker might use phishing tactics to acquire login credentials, enabling access to software handling patient-related data, or a user might inadvertently neglect to