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.

• 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.

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.

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.

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.

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, 3^rd 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

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

• 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

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

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.

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

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

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.