Blog
Information security and data protection (ISDS) concept made easy
The increase in cyber attacks, data breaches and the constantly growing legal requirements make an ISDS concept essential.
In the digital age, where data and information is the new gold, information security and privacy (ISDS) has become a critical concern for businesses worldwide.
The 18th century proverb "a good preparation is half the battle" has proven itself over time for a wide variety of challenges. This also applies to the creation of an ISDS concept. Thanks to our many years of experience, we can now pass on practical tips and tricks for creating an ISDS concept. Whether you are a small startup or an established company, the importance of a solid ISDS concept cannot be overstated.
The pillars of an ISDS concept
A good ISDS concept is based on a solid foundation consisting of the preparation and protection needs analysis as well as the four pillars illustrated below.
Preparation
Preparation is the cornerstone of any successful ISDS concept. Before you dive deep into the matter, it is crucial to identify all the roles involved.
The roles required for the creation of an ISDS concept are as follows:
- Project manager
- IT architect
- Information Security Officer
- Data protection consultant
- Data owner and/or risk owner
- Risk manager
- Legal department
The project manager is responsible for developing the ISDS concept.
The IT architect knows the connections, the scope and the schema of the applications and is therefore predestined to provide the required information on the data flows.
The Information Security Officer (ISO) is responsible for checking and evaluating the plausibility, effectiveness and conformity with the security architecture of the risk analysis and the proposed measures for dealing with the risks.
The Data Protection Advisor (DPO) supports the controller or processor in all matters relating to the protection of personal data.
The data owner is responsible for the data and information within their assigned area (specific application, service, etc.). He creates the protection requirements analysis as part of the ISDS concept.
The risk owner decides on the residual risks, taking into account the company's risk appetite. He therefore accepts the proposed measures to reduce the risks and bears the residual risks of the undertaking upon acceptance.
The risk manager is informed about the risks relevant to the company following the ISDS concept. He ensures that all formalities (approval process, documentation, etc.) have been complied with.
The legal department has the expertise to prepare a correct legal basis analysis. This analysis is very individual. Depending on whether a company is public or private and whether it operates in specific sectors, very different legal or regulatory requirements may apply that affect the project and its risks and measures.
Protection needs analysis
The protection requirements analysis is the starting point in the process of developing an ISDS concept. It aims to identify the critical values and assess their protection requirements based on a selected classification, e.g. Federal Office for Information Security (BSI IT-Grundschutz), International Organization for Standardization (ISO 27001), etc. Basically, the aim is to assess the protection goals of confidentiality, availability, integrity and traceability and assign them a protection level: e.g. normal, high or very high protection requirements. If it turns out after the protection needs analysis that there is no increased need for protection, you are already at the end here and do not need to create an ISDS concept, provided that the company's basic IT protection measures are complied with.
The protection requirements analysis can be created efficiently if a template is used that automatically identifies the appropriate protection requirements for each protection objective using company-specific questions and drop-down answers.
Analysis of the legal basis
The legal basis analysis deals with external requirements (laws and regulations) and internal requirements (governance).
The central questions that need to be answered by the legal basis analysis relate to the risks resulting from violations of compliance or governance requirements:
- What: Is there anything that prevents me from implementing my planned project?
- How: Is there anything that prevents me from implementing my planned project?
The key point is that the company knows and is aware of the requirements that must be met. In most cases, these requirements relate specifically to the Data Protection Act in the area of implementation.
If the current business case does not differ significantly from previous projects or the core business area, the legal basis analysis can be adopted depending on the risk appetite. If necessary, a legal opinion from industry associations can also be used; such principles have broad support.
Data flow and architecture
A data flow diagram depicts how data flows through a system, including the sources, destinations, storage and processes that handle the data. This visualization helps to develop a clear understanding of how information moves through the organization, which is critical for identifying potential security risks and dependencies.
The focus of the data flow analysis is on the interfaces between systems.
A risk analysis is used to check whether the use of an interface is associated with an additional risk, e.g. a transition from DMZ to intranet, data center to cloud, or even data flows between countries.
To ensure that the risk survey is complete, particular attention should be paid to the interfaces. The completeness of the description can be supported by means of checklists.
Risk analysis
The prerequisite for a risk analysis is that the risk management framework and risk acceptance are clearly defined. The protection levels of the protection objectives derived from the protection requirements analysis are checked by means of a risk analysis if they exceed the normal protection requirements.
As a first step, it makes sense to compile a set of mandatory measures into a basic protection catalog. This enables the checklist approach to evaluate the implementation of the measures. Basic protection measures that have not been implemented represent a potential risk that must be addressed by means of the risk analysis. Protection goals whose level of protection exceeds the normal level of protection must be analyzed in more detail in the next step.
The following diagram describes the risk analysis process using a fictitious protection requirements analysis:
This procedure can be automated using appropriate tools, thus creating sufficient scope for the actual risk analysis.
Experience has shown that it is advisable to organize the risk analysis in the form of a workshop consisting of the project manager, the architect and the information security officer in order to examine the project from the perspective of a bad actor. A bad actor would ask themselves, for example: In what way can I misuse a system? Where can data be stolen? How large is the attack surface of an insider threat, how are attacks detected and prevented? These questions are compiled into a catalog of threats.
To ensure that the project plan is examined from A to Z, the risks from the identified threats are discussed and evaluated in relation to the systems and interfaces of the data flow diagram. The process is repeated, taking into account the risk mitigation measures, in order to identify the residual risk.
Measures
Monitoring and controlling measures ensures that they are implemented in operations. Automation is also an option here, so that those responsible for implementation are reminded and reporting is made possible.
Review
The procedure described here is suitable for all companies. In order to best adapt the procedure to the individual company, we recommend the introduction of a review process, similar to a continuous improvement process. This process should ensure that the knowledge gained during the creation of the ISDS concepts is integrated into the process. One focus is on increasing the degree of automation of the first step of the risk analysis, whereby the defined measures from the previous review period are examined as a supplement to the mandatory measures. In addition, the focus is on the further development of the threat catalog as a basis for future risk analyses.
