Data privacy: success factor for the Corona Warn App (5 Learnings out of an exciting journey)
Cooperative approach with all involved roles

Data privacy: success factor for the Corona Warn App (5 Learnings out of an exciting journey)

As part of the celebrations for the 2nd birthday of the german Corona Warn App (CWA), the idea emerged in the privacy workstream of Telekom to write down and share our learnings. Sorry that the article has become a bit longer...

Data privacy consulting during development || Cooperation with architecture, development and operations

From the very beginning, it was clear that the handling of personal or personally identifiable data would be viewed very critically by the public. The mandate to develop the CWA was accompanied from a lively public discussion on the fundamental question of how contact tracking could be realized with the least possible impact on users' rights and freedoms. In order to realize the maximum success of the app, it was very important to consider all conceivable aspects and to design the entire system (the app is only one part of it) in such a way that as little personal data as possible is used. And if data is absolutely necessary after all, it must be stored for as short a time as possible. In addition, we have taken care to ensure that conclusions about individuals are not made possible by the fact that existing partial information can be linked together. By fulfilling these premises, it was possible to generate a high level of user acceptance.

Ongoing data protection concepts and support for data privacy impact assessment for the RKI

 It was mandatory to provide data privacy concepts for the back-end components for which T-Systems was responsible, and then to update these concepts for each functional expansion. Likewise, it was clear at the beginning of our work that a data privacy impact assessment (DPIA) would have to be prepared for this project, which would either be published immediately or whose publication would be enforced through appropriate requests under the Freedom of Information Act. Formally, a DPIA must be performed and documented before a system goes live. From the very beginning, this was an unequivocal demand of the Federal Commissioner for Data Protection and Freedom of Information (BfDI). At the planned launch of the app - only five weeks after the start of development - it was accordingly also clear that the preparation of the DPIA must begin immediately so as not to jeopardize the launch. Supporting the responsible body (RKI) with the DPIA was a separate component of the performance obligation for the CWA development. So was the creation and updating of customer data privacy concepts for the individual CWA components, which serve as the basis for identifying risks.

Risk-based, development-accompanying data privacy consulting

Due to the given time pressure, we combined the identification and assessment of risks with the definition of requirements, architecture and development consulting, and documentation. Risks that are rather implicitly captured and minimized in Telekom's internal privacy and security assessments via a broad set of data privacy and IT security requirements, flanked by the profound know-how of our consultants, we explicitly documented for the CWA and developed complementary measures for their reduction. Extremely early involvement of data privacy, IT security, architecture, development together with the business side, often in interdisciplinary rounds, led to very constructive discussions. In some cases, it turned out that risks could be reduced more through architectural changes than would have been possible through other measures. From this experience, the document "Design Decisions" was created. There, we created the possibility to document why we decided on a certain architecture for the app or certain backend systems. In addition, we have also described how we meet the requirements of various social groups (e.g., Chaos Computer Club (CCC), Forum Informatiker:innen für den Frieden (FIfF)) and public institutions, e.g., European Data ProtectionData privacy Authority (EDSA), which were published in advance.

With the expansion of the CWA's purpose through the integration of the contact diary, and even more so with the expansion of its functions through quick test connection and profile, and then later the wallet functions for the Digital Corona Certificates (DCC), there were always considerable challenges. It always had to be demonstrably documented that data flows of the different functions were separated from each other and that the data processing operations posed acceptable risks. 

Risk-based, development-accompanying data privacy consulting

570 risks and 50 risk assessments in the "DPIA team" of SAP and TSI in the release cycle of the CWA. 

Our tasks included providing ongoing support for the DPIA, in particular providing and updating the risk assessments for the RKI. These are published regularly on https://www.coronawarn.app/en/#privacy. The risk assessments were based on the data privacy concepts, which are also created and maintained by our team for the respective systems. 

In assessing the risks, we estimated the damage dimension and probability of occurrence in 4 gradations (low-1, medium-2, high-3, very high-4) and multiplied them by each other. In doing so, we differentiated the damage dimension in relation to the non-fulfillment of the performance targets of the standard data protection model, among other things in order to be able to better record the targets of measures.

Prior to the assessment, we developed a distinctive and scenario-based attacker model with more than 10 attacker roles (each characterized by know-how, motivation and available resources). In addition, there is a description of possible attack types and their combination and the possibility to differentiate according to affected groups. 

Risk assessments are conducted by us for six different processing activities / use cases. These are published at https://www.coronawarn.app/en/#privacy, Appendices 3-8. 

In total, we have documented and assessed more than 570 individual risks and identified countermeasures. The risk assessments were performed in the release cycle, i.e., more than 50 times, mostly every 2 weeks. 

What we learned and applied to other projects (5 learnings out of an exciting project)

1) Early involvement and cooperative, close collaboration with the teams

This is not new, but should be emphasized again and again: Early participation creates the greatest design opportunities. Close collaboration ensures the flow of information and enables ongoing influence and quick decisions.

2) Time for joint discussions and evaluations

Even under great time pressure, it pays to invest the time for dailies, stand-ups, workstream meetings, threat modeling and other rounds. The important thing is that the right people come together and the focus is on the will to achieve the goal together.

3) A central document as a "source" for risk assessments / DPIA, PSA, relevant contractual aspects and customer information

Based on our experience at CWA, we have now moved to creating a central document that serves as the content foundation for all others. This may be a matter of taste, but we continue to trial this approach. Currently, we have the impression that a single document with the described scope is easier to maintain and update than a large set of individual documents.

4) Looking at risks to data subjects (DPIA) and business risks (input to risk management)

Identifying risks for users (the "data subjects") requires the interaction of all experts for data privacy, IT security, process and risk management, as well as the responsible business side. With the combined expertise of the aforementioned experts and the methodology described above, it is easy to identify risks for the company (both in the role of the responsible department and in the role of the service provider). This identifying and analyzing risks not only serves to fulfill the legal requirement from the GDPR, it also benefits the company, especially by extending it in a meaningful and simple way.

5) Model for large projects with high criticality

Of course, the described approach does not fit for every project. The effort to be expended must always be in relation to the dimension and criticality of the project. But where this relation is right, we can only warmly recommend our approach.

Many thanks to the whole CWA team, proud to be part of the journey, always excited of our collaboration !

Ivan G.

IT Security Architect and Subject Matter Lead, Member of Telekom MMS Technology Board

2y

It was a pleasure to work with you in this challenging project! Gerne wieder! ;)

To view or add a comment, sign in

More articles by Frank Wagner

Insights from the community

Others also viewed

Explore topics