Menu
close
Call +44 (0)20 3005 4440
Intersys Logo
+44 (0)20 3005 4440
Menu
Close

Managed IT Support

A Reasonable, Fixed Monthly Fee for All Your IT Needs
Managed IT Support Provider

Consulting Services

The High Level IT Consulting Services You Need to Transform Your Business
Get IT Consulting Services

Cyber Security

A Comprehensive Range of Cyber Security Services for Robust, Industry-Leading Protection
Get Cyber Security Services

IT Solutions

Whatever your IT needs, we'll create a tailormade solution for you
Get IT Solutions

The 8 Week GDPR Compliance Plan

This series is intended as a ‘roadmap to compliance’. The 8 weekly installments can be used as a framework, to help guide your organisation through the process of ensuring you’ve covered critical aspects of Data Protection compliance and good practice. As articles are published, they will be linked below.

Introduction

General Data Protection Regulation – how bad can it be?

Working as a GDPR solution provider, this is one of the questions that often comes up in initial meetings with our customers. For those of us who lived through the Y2K panic, it is easy to draw parallels between the two storms and hope that GDPR amounts to an equally damp squib as the millennium bug. The difference is we know more this time – with Y2K, every apocalyptic scenario seemed possible and, however unlikely, there was always a sliver of a chance that aircraft would fall from the skies and ATMs would spit notes out, while back end systems added and removed zeros to bank balances. Nothing that dramatic will happen with GDPR…will it?

In Brief

In theory GDPR is simple – check that the data you are holding is legal and secure and you’re good to go. If it isn’t legal and it isn’t secure, then you could be in a spot of bother come the 25th of May 2018. Of course, nothing is ever that black and white, especially as we are talking about close to 90 pages of legal text containing 99 separate articles. So, there are plenty of interpretations to consider, but that shouldn’t stop you making a start by understanding where your issues are, what you need to tackle and in what order.

A Compliance Journey

To help you with this, I will be leading you on a journey over the next two months, tackling a new area each week to help you understand what needs to be done to comply with GDPR, prioritise your efforts and implement it.

With a little focus, next time the board ask if you have GDPR sorted, you will confidently announce ‘it’s all in hand!’

So, let’s get started with five GDPR basics before tackling the first of eight sections…
GDPR will be law in the UK in May 2018; Brexit has no effect on this as the UK will still be in the EU on that date. The UK Information Commissioner has already stated that the UK will be adhering to it and, regardless, the ‘Great Repeal Bill’ is set to enshrine existing EU legislation into UK law, ensuring that GDPR stays on UK statute books, even after leaving the EU.
It is a lengthy piece of regulation containing 99 articles (or stipulations) which need no local adaptation. It will be applied equally across the EU to ensure consistent handling of data, but must be adhered to anywhere in the world where EU resident data is being processed
The data being protected is what is called Personally Identifiable Information (PII) belonging to any EU resident. Think of any data that can be used to identify an individual such as address, phone number, credit card, national insurance number. The regulation is attempting to rein in and secure the processing of any PII belonging to an EU resident – the term processing is used to cover any function applied to the data such as storing, analysing, modifying etc.
Consent is key to compliance with GDPR. An organisation must make sure it has the explicit consent of an individual to process their data. Additionally, the individual has many more rights than in the past – they can ask for data held to be reported on, they can ask for it to be changed and they can even ask for it to be removed (right to be forgotten). Organisations need to be ready to respond to any of these requests
The penalties for non-compliance are heavy – the regulations articles carry different weights, but depending on which were breached, organisations can be hit for up to €20 million or 4% of annual global turnover

Week 1 of 8 – GDPR Legality, Consent and Territorial Scope

In this first week of our 8 week GDPR series, we will explore what needs to be looked at and addressed, to comply with the area of Legality and Consent.

Legality and Consent is fundamental to GDPR, so a breach of the articles focussing on them could lead to the maximum €20m fine.

Does GDPR apply?

First of all, does GDPR apply to your organisation?

Does your company hold any information belonging to EU residents* (which could be residents or people living in those states such as visa holders, asylum seekers etc.) that could be used to identify them?
Think of the HR systems, customer records, sale & marketing data etc. Also remember to think of the different teams and departments around your organisation who may be busily collecting personal information
If the answer is ‘yes’, you will need to keep reading and comply with GDPR, if it is definitely ‘no’, for you and anyone in your supply chain, then you don’t need to worry about GDPR, although you will need to monitor the situation and make sure it doesn’t change
*EU States: Austria, Belgium, Bulgaria, Croatia, Republic of Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, UK.

GDPR applies: what to do?

OK – so GDPR applies to your organisation, what now?

The first thing you must do, is make sure that you have the consent of the Data Subject (the person to whom the data refers).

  • In GDPR speak, the consent must be explicit – a pre-populated tick box unfortunately won’t wash anymore and the consent must be specific for the purpose of processing.
    • For example: if you have consent to use the data to send them account statements, you can’t start using the data to see if they are interested in switching Internet Service Providers – not without asking first.
  • So have a look at what consent is in place and make sure it is recorded and can be quickly shown as evidence if required.

There are further twists regarding consent that you need to be aware of with GDPR.

  • One is the right of the Data Subject to withdraw consent at any time. This will give organisations a bit of a headache as there will need to be processes and the technical ability to remove specific data if required.
  • You’ll also need the subject’s consent if you plan to share the PII– no more sharing customer data I’m afraid. However, there are also some allowances where consent is not required – if, for example, you need to share the PII to complete a contract, then you don’t need specific consent. To illustrate that, if you sell the customer a book, you can share their data without consent with the courier as they need to deliver the book to fulfil the contract.

Remember the third parties

While we have been talking about ‘you’ or ‘your organisation’ in this article so far, any third parties that may be involved also need to be considered.

  • Do you have someone who you use to issue invoices? Any back-office processing taking place with other companies?
  • If so, they need to adhere to the same requirements. In the event of a data breach, the ‘controller’ (probably your organisation) is responsible for the data, regardless of where the breach took place.
In addition to ensuring consent is received and recorded, GDPR also lays down that you should only hold the absolute minimum amount of personal data required to carry out the processing. If you are holding physical addresses, phones numbers and email addresses, but only one of those channels is used, then the superfluous data should be removed for existing records and not collected for new data subjects in the future. This will clearly lead to process changes in data collection.

Summary of Legality & Consent

Consent & Legality Pointers

So, if you have got this far and still aren’t sure what Consent and Legality in GDPR means to you, here’s a few simple pointers to help get you started:

  1. Check if the data being held and used by your organisation can be used to identify EU residents – if it does, you need to comply with GDPR by the 25th of May 2018. This is applicable even if you are not based in the EU.
  2. When looking at the data held in your organisation, think about different teams and departments and any third parties you may use. If you are holding and using data that can be used to identify a person, then GDPR need to be complied with
  3. Look at the consent you have from the ‘Data Subjects’. It needs to be clear that they have agreed for you to use their personal data for all the purposes that it is being used. If not, the consent needs to be obtained again.
  4. Make sure the data being held is kept to the minimum needed to do the processing. In future, make sure that only the minimum required data is gathered and retained.
  5. If a subject withdraws consent to have their data held, you must respond to this and stop processing all instances of that individual’s information.

Week 2 of 8 – GDPR Data Mapping

This is week two of our 8 week GDPR walkthrough – hopefully having completed week one, you managed to look at the data your organisation holds and understand the changes that your organisation needs to make around consent to comply with GDPR.

This week is quite straightforward  – but it will be time consuming. The objective is to get to the next level of detail on the data held through an exercise called ‘Data Mapping’ which is a GDPR requirement – Article 30 for anyone who is interested. Data Mapping will document the lifecycle of the Personal Identifiable Information (PII) through your organisation – who owns the data, where it is held and importantly and who can access it.

Having this information documented will help your organisation to not just understand the vulnerabilities, but also to respond more efficiently to data subject requests as you will know where their data is processed and held.

How to Map the Data

It is likely that the Data Mapping will involve quite a few team representatives from around the organisation, so the importance of the exercise will need to be stressed to get them along. Essentially what you are trying to achieve is:
  1. Understand the PII being held and handled by the organisation – start from the collection of the data
  2. Where is it stored? (location of the systems processing and storing the data – remember backups, tapes, audio recordings etc.)
  3. Who ‘owns’ or is accountable for the data?
  4. Who can access the data?
  5. Remember to consider third parties and system interfaces as part of the process flow

A good way to start the exercise is with a whiteboard. Get everyone to contribute to what data they hold and what systems they use – for example HR will hold sensitive employee data, staff performance information and even candidate CV. Sales will have CRM data containing sensitive data. Operations may have bank account details and credit cards. Get it all down on paper and then find an owner. You should also understand where this information is passed from system to system as part of the process flow and start to look for vulnerabilities.

At the end of the Data Mapping exercise you will have a lot of information and more than likely, a load of actions to look at. There will be surprises as well – did anyone ask for consent before recording customer’s wives’ birthdays in the CRM system?  HR may think they are the only ones with access to their data, but did they know that IT are able to view the database where it is kept, or another team can access it through another system? Did Operations know that their data is being used by Sales to cross sell products?

Importantly you will now know all the PII held in the organisation, where it is, who owns it and who can access it. Once you have that information you are in a strong position to start implementing controls and planning what needs to be done to secure the data that you now know you are dealing with.

Summary of Data Mapping

Data Mapping allows you to understand what data you have, where it is and who can access it. It is fundamental to be able to plan the GDPR project, but also to give your organisation the holistic picture of PII, owners and access. The quality of the Data Mapping work will ultimately dictate your compliance with GDPR. If you don’t know about data, you can’t secure it. In summary, here’s what you need to do:
  1. Try to get all the relevant team members in one room for a brainstorming exercise
  2. Document what PII is collected, where it is held, who owns it and who has access to it
  3. Look for system or process weaknesses around access control, transfers to unsecured systems, 3rd parties accessing data
  4. Compile a flow (graphic or otherwise) of data in, around and eventually out of your organisation
  5. Make sure you get sign-off from those involved – if they are not giving you the full picture, then you can’t be expected to secure the data, so they need to put their name to it

Week 3 of 8 – Data Protection Impact Assessment

This is week three of the GDPR walkthrough – if you have followed week one and week two, you should now understand the data that your organisation is holding, where it is, who is responsible for it and whether you have consent from the Data Subjects to process it. That is a great start to shaping and implementing your compliance project.

This week is another important lesson that needs to be understood and a process implemented to accommodate it – the subject is that of the Data Protection Impact Assessment (DPIA). GDPR places the responsibility of running DPIAs with the controller to evaluate the details and levels of risk threatening Personal Identifiable Information (PII). If the risk from the assessment is shown to be high, then GDPR expects the controller to consult with the Supervisory Authority prior to processing.

What is a DPIA?

A DPIA is a fairly straightforward assessment of risk employed when something is going to change. That change could be a project which uses PII in a new way, implements a new processing automation or processes for sharing data are changed. The concept is that ahead of such a change, a DPIA is carried out to evaluate what data is being placed at risk, what controls need to be employed, or if the proposed solution is workable. There are far too many examples of data breaches being triggered by changes, technical or otherwise, that did not test or evaluate the possible consequences. This is exactly what the DPIA process is trying to avoid.

How is a DPIA run?

The most important first step is to recognise the need for a DPIA to be carried out. It makes sense to build the DPIA into another Project Management process so that upon project initiation, the requirement to run a DPIA is considered. Once it is recognised as required, then there are four keys steps:

1. Document the information flow that is being modified. This could be the PII database being transferred, the PII being processed differently or a new technology being implemented that touches the PII in some way

2. Once you have established how the information flow is being placed at risk, the specifics of how need to be understood. So, in step 1 if you established that records are going to be transferred to a new IT system, in step 2 you need to understand how that causes a privacy risk, perhaps by potentially causing a corruption, an unintentional transmission or a data loss

3. Now you understand the specifics of the risk, you can identify mitigation that could potentially be used to reduce the risk identified – the mitigating actions

4. Lastly, you need acceptance and sign-off before proceeding. As noted earlier, if the risk is significant enough, you need to consult with the Supervisory Authority before making the change. If something goes wrong and some or all of the above steps were not followed or cannot be demonstrated, then penalties will be more severe

Who runs the DPIA?

If one exists in your organisation, it is the job of the Data Protection Officer (DPO) to carry out the DPIA. If there is no DPO in the organisation, then there needs to be a process or tools created to allow non-experts to work through the DPIA process effectively.

Summary of Data Protection Impact Assessment

Running a DPIA ahead of making any changes that could jeopardise the privacy of data is required as part of the GDPR. The assessment should be integrated into existing Project Management processes and be flexible enough to be able to cover risks in processes, people or technological changes. The output of the DPIA is a documented analysis of the changes being made, the risks and the mitigating actions which should be accepted and signed ahead of the change. If the impact of the change is viewed to be of high enough risk to PII, then the Supervisory Authority needs to be consulted with ahead of any implementation.

Week 4 of 8 – Breach & Security Response

This is week four of the GDPR walkthrough – we’ve already covered Legality & Consent, Data Mapping and running a Data Protection Impact Analysis and this week we are going to focus on what needs to be done ahead, during and after a breach. Your organisation will undoubtedly have response processes from security incident response to disaster recovery, so this week will make sure that those incorporate the additional requirements laid down by GDPR.

What are the expectations?

Unfortunately, Data Breaches have become commonplace for organisations, so GDPR emphasizes the need for well-documented incident response plan and breach management processes and the ability to demonstrate resilience as required.

The expectation is that Data Controllers take appropriate technical and organisational measures to ensure that processing is secure – in other words:

* design fit-for-purpose security considering the nature of the data
* assign and communicate information security responsibility within your organisation
* get the right security in place, underpinned by robust policies and procedures
* have a well-rehearsed incident response plan in place

In the event of a breach, then there are expectations on the Data Controller that GDPR stipulates:

1. The Supervisory Authority (the Information Commissioner’s Office in the UK) needs to be notified within 72 hours of the Data Controller becoming aware of the data breach. If it is not notified within that time, an explanation why needs to be given

2. The Data Subject whose data has been breached, needs to be notified ‘without undue delay’ of the breach along with the nature of the exposure and any recommendations that may need to be given to the data subject

How can your organisation meet these requirements?

It is clear that ISO27001 (Information Security Management System) will address a lot of the expectation of GDPR in this area. The implementation of a robust information security management system and certification will provide assurance to interested parties that data is being handled securely and the processes around the handling are mature and adequate. Of course, gaining ISO27001 certification is a project in itself, but setting that as a target and working towards it will address many areas of GDPR leaving you with a much-reduced set of actions to become compliant.

ISO27001 aside, if there is a security incident, then the question is what information was breached? If your organisation does not currently use one, consider a breach analytics package which offers the ability to respond quickly with knowledge of what records were accessed during the incident.

Another way of reducing risk and actually avoiding the need to report incidents altogether is to apply ‘pseudonymisation’ to the PII. Pseudonymisation is a procedure by which the most identifying fields within a data record are replaced by one or more artificial identifiers, or pseudonyms. As part of the Data Mapping exercise consider if the data really needs to be held in an identifiable format or if pseudonymisation can be applied. If there is a breach, then the severity is much reduced provided the process has meant the data cannot be attributed to an individual. On a related note, anonymisation is where data is irreversibly manipulated to prevent the identification of subjects, so is actually stronger in terms of securing the handling of PII and as such, anonymised data is not relevant for GDPR.

GDPR encourages these practices where possible and makes exceptions throughout for data that is pseudonymised or anonymised.

The communication processes need to be in place so that a channel is in place with the Supervisory Authority (SA) and the data subjects themselves in the event of a data breach. These processes need to be documented, communicated and rehearsed. The Data Protection Officer (DPO) will typically handle the communications with the SA if you have one in your organisation.

Summary of Breach & Security Response

The is no way around it, but getting the security and associated processes in place is fundamental to securing the PII. Having robust security will mean that the likelihood of a breach in much reduced, so demand for communication channels to the SA etc. will hopefully not be required.

But to make sure that all angles are covered, look at the following areas as part of your review of this section:

* Explore the implementation of ISO27001

* Look at pseudonymisation or anonymisation of as much of the PII as possible – if the data cannot be traced to an individual then it ceases to be PII

* Consider implementing a Breach Analytics system which can help identify what data is at risk to a breach, as well as what has been accessed in the event of a breach

* Develop, test and communicate the response plans including communications to the SA and to Data Subjects, bearing in mind the time limits laid down in GDPR

Need some help?

Having now followed half of the sections, the understanding of what is required should be starting to form. You will undoubtedly have recognised things you do well and things that need to be improved. If you would like to have that independently and formally ratified now or at the end of the 8 weeks, Intersys Compliance can run a gap analysis for you and produce a prioritised list of actions to get on with for each of the areas. Please drop Intersys Compliance a line for a chat or some guidance.
Please enable JavaScript in your browser to complete this form.
Name

Week 5 of 8 – Securing the Supply Chain

This is week five of the GDPR walkthrough – you’re more than halfway there and already covered Legality & Consent, Data Mapping, DPIAs and Breach & Security Responses. This week we will step back from our organisations and make sure that the partners you rely on are looking after your data and not exposing you to breaches, fines and all that nastiness.

What are the expectations?

GDPR calls out subcontracting of processing specifically and while there is no objection to that model, direct compliance obligations are imposed on both controllers and processors, and both controllers and processors will face direct enforcement and penalties if they do not comply. If your organisation acts as both the controller and processor then compliance is within your own control, however, if you use third parties to process data, you need to ensure that they are compliant or you will both suffer.

How to secure the supply chain

The first thing to establish of course is whether there are third parties involved in the processing of data. This should have become evident in week two when you performed the Data Mapping exercise and will include any company involved in the processing of data that you control. That could be external suppliers who work with your PII, who host PII for you, who provide hosting or backup services, or in any other way have access to where the PII is stored. If the third party could in any way access or expose PII controlled by your organisation, then it must be considered.

Once you have the comprehensive list of third parties it is a matter of validating how they handle the data and reflecting that contractually. The questions to explore are:
  1. Does the third party meet GDPR requirements? Can they prove it?
  2. Is there any further outsourcing involved that you have not considered? Confirm that the third party has no additional downstream companies who could access your organisation’s data
  3. Is security adhered to in the third party? For example, is the third party ISO27001 certified? What are the breach reporting processes?
  4. Remember to validate the transfer of data between your organisation and the third party, there could be weaknesses there
Once you are comfortable that there is no risk in the relationship, it needs to be ratified legally. Now is when you’ll need to get the contracts team to amend the contract – if you don’t have a team, contact the third party and explain what is required (namely a clause that they will adhere to GDPR). There is going to be a lot of this happening in the lead up to May 2018, so it shouldn’t come as a surprise to any service provider. However, the bad news is there is a risk that the additional costs to meet the increased compliance obligations when it comes to renewing the contract.

Summary of Securing the Supply Chain

This week should be a reasonably straightforward exercise building on the work you did in earlier weeks. In a nutshell, you need to find out exactly who can access your PII – anyone from outsourced payroll providers to hosting organisations. Once you have that you need to verify the security – don’t be shy to ask probing questions or evidence. If anything goes wrong you will be asked those questions by the regulator, so better to do it now. Finally amend the contract so that the third party has an obligation to continue to secure and meet your high standards. So, an easy task, but it could be time consuming and not one to leave until April 2018!

Week 6 of 8 – Securing PII

This is week six of the GDPR walkthrough and we have covered a lot so far. What we will be doing from now until completing the 8 weeks is looking at the steps your organisation needs to take to secure the data you hold, any changes or organisational arrangements that you need to consider and lastly the new data retrieval obligations you need to be ready for.

So, let’s start with securing the PII you hold. The 6th principle of GDPR is that organisations must ensure ‘appropriate’ security is in place including protection against unlawful processing, loss or damage and technical and organisation measures must be in place. Obviously, the security of the data is fundamental – the quickest way to get noticed by the Supervisory Authority and earn yourself a healthy fine is to suffer a data breach impacting PII. If your organisation is so secure that you can never suffer a data breach, then implementing GDPR will be a quick process. But few of us are willing to believe that, so this week will look at what you should be reviewing and implementing to keep things right.

What are the expectations?

The practical interpretation of the 6th principle is that you need to take appropriate measures against the data that you are processing – so if it is internal HR data that you are using, you may find a simple way of securing or isolating that out of harm’s way. But if you are actively processing sensitive medical information then it is a very different matter and you will be expected to design and implement cutting edge security technology and processes. Access Control is obviously going to be critical to securing the PII as are the processes around backing up, handling and responding to incidents.

How to secure PII?

As mentioned in earlier weeks, a good starting place is the implementation of an Information Security Management System such as ISO27001. If your organisation has, or is in the process of achieving 27001 certification, then you have pretty much nailed this area. If not, then take a look at it. You need to be:

* Adopting an information security policy such as 27001 and understanding what needs to be done to meet it in your organisation

* Developing a thorough understanding of the data being processed and implementing appropriate physical security controls

* Have a well documented access management process in place

* Develop and regularly test a Business Continuity plan – not just a DR plan which tends not to include the wider business stakeholders

* Have a documented incident detection and investigation process in place to address security incidents
The security of PII is often thrown over to IT to sort out, but that will not be enough to meet GDPR expectations. The whole business, right from the top, need to understand and support the processes to ensure end-to-end protection. Any fines will be applied to the business as a whole – therefore prevention needs to be an organisation wide responsibility. If your organisation still feels that one department should make this problem go away, then your starting point may be a conversation with senior management explaining what GDPR is and who is going to suffer if things go wrong. That may help you get the required support.

Summary of Securing PII

This section is all about process implementation. Everything from Security Policies, Segregation of Duties, Background Checks, Access Controls, Business Wide Risk Assessments, Asset Inventories, Software Development processes – everything that touches the security of the data that your organisation processes. It needs to be owned by everyone in the organisation, because ultimately everyone will suffer if a breach occurs.

Week 7 of 8 – Organisational Structure

This is week seven of the GDPR walkthrough. It’s time to look at the less technical demands of the regulation and turn our attention to how you need to structure your organisation and allocate responsibilities around the teams. Primarily this is around the Data Protection Officer (DPO) function.

What are the expectations?

Article 37 of GDPR is where focus is turned to the role of DPO, detailing what the DPO should do, when they should do it and how they need to be positioned. However, what is left to the company to decide is whether a dedicated DPO is required, or whether the responsibilities can be allocated within the existing team. Earlier drafts of GDPR attempted to put a headcount threshold on the requirement (e.g. more than certain number of employees meant a dedicated DPO needed to be in place) but these were removed from the final draft with the exception of some clear instances when a DPO was required. These guidelines are a DPO is required:
  • Where processing is carried out by a public body
  • Where core activities require regular and systematic monitoring of personal data on a large scale
  • Where core activities involve large-scale processing of sensitive personal data
Even with these three instances, there is plenty of room for interpretation and organisations may find themselves no wiser as to the need for a DPO after reading these. If that is the case for you, perhaps looking at the expectations of what the DPO role should perform will help.

What are the role responsibilities of the DPO?

According to GDPR, the DPO must:

  • ‘inform and advise of obligations’ – in other words, keep the organisation in line with the regulation
  • ‘monitor compliance’ – the DPO is expected to be the Board’s ear in terms of compliance. There will be areas in every organisation where compliance slips, the DPO must ensure this is communicated
  • ‘provide advice with regard to data protection impact assessments’ – it is the DPO who will (normally) lead or conduct Data Protection Impact Assessments when one is required
  • ‘cooperate & liaise with the Supervisory Authority’ – the DPO contact details need to be submitted to the Supervisory Authority (SA) and be available to speak to them should the need arise. The DPO is expected to stay current with communication or updates from the SA
  • ‘have due regard to risk associated with processing operations’ – the DPO should be the voice of reason for the organisation and highlight risk in the organisation operations

From this it is easy to see how it could quickly become a full-time role, especially given the requirement for cooperation and liaison with the SA. They want someone available to them to work with, especially if something goes wrong

How to structure your organisation?

The other specification of the DPO position in the GDPR is that of where the position should sit and report to and, how the position should be protected. As the DPO role is about ensuring compliance, it should not sit within the delivery functions of the business or IT. The rationale behind that is the role should be impartial and be able to call out risk associated with change and therefore not be part of the team delivering the change, so if an internal staff member is delegated as the DPO, they would normally sit within a Risk, Compliance or Governance function to ensure the required independence. The GDPR states that the data protection officer shall be designated on the basis of professional qualities and, in particular, expert knowledge of data protection law and practices, so make sure you get the right person.

There are also stipulations about reporting lines – the DPO should have ‘direct access’ to the board. This doesn’t necessarily mean they need to report to the CEO or one of the senior team, but they need to be able to escalate directly without needing to go through multiple go-betweens, risking the dilution or loss of the message. Following from that the DPO will ensure that Data Protection is on the board agenda. Lastly, the DPO position should be ‘protected’ and not risk losing their job, career prospects or bonus just because they called out a risk.

If this all sounds a little daunting, don’t worry, help is available…keep reading.

Contract DPO Service

GDPR states that the DPO does not need to be a permanent employee of the organisation, so if you are concerned that either you do not have someone with the required skills and experience, Intersys Compliance offer a Contract DPO service which will give you an assigned, experienced DPO who will act as the dedicated, named and communicated DPO for your organisation.

The contract DPO service can be tailored to meet the requirements of the organisation, but the standard service offering includes the following components:

  1. An initial ‘Applicability Assessment’ run by Intersys Compliance to understand and report on the improvement areas and prioritised action points. This assessment will be carried out at the start of the contract and can be repeated periodically outside the Contract DPO agreement if required
  2. With the input of your organisation, Intersys Compliance will prepare a suitable reporting format for updates to the senior management and board
  3. The above report in will be delivered monthly, (or as otherwise specified) and cover progress against known issues as well as escalating new issues. This fulfils the GDPR requirement to have Data Protection on the board agenda and access to senior management on an impartial basis
  4. Support will be given to the customer to carry out Data Protection Impact Analysis work as required by GDPR
  5. The Contract DPO will be on a site as defined by your organisation, but at least one day per month to carry out Data Protection Impact Analyses, deliver reports to senior management, carry out education or any of the other DPO relevant activities
  6. Intersys Compliance will register with the Supervisory Authority the name and contact details of the Contract DPO and cover the communication and liaison requirements

Summary of Organisational Structure

While GDPR is quite clear about the duties and reporting line of the DPO, what a lot of organisations are struggling with is whether they need a dedicated resource or not. The best guidance to follow for your organisation is to think ‘worst case’. If something goes wrong, did you have someone available to track the change, to perform a DPIA, to report the risk to the Supervisory Authority, to communicate the situation to the board and to work with the Supervisory Authority before, during and after a change or breach?

If you have someone who has all the credentials then there’s nothing to worry about. If not, speak to Intersys Compliance and see if the requirement can be filled much more efficiently than going to the market.

Week 8 of 8 – Data Storage & Retrieval

So, it’s the final week – and we’ve kept the best for last! GDPR brings with it significantly more rights for Data Subjects. As a result of this, your organisation needs to be prepared so that it can respond effectively to the requests received, or face the consequences. Unfortunately, it is not as simple as creating a few processes to follow when a request comes in, and could require a significant amount of work, both technical and non-technical.

What are the expectations?

Articles 15 to 21 of GDPR lay down the rights of the data subject regarding the processing of their PII. These include the below rights, which must be met free of charge for the Data Subjects:

  1. Right to be Informed – basically consent to having their data processed
  2. Right of Access – whether the controller is processing the PII of the data subject
  3. Right to Rectification – where data is incomplete, this needs to be rectified upon request of the Data Subject
  4. Right to Erasure – the much talked about ‘right to be forgotten’ should the data not be required, be processed illegally or consent for processing withdrawn
  5. Right to Restriction of Processing – this may be invoked if the Data Subject is contesting the processing of data, or where the data is no longer being processed but is required for legal reasons
  6. Right to Data Portability – essentially the Data Subject has the right to have all relevant data packaged up in a format that it can be used by the next organisation. An example of this would be a data subject switching service provider and needs access to their data to make the move
  7. Right to Object – data subjects can ask that their data is no longer processed in cases such as direct marketing
  8. Rights in relation to automated decision making or profiling – individuals have the right not to be subject to a decision when it is based on automated processing and it produces a legal effect, or a similarly significant effect on the individual

What does this mean to your organisation?

If you are like most other organisations, it means quite a lot. Some of the requests may not be completely possible. Think about erasure of data – do you even know where data such as historic call recordings are held? Are records, including backups in a format where one record can be removed leaving others intact?

Of all the changes coming in with GDPR, these requests are likely to cause organisations the biggest headache, especially when timing is taken into account. The requests must be responded to in one calendar month. Exceptionally, if you cannot action the request of the Data Subject within one month, then you may ask for a two-month extension, but that extension must be communicated and agreed in the first calendar month.

Now, if you’re a new organisation with modern data storage technology, this may be less of a problem for you to meet. However, there will be a lot of organisations out there with disparate legacy systems where data is stored in a different locations, in formats where records cannot be easily accessed, or even worse, they don’t even know where some of the records may be kept. That will pose a significant problem for many organisations come May 2018.

Do all requests need to be answered?

While it cannot be relied upon wholesale, there are certain situations where a request from a Data Subject can be declined. I’m sure that got your attention, so let’s explore that a little further.

Where requests are ‘manifestly unfounded or excessive’, in particular because they are repetitive, you can charge a reasonable fee taking into account the administrative costs of providing the information; or refuse to respond. Now it is a open to interpretation as to what is ‘manifestly unfounded or excessive’, but if you can make a strong case that, for example, someone wanting to have all data erased, but you know there are calls recorded and stored in backup tapes that would mean that all calls would need to be deleted in order to meet on Data Subject’s request, then that would warrant push back. The problem here however is that while it may save a massive piece of work retrieving or deleting data, pushing back on requests could also be time consuming and can’t be relied upon to close the request. A persistent Data Subject has every right to contact the Supervisory Authority and escalate the request, which could overturn the rejection.

The GDPR does not introduce an exemption for requests that relate to large amounts of data, but you may be able to consider whether the request is manifestly unfounded or excessive.

Practically speaking, the best approach to take is to make sure that any future systems are compliant regarding the requests – if you are buying or developing a new system make sure that all GDPR requests can be processed at the touch of a button. But that is the future and may not be in place ahead of May 2018. So regarding the existing systems, first you need to know what you can do now (or implement easily) to meet the new requests. Once you have that information, you’ll know what you cannot respond to and that needs to be documented. Depending on what those requests are and the mitigating factors may be then they can be considered on a case-by-case basis. Using the earlier example of voice recordings, if you can demonstrate that you are holding the recordings to meet existing customer obligations and that the recordings are locked away and not actively being processed, then there may be a case to have a conversation with the Supervisory Authority to explain the known shortfall. No guarantees, but at least it shows your organisation has done its homework and is keeping an eye on the risks.

Summary of Data Storage & Retrieval

This is going to be a very difficult component for organisations as they move towards compliance with GDPR. There will be instances where the cost of compliance would be prohibitive to the organisation, so those cases need to be identified and reviewed and properly documented. There also needs to be future-proofing for new processes or systems to ensure that opportunities are not missed to build Data Subject rights into on-going or future implementations, ideally through a self-service portal.

In terms of getting started, look at how you would respond to the above Data Subject requests and ask yourself if you can cover each completely in the one calendar month timeframe, or if not, where are your shortfalls and any of them be remediated inexpensively. It is what you are then left with that needs to be considered

End of the 8 Week GDPR plan

So this concludes our whistle stop tour of GDPR and what it means to you as an organisation. Hopefully you found it an enlightening journey and are now in a position where you know what needs to be done to become compliant. Obviously we skimmed over some topics, but the main points have been looked at.

Intersys Compliance is available to support you on the entire journey to compliance, or on specific areas that you may be challenged with. Please don’t hesitate to give up a call and let us see how we can help you deal with this large, but important task. Good luck with your GDPR implementation!
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram