GDPR third countries

 

The GDPR regulates the transfer of personal data to third countries. In order to be authorised, the transfer must be based on either an adequacy decision, an adequate level of data protection, or one of the exceptions provided for in the GDPR.


Recital 101 provides guidance on the rules for transferring personal data to a third country

  • A transfer could take place only if, subject to the other provisions of this Regulation, the conditions laid down in the provisions of this Regulation relating to the transfer of personal data to third countries or international organisations are complied with by the controller or processor.

 

Article 45 « Transfers on the basis of an adequacy decision » is invoked by the European Commission to determine whether a third country has an adequate level of protection or not.

The adoption of an adequacy decision based on Article 45 of the GDPR involves

  • A proposal from the European Commission
  • An opinion of the European Data Protection Committee
  • An approval by the representatives of the EU countries
  • Adoption of the decision by the European Commission 


At present only a limited list of third countries are considered to have adequate protection and are allowed to transfer personal data to their country.

The list of countries currently authorised by the European Commission is as follows.

  • Andorra,
  • Argentina,
  • Canada (commercial organisations),
  • Faroe Islands,
  • Guernsey,
  • Israel,
  • Isle of Man,
  • Japan,
  • Jersey,
  • New Zealand,
  • Republic of Korea,
  • Switzerland,
  • United Kingdom under the GDPR and LED.
  • Uruguay as offering adequate protection.
  • With the exception of the UK, these adequacy decisions do not cover data exchanges in the law enforcement sector which are governed by the Law Enforcement Directive (Article 36 of Directive (EU) 2016/680). »


In the absence of an adequacy decision under Article 45 of the GDPR, Article 46 « Transfers subject to appropriate safeguards » provides a list of « appropriate safeguards » on which a transfer to a third country may also be based


T
hese appropriate safeguards can be of various kinds:

  • Binding Corporate Rules (Article 47 of the RGPD): These are internal binding corporate rules relating to transfers of personal data to countries outside the European Union. They therefore constitute an internal « Code of Conduct » within a company group, defining the data transfer policy strategy for each of the entities that make up the group, including employees
  • Standard Contractual Clauses (Article 93(2)) adopted by the European Commission, which have very recently been recast as described below
  • Codes of conduct approved under Article 40
  • International agreements or administrative commitments

 

In the absence of an adequacy decision and appropriate safeguards given by Articles 45 and 46 of the GDPR, there is only one solution, and that is the exceptions provided for by Article 49 of the GDPR « Derogation for special situations ».


These exceptions are as follows

  • The data subject has given his/her explicit consent to the transfer
  • The transfer is necessary for the performance of a contract between the data subject Data subject and the RT / implementation of pre-contractual measures (or concluded In his or her interest if he or she is not party to the contract)
  • The transfer is necessary for important public interest reasons
  • The transfer is necessary for the establishment, exercise or defence of legal claims rights in a court of law
  • The transfer is necessary to protect the vital interests of the data subject
    and other persons
  • The transfer is made from a register which is intended to provide information to the public and is open to the public. information to the public and is open to consultation by the general public

Without an adequacy decision, appropriate safeguards, or derogations, the GDPR does not allow the transfer of personal data to a third country.


This article is only a short and incomplete one, but it aims to give you an idea of what the RGPD requires in certain situations. As non-compliance with the RGPD can lead to very heavy fines, I strongly advise you to ask your DPO or your RGPD consultant for advice and much more complete information
.

GDPR European Union representative

 

All companies, societies (or associations), wherever they are located in the world, whatever their size, whatever their sector of activity, whether they are public or private, must, as long as they deal with personal information of individuals located in Europe, comply with the GDPR regulation, otherwise they could be asked to pay large fines in case of control.

One of the obligations of the GDPR for companies based outside the EU, which deal with personal data of individuals located in Europe, is to appoint a GDPR representative in Europe. This is an obligation and not an option. However, there are circumstances where it is possible to be exempt from this obligation. There are therefore exemptions.

Let’s start with the definition of a GDPR representative as set out in Article 4(17).
What is a representative under the GDPR?

 

The first source I will share with you is Recital 80, which is part of the full GDPR, along with 172 other recitals and 99 articles. This recital 80/172 explains in detail the obligations regarding the appointment of a RGPD representative for a non-EU entity

The following is a brief summary of Recital 80 of the GDPR for ease of reading and understanding of what is the representative, how it will designed and what is role of the representative.The first source I will share with you is Recital 80, which is part of the full GDPR, along with 172 other recitals and 99 articles. This recital 80/172 explains in detail the obligations regarding the appointment of a RGPD representative for a non-EU entity

 

The second source I will share is Article 27 of the GDPR, which concerns the obligation to appoint a representative of the « controller » in Europe, if the company is based outside the EU and deals with personal data of individuals located in Europe. This article also explains what the exemptions are regarding the appointment of a GDPR representative in Europe.

 

Here I will focus on the exemption from the appointment of a European GDPR representative, for entities based outside the EU.The second source I will share is Article 27 of the GDPR, which concerns the obligation to appoint a representative of the « controller » in Europe, if the company is based outside the EU and deals with personal data of individuals located in Europe. This article also explains what the exemptions are regarding the appointment of a GDPR representative in Europe.

According to the GDPR, the following cases allow to be exempted from the appointment of a representative in the European Union.

These exemption possibilities are not cumulative. Only one of the cases needs to be present, and the exemption is not possible. This is most often the case for non-occasional processing. This is the end of this short article about the obligation for any entity located outside the European Union to process personal data of persons located in Europe, but also about the possibility of exemption from such designation.

That being said, I strongly advise you to call on a GDPR consultant, your DPO, or a specialist lawyer. Because the fines for not respecting the GDPR can be very expensive.

 

Re-use of personal data in the context of the GDPR

 

I collected personal data a few years ago, in this case email addresses for a specific purpose. Is it possible to reuse personal data that I collected before the GDPR for another purpose?

So first of all, what is personal data in the sense of the GDPR? Because many people don’t really know what personal data is and think that it is limited to names, surnames and addresses. But don’t worry, Article 4 gives the official definition of personal data.

 

(1) ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

 

The European Commission website provides a non-exhaustive list with examples of personal data.

 

  • A first and last name.
  • A personal address.
  • An e-mail address such as personalname@company.
  • An identity card number.
  • Location data (e.g. location data function on a mobile phone)*.
  • An Internet Protocol (IP) address.
  • A cookie identifier*.
  • Your phone’s advertising ID.
  • Data held by a hospital or doctor, which could be a symbol that uniquely identifies a person.

 

This same site also gives a small list, also not exhaustive, of what is not personal data.

 

  • A business registration number.
  • An email address as info@company.com.
  • Anonymised data.

 

Having settled this, let‘s get back to the problem at hand: « I collected personal data a few years ago, in this case email addresses for a specific purpose. Is it possible to reuse personal data that I collected before the GDPR for another purpose?

So what elements do we have to answer:

 

  • Collection of personal data.
  • Collected before the GDPR, i.e. before May 2018
  • Collected for a specific purpose.

 

Whereas the GDPR requires a legal basis for the processing of personal data.
Whereas the GDPR requires a time limit for the retention period.
Whereas the processing has received consent for a specific purpose.

The elements of the answer obviously count for all types of personal data

Let us ask ourselves different questions:
What is the legal basis for the retention period? Is the retention period compatible with Article 5.e of the GDPR which states that personal data must be :

(e) kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) subject to implementation of the appropriate technical and organisational measures required by this Regulation in order to safeguard the rights and freedoms of the data subject (‘storage limitation’);

 

Is post-consent processing compatible with Article 5.b which requires that :

 

(b) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’);

 

And the answers to the questions we have asked ourselves will determine whether we can legally re-use the data collected.

 

  • If the retention period has been set to be compatible with Article 5.e of the GDPR, we have a first element that allows us to re-use this data. If the retention period is not compliant, we will not be able to re-use the data legally.
  • Then, if the retention period is compliant AND the purpose for re-using the personal data is respected and therefore remains the same as the initial consent, there is nothing to prevent the re-use.
  • On the other hand, if the retention period is compliant BUT the purpose for re-use of the data does not correspond to the purpose of the initial consent, then re-use is not allowed for this new purpose.

 

BUT it is a bit more complex than that, and the European Commission gives more guidance on the re-use of data for a new purpose.

 

If your company/organisation has collected data on the basis of a legitimate interest, contract or vital interests, it may be used for another purpose but only after checking that the new purpose is compatible with the original purpose.

Attention should be paid to the following points:
– the link between the original purpose and the new or future purpose
– the context in which the data were collected (What is the relationship between your company/organisation and the data subject?)
– the type and nature of the data (Are they sensitive?);
– the possible consequences of the envisaged further processing (What impact will it have on the data subject?);
– the existence of appropriate safeguards (such as encryption or pseudonymization).

If your company/organisation wishes to use the data for statistical or scientific research purposes, there is no need for a compatibility test.
If your company/organisation has collected data on the basis of consent or in compliance with a legal requirement, no further processing beyond the areas covered by the original consent or legal provision is possible. Further processing would require a new consent or legal basis.

Examples
Further processing is possible.
A bank has a contract with a customer to provide a bank account and a personal loan. At the end of the first year, the bank uses the customer’s personal data to check whether he or she is eligible for a better type of loan and a savings plan. It informs the customer of this. The bank may process the customer’s data again because the new purposes are compatible with the original purposes.

Further processing is not possible.
The same bank wants to share the customer’s data with insurance companies, based on the same contract for a bank account and a personal loan. This processing is not allowed without the explicit consent of the customer as the purpose is not compatible with the original purpose for which the data were processed.

References
– Articles 5(1)(b), 6(4), 89(1); Recitals 39, 50
– Article 29 Working Party. Opinion 03/2013 on purpose limitation, 2 April 2013 (WP 203)

 

The outcome of the questions of re-use of personal data are therefore not so simple, and you will have to ask yourself different questions before knowing whether it will be possible or not to re-use personal data for a new purpose.

That being said, I strongly advise you to call on a GDPR consultant, your DPO, or a specialist lawyer. Because the fines for not respecting the GDPR can be very expensive.

 

 

Sources :
https://gdpr-text.com/ 
https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-personal-data_en
https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/principles-gdpr/purpose-data-processing/can-we-use-data-another-purpose_en

 

 

 

 

GDPR lawfulness of processing

 

The GDPR provides several legal bases for the lawful processing of personal data in accordance with its articles 5(1a) and 6
The CNIL, the French supervisory authority, defines the legal basis as follows:

 

The legal basis of a processing operation is what legally authorizes its implementation, which gives an organization the right to process personal data. It can also be referred to as the « legal basis » or « legal foundation » for processing.

 

Without an adequate legal basis for each processing operation, the processing of personal data is not lawful, and the controller is likely to be sanctioned by the supervisory authority in the event of an audit.

 

Article 5 – Principles relating to the processing of personal data

Personal data must be:
(a) processed lawfully, fairly and transparently with regard to the data subject (lawfulness, fairness, transparency);

 

There are 6 legal bases proposed by the GDPR
– Consent ;
– The contract ;
Legal obligation;
– Safeguarding vital interests;
– Public interest;
– Legitimate interests.

 

These 6 legal bases are the only legal bases proposed by the GDPR and there is no other possibility to make processing of personal data lawful.

Article 6 specifies the conditions of what GDPR calls lawfulness of processing, and lists in detail the different existing possibilities. The 6 legal bases are listed in its paragraph 1(a>f)

 

Article 6 Legality of processing

1. Processing shall be lawful only if and insofar as at least one of the following conditions is met
(a) the data subject has consented to the processing of his/her personal data for one or more specific purposes;
(b) the processing is necessary for the performance of a contract to which the data subject is party or for the performance of pre-contractual measures taken at the request of the data subject
(c) processing is necessary for compliance with a legal obligation to which the controller is subject
(d) processing is necessary to protect the vital interests of the data subject or of another natural person
(e) 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
(f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, unless the interests or fundamental rights and freedoms of the data subject which require the protection of personal data prevail, in particular where the data subject is a child.
Point (f) of the first paragraph shall not apply to processing carried out by public authorities in the performance of their tasks.

2. Member States may maintain or introduce more specific provisions to adapt the application of the rules of this Regulation in relation to processing for the purpose of complying with paragraph 1(c) and (e), by determining more precisely the specific requirements applicable to the processing as well as other measures to ensure lawful and fair processing, including in other specific processing situations as provided for in Chapter IX.

3. The basis for the processing referred to in paragraph 1(c) and (e) shall be defined by:
(a) Union law; or
(b) the law of the Member State to which the controller is subject.
The purposes of the processing shall be defined in that legal basis or, in the case of the processing referred to in paragraph 1(e), shall be necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller. This legal basis may contain specific provisions to adapt the application of the rules of this Regulation, inter alia general conditions governing the lawfulness of processing by the controller; the types of data that are subject to processing; the data subjects; the entities to which personal data may be disclosed and the purposes for which they may be disclosed; purpose limitation; retention periods; and processing operations and procedures, including measures to ensure lawful and fair processing, such as those provided for in other specific processing situations as set forth in Chapter IX. Union or Member State law shall serve a public interest objective and be proportionate to the legitimate objective pursued.

4. Where processing for a purpose other than that for which the data were collected is not based on the consent of the data subject or on Union law or the law of a Member State which constitutes a necessary and proportionate measure in a democratic society to safeguard the objectives referred to in Article 23(1), the controller, in order to determine whether processing for another purpose is compatible with the purpose for which the personal data were originally collected, shall take into account, inter alia
(a) whether there is a link between the purposes for which the personal data were collected and the purposes of the intended further processing;
(b) the context in which the personal data were collected, in particular as regards the relationship between the data subjects and the controller
(c) the nature of the personal data, in particular if special categories of personal data are processed pursuant to Article 9 or if personal data relating to criminal convictions and offences are processed pursuant to Article 10
(d) the possible consequences of the proposed further processing for the data subjects
(e) the existence of appropriate safeguards, which may include encryption or pseudonymization.

 

To illustrate the application of Article 6 and the different choices offered as legal bases, I will propose two simple examples.

The first example would be the case of a processing necessary for the execution of a contract, the legal basis of the consent is in this case not the most judicious choice, nor the most logical. That is why in this case the choice of the legal basis would simply be « the performance of a contract ».

The second example would be for a processing serving the subscription to a newsletter, the most logical choice would be the consent, because no other legal basis would be appropriate. The legal basis for processing for the performance of a contract, as in the first example, would obviously not be the best choice.

It is very important to check that the legal basis is adequate to the situation, because not only is it the only way to make the processing lawful, but it is also an important piece of information that must be included in various documents in your accountability file.

The lawfulness of the processing goes much further and is much more complex than the choice of the legal basis.
But it is an important point to take into account, and a carefully considered choice to make. Some processing is purely and simply forbidden, even if there are exceptions provided by the GDPR. I will surely talk about it in a future article.

I invite you to contact a GDPR consultant or a DPO for more information and help for the implementation of your compliance.

Christian

GDPR accountability

 

In this article, I will explain the different things you need to know about accountability, which roughly means that you as a data controller are obliged under the GDPR to document your compliance, in order to clearly demonstrate your compliance to a supervisory authority.

 

The CNIL, which is the official French supervisory authority, as well as the ICO for the UK, gives the following definition for accountability.

 

Accountability refers to the obligation for companies to implement internal mechanisms and procedures to demonstrate compliance with data protection rules.

 

The principle of accountability is enshrined in Article 5(2) of the GDPR, which dictates the principles for processing personal data.

 

Article 5 – Principles for processing personal data

1. Personal data must be:
(a) Processed lawfully, fairly, and transparently with respect to the data subject (lawfulness, fairness, transparency);
(b) Collected for specified, explicit, and legitimate purposes and not further processed in a way incompatible with those purposes; further processing for archival purposes in the public interest, for scientific or historical research purposes, or for statistical purposes shall not be considered, in accordance with Article 89(1), as incompatible with the original purposes (purpose limitation)
(c) Adequate, relevant, and limited to what is necessary for the purposes for which they are processed (data minimization)
(d) Accurate and where necessary kept up to date; every reasonable step must be taken to ensure that personal data which are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay. (accuracy)
(e) Kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which they are processed; personal data may be kept for longer periods insofar as they are processed exclusively for archival purposes in the public interest, for scientific or historical research purposes or for statistical purposes in accordance with Article 89(1), provided that the appropriate technical and organizational measures required by this Regulation to safeguard the rights and freedoms of the data subject are implemented. (limitation of storage)
(f) Processed in such a way as to ensure appropriate security of personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction, or damage, by means of appropriate technical or organizational measures (integrity and confidentiality);

2. The controller is responsible for compliance with paragraph 1 and is able to demonstrate compliance (accountability).

 

Recital 75 of the RGPD clarifies the notion of accountability in relation to its responsibility and documentation obligation

 

Recital 74 Responsibility and Liability of the Controller

The responsibility and liability of the controller for any processing of personal data carried out by the controller or on the controller’s behalf should be established.
In particular, the controller should be obliged to implement appropriate and effective measures and be able to demonstrate the compliance of processing activities with this Regulation, including the effectiveness of the measures.
Those measures should take into account the nature, scope, context and purposes of the processing and the risk to the rights and freedoms of natural persons.

 

The GDPR indeed provides for different things that will allow the creation of a documentary folder. So what type of documents is provided for in the GDPR to be able to demonstrate its good compliance.

The CNIL in its practical sheet « documenting your compliance » lists the different things to insert in your documentary folder

 

Documenting your compliance (CNIL)

The documentation on your personal data processing

1. The register of processing operations (for data controllers) or categories of processing activities (for processors),
2. Data Protection Impact Assessments for processing operations that are likely to generate high risks for the rights and freedoms of individuals
3. The framework for data transfers outside the European Union (in particular standard contractual clauses or BCRs).

Information to individuals

1. Information statements,
2. Models for collecting the consent of the persons concerned.
3. The procedures put in place for the exercise of the rights of individuals.

Contracts that define the roles and responsibilities of the actors

1. Contracts with subcontractors
2. Internal procedures for dealing with data breaches,
3. Evidence that data subjects have given their consent when their data is processed on that basis.

 

Accountability will be complete when your documentation file contains all the elements that demonstrate that you are in compliance with your obligations regarding the GDPR.

The elements constituting your documentation file will have to be checked regularly and updated if necessary.

 

This is a brief introduction to GDPR accountabilty .
I invite you to contact a RGPD consultant or a DPO for more information and help for the implementation

Christian

 

GDPR Privacy and data protection by design & data protection by default

 

According to the European Data Supervisor, « “privacy by design” is used to designate the broad concept of technological measures for ensuring privacy as it has developed in the international debate over the last few decades. »

This concept is not new. In fact, according to Wikipedia, «Ann Cavoukian, former Information and Privacy Commissioner of Ontario, developed the »privacy by design » approach to systems engineering. This approach was formalized in a joint report on privacy-enhancing technologies by a joint team of the Information and Privacy Commissioner of Ontario (Canada), the Dutch Data Protection Authority and the Dutch Organization for Applied Scientific Research in 1995. The Privacy by Design framework was published in 2009 and adopted by the International Assembly of Privacy Commissioners and Data Protection Authorities in 2010. »


A
ccording to this framework, Privacy by Design is based on seven « core principles ».

1. Proactive, not reactive; preventive, not remedial.
2. Privacy as a default setting
3. Privacy built into the design
4. Full functionality – positive sum, not zero sum
5. End-to-end security – full life cycle protection
6. Visibility and transparency – stay open
7. User privacy – stay user-centric


T
he concept of « privacy by default » foresees that the application of the seven core principles put in place at the design stage are also active by default without the user having to intervene.

Still according to the European Data Protection Supervisor, «the ”data protection by design” and “data protection by default” to designate the specific legal obligations».

«Established by Article 25 of the GDPR 9. While measures taken under these obligations will
also contribute to achieve the more general objective of “privacy by design”, considering.
that a wider spectrum of approaches may be taken into account for the objective of “privacy
by design” which includes a visionary and ethical dimension, consistent with the principles
and values enshrined in the EU Charter of Fundamental Rights of the EU. »

Article 25 of the GDPR details the concepts and mandatory measures to be implemented by the data controller regarding data protection by design and data protection by default.

 

Art. 25

GDPR Data protection by design and by default

  1. Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.
  2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons.
  3. An approved certification mechanism pursuant to Article 42 may be used as an element to demonstrate compliance with the requirements set out in paragraphs 1 and 2 of this Article.

 

Recital 78 provides additional information and context for completing Article 25

 

Recital 78

Appropriate Technical and Organisational Measures

The protection of the rights and freedoms of natural persons with regard to the processing of personal data require that appropriate technical and organisational measures be taken to ensure that the requirements of this Regulation are met. In order to be able to demonstrate compliance with this Regulation, the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default. Such measures could consist, inter alia, of minimising the processing of personal data, pseudonymising personal data as soon as possible, transparency with regard to the functions and processing of personal data, enabling the data subject to monitor the data processing, enabling the controller to create and improve security features. When developing, designing, selecting and using applications, services and products that are based on the processing of personal data or process personal data to fulfil their task, producers of the products, services and applications should be encouraged to take into account the right to data protection when developing and designing such products, services and applications and, with due regard to the state of the art, to make sure that controllers and processors are able to fulfil their data protection obligations. The principles of data protection by design and by default should also be taken into consideration in the context of public tenders.

 

This is a brief introduction to privacy by design, data protection by design and data protection by default.
I invite you to contact a RGPD consultant or a DPO for more information and help for the implementation.

Christian

 

 

Sources :
wikipedia privacy by design
edps preliminary opinion on privacy by design
edpb guidelines on dataprotection by design and by default
gdpr

 

What is the GDPR

 

The GDPR or General Data Protection Regulation, is the European regulation n°2016/679 that enshrines the protection of personal data as a fundamental right in its own right in the Charter of Fundamental Rights of the European Union in its article 8

 

Charter of Fundamental Rights of the European Union

Article 8 – Protection of personal data

1. Everyone has the right to the protection of personal data concerning him or her.
2. Such data must be processed fairly for specified purposes and on the basis of the consent of the data subject or some other legitimate basis laid down by law. Any person has the right to access and rectify the data collected concerning him/her.
3. Compliance with these rules is subject to supervision by an independent authority.


T
he GDPR was adopted definitively in April 2016. Its implementation for all member states of the European Union is to date from May 25, 2018.

Its Article 1.2 describes the purpose and objectives of the GDPR

 

Article 1 – Purpose and objectives

1. This Regulation establishes rules on the protection of individuals with regard to the processing of personal data and rules on the free movement of such data.
2. This Regulation protects the fundamental rights and freedoms of natural persons, and in particular their right to the protection of personal data.
3. The free movement of personal data within the Union shall not be restricted or prohibited on grounds relating to the protection of individuals with regard to the processing of personal data.

 

It is composed of 99 articles and 173 recitals, which detail the objective, to ensure a consistent and high level of protection of natural persons by strengthening the rights of data subjects and increasing the obligations of those who process such data

In its article 3, the GDPR specifies that the scope of application extends beyond the European Union, as long as the processing of personal data concerns individuals located in Europe

 

Article 3 – Territorial scope of application

1. This Regulation applies to the processing of personal data carried out in the course of the activities of an establishment of a controller or processor on the territory of the Union, whether or not the processing takes place in the Union.
2. This Regulation shall apply to the processing of personal data relating to data subjects who are in the territory of the Union by a controller or processor who is not established in the Union, where the processing activities relate to:
(a) offering goods or services to such data subjects in the Union, whether or not payment is required from such data subjects; or
(b) monitoring the conduct of such persons, to the extent that such conduct takes place within the Union.
3. This Regulation applies to the processing of personal data by a controller who is not established in the Union but in a place where the law of a Member State applies under public international law.


T
here are 6 fundamental principles that are listed in Article 5 of the GDPR. They are the basis for every GDPR compliance. The controller is responsible for compliance

1. Lawfulness, fairness, transparency
2. Purpose limitation
3. Data minimization
4. Accuracy
5. Limiting retention
6. Integrity and confidentiality

 

Article 5 – Principles for the processing of personal data

1. Personal data must be :
(a) processed lawfully, fairly and transparently with respect to the data subject (lawfulness, fairness, transparency);
 (b) collected for specified, explicit and legitimate purposes and not further processed in a way incompatible with those purposes; further processing for archival purposes in the public interest, for scientific or historical research purposes or for statistical purposes shall not be considered, in accordance with Article 89(1), as incompatible with the original purposes (purpose limitation)
 (c) adequate, relevant and limited to what is necessary for the purposes for which they are processed (data minimization)
 (d) accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data which are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (accuracy)
 (e) kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which they are processed; personal data may be kept for longer periods insofar as they are processed exclusively for archival purposes in the public interest, for scientific or historical research purposes or for statistical purposes in accordance with Article 89(1), provided that the appropriate technical and organisational measures required by this Regulation to safeguard the rights and freedoms of the data subject are implemented (limitation of storage)
 (f) processed in such a way as to ensure appropriate security of personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction or damage, by means of appropriate technical or organizational measures (integrity and confidentiality);
2. The controller is responsible for compliance with paragraph 1 and is able to demonstrate compliance (accountability).

 

The GDPR does not give any limit to the size or type of the companies concerned by the regulation. So whether you are a freelancer, a sole proprietorship, an SME or a multinational company. Private or public company or organisation. As long as you are located in Europe, or you process personal data of people residing in Europe, you are subject to the obligation to comply with the GDPR.

Penalties for  not complying with the regulation can be severe, and can cost the company up to 20 million euros or 4% of the annual worldwide turnover. They can vary according to different criteria listed in Article 83 of the GDPR. The criteria include, among others

– The severity and duration of the breach;
– The measures taken to mitigate the harm to the data subjects; and
– The degree of cooperation, etc.

 

Article 83 – General conditions for imposing administrative fines

1. Each supervisory authority shall ensure that administrative fines imposed under this Article for violations of this Regulation referred to in paragraphs 4, 5 and 6 are, in each case, effective, proportionate and dissuasive.
2. Depending on the specific features of each case, administrative fines shall be imposed in addition to or instead of the measures referred to in Article 58(2)(a) to (h) and (j). In deciding whether to impose an administrative fine and in deciding the amount of the administrative fine, due account shall be taken in each individual case of
 (a) the nature, seriousness and duration of the violation, taking into account the nature, scope or purpose of the processing concerned, as well as the number of data subjects affected and the level of harm they have suffered;
(b) whether the breach was committed intentionally or negligently
 (c) any measures taken by the controller or processor to mitigate the damage suffered by the data subjects
(d) the degree of responsibility of the controller or processor, taking into account the technical and organizational measures they have implemented pursuant to Articles 25 and 32
(e) any relevant previous breaches by the controller or processor
(f) the degree of cooperation established with the supervisory authority in order to remedy the breach and mitigate any adverse effects
(g) the categories of personal data affected by the breach
(h) how the supervisory authority became aware of the breach, including whether and to what extent the controller or processor notified the breach
 (i) where measures referred to in Article 58(2) have previously been ordered against the controller or processor concerned in respect of the same matter, compliance with those measures
 (j) the application of codes of conduct approved pursuant to Article 40 or certification schemes approved pursuant to Article 42; and
(k) any other aggravating or mitigating circumstances applicable to the circumstances of the case, such as financial benefits obtained or losses avoided, directly or indirectly, as a result of the violation.
3. If a controller or processor deliberately or negligently violates more than one provision of this Regulation, in the context of the same processing operation or related processing operations, the total amount of the administrative fine may not exceed the amount set for the most serious violation.
4. Violations of the following provisions shall be subject, in accordance with paragraph 2, to administrative fines of up to EUR 10,000,000 or, in the case of an undertaking, up to 2 % of the total worldwide annual turnover in the preceding business year, whichever is higher
 (a) the obligations of the controller and processor under Articles 8, 11, 25 to 39, 42 and 43;
 (b) the obligations of the certification body under Articles 42 and 43;
(c) the obligations of the body responsible for monitoring codes of conduct under Article 41(4).
5. Violations of the following provisions shall be subject, in accordance with paragraph 2, to administrative fines of up to EUR 20 000 000 or, in the case of an undertaking, up to 4 % of the total annual worldwide turnover in the preceding business year, whichever is the higher
(a) the basic principles of a processing operation, including the conditions applicable to consent under Articles 5, 6, 7 and 9;
(b) the rights of data subjects under Articles 12 to 22
(c) transfers of personal data to a recipient in a third country or to an international organization under Articles 44 to 49
(d) all obligations under the law of the Member States adopted pursuant to Chapter IX
(e) failure to comply with an injunction, temporary or permanent restriction of processing or suspension of data flows ordered by the supervisory authority under Article 58(2), or failure to grant access as provided for, in breach of Article 58(1).
6. Failure to comply with an injunction issued by the supervisory authority pursuant to Article 58(2) shall, in accordance with paragraph 2 of this Article, be subject to administrative fines of up to EUR 20 000 000 or, in the case of an undertaking, up to 4 % of the total worldwide annual turnover in the preceding business year, whichever is the higher.
7. Without prejudice to the powers of the supervisory authorities to take remedial action under Article 58(2), each Member State may lay down rules determining whether and to what extent administrative fines may be imposed on public authorities and public bodies established in its territory.
8. The exercise by the supervisory authority of its powers under this Article shall be subject to appropriate procedural safeguards in accordance with Union law and the law of the Member States, including effective judicial review and due process.
9. If the legal system of a Member State does not provide for administrative fines, this Article may be applied in such a way that the fine is determined by the competent supervisory authority and imposed by the competent national courts, while ensuring that these legal remedies are effective and have equivalent effect to administrative fines imposed by the supervisory authorities. In any event, the fines imposed shall be effective, proportionate and dissuasive. The Member States concerned shall notify the Commission of the legal provisions they adopt pursuant to this paragraph by 25 May 2018 at the latest and, without delay, of any subsequent legal provisions or amendments thereto.

 

This is the end of this article, in which I have tried to explain simply, what the GDPR is, what is its scope, what are its fundamental principles and what are the consequences of a possible non compliance. But it is obvious that I have only scratched the surface of this regulation for this article, and that it obviously goes much further and that there are many things missing in this article.

I advise you to contact a specialist for your compliance, either a GDPR consultant or even better a former or current DPO

Christian

Google dorks in recognition phase

 

Google is often used by hackers to search for various sensitive informations. This same technique is used along with other tools by IT security professionals to gather preliminary data or information about a target (a customer), in order to prepare a penetration test. The use of certain keywords that enter in association with your search will give surprising results in some cases. Avoid certain searches as they could get you into a lot of trouble, always check the legality of your actions. This tutorial is only intended to be used for personal research and especially as one of the different tools in phase 1 of an intrusion test, either through the different sites that offer to train you legally, or within the framework of an intrusion test that you will have previously validated by a contract with your client. It is obvious that in the case of a penetration test for a client, all the information and techniques that you have used must be included in the final report to inform your client, who will take the necessary measures to prevent malicious people from finding this information in the future, who can in some cases be very sensitive. Here is a small list of some of these keywords called «Google dorks»

 

inurl is used to search for any text inside a url.

intext is used to search for any text within the body or source code of the website.

filetype is used to search for any type of file you want to locate within a website or on a particular topic. You can search for any type of file.

intitle is used to search for web page titles.

site is used to narrow the search area to a particular website.

link is used to check other websites containing links to a website.

 

Here are some examples of the use of these google dorks. Not to be too long I would not put more, but you can of course do a search on Google to have more information and examples when using this search technique, or directly click on the following link: http://www.googleguide.com/advanced_operators_reference.html

 

An example to find the keyword « cybersecurity » in the title of a website would be to enter the following dork in the search bar:

  • intitle:cybersecurity

Another example with the same dork but a little more complex will allow you to access all sites where there is index.of in the title:

  • intitle:index.of

Another example with the same query but even more perfidious this time to find sites with a specific type of server which would norlamly be Apache version 2.0

  • « Apache/2.0 Server at » intitle:index.of
  •  intitle:index.of “Apache” “server at”

Thats is for this simple and short tutorial. Use it wisely and in legality.

 

 

OWASP

OWASP (Open Web Application Security) is a charity and non-profit organization. It is a global community dedicated to promoting knowledge to improve web application security. Its mission is to share information and free ways to train and make the right decisions about securing applications for individuals, professionals, universities and government agencies.

OWASP is known for publishing various documents, including the OWASP top 10, of which I will give you a brief description. This is a document that OWASP published the last two times in 2013 and 2017. It includes a list of the top 10 application security risks faced by developers and organizations, with the goal of helping developers and security teams better secure the applications they build and deploy, as well as techniques and best practices for avoiding and fixing vulnerabilities. Most security audits and specialized tools are based on this Top 10.

Here is the 2017 list of the top 10 most common vulnerabilities:

1   Injections
2   Broken Authentication
3   Sensitive Data Exposure
 XML External Entities (XXE)
5   Broken Access Control
6   Security Misconfiguration
7   Cross-Site Scripting (XSS)
8   Insecure Deserialization
9   Using Components with Known Vulnerabilities
10 Insufficient Logging & Monitoring

I provide you with the official link of the OWASP document that you can go through and analyze as you wish. It contains this list, with very detailed explanations, scenarios, as well as countermeasures to apply to secure your web applications. It also contains some links that I invite you to consult.

However, you should know that these are only the 10 main risks for web applications, and that there are many other more or less advanced ones. Don’t hesitate to get information and to consult official websites, books, links, etc. to learn more.

Here is the official document of the OWASP top 10 of 2017 in the original and complete version: https://owasp.org/www-pdf-archive/OWASP_Top_10_2017_RC2_Final.pdf

Clarification about penetration testing

 

The terms penetration testing and vulnerability assessment are often confused and used interchangeably, when in fact the two terms have distinct meanings.

Penetration testing, also known as penetration testing or simply pentesting, is a continuous cycle of searching for and attacking a target in order to identify vulnerabilities within a computer system, network, or web application that an attacker could exploit and then attempt to gain potential access to various confidential data and information about the system under a test.

Vulnerability assessment is the process of defining, identifying, and classifying potential security vulnerabilities in the target system.

Penetration testing can be automated with software applications or can be performed manually. In both cases, the process includes collecting information about the target before the test (reconnaissance), identifying possible entry points, attempting to break in (virtual or real), and reporting the results.

When a penetration test is performed correctly, the results allow professionals to make recommendations to solve the problems detected during the test. The main objective of penetration testing is to improve the security of the computer system, network, or web application and to provide protection for the entire network and connected devices against future attacks.

There are three types of penetration testing, depending on the company‘s expectations:

Black box: The tester puts himself completely in the shoes of a hacker. He does not have any information.
Grey box: The tester has a limited amount of information.
White box: The tester has all the information he needs.

I can’t stress the fact enough that you should always make sure that you are in the right by either going through specialized sites or by concluding a proper contract with your client before starting.

0

Metasploitable


Metasploitable
is a Linux-based virtual machine.
It is intentionally vulnerable and can be used to be exploited legally. Metasploitable Project is created and maintained by Rapid7 Community (Metasploit-FrameWork Community). In simple terms, Metasploitable is a Linux-based operating system, specifically designed for practicing penetration testing skills, network security skills. It can be accessed online, or installed on a virtual machine, at which point you will need to download it by clicking on this link.

I will use it to make scan demonstrations with different tools in some following articles. It is of course obvious that to be able to use the different tools towards the vulnerable Metasploitable machine, this one will have to be booted!

0

Phases of a pentest


I will begin by summarizing the five phases of a penetration test.
The five phases refer to each primary step in the process of a penetration test. Here is a brief overview of the five phases of a penetration test

Phase 1: Reconnaissance.

Reconnaissance is the act of gathering preliminary data or information about your target. The data is collected to better plan your attack. Reconnaissance can be done actively (meaning you hit the target directly) or passively (meaning your reconnaissance is done by an intermediary). Phase 1 includes identifying the target, discovering the target IP address range, network, domain name, mail server, DNS records, etc.

Phase 2: Scanning.

The Scanning phase requires the use of technical tools to gather more information about your target, in this case. The information sought is more often about the systems that are in place. A good example would be the use of a vulnerability scanner on a target network. Phase 2 includes scanning the target for running services, open ports, firewall detection, vulnerability scanning, bone scan, etc.

Phase 3: Obtaining access.

Obtaining access in Phase 3 requires taking control in order to extract data from the target or using that target to then launch attacks on other targets. Phase 3 includes exploiting vulnerabilities, social engineering, etc.

Phase 4: Maintaining access.

Maintaining access requires taking the necessary steps to be able to stay in the target environment to gather as much data as possible. The attacker must remain stealthy in this phase, so as not to be caught while using the host environment. Phase 4 includes escalation of privileges, installation of backdoor on the target to be able to keep the acquired access and see to connect to the target at any time, etc.

Phase 5: Erasing the traces.

This final phase simply means that the attacker must take the necessary steps to remove any semblance of traces. Any changes that were made, permissions that were escalated, etc. should all revert to a state of non-recognition by the host network administrators.


We could also add two other phases:

A pre-engagement phase: which takes place before the recognition phase and which consists of defining with the client a perimeter of the penetration test that is going to be carried out, what is allowed to be done and what is totally forbidden, as well as the objectives.

A phase where we create a final report: which is of course in the last position. It will be to provide the customer with a documented report that will explain how and with which tools the pentest was performed, what flaws were discovered, what are the risks for the customer, and of course how to remedy these problems by explaining how to correct the various flaws discovered.

0

Télécharger gratuitement le manuel officiel de Kali LInux

 

Kali Linux est une distribution basée sur Debian. Elle est le successeur de Backtrack. C’est un projet maintenu par Offensive Security qui est orienté test d’intrusion, analyse forensique, ingénierie inversée, audit de sécurité etc…
Cette distribution est la distribution favorite des professionnels de la sécurité de l’information dans le monde entier, elle contient plus de 600 des meilleurs outils préinstallés. Offensive Security propose le téléchargement gratuit d’un document en Anglais de 344 pages qui est considéré comme le premier manuel officiel de Kali Linux.
Que vous soyez débutant ou confirmé ce document sera pour tout le monde une mine d’or que vous consulterez régulièrement pour vous guider ou vous rafraichir la mémoire. En outre ce document pourra servir de feuille de route, de référence technique et de guide d’études pour ceux qui souhaiteraient suivre la certification KLCP (Kali Linux Certified Professional) proposée par Offensive Security.

Sans plus attendre voici donc le liens pour télécharger gratuitement et légalement le manuel.

https://kali.training/downloads/Kali-Linux-Revealed-1st-edition.pdf

 

N’oubliez pas que l’utilisation des différents outils et techniques pourrait dans certaines circonstances vous mettre hors la loi. Veuillez respecter la législation en vigueur en France en suivant les consignes que j’ai publie dans l’article intitulé “Rappel des textes en vigueur concernant les atteintes aux systèmes de traitement automatisé de données