As the architect who “drew the short straw” and was assigned on the GDPR project, I have here a few thoughts on GDPR, from a large enterprise practice, involving a lot of private individuals data which is processed on a daily basis.
1. What is GDPR?
GDPR stands for General Data Protection Regulation and it is a stringent EU regulation about privacy and private data protection which will go into effect in 25th May 2018.
By GDPR, EU intend to strengthen and unify data protection for all individuals within the European Union and also to address the export of personal data outside the EU. The primary aim of GDPR is to put control back into the hands on citizens and residents over their personal data and to simplify the regulatory environment for international business, by having the same rules all across EU.
When GDPR takes effect, it will replace the current data protection directive (officially Directive 95/46/EC)[2] of 1995.
2. Why is GDPR so important?
First of all, GDPR is important by it’s sanctions.
The lowest fine (in an oversimplified view) for non-compliance is 10.000.000 EUR or up to 2% of the annual worldwide turnover of the preceding financial year. Detailed sanctions model, here .
Second, from the 25th of May, 2018, GDPR will be the only data protection regulation in effect across EU, all other directives will cease effects then. So, any business, be it an online shop or a large, multinational corporation, will have to abide by GDPR and will have to abide by the local interpretation of GDPR. The data protection agencies form each country (in Romania, there is ANSPCD, http://www.dataprotection.ro/ ) will set, or already have done it, their own interpretation and methodology of applying GDPR regulation.
Even if your company is not located in EU, GDPR may apply to you. As Article 3 states, it “applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union”. Under this statement, the implications are that any US or other foreign soil companies that processes data of EU residents are liable under GDPR (think of Facebook, Google 🙂 ).
3. GDPR Impact
Major, from both business and IT perspectives.
From a business point of view, GDPR will be the rule to live by in the years to come, for all privacy and data protection topics, for private individuals. All the new things that are coming with GDPR (the new meaning of consent, by example), means that all business processes and procedures that are working with private data will have to be modified and / or adapted to some degree. And we are talking here of both front office and back office processes. Whenever the national authority will come for audit, you have to be able to prove that private individual data is protected and processed according to GDPR. And we are not talking about data breaches.
From an IT perspective, all systems that are working with or storing private data will be subject to changes. Think only at data encryption (at rest and in transit), data loss prevention, excessive data processing, and so on. I will detail them later on.
With GDPR, any data breach will have to be reported in a maximum of 72 hours, from the moment you are aware of it (Article 33 and 34) and this means you have to have good capabilities in place for data loss prevention, tracing, auditing and data lineage to be able to measure the impact of a data breach, to know exactly what data leaked, and to whom belongs that data (there are cases in which you also have to inform the data subjects about the breach, see Article 34).
In terms of impact, all areas of an enterprise are affected by GDPR. Starting with parking place video surveillance system, visitors registration system, going through CRM and ending up on the company website, everything is affected, both business processes and IT systems.
4. GDPR is about compliance
As Article 5 states: “The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’).” (full article here), besides being compliant when an eventual aduit comes, you also have to demonstrate ongoing compliance with GDPR for the entire organisation. As an IT architect, now is the best time to show usefulness and power of the enterprise architecture discipline, for all the diagrams and for the architecture repository you spent a lot of time to create it and provide cross-cutting analyses on the use, circulation and protection of private data across the enterprise, people, processes and IT systems (do you really know what it is in your data warehouse in terms of private data? Or in the operational and analytical reports ? Do you really need all those private data fields in that analytical report the business wants it everyday before 11 AM? Wouldn’t those fields come under “excessive data processing” GDPR article? ).
5. Consent
You are expected to have a consent from the private individual whose data you are collecting and processing.
What is different in GDPR is that now you have to have a separate consent for every data processing operation you are doing, except the ones that are mandatory for fulfilling contractual obligations.
You can’t use a 20 pages terms and conditions document, full of jargon. The request for consent must be given in a clear and accessible terminology, with the purpose of data processing clearly stated.
To be more specific, if now you have a general consent for private data gathering and processing and with this data you are doing marketing, profiling, fraud prevention, up-selling and so on, from GDPR era on, you will have to have a specific consent for each of the above (or try to justify them as mandatory for contractual obligations). And don’t forget, under GDPR, the private individual can anytime withdraw his consent.
And more, you will have to have a data processing catalog, where you have to record what data you are gathering and for which purpose. This have to include things like: at which location personal data is stored, which are the master data systems for data types, who has access to these applications, third parties which data is exchanged with. Trying to manage all of these in Excel spreadsheets in anything larger than a small shop quickly becomes a true nightmare, so you need very good enterprise architecture discipline and organisation (and probably such a data processing catalog will be better paired with an Enterprise Information Model).
6. Security by design
Article 32 states: “Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk” (full article here), which also includes “regularly testing, assessing and evaluating the effectiveness” of the measures taken. That means usual approach to security (throwing something in at the end of the project, or involving the security guys just before a go-live) will not make it. Now you have to have an integrated approach to data security, even from the solution design phase and the approach have to be somehow unitary and integrated, enterprise wide.
Measures have to be taken to ensure compliance with GDPR Article 32, like:
- Data anonymization and pseudo anonymization
- Data encryption (at rest and in transit)
- Processes and procedures for ensuring ongoing confidentiality, data integrity, resilience and so on.
- Procedures for restoring personal data in the event of a technical incident
- Continuously testing and assessing all of the above
You will have to have in place functional and tested procedures for backup, disaster recovery and data restoring (and the corresponding systems also).
7. Data protection impact assessments – DPIAs
For the current landscape of IT systems and for any new implementation from GDPR onward, you have to carry out a data protection impact assessment, which have to include a description of data processing, a risk assessment, measures to mitigate the risks found and how the systems or project are / will be compliant with GDPR.
End of part I
