{"id":10428,"date":"2020-08-19T12:39:55","date_gmt":"2020-08-19T10:39:55","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=10428"},"modified":"2023-08-06T21:43:58","modified_gmt":"2023-08-06T19:43:58","slug":"gdpr-and-information-security-for-startups","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2020\/08\/19\/gdpr-and-information-security-for-startups\/","title":{"rendered":"GDPR and Information Security: A practical guide for Startups and small businesses"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Let me start with a story. My first contact with GDPR (general data protection regulation) and the topic of information security was during my bachelor throughout an app project. We had set ourselves the goal of uploading the app to Google Play Store by the end of the semester and were thus inevitably confronted with the data protection and privacy topic, which was still relatively fresh at the time.
Since we had no previous experience and background knowledge in this area, we were rather intimidated by the available information and very vague wording in correlation with GDPR. The intrinsic desire to take care of personal and sensitive data was rather absent and overshadowed by the fear of doing something wrong and experiencing legal consequences. When we turned to professors and lawyers at the university, who were (in theory) responsible for the topic of GDPR and information security, the responses were comparable to the game \u201chot potato\u201d. Everyone we approached tossed the hot potato (aka GDPR) to the next person by saying something along the lines of \u201cAh yes, I think Mr. X would be more suitable for that\u201d. In the end, we kind of patched together a data privacy declaration and implemented suitable protective measures, which was okay for the time being, but not particularly good and worthwhile. Overall, it left a rather unsatisfactory feeling and aftertaste.<\/p>\n\n\n\n

The combination of founding my own Startup and attending the lecture \u201cSecure Systems\u201d during my masters made me rekindle with that topic again and I decided to take matters into my own hand and shine a new light on this rather unattractive and dry, but also very important and meaningful subject.<\/p>\n\n\n\n

Therefore \u2013 with this blog entry \u2013 I\u2019m hoping to provide you with a more practical and satisfactory approach to information security and GDPR. I will answer questions like \u201cWhy should I even strive for GDPR compliance or security in general?\u201d and \u201cWhat can I \u2013 as a programmer \u2013 do to achieve information security?\u201d. Furthermore I will explain terms like Privacy By Design, Privacy By Default and Security By Design. This guide is addressed to all those who want to gain a better understanding of this topic in general, as well as start-ups, smaller companies or freelancers who are looking for specific information to implement this topic in their own applications with a focus on inexpensive but effective measures. However, it should not be considered as a complete and sufficient solution for information security.<\/p>\n\n\n\n

\n

My forecast for the future is: In the future we will talk much more about information security instead<\/strong> of<\/strong> <\/span>talking about IT security<\/span><\/strong> and data protection \/ GDPR<\/strong> separately<\/strong><\/span>!<\/em><\/p>\nEric Weis (CISO and auditor of ISO\/IEC ISO27001)<\/em><\/cite><\/blockquote>\n\n\n\n

With this fitting quote in the back of our minds, let\u2019s dive right into it. \ud83e\udd3f<\/p>\n\n\n\n

\n\n\n\n

Why should you even strive for GDPR compliance?<\/h2>\n\n\n\n

Depending on the severity of the violation, fines of up to \u20ac10 million or 2% of the total annual turnover of the previous business year, or respective \u20ac20 million or 4% for the higher severity level, may be imposed if your organisation violates data privacy guidelines. The respective frame that is chosen is the one which is higher (GDPR Article 83, section 4 and 5).
For example, Google (Sweden) was fined \u20ac7 million in March 2020 for failing to remove personal information from various individuals who had requested exclusion from Google search results.
An Italian telephone and network operator (TIM SpA) was hit even harder, being fined \u20ac27 million in January. The reason for this was several legal violations in marketing and advertising campaigns. Unsolicited calls were made, people were entered into competitions without consent and in one case, a person was called 155 times after<\/em> requesting exclusion from calls.
Even in law-abiding Germany there was a high penalty in December 2019. 1&1 Telekom was fined \u20ac9 million because anyone could get complete access to a person’s data as long as they simply knew that person’s date of birth and name.<\/p>\n\n\n\n

The vagueness and individuality of GDPR<\/h2>\n\n\n\n

Upon reading statements and guidelines of the GDPR, such as the following excerpt of Article 32, which targets the Security of processing, one often has more questions and uncertainties than before.<\/p>\n\n\n\n

Art. 32 (1)<\/strong>: \u201eTaking into account the state of the art<\/span><\/strong>, the costs of implementation<\/span><\/strong> and the nature, scope, context and purposes of processing<\/span><\/strong> as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons<\/span><\/strong>, the controller and the processor shall implement appropriate technical and organizational measures<\/span><\/strong> to ensure a level of security appropriate to the risk<\/span><\/strong>\u2026\u201d.<\/p>\n\n\n\n

All wordings, components and safety measures that vary according to context and organization, are color highlighted. Only once you start breaking down the separate parts and enrich them with background knowledge from information security, a greater picture starts to form. With that being said, here\u2019s my breakdown of the separate parts:<\/p>\n\n\n\n

\u201c\u2026the state of the art\u2026\u201d<\/em> <\/mark><\/p>\n\n\n\n

Mainly refers to technology. It makes sense: the safety and security measures you implement today might be outdated in 3-5 years. Technology and software have a fast pace, which should be reflected and reviewed in your infrastructure and design choices.<\/p>\n\n\n\n

\n\n\n\n

\u201c\u2026nature, scope, context and purposes of processing\u2026\u201d<\/em><\/p>\n\n\n\n

Depending in which field your organization is operating and what kind of sensitive information you\u2019re processing the needed safety measures vary a lot. The how and where of data processing are also really important. Do you dispose of all data completely independently or are third parties involved? Do you process highly sensitive information like racial and ethnic background, political opinions or religious beliefs, health data or information regards the sexual life or orientation of your users.<\/p>\n\n\n\n

\n\n\n\n

\u201c\u2026risk of varying likelihood and severity for the rights and freedoms of natural persons\u2026\u201d<\/em>
\u201c\u2026appropriate technical and organizational measures\u2026\u201d
\u201c\u2026level of security appropriate to the risk\u2026\u201d.<\/em><\/p>\n\n\n\n

This is basically risk management. If you\u2019re striving for ISO 27001 compliance this is handled by your Risk Treatment Plan (RTP) and your Statement of Applicability (SoA). There are different approaches for application thread modeling. One popular and widespread one is using STRIDE and DREAD.
It\u2019s about analyzing which vulnerabilities or weaknesses in your infrastructure \/ architecture lead to risks of violating the core pillars of information security. Confidentiality, Integrity and Availability.<\/p>\n\n\n\n

\n\n\n\n

Depending on your background knowledge and the field you\u2019re specialized in, even in those more detailed explanations there might be a lot of unknown terms for you. I\u2019ll try to provide you with some basic knowledge in the following paragraphs.<\/p>\n\n\n\n

Before taking a closer look at core pillars of GDPR a quick side note about the LFDI<\/strong><\/a>: The LFDI is a German authority and roughly translates to \u201cstate commissioner for data protection and freedom of information\u201d. It supervises and advises the public authorities of the country on data protection and information security issues. One of the tasks of the LFDI is to impose fines on companies that violate data protection. In June 2020, for example, a fine of \u20ac1.2 million was imposed on the AOK, since they handled personal data incorrectly in regard to competitions during the timeframe from 2015 to 2019. Following an administrative fine, the LFDI also works with the organisation to improve the technical and organisational measures.
However, if you\u2019re looking for advice and specific recommendations, one must not have to wait until a fine is imposed on you. Instead, contact with the LFDI can also be proactively sought in order to receive advice and gain valuable insights. As part of my Startup, I did just that and will therefore incorporate advice and insights that have arisen throughout this cooperation. So, if I\u2019ll say something along the lines of \u201cthe LFDI recommended using encryption at rest\u201d you\u2019ll know what and who I\u2019m talking about.<\/p>\n\n\n\n

The core pillars of GDPR<\/h2>\n\n\n\n

Hint<\/em>: This is not an official classification; this is simply how I personally structured GDPR into different sections. It might help you too for forming a better understanding.<\/p>\n\n\n\n

\ud83d\udd10 Security <\/h3>\n\n\n\n

Prevent physical access to (personal) data. Ensure through appropriate infrastructure and technology that only authenticated users have access to data.<\/p>\n\n\n\n

Safety measures might include:<\/p>\n\n\n\n