GDPR: Protecting Your Data

GDPR – Protecting Your Data
Mark Rasch
Chief Legal & Compliance
Partner
Digital Risk Management
Institute
David Morris
Early Pioneer in
Cybersecurity Managing
Partner Morris Cybersecurity
Martyn Hope
Founder, GDPR
Institut
Ulf Mattsson
Head of Innovation at TokenEx

The GDPR Institut
Helping you resolve YOUR GDPR
Challenge
& Maximise the GDPR Opportunity
www.gdpr.institute
Martyn Hope

GDPR = Trust
ENTERPRISE wide Trust
© 2018 - The GDPR Institut - All Rights Reserved

Impact
Do you control or process personal data about
ANY EU Citizens?
If so you have to be GDPR compliant by 25th May
2018 or manage the implications of the fines and
the reputational damage of any and every Data
Breach
– including Customers Employees
Suppliers

YOU NEED TO UNDERSTAND THE TYPES OF DATA
Personal Data
A Universe of Data
Sensitive Data
At Risk
Data

1. Data → Seat 10K on Flight BA213 from London Heathrow to Boston Logan
2. Personal Data → Booking Reference XYN62F identifies Passenger Name, Address, Credit Card Details,
Phone Number, Passport Number etc
3. Sensitive Data → Passport details include Biometric Data which is classified as Medical Information and
thus Sensitive under GDPR
4. @Risk Data → The lead Passenger is travelling as part of a family group including children under 16 years
of age which is classified as @Risk Data under GDPR
Example of Types of Data

And the Data Processor shares it
with all their Sub Processors
Are you a Data Controller or a Data Processor?
Data Controller catches a GDPR Cold
Data Controller shares the GDPR
Cold
with their Data Processors

You will have a Data Breach

Legal Aspects and
Implications
Mark Rasch

Data Security Requirements
• Security is designed around protecting the privacy and processing of
data
• Ensure Confidentiality, Availability, Integrity and Resilience
• No specific technology required, no specific level of security
required
• References state of the art, risk, and nature of information
• Also looks at auditability and ability to demonstrate compliance

Data Covered
• Personal data is broader than just name, etc.
• Anything that can identify a specific individual
• Including MAC/IP address (inc.dynamic), RFID tags, etc. (Breyer)
• Assume any per-user record may be personal data
• ePrivacy Regulation covers all data relating to communications
• Headers, content, location…
• Even when it’s not personal data... If it can identify a specific person

GDPR Article 13(2)
• Each Member State shall provide that the provisions adopted
under national law in implementation of Articles 21 and 22 of
Framework Decision 2008/977/JHA regarding confidentiality
of processing and data security shall also apply to all
processing of personal data pursuant to this Directive.

GDPR Article 29 - Security
• Implement measures designed to:
• (a) deny unauthorized persons access to processing equipment used for processing (‘equipment access control’);
• (b) prevent the unauthorized reading, copying, modification or removal of data media (‘data media control’);
• (c) prevent the unauthorized input of personal data and the unauthorized inspection, modification or deletion of stored
personal data (‘storage control’);
• (d) prevent the use of automated processing systems by unauthorized persons using data communication equipment (‘user
control’);
• (e) ensure that persons authorized to use an automated processing system have access only to the personal data covered
by their access authorization (‘data access control’);
• (f) ensure that it is possible to verify and establish the bodies to which personal data have been or may be transmitted or
made available using data communication equipment (‘communication control’);
• (g) ensure that it is subsequently possible to verify and establish which personal data have been input into automated
processing systems and when and by whom the personal data were input (‘input control’);
• (h) prevent the unauthorized reading, copying, modification or deletion of personal data during transfers of personal data or
during transportation of data media (‘transport control’);
• (i) ensure that installed systems may, in the case of interruption, be restored (‘recovery’);
• (j) ensure that the functions of the system perform, that the appearance of faults in the functions is reported (‘reliability’) and
that stored personal data cannot be corrupted by means of a malfunctioning of the system (‘integrity’).

GDRP Security – Article 32
• 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 organizational measures to ensure a level
of security appropriate to the risk, including inter alia as appropriate:
(a) the pseudonymization and encryption of personal data;
(b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems
and services;
(c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or
technical incident;
(d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organizational
measures for ensuring the security of the processing.

GDRP Security – Article 32 (cont’d)
• In assessing the appropriate level of security, account shall be taken in particular of the risks that are
presented by processing, in particular from accidental or unlawful destruction, loss, alteration,
unauthorized disclosure of, or access to personal data transmitted, stored or otherwise processed.
• Adherence to an approved code of conduct as referred to in Article 40 or an approved certification
mechanism as referred to in Article 42 may be used as an element by which to demonstrate
compliance with the requirements set out in paragraph 1 of this Article.
• The controller and processor shall take steps to ensure that any natural person acting under the
authority of the controller or the processor who has access to personal data does not process them
except on instructions from the controller, unless he or she is required to do so by Union or
Member State law.

Code of Conduct
• fair and transparent processing;
• the legitimate interests pursued by controllers in specific contexts;
• the collection of personal data;
• the pseudonymization of personal data;
• the information provided to the public and to data subjects;
• the exercise of the rights of data subjects;
• the information provided to, and the protection of, children, and the manner in which the consent of the
holders of parental responsibility over children is to be obtained;
• the measures and procedures referred to in Articles 24 and 25 and the measures to ensure security
of processing referred to in Article 32;
• the notification of personal data breaches to supervisory authorities and the communication of such
personal data breaches to data subjects;
• the transfer of personal data to third countries or international organizations; or
• out-of-court proceedings and other dispute resolution procedures for resolving disputes between
controllers and data subjects with regard to processing, without prejudice to the rights of data subjects
pursuant to Articles 77 and 79.

Technologies to Protect Data Subjects Personal
Data
Ulf Mattsson

Source: https://www.dativa.com/data-science-gdpr-pseudonymization-data-pipeline/
GDPR has an extensive list of rules for handling data, but we can summarize them into 5 different areas:
1.Legitimate interest: You must have a valid reason to collect and store the confidential data.
2.Consent: To use certain types of personal data about an individual for commercial or marketing purposes, you
must first obtain the individual's permission.
3.The right to be forgotten: An individual may revoke access to their personal data, and you must remove it. You
must also correct errors in personal data upon the individual's request.
4.Anonymization/pseudonymization: Personal data must either be anonymized or go through
pseudonymization when stored. This ensures that confidential data is not accessed
inappropriately (more details in the next section of the article).
5.Sharing externally: If you obtain consent to share personal data with external parties, you must be able to
revoke the parties' access to these data. This includes the obligation to ensure that the data is erased from the
data warehouses of the partners.
GDPR rules for handling personal data

• Anonymization is a radical step for dealing with confidential data, as it removes any ability to correlate
personal identifiers with other data.
• For example, if an ID is converted to a random string of numbers, to be anonymized, the string cannot remain
the same over time.
• It should change according to the time the user was active.
• If it stays the same, showing just one data point about the individual is enough to re-identify them and their
associated data.
• In pseudonymization, another attribute is created to link personal identifiers to the anonymized identifiers
such that data can be de-anonymized later.
• There are three areas. to consider the first describes essential points to consider when deciding how to
handle user consent.
• The second area covers database setup and the third gives guidance in processing confidential data.
Anonymization or Pseudonymization of Personal Data

• Based on consent and rules for handling personal data a data gateway filters and splits raw data.
• The following rules can be applied.
Handling Personal Data
Rule GDPR
compliance
Action
Anonymize (hash) Full The data is anonymized using hash technique and makes data entry non-reversible. To make
the hash unique datetime is used as input. The uniqueness can be set on a second, day or year
level. Setting hash unique on a year level allows to track general user behavior but without
revealing identity.
Anonymize
(obfuscate)
Full The data is obfuscated but unlike hashing the data, some data is kept. For example, GPS
location, some of the lower digits in the coordinate are removed.
Pseudonymization
(tokenize)
Conditional if it is part
of running a business
The data is tokenized, and a separate lookup file is created with the original entry and the
token. The separate file must be managed with more security and stored in a restricted
database. As when anonymizing the datetime is used as input set the uniqueness of the data
over time.
Encrypt Conditional if part of
getting consent
The data does not need to have a table lookup but has a conditional access the data is stored
separately with a key. The key is used when performing SQL queries joining the datasets.

Handling Personal Data
Data
Entry
Action Type Recommendation
ID Anonymize (hash) String Take approach if there is no intention to have subscription-based services. The ID shall be
completely anonymized.
ID Pseudonymization
(tokenized)
Integer If a subscription is used, then tokenize the ID. Allows flexibility if at any point subscriber is
removed from the system without affecting the unrestricted database.
Name Encrypt Same options as ID but can be stored separately and use ID as the main key.
E-mail Encrypt Same options as ID but can be stored separately and use ID as the main key.
Physical
address
Encrypt Same options as ID but can be stored separately and use ID as the main key.
IP address Anonymize
(obfuscate)
String IP address can be converted into a physical address but keeping only city and country and
zip code.
IP address Encrypt Consider adding consent to keep the IP address. Information can give valuable insights that
the end-user will appreciate. Another reason for keeping information is if it’s part of
conducting a service. Due to sensitivity of data restricted database.
IP address Pseudonymization
(tokenized)
Integer Only reason for using tokens for IP address is if it is important to track changes of IP
address.
Location Anonymize
(obfuscate)
Integer GPS based location can obfuscated to a level that exact location is not found. This is done
by removing the lower digits of the coordinates.
How the personal data should be processed

Source: Gartner
Encryption Options and Access Controls

• All private or sensitive data must be kept in a restricted database with separate login access.
• The rest of the data can be stored in an unrestricted database.
• The separation enables accountability, as only individuals with restricted access and proper training in
handing personal data may work with such data.
• The data in the unrestricted database will have undergone anonymization or pseudonymization and
thus cannot be correlated with personal identifiers.
• The data in the unrestricted database may also be persistent and need not be forgotten.
• It is enough to remove it from the restricted database, where personal identifiers can be correlated
with other data.
Database Handling

The pseudonymization framework gives a means to continue collecting personal data in compliance to GDPR
without having to drop confidential data that can enable continued data science within the organization.
The goal of the framework is to provide:
• A better understanding of what confidential data is and when to apply anonymization or pseudonymization
• Strategies for handling consent
• Routines for handling personal data in compliance with GDPR
• Strategies for accountable sharing of data with partners
• Data that remains valuable to data science analysis
Summary

For more information about this
presentation, contact: David
Morris at:
David.Morris@Morriscybersecurity.com

GDPR: Protecting Your Data

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to GDPR: Protecting Your Data

Similar to GDPR: Protecting Your Data (20)

More from Ulf Mattsson

More from Ulf Mattsson (20)

Recently uploaded

Recently uploaded (20)

GDPR: Protecting Your Data

Editor's Notes