Report: Only 34% of Websites in the EU are Ready for GDPR

It’s been nearly 2 years since the Council of the European Union, European Parliament and the European Union passed the privacy legislation known as the General Data Protection Regulation (GDPR).

Beginning on May 25th, 2018 any company that hasn’t updated their privacy policy during the two-year grace period will be in violation of the law and could face fines as much 4% of the company’s global revenue or €20 million, whichever is higher.

The new privacy policy must be transparent and tell the users what will happen with the data that is collected. It should be concise and written clearly, let the user know whether their data will be shared with a 3rd party or used for marketing purposes, explain the use of cookies and their purpose, and clearly state the rights of the individual visiting the site.

Report: Only 34% of Websites in the EU are Ready for GDPR

63% of data breaches involve a third party relationship.

63% of data breaches involve a third party relationship, so if you do not have suitable 3rd Party contracts if they breach your data it will have a major impact on you.

The new General Data Protection Regulation (GDPR) – which comes into force on the 25th May 2018 – may at first review seem like “just another EU rule”. However, organizations – and specifically third party risk management teams within them – would take a “tick-box” approach to compliance at their peril.

In fact, the GDPR is such a significant new rule that any organization that does business with EU nationals and holds some form of personal data on them, should dedicate the the time and resources to take a more strategic approach to risk management and compliance within 2017, rather than waiting until next year, or complying more tactically. Compliance with this rule requires a strategic approach because:

  • It is an EU regulation, but with significant extraterritorial implications. For example, it effects data about EU citizens processed elsewhere around the world.
  • Organizations have significant new risk responsibilities regarding the third parties they engage, who work with impacted personal data.
  • The new rule has much more robust protections woven into it for privacy, data protection, and consent.
  • The rule requires data protection to now be built into new products, rather than tacked on as an afterthought.
  • New fines and sanctions built into the rule are much more severe than under the previous rule – and would apply in the global way in which the rule is written.
  • Organizations need to evidence that they have done what is required.

The GDPR: A guide for small businesses

Businesses are starting to panic as they try to comply with the General Data Protection Regulation (GDPR) before the May 2018 deadline. Many even believe that the GDPR won’t apply to them because they have fewer than 250 employees. Our small business guide to the GDPR should help clarify some of the key factors affecting SMEs.

Does it apply to me?

Any organisation, regardless of size, that regularly processes EU residents’ personal data must comply with the Regulation. However, SMEs may be exempt from the more rigorous steps.

Article 30, for example, states that the Article (which relates to the documentation controllers and processors must keep regarding data processing) “will not apply to small businesses except if the processing results in a risk to the rights and freedoms or data subjects, processing is not occasional, or the processing includes special categories of data as referred to in article 9, or personal data relating to criminal convictions and offences.”

This means you might not need the extensive documentation that larger organisations are required to keep. Nevertheless, you may find that your suppliers or customers will require you to have such documentation within their new GDPR-compliant contracts, so having it may give you a competitive advantage.

Data protection officers

The GDPR stipulates that certain organisations must appoint a data protection officer (DPO). There isn’t an exception for small businesses, so if you fall into the following categories, you’ll need a DPO:

  • You are a public authority (except for courts acting in their judicial capacity).
  • You carry out large-scale systematic monitoring of individuals (for example, online behavior tracking).
  • You carry out large-scale processing of special categories of data or data relating to criminal convictions and offences.

The good news is, you aren’t obliged to hire a full-time employee for this role. You can have someone who performs this alongside other duties (if they aren’t processing data and don’t have a conflict of interest), you can share a DPO with other organisations, or you can outsource the role entirely. It may seem a daunting and expensive prospect, but there are cost-effective options out there for SMEs.

If you are an SME or charity and you need GDPR assistance please email dpo@deniscroombs.ie or call us on 086 17 29383 as we can assist you in a cost effective and realistic way.

How the GDPR will protect individuals

How the GDPR will protect individuals

But it’s not only organisations that will have to pay closer attention to the way personal data is collected. Individuals’ new and strengthened rights under the GDPR will make them think about the way their data is being collected and used in a way they perhaps never have before.

People will be given more information

When the GDPR takes effect on 25 May 2018, individuals are going to be given frequent, in-depth and transparent notices from organisations looking to collect their data. This is because the Regulation strengthens people’s right to be informed and makes changes to consent requirements.

As the name suggests, the right to be informed requires organisations to tell individuals how their personal data will be used. Some organisations have already implemented this change with regards to cookie policies. Most sites have adopted soft opt-in consent, which presents users who visit a site for the first time with a notice that informs them of the organisation’s cookie policy. The notice remains prominently on the page until the user agrees to it or leaves the site.

Such notices will probably become standard practice online, meaning individuals will be regularly reminded of how much organisations rely on their data.

The same will be true of any data collection practice that relies on consent. All consent requests must be clear about people’s options to consent to different types of processing, and which organisations and third parties will be relying on their consent.

Consent requests must also meet other criteria, but, crucially, consent must be given with a clear affirmative action.

It’s worth noting that consent is only one of six lawful grounds for processing data, and it’s the least preferable for organisations. Therefore, organisations should only rely on it if none of the other grounds apply.

Individuals can communicate with organisations

The GDPR makes it easier for individuals to have their data rectified, restricted or erased. It enforces this through four rights.

The first is the right to object, in which individuals can contest:

  • Processing based on legitimate interests or the performance of a task in the public interest or through an official authority. If an individual contests this, the organisation must stop processing their data unless it can demonstrate compelling legitimate interests for the processing, or if the processing is for the establishment, exercise or defence of legal claims.
  • Processing for the purposes of direct marketing. If an individual objects, the organisation must stop processing their personal data immediately.
  • Processing for scientific or historical research and statistics. Individuals can only object to this type of processing if they have “grounds relating to his or her particular situation”.

The second is the right to rectification, which applies when the information an organisation holds is inaccurate or incomplete. Individuals are entitled to contact the organisation and request that this information be updated.

The third is the right to erasure (also known as the right to be forgotten), in which individuals can request that an organisation deletes the data it holds on them if:

  • It’s no longer needed for the purpose that it was originally collected;
  • There’s no overriding legitimate interest for continuing the processing;
  • The personal data was unlawfully processed;
  • The personal data must be erased to comply with a legal obligation; or
  • The personal data is processed for an information society service provided to a child.

If an individual consented to the processing of their data, they are entitled to withdraw that consent and therefore request the removal of any data that relied on that basis.

The fourth is the right to restrict processing. When processing is restricted, organisations can keep hold of the data, but they can no longer process it.

Individuals may exercise this right if they believe the data is inaccurate or they object to the processing on the grounds of legitimate interest or the performance of a public task. In these circumstances, processing should be suspended until the matter is resolved.

Individuals may also exercise this right if the processing is unlawful, but they prefer restriction to erasure, or if the organisation doesn’t need the personal data any more, but they require the data to establish, exercise or defend a legal claim.

GDPR 59 days before ALL organisations need to be able to prove compliance.

GDPR 59 days before ALL organisations need to be able to prove compliance.

Some people wrongly believe the GDPR regulation does not apply to SME’s, but it applies to any organisations that hold or process personal data as per the statement below:-

‘These rules apply for ALL organisations, including charities, churches and companies of ANY size, for example even a bed and breakfast. There are zero exceptions, which is why companies need to be able to PROVE they are compliant. Every company who has ANY names, email address’s or phones numbers (so any company, charity, church,  even a local children’s soccer club) need to comply.’

GDPR, Cross-border processing and the one stop shop

Cross-border processing and the one stop shop

For organisations

The GDPR provides a new mechanism, the one stop shop (OSS), that will be in place from 25 May 2018 for organisations that are established in the European Union and that are engaged in cross-border processing of personal data. Read this guide to learn more about the OSS, and how it will apply to your organisation.

Key Points

  • The OSS will allow your organisation to deal with a single lead supervisory authority (LSA) for most of your processing activities.
  • For the OSS to apply to your organisation, it must be established in the EU and be engaged in cross-border processing.
  • If your organisation is established in the EU and is engaged in cross-border processing, you should determine the location of your main establishment.
  • The supervisory authority of the EU Member State where your main establishment is located will be the lead supervisory authority (LSA) for your organisation’s processing activities.
  • Guidelines are available from the EU Article 29 Working Party to help you to identify your LSA (further information below).

About cross-border processing

The GDPR defines cross-border processing as either:

  • Processing of personal data which takes place in the context of the activities of an organisation in more than one Member State where that organisation is established in more than one Member State,
    or;
  • Processing of personal data which takes place in the context of the activities of an organisation’s single establishment but where that processing substantially affects or is likely to substantially affect data subjects in more than one Member State.

What is meant by ‘substantially affects’ will depend on the nature of the processing activities your organisation is engaged in. If necessary, your LSA will make a determination of what constitutes a substantial effect on a case by case basis.

You must engage in cross-border processing as described above for the OSS to be applicable to your organisation. If your organisation is not engaged in cross-border processing, the OSS will not apply.

Once you have confirmed that your organisation is engaged in cross-border processing, your next step will be to determine the location of your main establishment.

Where is my organisation’s main establishment?

The process you will follow to determine your main establishment differs depending on whether your organisation is a data controller or a data processor.

A data controller is defined as:

  • An organisation that determines, alone or jointly with others, the purposes and means of the processing of personal data.

A data processor is defined as:

  • An organisation that processes personal data on a data controller’s behalf.

The key to determining your main establishment if you are a data controller is to identify which of your organisation’s establishments has the power to take decisions on the purposes and means of your processing of personal data. This may be your place of central administration in the EU, but if your organisation takes these decisions at another establishment and that establishment has the power to have the decisions implemented, then the other establishment will be your main establishment.

If you are a data processor, your main establishment will be the location of your central administration in the EU unless your organisation does not have any central administration in the EU. If this is the case, the location where your organisation’s main processing activities take place will be your main establishment.

If your organisation is a joint controller with one or more other organisations, you should identify which establishment of the joint controllers has the power to take and implement decisions on the purposes and means of processing. That establishment will be the main establishment of the joint controllership.

If your organisation is part of a group of undertakings, the main establishment for the group will be the establishment where the entity that controls the group takes decisions on the purposes and means of the group’s processing.
If your organisation is engaged in a number of separate cross-border processing activities, it is possible that you will have more than one main establishment. You should not assume that all of your organisation’s cross-border processing activities will share the same main establishment.

This will be the case where decisions on the purposes and means of one processing activity are taken in the context of one establishment, while the decisions for a separate processing activity undertaken by the same organisation are taken in the context of a separate establishment.

The lead supervisory authority

The supervisory authority that will act as your LSA is the supervisory authority of the Member State where your organisation has its main establishment. Your LSA will have primary responsibility for dealing with your organisation’s processing activities and will be the supervisory authority that your organisation deals with in relation to its cross-border processing in most cases.

Your organisation’s engagement in cross-border processing means that supervisory authorities other than your LSA will also be concerned by your processing activities. Supervisory authorities, known in this context as supervisory authorities concerned (CSAs), will be concerned with your organisation’s processing activities where any of the following applies:

  • Your organisation is established in the Member State of that supervisory authority,
  • Data subjects residing in the Member State of that supervisory authority are substantially affected or are likely to be substantially affected by your organisation’s processing activities,
  • A complaint regarding your organisation’s processing activities has been lodged with that supervisory authority.

Should your LSA be required to investigate your organisation’s cross-border processing activities, it will do so according to the GDPR’s cooperation and consistency procedures. In such investigations, your LSA will closely coordinate with the relevant CSAs as appropriate.

In most cases, you will be required to deal only with your LSA. However, in certain circumstances, a CSA and not your LSA will be competent to handle a case regarding your organisation’s processing activities. A CSA may request to handle a case where the subject matter either:

  • Relates only to an establishment of your organisation in the CSA’s Member State,
    or;
  • Substantially affects data subjects only in the CSA’s Member State.

If CSAs have conflicting views on your main establishment, it is open to them to challenge this and refer to the European Data Protection Board, which will make a binding decision on where your organisation’s main establishment is.

Further information

The Article 29 Working Party has issued guidelines that will aid your organisation in identifying where your main establishment is and therefore who your LSA is. These guidelines can be found on the Working Party’s website: http://ec.europa.eu/newsroom/document.cfm?doc_id=44102

GDPR for individuals

GDPR for individuals

The General Data Protection Regulation (GDPR) from 25th May 2018 will replace current data protection laws in the European Union.

The new law will give individuals greater control over their data by setting out additional and more clearly defined rights for individuals whose personal data is collected and processed by organisations. The GDPR also imposes corresponding and greatly increased obligations on organisations that collect this data.

Personal data is any information that can identify an individual person. This includes a name, an ID number, location data (for example, location data collected by a mobile phone) or a postal address, online browsing history, images or anything relating to the physical, physiological, genetic, mental, economic, cultural or social identity of a person.

The GDPR is based on the core principles of data protection which exist under the current law. These principles require organisations and businesses to:

  • collect no more data than is necessary from an individual for the purpose for which it will be used;
  • obtain personal data fairly from the individual by giving them notice of the collection and its specific purpose;
  • retain the data for no longer than is necessary for that specified purpose;
  • to keep data safe and secure; and
  • provide an individual with a copy of his or her personal data if they request it.

Under the GDPR individuals have the significantly strengthened rights to:

  • obtain details about how their data is processed by an organisation or business;
  • obtain copies of personal data that an organisation holds on them;
  • have incorrect or incomplete data corrected;
  • have their data erased by an organisation, where, for example, the organisation has no legitimate reason for retaining the data;
  • obtain their data from an organisation and to have that data transmitted to another organisation (Data Portability);
  • object to the processing of their data by an organisation in certain circumstances;
  • not to be subject to (with some exceptions) automated decision making, including profiling.

Organisations and businesses collecting and processing personal data will be required to meet a very high standard in how they collect, use and protect data. Very importantly, organisations must always be fully transparent to individuals about how they are using and safeguarding personal data, including by providing this information in easily accessible, concise, easy to understand and clear language.

For organisations and businesses who breach the law, the Data Protection Commissioner is being given more robust powers to impose very substantial sanctions including the power to impose fines. Under the new law, the DPC will be able to fine organisations up to €20 million (or 4% of total global turnover) for the most serious infringements.

The GDPR will also permit individuals to seek compensation through the courts for breaches of their data privacy rights, including in circumstances where no material damage or financial loss has been suffered.

In the coming period further information will be provided here on the rights of individuals under the GDPR.

Data Protection Impact Assessments (DPIA)

Data Protection Impact Assessments (DPIA)

For Organisations

Data Protection Impact Assessments can be used to identify and mitigate against any data protection related risks arising from a new project, which may affect your organisation or the individuals it engages with. Read this guide to learn more about how and when to carry out a DPIA.

Key points

  • Under the GDPR, DPIAs will be mandatory for any new high risk processing projects.
  • The DPIA process will allow you to make informed decisions about the acceptability of data protection risks, and communicate effectively with the individuals affected.
  • Not all risks can be eliminated, but a DPIA can allow you to identify and mitigate against data protection risks, plan for the implementation of any solutions to those risks, and assess the viability of a project at an early stage.
  • If a DPIA does not identify mitigating safeguards against residual high risks, the Data Protection Commissioner must be consulted.
  • Good record keeping during the DPIA process can allow you to demonstrate compliance with the GDPR and minimise risk of a new project creating legal difficulties.

Contents

What is a Data Protection Impact Assessment?

When your organisation collects, stores or uses personal data, the individuals whose data you are processing are exposed to risks. These risks range from personal data being stolen or inadvertently released and used by criminals to impersonate the individual, to worry being caused to individuals that their data will be used by your organisation for unknown purposes. A Data Protection Impact Assessment (DPIA) describes a process designed to identify risks arising out of the processing of personal data and to minimise these risks as far and as early as possible. DPIAs are important tools for negating risk, and for demonstrating compliance with the GDPR.

This document assumes that a DPIA will be conducted for a defined project, rather than for an organisation’s operations as a whole. A particular function of your organisation, or a programme of changes to your organisation’s operations as a whole, may be viewed as a project.

What are the benefits of conducting a DPIA?

Conducting a DPIA will improve awareness in your organisation of the data protection risks associated with a project. This will help to improve the design of your project and enhance your communication about data privacy risks with relevant stakeholders. Some of the benefits of conducting a DPIA are as follows:

  • Ensuring and demonstrating that your organisation complies with the GDPR and avoids sanctions.
  • Inspiring confidence in the public by improving communications about data protection issues.
  • Ensuring your users are not at risk of their data protection rights being violated.
  • Enabling your organisation to incorporate “data protection by design” into new projects.
  • Reducing operation costs by optimising information flows within a project and eliminating unnecessary data collection and processing.
  • Reducing data protection related risks to your organisation.
  • Reducing the cost and disruption of data protection safeguards by integrating them into project design at an early stage.

Data Protection by design means embedding data privacy features and data privacy enhancing technologies directly into the design of projects at an early stage. This will help to ensure better and more cost-effective protection for individual data privacy.

Data Protection by default means that service settings must be automatically data protection friendly.
While long recommended as good practice, both of these principles are enshrined in law under the GDPR (Article 25).

How do I know if a DPIA should be conducted?

Under the GDPR, a DPIA is mandatory where data processing “is likely to result in a high risk to the rights and freedoms of natural persons.” This is particularly relevant when a new data processing technology is being introduced. In cases where it is not clear whether a DPIA is strictly mandatory, carrying out a DPIA is still good practice and a useful tool to help data controllers comply with data protection law.

The GDPR provides some non-exhaustive examples of when data processing is “likely to result in high risks”:

  • “a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person”
  • “processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10”
  • “a systematic monitoring of a publicly accessible area on a large scale”

The Article 29 Working Party, consisting of the representatives from each data protection authority in the EU, has published guidelines on DPIAs and whether processing is likely to result in a high risk for the purposes of the GDPR. The guidelines were recently subject to public consultation and it is anticipated that the final text will be adopted at the next meeting of the Working Party. The guidelines are available at http://ec.europa.eu/newsroom/just/item-detail.cfm?item_id=50083. In assessing whether processing is likely to result in a high risk the Article 29 Working Party has set forth the following criteria to consider:

  1. Evaluation or scoring, including profiling and predicting, especially “from aspects concerning the data subject’s performance at work, economic situation, health, personal preferences or interests, reliability or behaviour, location or movements” (recitals 71 and 91). Examples of this could include a bank that screens its customers against a credit reference database, or a biotechnology company offering genetic tests directly to consumers in order to assess and predict the disease/health risks, or a company building behavioural or marketing profiles based on usage or navigation on its website.
  2. Automated decision making with legal or similar significant effect: processing that aims at taking decisions on data subjects producing “legal effects concerning the natural person” or which “similarly significantly affects the natural person” (Article 35 (3)(a)). For example, the processing may lead to the exclusion or discrimination against individuals. Processing with little or no effect on individuals does not match this specific criterion.
  3. Systematic monitoring: processing used to observe, monitor or control data subjects, including data collected through “a systematic monitoring of a publicly accessible area” (Article 35 (3)(c)). This type of monitoring is a criterion because the personal data may be collected in circumstances where data subjects may not be aware of who is collecting their data and how they will be used. Additionally, it may be impossible for individuals to avoid being subject to such processing in frequent public (or publically accessible) space(s).
  4. Sensitive data: this includes special categories of data as defined in Article 9 (for example information about individuals’ political opinions), as well as personal data relating to criminal convictions or offenses. An example would be a general hospital keeping patients’ medical records or a private investigator keeping offenders’ details. This criterion also includes data which may more generally be considered as increasing the possible risk to the rights and freedoms of individuals, such as electronic communication data, location data, financial data (that might be used for payment fraud). In this regard, whether the data has already been made publically available may be considered as a factor in the assessment if the data was expected to be further used for certain purposes. This criterion may also include information processed by a natural person in the course of purely personal or household activity (such as cloud computing services for personal document management, email services, diaries, e-readers equipped with note taking features, and various life-logging applications that may contain very personal information), whose disclosure or processing for any other purpose than household activities can be considered as very intrusive.
  5. Data processed on a large scale: the GDPR does not define what constitutes large-scale, though recital 91 provides some guidance. In any event, the WP29 recommends that the following factors, in particular, be considered when determining whether the processing is carried out on a large scale:
    1. The number of data subjects concerned, either as a specific number or as a proportion of the relevant population
    2. The volume of data and/or the range of different data items being processed
    3. The duration, or permanence, of the data processing activity
    4. The geographical extent of the processing activity
  6. Datasets that have been matched or combined, for example originating from two or more data processing operations performed for different purposes and/or by different data controllers in a way that would exceed the reasonable expectations of the data subject.
  7. Data concerning vulnerable data subjects (recital 75): the processing of this type of data can require a DPIA because of the increased power imbalance between the data subject and the data controller, meaning the individual may be unable to consent to, or oppose, the processing of his or her data. For example, employees would often meet serious difficulties to oppose to the processing performed by their employer, when it is linked to human resources management. Similarly, children can’t be considered as not able to knowingly and thoughtfully oppose or consent to the processing of their data. This also concerns more vulnerable segments of the population requiring special protection, such as, for example, the mentally ill, asylum seekers, or the elderly, a patient, or in any case where an imbalance in the relationship between the position of the data subject and the controller can be identified.
  8. Innovative use or applying technological or organisational solutions, like combining use of finger print and face recognition for improved physical access control, etc. The GDPR makes it clear (Article 35(1) and recitals 89 and 91) that use of a new technology can trigger the need to carry out a DPIA. This is because the use of a new technology can involve novel forms of data collection and usage, possibly with a high risk to individuals’ rights and freedoms. Indeed, the personal and social consequences of the deployment of a new technology may be unknown. A DPIA will help the data controller to understand and to treat such risks. For example, certain “Internet of Things” applications could have a significant impact on individuals’ daily lives and privacy; and therefore require a DPIA.
  9. Data transfer across borders outside the European Union (recital 116), taking into consideration, amongst others, the envisaged country or countries of destination, the possibility of further transfers, or the likelihood of transfers based on derogations for specific situations set forth by the GDPR.
  10. When the processing in itself “prevents data subjects from exercising a right or using a service or a contract” (Article 22 and recital 91). This includes processings performed in a public area that people passing by cannot avoid, or processings that aims at allowing, modifying or reusing data subjects’ access to a service or entry into a contract. An example of this is where a bank screens its customers against a credit reference database in order to decide whether to offer them a loan.

The Working Party considers that the more criteria are met by the processing, the more likely it is to present a high risk to the rights and freedoms of data subjects, and therefore to require a DPIA. As a rule of thumb, a processing operation meeting less than two criteria may not require a DPIA due to the lower level of risk, and processing operations which meet at least two of these criteria will require a DPIA. If the controller believes that a processing operation which meets at least two of these criteria is not likely to be high risk, the controller should thoroughly document the reasons for not carrying out a DPIA.

When is a DPIA not required?

A DPIA is generally not required in the following cases:

  • Where the processing is not “likely to result in a high risk to the rights and freedoms of natural persons”(article 35(1))
  • When the nature, scope, context and purposes of the processing are very similar to the processing for which DPIAs have been carried out. In such cases, results of a DPIA for similar processing can be used (Article 35(1))
  • Where a processing operation has a legal basis in EU or Member State law and has stated that an initial DPIA does not have to be carried out, where the law regulates the specific processing operation and where a DPIA, according to the standards of the GDPR, has already been carried out as part of the establishment of that legal basis (Article 35(10))
  • Where the processing is included on the optional list (established by the supervisory authority) of processing operations for which no DPIA is required (Article 35(5)). Such a list may contain processing activities that comply with the conditions specified by this authority, in particular through guidelines, specific decisions or authorisations, compliance rules, etc. In such cases, and subject to reassessment by the competent supervisory authority, a DPIA is not required, but only if the processing falls strictly within the scope of the relevant procedure mentioned in the list and continues to comply fully with the relevant requirements.

Is a DPIA mandatory for existing processing operations, existing before the GDPR becomes effective on the 25th May 2018?

The GDPR is effective from the 25th May 2018, and DPIAs are legally mandatory only for processing operations that are initiated after this date. Nevertheless, the Article 29 Working Party strongly recommends carrying out DPIAs for all high risk operations prior to this date. Indeed a DPIA can be a powerful tool in ensuring that any operations commencing now will not leave you at risk of non-compliance once the law changes on the 25th May 2018, and save your organisation from operational disruption by allowing you to future proof new projects against the GDPR at an early stage.

Additionally, new DPIAs or reviews of DPIAs for existing processing that commenced before the 25th May 2018 may be required after that date in the following circumstances:

  • Where a significant change to the processing operation has taken place after the GDPR takes effect. For example, when a new technology comes into use, or when data is being used for a different purpose. In these cases the processing is effectively a new operation and could require a DPIA.
  • When there is a change of the risk presented by the processing operation. The risks and level of risk can change as a result of a change to one of the components of the processing operation (data, supporting assets, risk sources, etc.), or because the context of the processing evolves (purpose, functionalities, etc.). Data processing systems can evolve over time, and new threats and vulnerabilities can arise.
  • The organisational or societal context for the processing activity has changed, for example because the effects of certain automated decisions have become more significant, new categories of natural persons become vulnerable to discrimination or the data is intended to be transferred to data recipients located in a country which has left the EU.

As a matter of good practice, the Article 29 Working Party recommends that all DPIAs should be re-assessed after 3 years, or sooner if circumstances have changed quickly.

When in a project lifecycle should a DPIA be conducted?

The DPIA should be carried out “prior to the processing” (GDPR Articles 35(1) and 35(10), recitals 90 and 93). It is generally good practice to carry out a DPIA as early as practical in the design of the processing operation. It may not be possible to conduct a DPIA at the very inception of the project, as project goals and some understanding of how the project will operate must be identified before it will be possible to assess the data protection risks involved.

For some projects the DPIA may need to be a continuous process, and be updated as the project moves forward. The fact that a DPIA may need to be updated once processing has actually started is not a valid reason for postponing or not carrying out a DPIA.

Who should be involved in conducting the DPIA?

The Data Controller is responsible for ensuring the DPIA is carried out. It may be delegated to someone else, inside or outside the organisation, but the Data Controller is ultimately accountable.

The DPIA should be driven by people with appropriate expertise and knowledge of the project in question, normally the project team. If your organisation does not possess sufficient expertise and experience internally, or if a particular project is likely to hold a very high level of risk or affect a very large number of people, you may consider bringing in external specialists to consult on or to carry out the DPIA.

A wide internal consultation process can benefit the DPIA, as some data protection risks will only be apparent to individuals working on specific aspects of the project. It will also allow you to gain feedback from those whose work will be affected by the project after implementation, such as engineers, designers and developers, who will have a practical knowledge of the operations. Involving your organisations Public Relations team will allow for effective communication of the DPIA’s outcomes to external stakeholders.

Under the GDPR (Article 35), it is necessary for any Data Controller with a designated Data Protection Officer (DPO) to seek the advice of the DPO. This advice and the decisions taken should be documented as a part of the DPIA process. If a Data Processor is involved in the processing, the

  • The Data Protection Officer (DPO) is a designated person appointed by an organisation to advise on data protection practices within the organisation. The DPO can be a staff member or an external service provider. Under the GDPR, appointment of a DPO is mandatory in the following circumstances:
  • For public bodies carrying out data processing, except for courts acting in their judicial capacity;
  • If the core activities of the organisation consist of data processing which, by virtue of their scope and/or purposes, require regular and systematic monitoring of data subjects on a large scale;
  • The core activities of the organisation consist of processing on a large scale of special categories of data as outlined in Article 9 or personal data relating to criminal convictions as outlined in Article 10 of the GDPR.
  • Data Processor should assist with the DPIA and provide any necessary information.

The Data Controller is bound to “seek the views of data subjects or their representatives” (Article 35(9)), “where appropriate” in carrying out the DPIA. In some cases, the data subjects may be people within the organisation. Seeking the views of Data Subjects will allow the Data Controller to understand the concerns of those who may be affected, and to improve transparency by making individuals aware of how their information will be used.

The views of Data Subjects can be sought through a variety of means, depending on the context. Staff could be consulted through a trade union; customers could be consulted by means of a survey. If the Data Controller’s final decision differs from the views of Data Subjects, the reasons should be recorded as a part of the DPIA. If the Data Controller does not feel it appropriate to seek the views of Data Subjects, the justification for this should be documented.

What steps are involved in carrying out a DPIA?

The GDPR sets out the minimum features of a DPIA (Article 35(7), and recitals 84 and 90):

  • “a description of the envisaged processing operations and the purposes of the processing”
  • “an assessment of the necessity and proportionality of the processing”
  • “as assessment of the risks to the rights and freedoms of data subjects”
  • “the measures envisaged to:
    • “address the risks”;
    • “demonstrate compliance with this Regulation”.

The GDPR presents a broad, generic framework for designing and carrying out a DPIA. This allows for scalability, so even the smallest Data Controllers can design and implement a DPIA; as well as for flexibility, so the Data Controller can determine the precise structure and form of the DPIA, allowing it to fit with existing working practices.

Key elements of a successful DPIA

The GDPR does not prescribe the exact process for carrying out a DPIA beyond the minimum features outlined above, allowing for flexibility and scalability in line with your organisation’s needs. Although there is no one prescribed approach to take, the following steps can guide you through the process:

  1. Identifying whether a DPIA is required
  2. Defining the characteristics of the project to enable an assessment of the risks to take place
  3. Identifying data protection and related risks
  4. Identifying data protection solutions to reduce or eliminate the risks
  5. Signing off on the outcomes of the DPIA
  6. Integrating data protection solutions into the project

1. Identifying whether a DPIA is required

You can use the steps described in the above section “How do I know if a DPIA is required” to assess if you need to perform a DPIA. This should take place as early as practicable in the lifecycle of the project. You will also need to identify the resources needed, the individuals who will be involved, and the timeframe of the DPIA process.

As the nature and operational implications for data privacy of a project may not be apparent at an early stage in the planning, the DPIA may need to be an ongoing process, and may need to be reviewed or repeated as the project moves forward.

2. Describing the information flows

At an early point in the DPIA project, you should identify how it is intended to collect, store, use and delete personal information as part of the project. This exercise should also identify what kinds of information will be used as part of the project and who will have access to the information.

The aim of this step is to get an early understanding of how information will be used as part of a project at each step along the process. This is crucial to being able to recognise the data privacy risks which may be posed by a project and to identifying what means might be used to mitigate those risks.

You should consider if any new personal information will be generated by the project, and include it in your record of this stage. For example, a project involving the processing of psychometric tests might take one type of personal information (the answers to psychometric test questions) and process it to another (a psychometric profile). This new type of personal information is different in character, and so recording it separately in your map of information flows will help to ensure that its special characteristics are taken account of later in the DPIA process.

This part of the DPIA will often mirror other elements of your project design process, such as a general scoping exercise to identify how the project will be carried out, and can be integrated with such a scoping exercise. Paying attention in the design of a project to how information will be used as part of the project may also yield efficiency benefits for your organisation by assisting you in streamlining processes for handling information.

At this stage of the DPIA process, you should consult with internal stakeholders with a view to identifying the technical aspects of information collection, storage and processing, and how the different elements of the project will fit together in operation. You may also want to consult with external partners, who may be engaged by your organisation as a data processor, or to whom information might be disclosed as part of a project.

This exercise should be documented using whatever means are most suitable for your organisation and the project concerned. Using visual aids, such as flow charts, to document how information will be used as part of a project can assist in identifying potential data privacy risks. This may also help with internal communication by better allowing the project team and others in your organisation to understand the design of the project.

This stage involves examining the project design to assess what data protection issues arise in the project, and to identify any risks it may expose individuals to, as well as any data protection-related risks that the project might create for your organisation.

There are a range of different ways that an individual’s data privacy can be compromised or put at risk by a new project. The types of risk range from the risk of causing distress, upset or inconvenience to risks of financial loss or physical harm. There are equally as many kinds of data privacy-related risks to organisations, related to compliance issues and commercial factors. Breaches of the GDPR, such as excessive data processing or data breaches, can lead to significant penalties, as well as causing reputational damage to your organisation.

This step should build upon work done at previous stages of the DPIA. The responses to the criteria laid out in the above section “How do I know if a DPIA should be conducted” should act as a guide to the risks which may be present. The map of information flows generated in stage 2 may help you to identify particular weak spots, where general data privacy risks are likely to be particularly acute, or which might give rise to specific risks.

For public sector bodies contemplating data processing measures that limit the EU fundamental right to data protection under Article 8 of the EU Charter of Fundamental Rights, a detailed analysis of the ‘necessity’ of the measure must be undertaken. Guidance published by the European Data Protection Supervisor will assist public sector policy makers in conducting the necessary analysis. The EDPS guidance is available at https://edps.europa.eu/sites/edp/files/publication/17-06-01_necessity_toolkit_final_en_0.pdf

Examples of the types of risks that you should be alert for at this stage of the DPIA process are outlined below. You should also examine sector-specific guidance which may be provided by regulators or industry groups in your area of operations, which can highlight types of risk which may be relevant for your organisation or project.

You should take note of the magnitude of the risks identified, having regard to both the likelihood of a risk manifesting itself, and its impact. In assessing the severity of the risk, it is important to bear in mind the sensitivity of the personal data to be processed as part of the project, the number of people likely to be affected by any of the risks identified, and how they might be affected.

You should keep a record of all risks identified at this stage. This will assist later on in the DPIA process in creating solutions to avoid or reduce those risks. Record keeping may be especially important in the event of an investigation or audit by the DPC. Good record keeping may help to demonstrate how your organisation complied with its obligations under the GDPR.

This identification exercise should be carried out relatively early in the project design, as the sooner that data privacy risks can be identified, the easier and cheaper it will be to mitigate them. However, it is not a once-and-for-all exercise; you should keep the project design under review throughout the DPIA process to monitor the emergence of any new risks, which may occur by reason of a change to the design or scope of the project, and to assist in assessing which risk reduction techniques work.

Your organisation can choose the risk management approach that best suits your existing project management process. The same tools you use for identifying other regulatory or commercial risks as part of your project management process can be used to assess the data protection risks involved in a project. The key point is to ensure that a methodological approach to identifying risks is adopted, and that records are kept of this process, and of all the risks identified. Your organisation may wish to maintain a data protection risk register to describe the risks associated with a project and assess their likelihood and impact. You can then go back to the register in the event of any changes to the project, to make note of any steps taken to mitigate risk, or any additional risks that emerge. This can be incorporated into an existing risk register if one exists for the project. Small scale projects may adopt a relatively informal approach to risk. You can still use a data protection risk register in such cases, but with the entries reflecting the less formal approach adopted.

Data Protection risk register is a master document that is used to record information about data protection risks which have been identified in relation to a particular project, as well as an analysis of risk severity and evaluations of the possible solutions to be applied.

The data protection risk register should be updated as the project progresses, to reflect any solutions or new risks which have been identified.

Example Risks To Individuals

  • Inappropriate disclosure of personal data internally within your organisation due to a lack of appropriate controls being in place.
  • Accidental loss of electronic equipment by organisation’s personnel may lead to risk of disclosure of personal information to third parties.
  • Breach of data held electronically by “hackers”.
  • Vulnerable individuals or individuals about whom sensitive data is kept might be affected to a very high degree by inappropriate disclosure of personal data.
  • Information released in anonymised form might lead to disclosure of personal data if anonymisation techniques chosen turn out not to be effective.
  • Personal data being used in a manner not anticipated by data subjects due to an evolution in the nature of the project.
  • Personal data being used for purposes not expected by data subjects due to failure to explain effectively how their data would be used.
  • Personal data being used for automated decision making may be seen as excessively intrusive.
  • Merging of datasets may result in a data controller having far more information about individuals than anticipated by the individuals.
  • Merging of datasets may inadvertently allow individuals to be identified from anonymised data.
  • Use of technology capable of making visual or audio recordings may be unacceptably intrusive.
  • Collection of data containing identifiers may prevent users from using a service anonymously.
  • Data may be kept longer than required in the absence of appropriate policies.
  • Data unnecessary for the project may be collected if appropriate policies not in place, leading to unnecessary risks.
  • Data may be transferred to countries with inadequate data protection regimes.

Corporate Risks

  • Failure to comply with the GDPR may result in investigation, administrative fines, prosecution, or other sanctions. Failure to adequately conduct a DPIA where appropriate can itself be a breach of the GDPR.
  • Data breaches or failure to live up to customer expectations regarding privacy and personal data are likely to cause reputational risk.
  • Public distrust of your organisation’s use of personal information may lead to a reluctance on the part of individuals to deal with your organisation.
  • Problems with project design identified late in the design process, or after completion, may be expensive and cumbersome to fix.
  • Failure to manage how your company keeps and uses information can lead to inefficient duplication, or the expensive collection and storage of unnecessary information. Unnecessary processing and retention of information can also leave you at risk of non-compliance with the GDPR.
  • Any harm caused to individuals by reason of mishandling of personal data may lead to claims for compensation against your organisation. Under the GDPR you may also be liable for non-material damage.

Compliance Risks

Your organisation may face risks of prosecution, significant financial penalties, or reputational damage if you fail to comply with the GDPR. Individuals affected by a breach of the GDPR can seek compensation for both material and non-material damage.

Failure to carry out a DPIA where appropriate is itself a breach of the legislation, as well as a lost opportunity to identify and mitigate against the future compliance risks a new project may bring.

4. Identifying and evaluating data protection solutions

This stage follows on from the identification of data protection risks at stage 3, with the aim of minimising the data privacy risk associated with the project, insofar as possible. In almost all cases, it will not be possible to eliminate data protection risks completely, but the aim of this stage is to balance those risks against the aims of the project, to ensure that any risks that are accepted are proportionate to the outcomes of the project. However, under GDPR, if there are remaining high risks, then you will need to consult with the Data Protection Commissioner, as described below.

Data Protection solutions are steps which may be taken to reduce the likelihood or severity of data privacy risks being realised.

During this stage, you should try to identify “data protection solutions” to reduce the impact of the project on data protection. You should do this by looking at each of the risks identified as part of the previous stage in the DPIA process and seeking to address it individually, or as part of a privacy solution which may address a number of risks together.

In some cases, data protection solutions may be able to eliminate some types of risk, for example by abandoning unnecessary parts of a project which create unique risks. In others, data protection solutions may simply mitigate against risk or reduce the significance of data breaches, for example by adopting pseudonymisation to reduce the risk of identification of data subjects. The nature of these solutions will depend on the types of risk that have been identified, and the aims of the project. You should keep a full record of the process, to document any data protection solutions which have been identified, and which risks they were intended to address, as well as any risks which have been accepted. This can be done in a data protection risks register created under step 3.

This step involves conducting a balancing exercise between the benefits to individuals and your organisation from the project, and the data protection and related risks to those individuals and your organisation. Equally, in assessing whether a particular data protection solution should be pursued, it is necessary to weigh up the costs and benefits of each solution. For example, anonymising data may help to prevent the risk of data relating to an identifiable person being accidentally disclosed to a third party, but it is likely to cost the organisation money to put an anonymisation system in place, and it may prevent some of the goals of the project from being realised (if those goals depend on processing information about identified individuals).

Every project will have its own unique circumstances and risk profile, so there is no “one size fits all” set of data privacy solutions which may be adopted. However, the following are examples of data protection solutions, some of which may be applied in a range of different scenarios:

  • Deciding not to collect or store particular types of information.
  • Putting in place strict retention periods, designed to minimise the length of time that personal data is retained.
  • Reviewing physical and/or IT security in your organisation or for a particular project team and making appropriate improvements where necessary.
  • Conducting general or project-specific training to ensure that personal data is handled securely.
  • Creating protocols for information handling within the project, and ensuring that all relevant staff are trained in operating under the protocol.
  • Producing guidance for staff as reference point in the event of any uncertainty relating to the handling of information.
  • Assessing the need for new IT systems to safely process and store the data, and providing staff with training in any new system adopted.
  • Assessing the portability of using anonymised or pseudonymised data as part of the project to reduce identification risks, and developing an appropriate anonymisation protocol if the use of anonymised data is suitable.
  • Ensuring that individuals are fully informed about how their information will be used.
  • Providing a contact point for individuals to raise any concerns they may have with your organisation.
  • If you are using external data processors, selecting appropriately experienced data processors and putting in place legal arrangements to ensure compliance with data protection legislation.
  • Deciding not to proceed with a particular element of a project if the data privacy risks associated with it are inescapable and the benefits expected from this part of the project cannot justify those risks.

In most cases, there are some data protection risks which cannot be eliminated or reduced. These risks can be accepted if they are proportionate to the outcomes that will be achieved by proceeding with the project notwithstanding the risk. Any decisions to accept data protection risks should be recorded in the data protection risk register, or otherwise in accordance with your project management process.

At this stage, you should also ensure that the project will be in compliance with data protection laws. In particular, you should consider whether the project complies with the data protection principles, and ensuring that you have a good legal basis for processing personal data.

5. Signing off and recording the DPIA outcomes

The primary aim of conducting a DPIA is to identify and minimise the data protection risks involved in a project. However, as has been emphasised throughout this guide, keeping a record of all steps taken as part of the DPIA will help to ensure that the process is completed thoroughly, and to reassure stakeholders that all data protection risks have been considered. This written record should also form that basis of putting into effect the data protection solutions which have been identified, and can be used to check off the implementation of each solution.

There is no requirement to produce a final DPIA report but it is good practice to do so. This report should bring together, in summary form, the record keeping from each stage of the DPIA process and note the conclusions from each step of the process. It should also include an overview of the project, explaining why it was undertaken and how it will impact on data protection. It should describe the process adopted in conducting the DPIA, and set out the data protection risks and solutions which were identified as part of the process. Your organisation may decide to publish the DPIA report or a summary of it. The decision of whether or not to publish the report will probably have a bearing on how much detailed information is put into the report, as it may not be appropriate to publish commercially sensitive information or information containing too much detail about security vulnerabilities which have been identified.

A DPIA does not necessarily require a formal signing-off process, but your organisation may require it, particularly if it recommends significant changes to the nature of a project, or if it recommends accepting significant risks.

If the data privacy risks which have been identified are not capable of mitigation consistent with the goals of a project, and it would not be proportionate to accept them, this stage should be used for re-evaluating the viability of the project. In such circumstances, an organisation may decide to either change the goals of a project to allow for mitigation of data protection risks, or abandon the project altogether.

6. Integrating the DPIA outcomes back into the project plan

Once it has been signed off, it is necessary to put the findings of the DPIA into action by integrating any necessary changes into the plans for the project. The earlier the DPIA can be completed, the easier it will be to give effect to the data privacy solutions, but as the DPIA will not normally be completed until the project has already progressed somewhat in the planning stages, it will normally be necessary to adjust plans to give effect to the data privacy solutions identified.

As part of the implementation of the DPIA, you should keep data protection issues under review. In particular, you should assess whether the data protection solutions implemented are having the intended effect of mitigating data protection risks. Additionally, if the project aims change or expand over its lifetime, it may be necessary to assess whether a further DPIA is required to assess the effect of the changes on the data protection risks identified. Such a review can be built into your organisation’s existing procedures.

Consulting with the Data Protection Commissioner and publishing the DPIA

Should the Data Protection Commissioner be consulted on completion of the DPIA?

If, during the DPIA process, the Data Controller has identified and taken measures to mitigate any risks to personal data, it is not necessary to consult with the DPC before proceeding with the project.

If the DPIA suggests that any identified risks cannot be managed and the residual risk remains high, you must consult with the Data Protection Commissioner before moving forward with the project.

Regardless of whether or not consultation with the DPC is required, your obligations of retaining a record of the DPIA and updating the DPIA in due course remain.

Even if consultation is not required, the DPIA may be reviewed by the DPC at a later date in the event of an audit or investigation arising from your use of personal data.

Should the DPIA be published?

It is not legally mandatory to publish the DPIA. However, there are a number of benefits to doing so. Publishing the DPIA can help to foster trust in your handling of personal data, and demonstrate accountability and transparency, particularly where members of the public are affected. This may be especially beneficial for DPIAs carried out by public bodies.

The published DPIA does not need to contain the whole assessment, especially when the DPIA could present information concerning security risks or commercially sensitive information. It could even consist of just a summary of the DPIA’s main findings.

Some of the key features of GDPR

 Awareness

As an organisation you must ensure you are aware of the changes ahead and what they will mean for you.

  • Obtain Board and Senior Management Team support. This is no longer an area that can be the responsibility of one individual. Board level engagement is essential.
  • Consider the resource and procedural implications of putting in place robust and effective data governance for your organisation.
  • Privacy and data security are now part of corporate risk management. Add GDPR to your organisation’s risk register.
  • Task key people with keeping up to date with developments and make sure they are at an appropriate level of seniority and adequately resourced.
  • Run awareness sessions to ensure all staff are aware and up to date with the changes GDPR will bring to the organisation.

 Consent

The GDPR considers consent an important part of ensuring individuals have control and an understanding of how their data are to be processed.

  • Consent must be:
    • Freely given
    • Specific
    • Informed
    • Unambiguous
  • There has to be a positive indication of agreement.
  • Consent as a basis for processing gives individuals stronger rights.
  • Data controllers must be able to evidence consent was given.
  • Parental consent to process children’s† data on the internet.

 Wider Scope

The GDPR will impact new and far reaching areas both geographically and procedurally. More organisations will be captured by the requirements and more data processing will be encompassed by the definitions.

  • Data Processors come under the remit of the GDPR and will have specific compliance obligations.
  • Organisations outside the EU, targeting EU citizens by offering goods or services or monitoring their behaviour will need to comply with GDPR.
  • If you have an EU presence or process data on EU citizens, you may need to nominate a representative in a Member State.

 Individual’s Rights

Individual’s rights are enhanced and extended in a number of important areas. They include:

  • A right of access to data (Subject Access);
  • A right for the correction of data where inaccuracies have been identified;
  • A right to require the erasure of personal data (often referred to as the ‘right to be forgotten’);
  • A right to prevent direct marketing;
  • Control over automated decision making & profiling;
  • A right to data portability between controllers.

 Subject Access Requests

As the GDPR captures more information within the definition of personal data, you must prepare ahead for access requests. Your records management systems and processes, both electronic and paper based, must be consciously designed to support the efficient discovery of information noting that:

  • In most circumstances no fee can be charged;
  • A response must be provided within 1 month;
  • More information is required to be provided including data retention periods & rights to have data corrected;
  • Policies & procedures will need to be in place to govern refusing requests.

 Privacy Notices

Empowering individuals by being transparent and clear about how their data are going to be processed, and by whom, is a key element of compliance with the GDPR. At every point at which personal data are collected, whether that is from your clients, staff or others, review how you intend to provide the following at the time of collection:

  • Purpose of and legal basis for processing;
  • Recipients of the data;
  • Any third countries data are transferred to and safeguards in place;
  • Data retention periods;
  • The existence of individual’s rights;
  • Right to withdraw consent where provided;
  • Data Protection Officer’s contact details;
  • Whether data provision has statutory or contractual basis;
  • Details where the legitimate interest condition has been relied upon.

 Privacy By Design, DPIAs

The GDPR places much more emphasis on building in effective data protection practices and safeguards from the very beginning of all processing.

  • Data protection must be considered early on in projects involving data
  • Data Protection Impact Assessments (DPIA) are best practice and likely to be mandatory in some circumstances such as
    • Decisions that produce legal effects
    • Processing of special category data e.g. health data
    • Monitoring of publicly accessible areas

Ensure such processes become routine and well documented. As business models and processes change and evolve, so too do compliance needs. Regular reviews are therefore essential and should be proactively managed and recorded.

? What, Where, Why, How

A detailed understanding of your own data processing underpins the accountability aspect of the GDPR. Any effective data governance strategy has to begin with a comprehensive data audit so ensure you have detailed and documented answers to the following key questions:

  • Whatpersonal data do you hold? Do you hold any special category data?
  • Whereis it from and where is it sent?
  • Whyis it processed? For what purpose?
  • Howis the processing lawful and fair? Which of the conditions is met? Have you provided individuals with details about the processing of their data, including reference to the rights they have?

 Data Protection Officers (DPOs)

Getting ready for the GDPR requires multidisciplinary skills and approach. Identifying and supporting a member of your staff with responsibility for data protection compliance may be a mandatory requirement for your organisation. But even if it is not, having someone in place undertaking that role will be beneficial to your organisation.

The DPO role will require a solid understanding of the way your organisation operates, and a skill set that stretches well beyond an understanding of legal compliance. It must include IT, cyber and data security, strategy, communication, risk management etc and ensure they keep up to date with all of these skillsets and the latest training/certification available.

The GDPR is clear that such a role should be appropriately senior and autonomous. They will be expected to be the front-face of data protection for your organisation which will necessarily include dealing with data subjects and the Data Protection Authority.

  • DPOs likely to be mandatory for:
    • Public authorities.
    • Organisations involved in high risk processing.
    • Organisations processing special categories of data in large volumes.
  • DPO must be suitably experienced and skilled.
  • Has set tasks including:
    • Inform & advise organisation of obligations.
    • Monitor compliance including awareness raising, staff training, audits.
    • Cooperate with Data Protection Authority and act as contact point for data subject and data commissioner.
  • Can be shared with other organisations or have other functions too but none that conflict with day to day operations/IT.
  • Even if not mandated for your organisation, the EU is still encouraging organisations are to appoint a DPO as a sign of their commitment to data protection, data security and GDPR compliance, some customers are also looking for this are part of their risk and compliance projects.
  • In Germany for example it is mandatory for organisations of more than 20 staff to have a DPO and generally this is outsourced by SME’s because of the wide ranging and specialist skillset.

 Penalties And Data Breaches

The GDPR provides for a tougher enforcement approach by the Data Protection Authority including the ability to impose significant fines.

  • Data breaches must be reported to Data Protection Authority within 72 hours of discovery
  • Individuals impacted should be told where there exists a high risk to their rights and freedoms e.g. identity theft, personal safety
  • Fines can be issued up to €20 million or 4% of global annual turnover
  • Data Protection Authority can issue reprimands, warnings and bans as well as fines.

The level of fine is likely to be dependent on a number of factors including:

  • Nature, gravity and duration including categories of data;
  • Intentional or negligent;
  • Action taken to mitigate damage;
  • Security and Privacy by Design measures;
  • Degree of co-operation;
  • How Data Protection Authority found out;
  • Previous enforcement activity;
  • Other aggravating or mitigating factors.

It is essential for data protection to be integrated into corporate risk management for your organisation. Consider how you will manage breach reporting both internally and in respect of your obligations to the Data Protection Authority. If you use a data processor, be clear about your expectations in respect of breach management and ensure these expectations are incorporated into the relevant contracts.

GDPR 12 Steps

GDPR 12 Steps

Note:- Compliance with existing data protection laws is assumed in these steps.

Becoming Aware

It is imperative that key personnel in your organisation are aware that the law is changing to the GDPR and start to factor this into their future planning. They should start to identify areas that could cause compliance problems under the GDPR. Initially, data controllers should review and enhance their organisation’s risk management processes, as implementing the GDPR could have significant implications for resources; especially for more complex organisations. Any delay in preparations may leave your organisation susceptible to compliance issues following the GDPR’s introduction.

Becoming Accountable

Make an inventory of all personal data you hold and examine it under the following headings:

  • Why are you holding it?
  • How did you obtain it?
  • Why was it originally gathered?
  • How long will you retain it?
  • How secure is it, both in terms of encryption and accessibility?
  • Do you ever share it with third parties and on what basis might you do so?

This is the first step towards compliance with the GDPR’s accountability principle, which requires organisations to demonstrate (and, in most cases, document) the ways in which they comply with data protection principles when transacting business. The inventory will also enable organisations to amend incorrect data or track third-party disclosures in the future, which is something that they may be required to do.

3Communicating with Staff and Service Users

Review all current data privacy notices alerting individuals to the collection of their data. Identify any gaps that exist between the level of data collection and processing your organisation engages in, and how aware you have made your customers, staff and services users of this fact. If gaps exist, set about redressing them using the criteria laid out in ‘2: Becoming Accountable’ as your guide.

Before gathering any personal data, current legislation requires that you notify your customers of your identity, your reasons for gathering the data, the use(s) it will be put to, who it will be disclosed to, and if it’s going to be transferred outside the EU.

Under the GDPR, additional information must be communicated to individuals in advance of processing, such as the legal basis for processing the data, retention periods, the right of complaint where customers are unhappy with your implementation of any of these criteria, whether their data will be subject to automated decision making and their individual rights under the GDPR. The GDPR also requires that the information be provided in concise, easy to understand and clear language.

Personal Privacy Rights

You should review your procedures to ensure they cover all the rights individuals have, including how you would delete personal data or provide data electronically and in a commonly used format.

Rights for individuals under the GDPR include:

  • subject access
  • to have inaccuracies corrected
  • to have information erased
  • to object to direct marketing
  • to restrict the processing of their information, including automated decision-making
  • data portability

On the whole, the rights individuals will enjoy under the GDPR are the same as those under the Acts, but with some significant enhancements. Organisations who already apply these principles will find the transition to the GDPR less difficult.

Review your current procedures. How would your organisation react if it received a request from a data subject wishing to exercise their rights under the GDPR?

  • How long to locate (and correct or delete) the data from all locations where it is stored?
  • Who will make the decisions about deletion?
  • Can your systems respond to the data portability provision of the GDPR, if applicable where you have to provide the data electronically and in a commonly used format?

How will Access Requests change?

You should review and update your procedures and plan how you will handle requests within the new timescales. (There should be no undue delay in processing an Access Request and, at the latest, they must be concluded within one month).

The rules for dealing with subject access requests will change under the GDPR. In most cases, you will not be able to charge for processing an access request, unless you can demonstrate that the cost will be excessive. The timescale for processing an access request will also shorten, dropping significantly from the current 40 day period. Organisations will have some grounds for refusing to grant an access request. Where a request is deemed manifestly unfounded or excessive, it can be refused. However, organisations will need to have clear refusal policies and procedures in place, and demonstrate why the request meets these criteria.

You will also need to provide some additional information to people making requests, such as your data retention periods and the right to have inaccurate data corrected. If your organisation handles a large number of access requests, the impact of the changes could be considerable. The logistical implications of having to deal with requests in a shorter timeframe and provide additional information will need to be factored into future planning for organisations. It could ultimately save your organisation a great deal of administrative cost if you can develop systems that allow people to access their information easily online.

What we mean when we talk about a ‘Legal Basis’

You should look at the various types of data processing you carry out, identify your legal basis for carrying it out and document it. This is particularly important where consent is relied upon as the sole legal basis for processing data. Under the GDPR, individuals will have a stronger right to have their data deleted where customer consent is the only justification for processing. You will have to explain your legal basis for processing personal data in your privacy notice and when you answer a subject access request.

For government departments and agencies, there has been a significant reduction in the number of legal bases they may rely on when processing data. It will no longer be possible to cite legitimate interests. Instead, there will be a general necessity to have specific legislative provisions underpinning one or more of the methods organisations use to process data. All organisations need to carefully consider how much personal data they gather, and why. If any categories can be discontinued, do so. For the data that remains, consider whether it needs to be kept in its raw format, and how quickly you can begin the process of anonymisation and pseudonymisation.

Using customer consent as a grounds to process data

If you do use customer consent when you record personal data, you should review how you seek, obtain and record that consent, and whether you need to make any changes. Consent must be ‘freely given, specific, informed and unambiguous’. Essentially, your customer cannot be forced into consent, or be unaware that they are consenting to processing of their personal data. They must know exactly what they are consenting to, and there can be no doubt that they are consenting. Obtaining consent requires a positive indication of agreement – it cannot be inferred from silence, pre-ticked boxes or inactivity.

If consent is the legal basis relied upon to process personal data, you must make sure it will meet the standards required by the GDPR. If it does not, then you should amend your consent mechanisms or find an alternative legal basis. Note that consent has to be verifiable, that individuals must be informed in advance of their right to withdraw consent and that individuals generally have stronger rights where you rely on consent to process their data. The GDPR is clear that controllers must be able to demonstrate that consent was given. You should therefore review the systems you have for recording consent to ensure you have an effective audit trail.

Processing Children’s Data

If the work of your organisation involves the processing of data from underage subjects, you must ensure that you have adequate systems in place to verify individual ages and gather consent from guardians.

The GDPR introduces special protections for children’s data, particularly in the context of social media and commercial internet services. The state will define the age up to which an organisation must obtain consent from a guardian before processing a child’s data. It should be noted that consent needs to be verifiable, and therefore communicated to your underage customers in language they can understand.

Data Protection Impact Assessments (DPIA) and Data Protection by design and default

A DPIA is the process of systematically considering the potential impact that a project or initiative might have on the privacy of individuals. It will allow organisations to identify potential privacy issues before they arise, and come up with a way to mitigate them. A DPIA can involve discussions with relevant parties/stakeholders. Ultimately such an assessment may prove invaluable in determining the viability of future projects and initiatives. The GDPR introduces mandatory DPIAs for those organisations involved in high-risk processing; for example where a new technology is being deployed, where a profiling operation is likely to significantly affect individuals, or where there is large scale monitoring of a publicly accessible area.

Where the DPIA indicates that the risks identified in relation to the processing of personal data cannot be fully mitigated, data controllers will be required to consult the DPC before engaging in the process. Organisations should now start to assess whether future projects will require a DPIA and, if the project calls for a DPIA, consider:

  • Who will do it?
  • Who else needs to be involved?
  • Will the process be run centrally or locally?

It has always been good practice to adopt privacy by design as a default approach; privacy by design and the minimisation of data have always been implicit requirements of the data protection principles. However, the GDPR enshrines both the principle of ‘privacy by design’ and the principle of ‘privacy by default’ in law. This means that service settings must be automatically privacy friendly, and requires that the development of services and products takes account of privacy considerations from the outset.

10 Reporting data breaches

You should make sure you have the right procedures in place to detect, report and investigate a personal data breach.

Some organisations are already required to notify the DPC when they incur a personal data breach. However, the GDPR will bring in mandatory breach notifications, which will be new to many organisations. All breaches must be reported to the DPC, typically within 72 hours, unless the data was anonymised or encrypted. In practice this will mean that most data breaches must be reported to the DPC. Breaches that are likely to bring harm to an individual – such as identity theft or breach of confidentiality – must also be reported to the individuals concerned. Now is the time to assess the types of data you hold and document which ones which fall within the notification requirement in the event of a breach. Larger organisations will need to develop policies and procedures for managing data breaches, both at central or local level.

It is worth noting that a failure to report a breach when required to do so could result in a fine, as well as a fine for the breach itself.

11 Data Protection Officers

The GDPR will require some organisations to designate a Data Protection Officer (DPO). Organisations requiring DPOs include public authorities, organisations whose activities involve the regular and systematic monitoring of data subjects on a large scale, or organisations who process what is currently known as sensitive personal data on a large scale.

The important thing is to make sure that someone in your organisation, or an external data protection advisor, takes responsibility for your data protection compliance and has the knowledge, support and authority to do so effectively.

Therefore you should consider now whether you will be required to designate a DPO and, if so, to assess whether your current approach to data protection compliance will meet the GDPR’s requirements.

12 Cross-border processing and the one stop shop

The GDPR includes the one stop shop (OSS) mechanism, which will be in place for data controllers and data processors that are engaged in cross-border processing of personal data.

The OSS will allow your organisation to deal with a single lead supervisory authority (LSA) for most of your processing activities. Your LSA will be the supervisory authority of the country in which you have your main establishment.
For the OSS to apply to your organisation, you must be engaged in cross-border processing and be established in the European Union.

The way you will identify your main establishment depends on whether you are a data controller or a data processor, but in general it will be helpful for you to map out where your organisation makes its decisions about data processing.