Risk Analysis
The main scope affected by the regulations in this regard is the presentation of a new approach based on the risk management process. One of the primary objectives of such action is to identify and minimize risks to assets that have not been secured or for which the applied safeguards are insufficient. In other words, organizations within such a process should identify assets whose vulnerabilities with the highest level of risk may lead to the materialization of a threat and ultimately an incident involving personal data, and implement measures to mitigate such risks.
Receive a package of free GDPR guides and micro-trainings
What does GDPR say about safeguards?
Should IT departments then focus solely on risk analysis, which is so widely discussed? Unfortunately, no… GDPR is a regulation that is full of ambiguous and imprecise statements. Another such "place" that directly affects IT departments is Article 32, according to which organizations processing personal data are required to implement appropriate technical and organizational measures, including, among others, where applicable:
- pseudonymization and encryption,
- ensure the ability to continuously maintain the confidentiality, integrity, availability, and resilience of processing systems and services,
- ensure the ability to quickly restore the availability of personal data and access to it in the event of a physical or technical incident,
- ensure regular testing, measuring, and evaluating the effectiveness of technical and organizational measures aimed at ensuring the security of processing.
As can be seen above, even a thorough familiarization with the regulations, including all guidelines published by the President of the Polish Data Protection Authority, or the Guidelines of the Article 29 Working Party, will not provide us with a clear answer on how organizations should specifically fulfill the imposed requirements. While in the last point concerning the testing of the effectiveness of the applied technical and organizational safeguards, it should be assumed that we can achieve this, among other things, through a systematically conducted risk analysis, which should also give us insight into the state and effectiveness of the applied safeguards, in the remaining points this is not so precise.
Where to apply pseudonymization and encryption?
The use of pseudonymization in practice is rarely utilized and is not widespread, whereas encryption is a concept already known from the previous legal framework regulating the area of personal data protection prior to May 25, 2018. However, a significant difference in this regard is that at that time, it was quite precisely related to its application concerning the hard drives of portable computers. In the case of the GDPR, the matter is no longer so simple. Indeed, encryption is a safeguard that, according to the regulations, organizations should implement wherever appropriate…
Should we, therefore, focus only on such trivial places as the hard drives of portable computers, mobile data carriers, or websites where personal data is processed through a contact form or the possibility of subscribing to a newsletter? Unfortunately, no… There may be significantly more such places in the organization, including backups, the storage location of which does not provide a clear guarantee of its physical or logical security, or smartphones, which, like portable computers, process a vast amount of information, including personal data.
Confidentiality, integrity, availability, and resilience. What to do about it?
An even less precise statement is the next point mentioned above regarding ensuring the ability to continuously maintain the confidentiality, integrity, availability, and resilience of processing systems and services. The obligation indicated by the GDPR, presented in a single sentence, is so broad that we can essentially fit any possible security measure that comes to mind. Unfortunately, the relevant legal act is completely silent on such security measures. So what are we left with?
The most commonly used practice in this regard is to utilize guidelines that have been in existence in the international market for some time. This refers, of course, to ISO standards, particularly those from the "family" 27000 concerning information security management, which in turn translates into the protection of personal data. The best situation regarding the implementation of this point is for companies in the financial sector, which have long been required to comply with the recommendations of the Polish Financial Supervision Authority. This authority has always enforced proper protection of personal data from a technical standpoint through Recommendation D for the banking sector, addressing threats both from outside and within the organization.
The necessity of quickly restoring access to data
Another point mentioned in Article 32 is the obligation to ensure the ability to quickly restore access to personal data and to access it in the event of a physical or technical incident. Similar to the previous case, there are no detailed guidelines in this regard. Nevertheless, it certainly refers to the systematic execution of backups of all systems and collections of personal data. One should also not forget about the appropriate location for their storage, which, according to good practice, should be in at least a different fire zone than the data processed in the production environment.
According to the principle of accountability mentioned in Article 5(2) of the GDPR, data controllers should also remember to prepare appropriate emergency and recovery procedures. These should describe the exact course of action in the event of crisis situations, as well as outline other elements such as the frequency of backups or specify situations in which a backup is necessary to perform outside the planned schedule. To fulfill the discussed requirement, ISO 22301, which pertains to maintaining organizational continuity, may prove helpful.
Documentation on IT Security?
Migrations, clouds, systems.
GDPR in IT.
- asset management (processed data sets),
- access controls (user registration and deregistration, password management, use of privileged tools),
- cryptographic protection measures (security policy application, key management),
- physical and environmental security and operational security (change management, capacity management, business continuity assurance, event logging and monitoring),
- communication security (network protection, separation),
- acquisition, development, and maintenance of systems,
- relationships with suppliers (contracts, including data processing agreements),
- management of information security incidents,
- business continuity management,
- compliance with legal and contractual requirements.
New Features of Systems
Continuing, unfortunately, we cannot conclude with "bureaucracy." Another extremely important and exceedingly difficult element is adapting the infrastructure to enable the exercise of the rights of individuals whose data is being processed. This includes, among other things, the right to data portability, the right to restrict processing, and the increasingly popular right to be forgotten. Various approaches have been attempted to address this issue, and organizations consistently encounter the greatest difficulty regarding the ability to locate the data of a specific individual within corporate resources. This refers to non-aggregated, unstructured data, information that is stored outside of databases, for example, on local hard drives of company computers or external mobile storage devices. Of course, there are many more such locations.
Another challenge is implementing the right to be forgotten concerning backup copies that have not been exempted by regulations in this regard. Various practices exist, starting from preparing a test environment where the backup is restored, the record is deleted, and then the copy is created again, to shortening its retention period to 3 months, as stipulated in Article 12 of the GDPR, which allows us to extend the fulfillment of the aforementioned obligation. When addressing the topic of adapting the IT environment, one should certainly not forget about the functionality of recording objections in cases where systems are used for marketing purposes. Additionally, such systems, in accordance with the accountability principle discussed above, should guarantee the ability to verify the exact date and time consent was given, as well as its withdrawal.
Of course, it is impossible to list all activities and necessary tasks to be performed within the aforementioned points, as the manner of their implementation will always differ depending on the solutions currently applied and functioning. However, it should be noted that the GDPR is a regulation that certainly requires changes in every IT environment, and organizations that have not made these changes cannot rest easy now. Therefore, looking through the lens of this document, have you considered all the above points in your implementation? Does the GDPR actually function and affect all required areas in your organization?


