Big school of GDPR lesson 6: Harmonization of IT systems and IT systems management

At first glance, GDPR does not seem to have a major impact on IT systems. In fact, there are only a few functional requirements directly related to IT systems.

Functional requirements on IT systems

The right to be forgotten and the right to portability are certainly the most controversial among them. These are completely new functional requirements that existing IT systems are simply unable to meet, and many also cannot easily realize the right to correct personal data, the right to access data, or the right to restrict processing. Since these are the unavoidable functional requirements that IT systems must now fulfill, we will pay close attention to them.

Right to correction

This is one of the simplest functional requirements directly related to IT systems. You must provide the owner of personal information with the personal information you have about him/her, and provide with the possibility to correct it. Many organizations do this today. If you notice an error in your name or address on the phone bill, you can contact the Customer Center that will allow you to correct it.

The problem arises in heterogeneous complex IT systems of large companies where your personal information is located at different locations and is collected for various reasons. For example, a telecom may have you in the billing system under the name Stjepan as it is written on your ID, while in the marketing system you may be under the name Štef, as your wife sent in an SMS for a prize game. Zagrebački Holding may have one piece of data related to gas delivery and completely different for garbage disposal. Various data processing can also have a negative impact on accuracy, so the mess around OIB, JMBG, and addresses can result in a complete change of your digital identity in someone's IT system.

In practice, there are rare (if any) organizations that really know where all personal information is located. Have you ever sent a photo of your ID card to someone via email? If you ask the organization which information they have of you, and where that information is, do you think they will mention the photo of your ID card in someone's inbox on the mail sever and all the backups of that server, and someone's laptop on which Is it temporarily extracted before CRM and CRM system backups are entered? For an organization to really effectively update your personal information, they first need to know where the information is and how to identify it. Still, the things are not that bad. Most organizations, at least as far as production data are concerned, take care of their accuracy.

Right to be forgotten

This is without a doubt the most technically challenging right. The IT system must allow easy deletion of personal information at the request of their owner. For example, if you are no longer a bank's client, you can ask them to delete your personal information from all of their systems. In addition to the problem of identifying data in all IT systems, backups and archives, there is a whole new set of issues here. If you have given this information to someone for processing, you must ensure that they delete it. Deleting somebody's personal data from the database will most likely compromise the integrity of the database. If you delete information about the bank's client but keep the traffic data, this data will not be possible to link to something, and this is the case in almost every instance. In the design of the existing IT systems, the right to be forgotten has not been considered, so most of them indicate the information as inactive, but still keep it. With GDPR, that is not enough.

In addition, some data must be retained based on other applicable regulations. No one can come to the bank and ask for the deletion of personal information because they do not want to pay the loan installments, nor will the company you worked for delete the salary payment information. The right to be forgotten is primarily related to the information you have voluntarily provided with consent to use (for example, a consumer loyalty program), and to a limited extent on the information you provided to someone for the service you have contracted for (e.g., mobile subscription).

While in new IT systems this functional requirement is solved by the architecture that supports it, the problem with the existing systems is considerably higher.

The topic of right to be forgotten we have discussed in detail with IT management of 10-odd global and local leading organizations in the telecommunications, pharma, finance, state administration, energy and many vendors. Until now, we have not found a solution that completely addresses this problem, but we have come across some solutions that have proved to be quite interesting. They are all based on the idea of replacing personal data that needs to be deleted with some other data. Technically, it's about encryption and pseudonymizing. By applying a specific encryption key for each personal data, it is possible to fulfill the right to be forgotten without actually deleting the data. Instead, the key is deleted.

The problem with the application of encryption to existing IT systems is in the different length and form between the original and the ciphertext, i.e. its encrypted value, because of which it simply cannot be entered into existing databases, nor can existing applications handle that data. A cunning solution to this problem was offered in the form of FPA (format preserving encryption) technology. The decision to apply such technologies to existing databases will depend on the DPIA (Data Protection Impact Analysis) results, which will in more detail be covered in a separate lesson on this subject. The fact that, besides the creation of preconditions for the exercise of the right to be forgotten, they greatly increase the security of production data speaks in their favor.

Right to portability

The individual's right to portability requires that the owner of personal data is allowed to transfer them in electronic form. For example, if you want to change your current electricity supplier, you can ask your existing supplier to export your consumption for previous periods so that your new supplier could calculate savings. This functionality was largely not implemented in existing IT systems because there was no need for it, and its introduction from the technology side is relatively easy. On the organizational side, that's not so. The first question that is being asked is what exactly is the customer's personal information. Which data is owned by the buyer and which by the company? Should consumption information include a tariff model, should tariffs be split, should loads over time be displayed, does it include geolocation of the metering point? Each organization has its own doubts that must first be resolved by aligning business attitudes with the requirements of applicable legal regulation. Only then can IT start solving the task and enable the data export system as requested. The regulation states that data must be exported in a generally accepted electronic format. Do not think much. Make it CSV. Of course, IT will promptly ask the question of importing such files brought by customers of other companies because, you can already guess, not only will the format of their files be different from the format of your files, but will also contain other data. The customers will then wonder why company A gives some information, and company B does not. Then they will file a complaint about the protection of rights to the regulator, and company A will be punished. But the same question will be asked for company B and C, and B will be punished. If such a practice causes damage to the buyer, he is entitled to compensation for that damage, regardless of whether the regulator has punished somebody.

This problem is solved through the adoption of codes at industry, profession, etc. level. These codes would define specificities related to the management of personal data at the industry level and enable the standardization of data transfer formats related to right to portability. The codes are approved by the regulator, and conduct in accordance with their provisions protects the organization from violating the right to protection of personal data.

Managing Consents

Consents for the collection and processing of personal data have so far mostly been collected just for the sake of formality. Now, this is significantly changing. Organizations are obliged to maintain a registry of consents, and IT systems must use the data in a way that is based on: the legal basis, the need because of provision of a contracted service or consents. The consent management solution will become an indispensable part of any serious IT system that contains personal information. Quality integration of this solution will automate the selection of personal data for processing in accordance with the given consents. Detailed information on how to design a good consent, and how to technically provide for its application can be requested here.

Safety requirements

The EU seldom gives a regulation whose core is unquestionably clear from the very core of its name, and the core of the name called 'GDPR', are the letters in the middle 'DP' - Data Protection. Data protection is a priority task of this regulation. Regardless of whether you collect personal information under statutory regulations, to provide a contracted service or the owner voluntarily surrendered them to you, you must protect their information. You had to do it according to the old regulation as well, but no one checked whether you did that or how, nor had the authority to do so. In my 20-year long career I have not met any company that has paid attention to personal data protection as is expected by GDPR. The powers and ability of the regulator are changing significantly in this regard. The amount of the penalty now directly depends on the adequacy of the security controls the organization has implemented to protect personal information.

Minimization and Data Protection

Know where personal information is, why they are there and get rid of all copies of personal information that you really do not need! Protect the rest!

This is the most important rule and the strategy that needs to be adhered to when aligning IT systems with GDPR requirements. Identify which personal information you might have at all. What is being collected, why and on what basis? How is data entering the organization, where are they stored and processed, and who and why accesses them? If you have a larger amount of personal data, consider purchasing a technical solution for the identification of personal data or DLP solutions with such functionality. No matter where you think the personal information is scattered in your IT system - you do not know. Anyone who implemented a personal data identification tool on the IT system has been uncomfortably surprised by the amount of data which is out of control.

Once you've identified the personal information, got rid of the surplus, found out what normal, and what abnormal personal data flows are, you're ready for the next step. If you have identified the data with the DLP solution, this step will definitely be setting up personal data protection solutions, and you will achieve a lot with it. If the data somehow leaks from the organization, or fall into the hands of unauthorized persons within it, there is much less worry if they are encrypted. In fact, the encryption of the production data will completely free you of any penalty in the event of theft. A well-designed and implemented combination of FPEs (described in the "Right to be forgotten" chapter) and DLP solutions will result in a very high level of security of personal (and all other confidential) data.

The prerequisite for effective personal data protection is the high-quality IT and data access rights management. Poor practices of exporting personal data to various Excel tables for 'handy analysis', developers who have access to production systems, or the use of duplicate production data for testing, simply must disappear. Abolishing these practices will be long-lasting and painful for people who are accustomed to doing so. On the other hand, in companies that foster safe development practices such bad practices are simply unimaginable. Applying personal data anonymizing and masking tools significantly reduces the risks of bad practices in development and testing, and the risks of insecure applications.

GRC

We are all aware of the countless regulatory requirements we need to align business and IT systems with. Banks are aware of the strong roles of the regulator in the control of compliance, and insurance companies are as well more and more aware of it. GDRP comes with its regulator that, like the CNB and HANFA, has the authority, mechanisms and resources to enforce compliance control. More and more organizations will reach for centralized risk management and compliance. Tools that enable this are called GRC (Governance Risk Compliance) tools and are only needed for the largest organizations with very complex regulatory requirements.

We will talk more about them in the next lesson that focuses on GDPR audit.