The GDPR Fever: From Legal to Technical – Landing the GDPR at the IT Field
This is the third post in the GDPR Fever series aimed at explaining whether and how DLP technologies could be used for achieving GDPR compliance.
Being declared technology-neutral, the GDPR does not define which specific technologies should be used to implement its data protection principles. Yet by mapping the GDPR specifics to the IT context, where ultimately its legal norms have to be applied, it is possible to develop the key technical requirements to security components of data processing systems that must be met to protect the information this regulation is about from leakage.
The very nature of the GDPR is the protection of a specific type of data – personal data, the data that contains personally identifiable information (PII). The GDPR provisions are not applicable to the data that carry any other information but PII.
However, in real IT systems that process personal data, a lot of other types of data are used. These include information that supports business operations, employee’s communications, financial reports, anonymized statistics, etc. These types of data are not personal, because they do not contain PII, and consequently their processing is not required to be in compliance with the GDPR. In other words, the processing of non-personal data in a GDPR-compliant system should neither be (necessarily) protected nor restricted, while the system must protect personal data.
As a result, in many cases an operation with data (for instance, sending an email) shall be allowed because it carries non-personal data outbound and cannot violate the GDPR, but the very same operation with personal data shall be prohibited because it leads to a data leak or violates privacy in some other way – for instance, perhaps it enables data controllers to identify clients for a purpose not approved by them.
The critical point to note is that the only technical-level difference between these two otherwise identical cases of sending emails is the content of processed data – is it PII or not (?) – and, consequently, the only way to distinguish one case from the other is to analyze all of the data content prior to egress.
This is why security components of GDPR compliant processing systems must be able, firstly, to analyze the content of processed data against the applicable PII protection policy and, secondly, to enforce actions necessary to prevent data leakage – for instance, by blocking an operation with personal data that violates the protection policy.
It is imperative that the analysis and protective actions are accomplished in real time, which implies their automatic execution. The reason is to enable security components to timely and effectively deny policy-violating operations, while transparently allowing compliant data operations performed in the scope of normal business processes.
The last, but equally important technical requirement to processing systems results from the I&C principle, which demands that personal data be protected for such processing operations as “storage, use, disclosure by transmission, dissemination” – hence, the system must protect personal data in all their states including data in use, in motion, and at rest.
There Is No Privacy Without Security
Deciphering the "Integrity & Confidentiality" Principle
From Legal to Technical – Landing the GDPR at the IT Field
DLP Is Necessary for GDPR Compliance
Engineering Information Privacy
DLP by Design