2. Welcome to today’s Webinar
2
We will be starting shortly at 12.00pm
The webinar will run for 1 hour
Submit your questions at any time during the webinar
We will have the Q&A at the end
This webinar is being recorded and will be circulated
tomorrow
3. Agenda
3
GDPR Key Processes & Guidelines
How Wolters Kluwer can help you and your clients with
GDPR compliance through our software
Q&A
5. Poll 1
5
How far has your organisation progressed with your preparations for GDPR?
Not started
Currently implementing
Nearly finished
Completed
Not sure
6. GDPR Recap
6
Enhanced rights for Individuals
Enhanced responsibilities for Controllers & Processors
Enhanced penalties
Opportunity to improve processes
Opportunity to reduce operational risk
8. Data Inventory
8
What data you are collecting
Why you are collecting the data
When the data is no longer required
How you are collecting the data
Where the data is stored and processed
Who you are sharing data with
I keep six honest serving-men (They taught me all I knew); Their names are What and
Why and When and How and Where and Who. - Kipling
9. Lawful Basis for Processing
9
Identify bases for processing
Update privacy notice
Understand the obligations and limitations for choses bases
Ensure engagement letters allow communications
Opt-out
Silence is sometimes an argument of Consent – Thomas Hobbes
10. Data Retention
10
Identify retention periods for all personal data
Leverage legal and (EEA) industry guidelines
Consider anonymisation
Ensure policy is consistently applied
Personal data processed for any purpose or purposes shall not be kept for longer than is
necessary for that purpose or those purposes. – ICO / GDPR Article 5 (e)
11. Poll 2
11
Do you have a formal data retention policy within your practice?
Yes
No
Not sure
12. Poll 3
12
Is your data retention policy implementation consistent?
Yes
No
Not sure
13. Data Privacy by Design & Default
13
Privacy Impact Assessment (PIA)
Perform Due Diligence
Implement common sense controls
Embed privacy requirements into projects and operational activities
Policy & Processes Practices
All human beings have three lives: public, private, and secret.” - Gabriel Márquez
14. Access Requests
14
Nominate a coordinator / Privacy Champion
Develop a response process
Identify roles & responsibilities
Use the data mapping to identify systems
Ensure that identity verification is proportionate
I want it all and I want it now – Queen
15. Breach Management
15
Have a plan
Identify what is a notifiable event
Ensure team know their roles
Ensure that contracts with processors have notification clauses
Maintain a breach register
Captain, we have a problem - various
16. Poll 4
What percentage of your clients would you estimate are prepared for
GDPR?
0-25%
25-50%
50-75%
75-100%
Not sure
16
17. CCH Central is GDPR
compliant and ready......
Nicholas Brown
18. 18
CCH Central
GDPR
Capturing and recording Consent
Personal Data
Information access requests
The right to data portability
Audit Trail
The right to be forgotten (erasure)
Data retention
Permissions
19. Capturing and recording consent
GDPR requires that all users provide explicit consent to track personal
information.
CCH Central offers the necessary functionality for the Practice to store the
consent from the clients whose data they want to use and/or share.
19
25. Personal Data
Personal data is classed as any information relating to an identifiable natural
person.
This includes a broad range of data including: name, number , location, online
ID, physical, physiological, genetic, mental, economic, cultural and social data.
25
28. Information access requests
CCH Central has a single routine to select the data you wish to include ion
your response.
This will be saved in a PDF format or other human readable format so it can
be provided to the individual making the request.
Allows the export of files in standard formats: PDF and XML.
28
29. The right to Data Portability
Data portability, in accordance with the GDPR, is the right for an individual to
require an organisation to give them back a copy of the personal data they
previously provided or, to send this data to another organisation.
Users may request access to any information companies possess relating to
them like information about their Tax Returns or Accounting Periods.
CCH Central allows the export of files in standard formats: PDF and XML.
29
31. GDPR – Subject Access Request
31
Central: Personal Data option is by
default selected. A PDF file that
contains personal information about
the client or contact like name, date of
birth, address, associated contacts, etc,
will be generated.
Personal Tax/Trust Tax: Current Year
and Prior Years are available on Clients
with the following Contact Types: Other
Person, Trust, Partnership and LLP.
Accounts Production is not available in
the 2018.1 (April) release
33. 2018.2 May GDPR Central Release
The key enhancement is the functionality to address Erasure or the “right
to be forgotten”
Data portability of Accounts Production
Data Retention
Permissions
33
There has been a lot of information circulating about GDPR for the last couple of years so I don’t intend to cover that in much detail or go over definitions, just enough to put some colour around some of the key processes that should in place.
Lets start with the purpose behind the GDPR – to give more control to individuals over what their personal data is used for. To support this a set of rights for individuals has been enshrined in law, including:
- The right to be informed
- The right of access
- The right to rectification
- The right to erasure
- The right to restrict processing
- The right to data portability
- The right to object
- The right not to be subject to automated decision making & profiling
To support that, data controllers are required to explain, in a privacy notice, what personal data they collect, what it is used for and the legal grounds for processing such data. We are going to cover legal bases a bit later. There are also additional responsibilities for Controllers & Processors, in particular around notifications and demonstrating that controls to protect personal data are in place.
To ensure that controllers and processors do what they are required to, GDPR gives supervisory authorities bigger teeth with well publicised maximum financial penalties. The UK data protection bill currently under review defines some criminal offences relating to:
- Handling personal data without the consent of the controller
- Disclosing personal data without the consent of the controller; or
- Retaining personal data after it has been obtained without the consent of the controller
There are also offences to reidentify anonymised data and alter data to prevent disclosure.
In summary, don’t do with other people’s data that which you wouldn’t want done with yours.
Lastly, with any regulatory change there are opportunities. Evaluating your processes that use personal data is a good opportunity to rework those processes to streamline and/or add additional controls. Where we are adding controls to processes, if done properly it can reduce operational risk.
There are two stages to any compliance initiative. Those are get clean and stay clean. For GDPR we are all in the get clean stage and will soon be entering into the stay clean stage.
When I was working in practice for one of the Big 4 in the early 2000’s I worked an a number of Sarbanes Oxley compliance projects. After leaving practice in 2005 I consulted at many companies who fell under the remit of Sarbanes Oxley and I got to see how they were getting on post-implementation. Almost without exception we saw that the burden of operating controls far outweighed the effort to implement. If the implementation is a sprint (I know it feels longer!) then operating those controls was a marathon. While arguably GDPR is possibly less cross cutting than Sarbanes Oxley, there are parallels and it’s important that practices that you put in place to address control risks are embedded, pragmatic and effective.
Firstly: Fundamental to any change initiative is engaging and training the team. That includes partners, staff and third parties who work with you. In almost all cases, the human factor is a significant influence on a breach. Training and educating the biggest cause of breaches is a great investment.
Secondly: We all know the importance of Knowing Your Customer as it relates to Anti-Money Laundering, well Knowing Your Data is pivotal to meeting your GDPR obligations. We are going to cover that in the next slide but it’s important to point out that it is the cornerstone to the success of a project during implementation and on to operation.
Thirdly: GDPR requires us to operate appropriate technical and organisational measures. The key work is appropriate and this will vary depending on the type of data e.g. the disclosure of a set of email addresses is going to be less damaging than a set of personal tax returns. We are going to touch on Data Privacy by Design and Default later but for now it’s important that we have both technical measures for example encrypted hard drives, and organisational measures which are the policies and processes in place to support compliance.
Fourth: Without governance it is hard to effect change. There are lots of definitions for governance, I like to refer to it as the structures and frameworks in place to support effective decision making.
The Fifth key is considering how the process operates in the long term. Decisions should be made with an eye on living with those choices as they become operational. In the second half of this webinar my colleague Nicholas will be talking about how tooling can be leveraged to reduce some of this burden.
Knowing Your Data is fundamental to complying with GDPR.
You need to:
Provide privacy notice
Know where it is stored and how it is used
Understand your sub-processors & ensure that Data Processing Agreements are in place
Assess the measures in place to protect the data
Respond to Access Requests
And many more
The data inventory need not be complex but should be addressing the following questions:
1. What types personal data do we hold? Are we holding special categories of data? Are we holding data that we don’t need?
2. Why we are collecting and holding the data – this is the purpose which needs to be identified in privacy notices
3. We will talk a bit more about retentions later but When can we delete or depersonalise the data?
4. How we collect the data – online forms, customers sending us information, mobile apps etc.
5. A really important one, Where the data is stored and processed. We could do a whole webinar on data residency but fundamentally we need to know where the data we control is being stored and ensure that the right protective measures, contractually, legally & technically ally are in place.
6. Who the data is being shared with – these are your processors.
If you can answer those questions for all the data your process then you are in a good position. There are some exemptions for maintaining an inventory of processing for smaller businesses however in reality it is a formality as an outcome of Knowing Your Data.
Consents are probably the most broadly debated topic for GDPR. I’m sure everyone on this call has recently received emails requiring you to re-opt in to receive communications relating to services you may have used.
Consent is one of 6 lawful bases for processing personal data but not one of the ones probably most used for advisors.
The other relevant bases are:
Contract – required in order to fulfil a contract – this most applicable for work that advisors do for customers.
Legitimate interests – Most flexible. Appropriate when you are using data in ways that they would expect. Marketing to current customers or people who have signed up to mailing lists.
If you are relying on legitimate interests, as with consent, then ensure that you give the option to opt-out.
Less relevant to practices are also:
Legal obligation – If you need to process the data to comply with a legal or statutory obligation. This is not new
Vital interests – Processing personal data to protect someone’s life.
Public task – Carrying out tasks in the public interest which is most relevant to the public sector.
When you are drafting your privacy notices you will need to identify the bases of processing along with your intended purposes for processing personal data. It is a natural extension of creating your data inventory.
When you are drafting engagement letters, ensure that they allow communications. If you are processing special categories of data such as evidence of personal donations to religious charities or some union memberships then ensure that you have explicit consent for processing those categories of data required for the provision of services.
GDPR Article 5 covers the principles related to the processing of personal data. The one which seems to get the most airtime is data retention. The relevant requirement is that data is “kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed”.
There are two useful items here. The first is “no longer that necessary for the purposes for which the personal data are processed.” There are a number of factors which contribute to identifying an appropriate duration for retaining data. For some of the information that practices work with there are laws and industry practices
Some useful examples include:
Contracts: The Limitation Act 1980 requires that information relating to contracts and arrangements are retained for the length of the contract + 6 years.
The HMRC 6 year rule for reassessment
Pensions: The Registered Pension Scheme Regulations 2006 require a minimum of 6 years retention
Payroll must be retained for 3 years from the end of the tax year
Money Laundering Regulations 2007 require retention for 5 years after the relationship ceases.
Something it is also important to take into consideration is that there may be additional retention periods stipulated by PI insurers so do check when performing this exercise.
When you take into consideration the scope of what we have just discussed then that covers a large amount of personal data likely to be processed by practices. For any retentions that are legally defined, it is also a valid reason for refusal to delete certain pieces of information should a data subject exercise their right to be forgotten.
The other interesting part of the requirement is that it relates only to data which is “kept in a form which permits identification of data subjects”. If we were to retain datasets that had been anonymised then that is OK but keep in mind that de-anonymising datasets is likely to become a criminal offence when the current data protection bill is passed.
It is important to apply this policy consistently across all systems that holds data in a way which catalogues or indexes data subjects. This is one of the reasons that the initial data mapping exercise is so important.
Customers who run CCH Document Management are able to set retention periods for files held within the product.
We’ve used the last few slides to talk about data mapping, use of that data and how we can decide how long we retain data for. The next 3 slides talk about protecting data and some processes that it is prudent to plan for.
Article 25 of the GDPR talks about Data Privacy by Design and Default.
Under the GDPR, practices have an obligation to implement technical and organisational measures to show that you have considered and integrated data protection into your processing activities. This concept is not new, Privacy by Design has been championed by many privacy groups, including the ICO for years. There are some items in common with the triad of information security which is confidentiality, integrity and availability.
There are some key considerations for Data Privacy by Design & Default.
Firstly, to embed data privacy in projects, processes and practices it is useful to perform a Privacy Impact Assessment. This is effectively just a focused risk assessment so can be treated as such – identify privacy objectives (GDPR requirements), identify the threats to achieving those objectives and implement appropriate control measures. Use industry good practice, where available, as a baseline. For information security type risks I strongly recommend that all companies look at the Cyber Essentials program as it covers the basics and is not too onerous.
Secondly, increasingly we are relying on other organisations to process data on our behalf. When we are accessing the risks to the data we need to be asking ourselves what data are we transferring, what happens if something goes wrong. What controls are in place to minimise the risks? what recourse do I have? Trust is great but facts, not good faith rule.
Thirdly, the controls or measures that we put in place to reduce the risk to acceptable levels need to be pragmatic and operable by an organisation. Restricting access to data is a great preventative control but you need to be of a certain size for it work otherwise you will end up with people finding workarounds which potentially present a bigger risk than not implementing the original control. Uncontrolled spreadsheets are a prime example.
Finally, look to embed privacy assessments into usual ways of working. Policies & Processes are great but only become effective when they become practices.
The ability to request what data an organisation holds on you is not new. The current Data Protection Act provides that ability, albeit at a small cost. GDPR carries this on but organisations will no longer be able to charge to fulfil a standard request, that is one which is not excessive or repetitive.
The timescale for responding to a request is 1 month so is highly recommended to develop an easily actioned procedure to respond within the timescales. On Friday 5th May the ICO served an enforcement notice on an organisation who failed to respond correctly to a Subject Access Request. The organisation was the parent company of Cambridge Analytica so may have had other problems to contend with but it is by no means the only company to be subject to enforcement by the ICO for failing to fulfil their obligations.
When defining your process consider the following:
Appoint someone responsible for coordinating the response. There is no legal requirement to appoint a Data Protection Officer unless certain criteria are met but it is recommended that there is a responsible individual or privacy champion who knows what the notification requirements are for both Access Requests and breaches – more of that later.
Use your data mapping exercise to list the systems that you will need to access to get the information. If you have several teams then appoint a primary and secondary responder and make sure that they have access to the systems or are able to get the information out in a timely manner. Perform dry runs to make sure that you know how to extract the data. Functionality to allow our clients to respond to access requests and data export requests is being built into our Central suite and online products.
Ensure that the requestor appropriately authenticates themselves. Work out how you are going to verify the identity of a requestor to ensure that they do not accidentally disclose personal data to the wrong person. It’s also important not to request more information than you need to verify the identity. It is easy to verify the address of a member of staff for example. A failed job applicant may need more verification. The ICO has some good information in their Access Request code of practice.
Last but not least we come to Breach Management. While everything we have talked about so far helps to prevent a breach, people and systems are fallible and if we have a notifiable event then a plan, or process, that can be invoked and executed in a stressful situation is worth the time invested.
A breach is defined by the GDPR as “When the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons”.
The GDPR requires that a Data Controller notifies the supervisory authority within 72 hours. There is no specified timescale for Data Processors to notify other than it should be without undue delay. This appears to be one of the areas where we will see case law giving more clarity in due course.
Anyone who has been involved in breaches of one kind or another will know that 72 hours is not a long time to:
Identify and potentially fix the point of failure
Gather the relevant information for a submission (nature of breach, what types of data, the number of data subjects & the number of records concerned
Describe the measures that have been put in place, or plan to be, to address the breach
Identify the consequences of the breach
Report to the ICO, any other regulators and other 3rd parties such as insurers
With all of those activities needing to be performed it is easy to see the benefit of planning in advance. Where you have 3rd parties working on your behalf e.g. IT support, legal representation, ensure that contracts enable response to support the required activities. Where you use data processors then ensure that their Data Processing Agreements specify that they will notify without undue delay.
A new window called Report Audit Trail, has been introduced within File > Maintenance> Audit Trail, allowing users the ability to view the history of reports created in CCH Reporting and Smart Reports that have been run and the history of the files that have been exported to Excel.