GDPR Requirements

[table width =”100%” style =”table-striped” responsive =”true”]
[table_head]
[th_column]Requirement[/th_column]
[th_column]Description[/th_column]
[th_column]Article[/th_column]
[/table_head]
[table_body]
[table_row]
[row_column]Right to be forgotten[/row_column]
[row_column]Private individuals have the right to ask you to erase all of their data from your systems. Your are obliged to do so, unless this contradicts another local regulation that supersedes GDPR [/row_column]
[row_column]Article 17[/row_column]
[/table_row]
[table_row]
[row_column]Rights of access[/row_column]
[row_column]The given subject has the rights to ask you what personal data you are holding and how they are processes and shared with others. And also,  how the data was acquired. This is applicable for both customers and employees of an enterprise.[/row_column]
[row_column]Article 15[/row_column]
[/table_row]
[table_row]
[row_column]Data portability[/row_column]
[row_column]Subjects has the rights of transferring the data from one provider to another, without being prevented to do so by a data controller. The data must be provided by the controller in a structured and commonly used open standard (XML, PDF, JSON)[/row_column]
[row_column]Article 20[/row_column]
[/table_row]
[table_row]
[row_column]Data protection by design and by default[/row_column]
[row_column]Ensure processes and procedures are in place to embed privacy into any new project. You have to abide by data minimization principle, data pseudo anonymisation. By default, data shall be made available only to whose are entitled (by process or procedure) to work with it and an audit trail must be kept.[/row_column]
[row_column]Article 25, 35[/row_column]
[/table_row]
[table_row]
[row_column]Geographic extent of your data processing[/row_column]
[row_column]Check if you use third party data processors and if you (or the entities which are processing data on your behalf)  transfer data outside EU[/row_column]
[row_column]Articles 44-50[/row_column]
[/table_row]
[table_row]
[row_column]Record of processing[/row_column]
[row_column]You have to identify and  keep a detailed record of data processing activities, including purpose of processing, data categories and description, security measures and a comprehensive data flow map (data lineage)[/row_column]
[row_column]Article 30[/row_column]
[/table_row]
[table_row]
[row_column]Data protection officer[/row_column]
[row_column]You have to appoint a Data Protection Officer. The person who covers this role can be an employee or an external consultant. The recommendations are that a DPO should be from Legal, Compliance or IT areas, with a focus on the legal side. This role should work closely with business, CIO and Chief Data Officer [/row_column]
[row_column]Articles 37-39[/row_column]
[/table_row]
[table_row]
[row_column]Data breaches[/row_column]
[row_column]Under GDPR, you, as data controller, have the legal obligation to notify the Local Supervisory Authority without undue delay. A data breach must be reported within 72 hours after being aware of it. If, from the data that has been breached, private individual can be identified, then you also have the obligation of notifying them.[/row_column]
[row_column]Articles 33 – 34[/row_column]
[/table_row]
[table_row]
[row_column]Data retention[/row_column]
[row_column]Data can only be retained for as long as necessary for the purpose for which it was obtained, let’s say for the entire duration of the contractual obligations. However, the retention period can be prolonged if there are any other regulations that supersedes GDPR (example; 7 years retention period for data after you have close the business relationship with a bank).

For each category of data, you have to have a well defined retention period, before deleting or anonymizing  the data. Think of call recordings in a call center. For those recordings you have to specify an amount of time to keep them.

You can’t keep everything for an undefined period of time or forever.[/row_column]
[row_column]Article 5[/row_column]
[/table_row]
[table_row]
[row_column]Privacy Impact Assessment – PIA[/row_column]
[row_column]Every new project involving personal data must undergo a PIA. The results will have to show what impact the new project, technology, application, process will have on individuals and to ensure GDPR compliance.[/row_column]
[row_column]Article 35[/row_column]
[/table_row]
[table_row]
[row_column]Profiling[/row_column]
[row_column]You have to have the individual consent for profiling or put it under lawful data processing.[/row_column]
[row_column]Article 22[/row_column]
[/table_row]
[table_row]
[row_column]Lawful data processing[/row_column]
[row_column]

Under GDPR, there are several lawful criterias under which personal data can be processed:

• the data subject has given consent to the processing of his or her personal data for one or more specific purposes
• processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract
• processing is necessary for compliance with a legal obligation to which the controller is subject
• processing is necessary in order to protect the vital interests of the data subject or of another natural person
• processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller
• processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child

[/row_column]
[row_column][/row_column]
[/table_row]
[table_row]
[row_column]Children[/row_column]
[row_column]If you collect and / or process personal data of children, then you have to obtain a consent. Consent for children must be given by the child’s parent or custodian and be verifiable.[/row_column]
[row_column]Article 8[/row_column]
[/table_row]
[table_row]
[row_column]Data security[/row_column]
[row_column]

Security has to be appropriate to the risks of individuals if data was lost, stolen or disclosed to unauthorized persons.

On other words, security measures have to be tailored to the risk, for the private individual, of if his data would be breached.

Security covers all aspects of an organisation (people, processes, systems)

Things to be taken into account:

• Pseudo anonymisation
• Encryption (at rest / intransit)
• Ongoing integrity
• Ability to restore data in timely manner
• Processes for testing security

[/row_column]
[row_column]Article 32[/row_column]
[/table_row]
[table_row]
[row_column]Governance[/row_column]
[row_column]

One of the key principles of GDPR is that any organisation have to place personal data governance in the center of their activity.

Enterprise wide it is important to raise awareness about data privacy and make it into the mindset of the people who are working with data.

 

• Develop and / or document your Privacy Governance Model, with clear roles and responsibilities, to embed privacy into organisation
• Appoint a DPO
• Training for all personnel
• Review insurance policies  and update them if necessary, in the light of new increased fines
• Establish a clear procedure for notifying a data breach

[/row_column]
[row_column]Article 5, 27, 37-39[/row_column]
[/table_row]

[table_row]
[row_column]Accountability[/row_column]
[row_column]

In GDPR era you have to have documentation, to prove how are you GDPR compliant. GDPR compliance should be integrated in audit framework to ensure that all policies are working

 

You need to implement an enterprise wide data protection policy

[/row_column]
[row_column]Article 5, 24, 25, 30[/row_column]
[/table_row]

[table_row]
[row_column]Consent[/row_column]
[row_column]

Where consent is used as the basis for data processing, consent must be explicit given for data collected and for the purpose of the processing.

GDPR imposes new requirements for a valid consent. You can no longer use a 20 pages document, full of jargon that nobody reads or worse, understands, but are required to sign if they want the services you are providing.

The consent must be in a clear, eligible form and language and must be given freely, with no “coercition”.

Under GDPR, any privacy note must state the processing ground you are relying upon and if rely on legitimate interest, state the nature of it.

[/row_column]
[row_column]Article 4, 7[/row_column]
[/table_row]
[/table_body]
[/table]

End of part II

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