With the Technical Guideline BSI TR-03161, the information security requirements for digital health applications have become significantly more specific. Since compliance with the guideline must be demonstrated for certain approval procedures at the latest, it has become an integral part of product development for many manufacturers.
Nevertheless, in practice it repeatedly becomes apparent that there are a number of misconceptions surrounding TR-03161. They often lead to unnecessary effort or delay certification and approval processes. It is therefore worth taking a closer look at the five most common misconceptions.
Misconception 1: TR-03161 only applies to the app
Many people initially think of the mobile application itself. In fact, however, the guideline considers the entire technical solution. Depending on the architecture, the evaluation may include not only the app but also backend systems, interfaces, web applications (possibly including web applications of the administrator interface!) or other components—for example, a cloud infrastructure used to synchronize health data, or an API gateway that connects third-party systems. What matters is not whether it is an app, but which systems process health data and how they interact with each other.
Misconception 2: We are already certified to ISO/IEC 27001
An information security management system in accordance with ISO/IEC 27001 is an important foundation. However, TR-03161 has a different focus. While ISO/IEC 27001 describes the organizational framework for information security, the Technical Guideline sets out specific requirements for the technical implementation of a health application. For backend systems, Part 3 of TR-03161 goes even further: Requirement O.Org_1 explicitly requires the operator of the backend systems to provide evidence of certification to ISO/IEC 27001, based on IT-Grundschutz (BSI 27001) or a comparable standard. An existing ISO certification is therefore by no means redundant here; rather, it is a mandatory prerequisite for operating the backend systems.
Where TR-03161 becomes noticeably more specific
Topics such as authentication, cryptography, or secure communication are broken down in TR-03161 to a level of detail that an ISMS does not cover in this form. For cryptographic methods, for example, the guideline refers to specific algorithm and key-length requirements, as described for instance in BSI TR-02102, instead of merely requiring a general cryptographic concept. An ISO certification therefore does not replace the requirements of TR-03161—even where it is explicitly required, such as for operating the backend systems, it only covers part of the technical specifications and must be supplemented by the specific requirements of TR-03161.
Misconception 3: It’s only about data protection
Data protection and information security are often treated as the same thing. In fact, they pursue different objectives. Data protection governs which personal data may be processed and under what conditions. TR-03161, by contrast, deals with the technical protection of this data. Among other things, it considers confidentiality, integrity, and availability, as well as the concrete implementation of appropriate security measures. An application can be perfectly compliant from a data protection perspective and still have technical security vulnerabilities—this is exactly where TR-03161 comes in. However, the boundary is not entirely clear-cut: TR-03161 also touches on data-protection-related issues with certain requirements. For example, requirement O.Purp stipulates that sensitive data may only be collected if this is necessary for the application’s primary and lawful purpose. In such places, data protection and information security overlap, but they remain fundamentally different topics in terms of their overall objectives.
Misconception 4: We’ll apply for the certificate at the end of the project
In many development projects, certification is only planned once the product is almost finished. This can lead to significant delays. The requirements of TR-03161 affect numerous technical decisions that are made during development—for example, the choice of authentication method, the interface architecture, or key management.
What happens when security is only considered at the end
If these points are only addressed shortly before certification, rework is often required in areas that can only be changed in the finished product with considerable effort—for example, if an authentication method has to be replaced retrospectively. That is why it pays to incorporate the requirements of TR-03161 into project planning early on—ideally as early as the architecture phase. In addition, an efficient evaluation requires appropriate documentation. Here, too, it pays to coordinate with the evaluation body early in the development process, rather than compiling evidence and documentation only shortly before the evaluation.
Misconception 5: The evaluation body will tell us how to implement the requirements
Here, too, there are often false expectations. In principle, an evaluation body can certainly provide consulting services. However, at the latest during the actual evaluation process, there must be a separation of personnel between consulting and evaluation: anyone who supports or advises a product may not later evaluate it themselves. The evaluation body’s task in the evaluation is to independently assess the implementation against the applicable requirements and to provide technical support throughout the certification process. This separation of personnel is intentional: it ensures that the evaluation is objective and traceable, and ultimately also protects the manufacturer, whose certificate gains credibility as a result.
Conclusion: Early understanding pays off
TR-03161 is far more than a formal prerequisite for digital health applications. Those who understand the requirements early and avoid typical misconceptions can make certification and approval processes significantly more efficient and avoid costly rework. Especially because the guideline and its interpretation in practice are continuously evolving, it is also worth regularly aligning your product architecture with the current state of requirements, rather than relying on a one-time assessment.
As a BSI-recognized evaluation body, SRC supports manufacturers throughout the entire TR-03161 certification process. The aim is to assess requirements transparently, carry out evaluations efficiently (e.g., through immediate feedback on identified security issues), and provide expert support to companies on their path to successful approval.
