2. Getting to grips with GDPR
David Reeve, Head of information strategy, Jisc
20/12/2017 2Getting to grips with GDPR
3. 20/12/2017 3
Global spend estimated
at $300 to $500 billion
combating the bug
Getting to grips with GDPR
4. GDPR coverage in the newspapers
20/12/2017 4
“Banks could be stung for €5bn
under GDPR, screams latest report
on industry readiness”
“Fears data protection rules could
close small firms”“Last year’s ICO would be 79 times
higher under GDPR: TalkTalk’s
£400,000 penalty was big – how
about £59 MILLION?”
“Worldwide climate of fear over
GDPR data compliance claims
veritas study”
“Cyber insurance ‘unlikely to cover
massive GDPR fines’ ”
“Last year’s ICO fines would soar to
£69 million post – GDPR””
Getting to grips with GDPR
6. The dangers of running projects based on FEAR
20/12/2017 6
“I am a GDPR expert offering consultancy”
There is no case law or enforcement actions to offer compliance guidance. We don’t know yet what the final GDPR will
look like so how can you be an expert…be sceptical!! ££££££££££
“You can buy our GDPR solutions now”
“Our product will make you compliant”
There are some solutions that can help with auditing but there is no miraculous product that will make you compliant
simply by purchasing and installing it. ££££££££££
“After Brexit the GDPR won’t apply to the UK”
Recent survey revealed 44% of firms think the regulation will not apply to UK business after Brexit UK bring this into
law by 25 May 2018 and a new bill is going through Parliament for post Brexit. £££££££££
Information Commissioner’s Office:
Don’t focus on fines regime “focus on risk, transparency, control and accountability”
There is no silver bullet technology solution. GDPR is still an unknown so claims of compliance is premature. ££££££££
Getting to grips with GDPR
7. Implementing GDPR
20/12/2017 7
Jan 2017 May 2018
Not applicable to Jisc 11. Children (ICO Step 8) 12. International (ICO Step 12
Dec 2017
Getting to grips with GDPR
8. Where to go for help
» Information Commissioner’s Office: (https://ico.org.uk/)
» Article 29Working Group: (https://edps.europa.eu/)
» Legal changes: Number of free sites including: Bird and Bird guide to the GDPR (http://ji.sc/two-birds-
data-protection)
» Sector guidance and advice: (jisc.ac.uk/gdpr)
20/12/2017 8Getting to grips with GDPR
9. Links to Jisc blogs
Step 1: Awareness
GDPR: Alumni Process (http://ji.sc/regulatory-developments-alumni)
Data Protection Bill and Public Authorities (http://ji.sc/gdprdata-protection)
Step 2: Information we hold
GDPR: Information Lifecycle Registers (http://ji.sc/gdpr-moving-information)
Service Categories (http://ji.sc/gdpr-service-categories)
Step 4: Individual rights
Portability Rights and Data Protection Challenges (http://ji.sc/portability-right-data-protection)
GDPR: Backups, Archives and the Right to Erasure (http://ji.sc/gdpr-backups-archives)
20/12/2017 9Getting to grips with GDPR
10. Links to Jisc blogs
Step 6: Legal basis for processing personal data
What'sYour Justification? (http://ji.sc/gdpr-whats-your-justification)
Web forms and consent (http://ji.sc/gdpr-web-forms-and-consent)
GDPR: Student Unions (http://ji.sc/gdpr-student-unions)
Service categories (http://ji.sc/gdpr-service-categories)
Step 7: Consent
GDPR: A New Kind of Consent (http://ji.sc/gdpr-new-kind-of-consent)
Step 9: Data breaches
Incident Response and GDPR (http://ji.sc/incident-response-and-gdpr)
20/12/2017 10Getting to grips with GDPR
11. What you should be doing now – top 10 tips
1. Get support …put together a GDPR implementation task force
2. Conduct an audit of what personal data the organisation holds, how it is being used, to whom it is being disclosed and to where it is
being transferred
3. TheGDPR advocates taking a risk based approach; through the audit identify your systems and services that present most risk and
focus on mitigating these
4. Start reviewing data protection clauses used (both for templates and live negotiations) in supplier agreements to include the
mandatoryGDPR clauses
5. Review breach notification and management systems and procedures, including draft notification forms for both notifications to
the supervisory authority and affected individuals
6. Review IT systems and internal processes to ensure that an individual's data can be captured both for the purpose of data portability
(ie passing a copy to the data subject or another controller), but also to enable such data to be deleted easily when no longer needed
7. Review and update student and staff privacy notices to reflect the new transparency requirements of theGDPR
8. Develop a template DPIA to be used in any high risk projects with a checklist of when to apply
9. Review existing processes and procedures for subject access requests, including the development of template response forms and
assessing whether the one-month response deadline could be met
10. Start putting together training materials to raise staff awareness of the new rules under the GDPR
20/12/2017 11Getting to grips with GDPR
14. Practical applications of GDPR for FE
JoeYeadon, GodalmingCollege, jxy@godalming.ac.uk
20/12/2017 14Practical applications of GDPR for FE
15. Practical applications of GDPR for FE
About Godalming College:
»Sixth Form College in SW Surrey
»2100 full-time 16-19 students
»<50 14-16 from local schools
»Turnover c £9m, 250 staff
»In-house MIS, online systems
»Planning conversion to Sixth
FormAcademy
20/12/2017 15Practical applications of GDPR for FE
16. Practical applications of GDPR for FE
About me:
»Worked in FE since 2001
»Responsible for IT and MIS at
Godalming College
› ILR, SQL Reporting, Software, etc
»Data Protection Officer
»Dealt with DP Breach in 2011
»No formal DP qualifications!
20/12/2017 16
JoeYeadon
Practical applications of GDPR for FE
17. Where to start?
»Look at the “12 Steps”, JISC website and ICO guidance – it’s free!
»Work out where you are – it might be better than you think!
»Read the Data Protection Bill (and EU Reg 2016/679)
»Work out where you need to be
»Have a data security breach (or just panic – whichever you prefer)
“I’m in FE – where do I start with this GDPR-fangled thing?”
20/12/2017 17Practical applications of GDPR for FE
18. Where to start?
20/12/2017 18
1. Awareness – make sure the College boss knows about GDPR
2. Document – what Personal Information have you got and where is it?
3. Communication – how do your staff/students etc know?
4. Rights – Retention policy, erasure procedure etc
5. SAR – procedures/policy – need a mechanism
6. Lawful basis – statutory duty (Education & Skills Act etc)
7. Consent – to consent or not consent, that is the question
8. Children – what age are the Data Subjects?
9. Breaches – have a procedure
10. Design – ‘Data Protection by Design’
11. Data Protection Officer – you need one!
12. International - (EU – identify the lead authority etc)
12Stepsto
GDPR
Practical applications of GDPR for FE
19. Good News for FE
»Most College activity is covered by Statutory Duty – contract rather
than consent
»Very little automated processing (if any)
»UK implementation of GDPR gives lower age limit for consent
»Most data is only collected for a specific purpose
»Generally, the same sorts of things which make Colleges work well
involve centralisation of data
»Generally, there’s already expertise
»Generally, there’s no cross-border transfer of Personal Information
20/12/2017 19Practical applications of GDPR for FE
20. Where did we start?
»DPO in place already – reporting to Principal, will report to
Governors. Experience of Breach management
»Good Data Protection Policy already, revamped forGDPR (draft)
»In-house MIS
› Logs of communication, scanned documents, no student files
› Staff, Student and Parent Portals
»Reasonable culture of contract and consent
› We can’t perform our legal duty without Personal Information,
but we already seek consent for publicity purposes
20/12/2017 20
Godalming College’s approach (1/2)
Practical applications of GDPR for FE
21. Where did we start?
»Use networks
› S7 Group of Sixth Form College
› Principals’ group, MIS managers, new Data Protection Group
› JISC, ICO webinars
»Use common-sense
› Read the Directive, read the Bill, look around the College
»Get the ‘management’ on-board
»Write the policy – get some momentum in the right direction
20/12/2017 21
Godalming College’s approach (2/2)
Practical applications of GDPR for FE
22. Where to start?
»Lack of experience with GDPR
› Nobody has been tested yet!
»Hype – consultants want it to sound difficult
»Unclear guidance on data retention
»Possibly need new systems to deal with Subject Access?
»Silo mentality – ‘department spreadsheet’, mark-books, separate
systems for teaching & learning …
“OK – that sounds easy, what’s the catch?”
20/12/2017 22Practical applications of GDPR for FE
23. Where are we?
“So what’s the problem?”
20/12/2017 23
»Hype –worrying the boss
»Safeguarding – guidance is confusing (age 25, indefinitely?)
»What about UCAS references 10 years-on, COSHH 40 years..?
»Do emails referencing personal information stored elsewhere
form part of the record? (Confusing advice)
»Is CCTV Personal Information?
»Information stored/backed-up in the Cloud, paper and tape
»Perception about ‘right to erasure’, education exemptions
Practical applications of GDPR for FE
24. Where are we?
Godalming College – progress to date
20/12/2017 24
»Read the documentation, drafted the policy, revised the NFP
»Network – S7 Data Protection group, consulted JISC
› Worked out who the real experts are in the network
»Senior ManagementTeam meetings – clarifying and refining
»Identified need to clarify how data is deleted
»Identified need to develop a one-stop-SAR-shop
»Inset activities planned
Practical applications of GDPR for FE
25. »GDPR in FE isn’t necessarily difficult
»We are all travelling in the right direction
»There’s still some confusion of the detail
»Engage with Senior Managers – appoint a DPO if you haven’t
already
»Review, refresh DP statements and policies – and communicate
20/12/2017 25
In summary…
Summary
Practical applications of GDPR for FE
26. jisc.ac.uk
JoeYeadon
Head of ILT services
Godalming College
jxy@godalming.ac.uk
20/12/2017 26Practical applications of GDPR for FE
27. Developing an information asset register
from scratch
Rachael Maguire, Records Manager, London School of Economics
20/12/2017 27Developing an information asset register from scratch
28. Developing an information asset register
»Why develop an information asset register?
› Why not before now?
–Not covered by Crown Copyright
› GDPR Article 30 requirements
› Internal requirements
–Data Licences agreements
–Secure destruction
–Better records management
20/12/2017 28Developing an information asset register from scratch
29. Developing an information asset register
»Article 30 requires:
» Each controller and, where applicable, the controller’s representative, shall maintain a record of processing activities under its
responsibility.That record shall contain all of the following information:
› the name and contact details of the controller and, where applicable, the joint controller, the controller’s representative and the
data protection officer;
› the purposes of the processing;
› a description of the categories of data subjects and of the categories of personal data;
› the categories of recipients to whom the personal data have been or will be disclosed including recipients in third countries or
international organisations;
› where applicable, transfers of personal data to a third country or an international organisation, including the identification of that
third country or international organisation and, in the case of transfers referred to in the second subparagraph of Article 49(1), the
documentation of suitable safeguards;
› where possible, the envisaged time limits for erasure of the different categories of data;
› where possible, a general description of the technical and organisational security measures referred to in Article 32(1).
20/12/2017 29Developing an information asset register from scratch
30. Developing an information asset register
How did we go about creating the IAR?
»CheckedTNA guidance
»Looked at other examples. What was useful to us?What was worth
borrowing?
»Developing the specification
»Refining what the fields should be called
»Getting sign off through the committees
20/12/2017 30Developing an information asset register from scratch
31. Developing an information asset register
Our IAR includes:
» Core fields – name, owner, description, retention
» Information Security fields – access, classification, security measures
» Business continuity fields – risks to asset, support contacts, backup
» Data protection fields – what sort of personal data, lawful basis, data processor
» Publication fields – is the asset published and if so where
» Data licence agreements – restrictions of use, renewal date
» Systems/unstructured collections
20/12/2017 31Developing an information asset register from scratch
32. Developing an information asset register
Asset Type Asset Name Asset Description No. of Records Retention Retention Trigger Location Asset Platform Owner Business Area Data Collection Activity
Physical,
Electronic,
Database,
Office PC,
Mobile Device
What is the asset called.
Sometimes this will be a
database name e.g. SITS,
sometimes it will be a
description of a collection
e.g. personnel files.
Short description of what
information the asset
contains
How many records
are held within the
asset? This may be
shelf metres,
number of records
in a database, size
in KB/GB/TB, etc
How long
should the
information
asset be kept -
NOTE
Permanent
should only be
used on
guidance of
LSE Archivist
What causes the
disposal/archiving of
the information asset
Where is the
information
asset? In
general, we
would want a
specific room
number or
drive or cloud
storage name.
What software
manages the
information asset
e.g. Oracle,
proprietary system
and/or the format
e.g. Word. Excel
Who is
responsible
for managing
the
information
asset
Department/
Division/ Centre
and sub team if
necessary
E.g. ongoing, ceased
Electronic
Data Protection
request case files
The case files for DP
requests, organised
by DP number 26.2MB 7 years
Last action on
case file P Drive
Mainly Word,
some Excel, pdf
and email
Rachael
Maguire
Secretary's
Division, Legal
Team Ongoing
20/12/2017 32Developing an information asset register from scratch
33. Developing an Information Asset Register
Getting the IAR filled out
»We have started!
»An Excel template, two examples
»Already filled out by a couple of units at the School, only 140 to go
»Aiming for finishing this by end of January 2018
20/12/2017 33Developing an information asset register from scratch
34. Developing an information asset register
Next steps
»Where are we keeping the data gathered?
»Spreadsheet, SharePoint or database?
»How will we keep it updated?
20/12/2017 34Developing an information asset register from scratch
40. Scary services
20/12/2017 40
We may not be able to contact all data subjects
They’re complicated
They probably need individual treatment
Simplifying GDPR
42. Service categories
Risk
level
Relationship Example
1 Service provider has direct
interaction with user
helpdesk
2 Service provider has direct
long-term relationship with
user
eduroam site
contact
Risk-based guide to prioritisation/resource
20/12/2017 42Simplifying GDPR
43. Service categories
Risk
level
Relationship Example
1 Service provider has direct
interaction with user
helpdesk
2 Service provider has direct
long-term relationship with
user
eduroam site
contact
3 User has relationship with
third party
eduroam user
Risk-based guide to prioritisation/resource
20/12/2017 43Simplifying GDPR
44. Service categories
Risk
level
Relationship Example
1 Service provider has direct
interaction with user
helpdesk
2 Service provider has direct
long-term relationship with
user
eduroam site
contact
3 User has relationship with
third party
eduroam user
4 User may be unaware of
service’s existence
incident
response
Risk-based guide to prioritisation/resource
20/12/2017 44Simplifying GDPR
45. Bundles
Groups of services likely to use same approach
20/12/2017 45
Type 1 (direct interaction): enquiry/response/done
Helpdesk-like
Type 2 (direct relationship): join/nominate/use
SiteLicence-like
Type 2 (as above) for site contact
Type 3 (indirect relationship) for users
FedAuth-like
More…?
Simplifying GDPR
47. GDPR instruments
Sources of assurance to provider and user…
20/12/2017 47
• Explain key points to data subjects
User-friendly
privacy notice
• Assign legal responsibilities among partners
Contractual terms
and conditions
• Understand/document non-obvious
legal bases
Legal analysis
• Analyse risks (to individuals) and mitigations
of processing
Data Protection
Impact Assessment
Simplifying GDPR
48. Service categories
Risk-based guide to prioritisation/resource
20/12/2017 49
Risk
level
Relationship Example Privacy
notice?
Contract? Legal basis
test?
DPIA?
1 Service provider has direct
interaction with user
helpdesk
2 Service provider has direct
long-term relationship with
user
eduroam site
contact
3 User has relationship with
third party
eduroam user
4 User may be unaware of
service’s existence
incident
response
Simplifying GDPR
49. Service categories
Risk-based guide to prioritisation/resource
20/12/2017 50
Risk
level
Relationship Example Privacy
notice?
Contract? Legal basis
test?
DPIA?
1 Service provider has direct
interaction with user
helpdesk X X X
2 Service provider has direct
long-term relationship with
user
eduroam site
contact
3 User has relationship with
third party
eduroam user
4 User may be unaware of
service’s existence
incident
response
Simplifying GDPR
50. Service categories
Risk
level
Relationship Example Privacy
notice?
Contract? Legal basis
test?
DPIA?
1 Service provider has direct
interaction with user
helpdesk X X X
2 Service provider has direct
long-term relationship with
user
eduroam site
contact
? X
3 User has relationship with
third party
eduroam user
4 User may be unaware of
service’s existence
incident
response
Risk-based guide to prioritisation/resource
20/12/2017 51Simplifying GDPR
51. Service categories
Risk
level
Relationship Example Privacy
notice?
Contract? Legal basis
test?
DPIA?
1 Service provider has direct
interaction with user
helpdesk X X X
2 Service provider has direct
long-term relationship with
user
eduroam site
contact
? X
3 User has relationship with
third party
eduroam user ?
4 User may be unaware of
service’s existence
incident
response
Risk-based guide to prioritisation/resource
20/12/2017 52Simplifying GDPR
52. Service categories
Risk
level
Relationship Example Privacy
notice?
Contract? Legal basis
test?
DPIA?
1 Service provider has direct
interaction with user
helpdesk X X X
2 Service provider has direct
long-term relationship with
user
eduroam site
contact
? X
3 User has relationship with
third party
eduroam user ?
4 User may be unaware of
service’s existence
incident
response
?
Risk-based guide to prioritisation/resource
20/12/2017 53Simplifying GDPR
56. Possible employment activity categories
Same relationship with all, so now based on data type
20/12/2017 57
Risk
level
Type of data Example Privacy
notice?
Contract? Legal basis
test?
DPIA?
1 Optional Social chatter X X X
3 Mandatory, non-sensitive
data
IT, HR ?
4 Sensitive data (inc.financial) Payroll, medical ?
Simplifying GDPR
57. Possible employee privacy notices
Work-in-progress…
20/12/2017 58
Master Notice
» Retention, transfers, exports,
security, exercising rights
»For each of
› “purposes of employment”
› “law requires us to”
› Vital interests
› “identify problems or improvements”
› “you asked us to”
Per-service notice
(at point of collection)
» Purpose(s), link to master
» [Other options]
»Not (only) at point of collection
› That could be many years ago
› Probably a role for context-awareness
› eg reminders on communications?
jisc.ac.uk/website/privacy-notice
Simplifying GDPR
60. 3 Data Subjects are entitled to have data rectified if it is inaccurate or incomplete.
If the data in question has been disclosed to third parties, you must inform the
third parties of the rectification, and the Data Subject about the third parties
involved.
The controller must respond within one month. This can be extended by two
months where the request for rectification is complex.
If you decide to take no action in response to a request for rectification, then
you must explain why, informing the Data Subject of their right to complain to
the supervisory authority and to a judicial remedy.
Tribal Group plc 61
Right to Rectification
(Article 5(1)(d), 16; Recital 39, 59, 65, 73)
61. 4 Otherwise known as “the right to be forgotten”, this right entitles the
data subject to require an organisation that holds their personal data to
delete those data, cease further distribution of the data, and have third
parties halt processing of the data where the retention is not GDPR
compliant.
The right, however, is not an absolute right. In most cases, provided that
an organisation has a lawful basis for processing personal data, it will not
be significantly affected by the right to be forgotten.
Tribal Group plc 62
Right to Erasure
(Article 17; Recital 65-66, 68)
62. 5 Under the DPA, individuals have a right to ‘block’ or suppress processing
of personal data. The restriction of processing under the GDPR is similar.
When processing is restricted, you are permitted to store the personal
data, but not process it further. You can retain just enough information
about the individual to ensure that the restriction is respected in future.
If you have disclosed the personal data in question to third parties, you
must inform them about the restriction on the processing of the
personal data, unless it is impossible or involves a disproportionate
effort to do so.
Tribal Group plc 63
Right to Restrict Processing
(Article 18, 19; Recital 67)
63. 6 The right to data portability allows individuals to obtain and reuse a
digital copy of their personal data in a safe and secure manner.
Data covered by a portability request includes: ‘personal data’ that the
data subject has provided and ‘observed data’ (i.e. anything observed or
measured, such as Marks/Grades or Attendance records)
Data excluded includes: ‘derived data’ (e.g. data calculated using other
values, for example ranking data) and ‘Inferred data’ (e.g. data created
using predictive analytics, such as a student risk/intervention record).
Tribal Group plc 64
Right to Data Portability
(Article 20; Recital 68, 73; WP29)
64. 7 Data subjects have the right to object to the processing of their personal
data, where the basis for that processing is either public interest; or
legitimate interests of the controller.
The burden of proof is now with the controller who must cease such
processing unless it can demonstrate compelling legitimate grounds for
the processing which override the interests, rights and freedoms of the
data subject; or requires the data in order to establish, exercise or
defend legal rights. This is unlikely to impact universities or colleges as
they rely upon a different legal basis for processing.
Tribal Group plc 65
Right to Object to Processing
(Article 21; Recital 50, 59, 69-70, 73)
65. 8 Data subjects have the right not to be subject to a decision based solely
on automated processing of their personal data which significantly
impacts them (including profiling) without human intervention.
Processing is permitted where it is necessary for entering into or
performing a contract with the data subject provided that appropriate
safeguards are in place; it is authorised by law; or explicit consent has
been obtained.
Tribal Group plc 66
Rights related to automated decision making
(Article 22; Recital 71, 75)
66. 9 Breach notifications to the ICO are mandatory where they are likely to
“result in a risk for the rights and freedoms of individuals”.
Notification must occur within 72 hours of the breach. Data processors
will also be required to notify their customers, the controllers, “without
undue delay” of any data breach.
Where a breach is likely to result in a “high risk” to the rights and
freedoms of individuals, those concerned must be notified directly
“without undue delay,” and be provide with specific information about
the steps they should take to protect themselves.
Tribal Group plc 67
Right to Breach Notification
(Article 34, A29 WP)
67. 1
0
Any data subject has the right to lodge a complaint with a supervisory
authority (in the UK this is the ICO) if they consider that the processing
of personal data relating to him or her infringes the GDPR.
Upon investigation, the supervisory authority shall inform the
complainant on the progress and the outcome of the complaint.
The data subject has the right to an effective judicial remedy where the
supervisory authority does not handle a complaint or does not inform
the data subject within three months on the progress or outcome of the
complaint.
Tribal Group plc 68
Right to Lodge a Complaint
(Article 77-79; Recital 141, 143, 145)
68. 1
1
Any data subject has the right to compensation for material, or non-
material damage resulting from a GDPR infringement.
Compensation can be sought from the controller and processor.
Tribal Group plc 69
Right to Compensation
(Article 82)
69. Key Takeaways…..
FEES: In most cases, the GDPR does not permit fees to be charge. There is a risk
that individuals will attempt to exercise their rights merely because they can, or as a
cheap but effective means of protest. This may result in an increase in administrative
costs on your organisation. There is no limit on the cost of a SAR. Recent Court of
Appeal cap at £120k.
MANDATORY INFORMATION: The GDPR expands the mandatory categories of
information which must be supplied in connection with a subject access request. Such
requests will place an even greater burden on your DPO’s than currently experienced.
TIME LIMITS: The introduction of specified time limits under the GDPR results in more
onerous compliance obligations for controllers.
SUBJECT ACCESS REQUESTS: SAR’s do not have to include the words “Subject Access” or
refer to the GDPR to constitute a valid SAR. Just because a SAR ends up sitting in the wrong in-
tray, it does not make it any less valid. It’s therefore essential to ensure all staff can recognise a
SAR, and know exactly who to pass them on to.
20 December 2017 Tribal Group plc 70
70. A free pocket book, based
on a summary of this
presentation will be
available in Jan 2018.
To obtain your copy of
this pocket book and
today’s presentation, just
register your interest on
our stand or email me at:
71Tribal Group plc
Paul.duller@tribalgroup.com
72. Required contract provisions for data protection
Anjeli Bajaj, Director of information and data compliance,
University ofWarwick
20/12/2017 73
73. Anjeli Bajaj - Information and Data Director,University of Warwick
Data ProtectionOfficer
Overview Required Contract Provisions:
GDPR
74. Required Contract Provisions: Data Protection
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 75
Focus – procuring services of a data processor
CommercialTerms run parallel
Data Compliance Schedule
- Data Protection terms
- PIA ( SIA) Article 25
- Security Measures
- 2% of GTO Article 83
75. Required Contract Provisions: Data Protection
Supplier of Services as Data Processor
» The GDPR enhances the responsibilities and liabilities of Data Processors it is
still important to be clear as to the parties respective roles
breach reporting .
» Relevant legislative provision
› See S1(1) DPA, and Article 4(7) GDPR for the definitions of Data Controller
and Data Processor.
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 76
76. Required Contract Provisions: Data Protection
The Contract between the DP and DC
»Should set out the subject matter, duration, nature, and
purpose of the processing, the type of personal data that is
processed, the categories of data subjects and the duties and
rights of the DC.
»Relevant legislative provision
- Article 28 (3)
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 77
77. Supplier’s ObligationsTo Act on Instructions
» The DP must only act upon receipt of the Data Controller's documented
instructions (evidence – expecting demonstration of compliance ).
» So as to limit the University’s exposure for non-compliant processing of
personal data it is important for the University control the way in which the
Supplier processes personal data.
» It is important therefore that in any accompanying commercial agreement
the scope of the Service(s) to be provided by the Supplier is very clearly
specified and that very clear instructions are given to the Supplier so that
they can understand what their instructions are.
» Relevant legislative provision
› Article 28 GDPR - Paragraphs 11 and 12 of Schedule 1 part II DPA.
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 78
Required Contract Provisions: Data Protection
78. Third Parties - Engaging Another Processor
» The use by the Supplier of third parties needs to be strictly regulated and
expressly approved by the University.
» Only if, the DP has the DC's authorisation,
» the nomination is in a written contract or other legal act,
» has the same duties arranged with the DC,
» specifies the data protection obligations & the initial DP remains liable
» Relevant legislative provision
› Article 28 (4)
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 79
Required Contract Provisions: Data Protection
79. Confidentiality
» Stipulate:Guarantee Confidentiality
» The DP shall ensure that all its staff processing the personal data are
committed to confidentiality duties or other appropriate statutory obligation
of confidentiality.
» Relevant legislative provision
› Article 28 (3b) .
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 80
Required Contract Provisions: Data Protection
80. Duty of Assistance to the DC
DP must assist to respond the data subject's requests, security
processing, the duties in case of a data breach, data protection
impact assessment and prior consultation.
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 81
Required Contract Provisions: Data Protection
81. Security Measures
» It is a legal requirement for the University to ensure that the Supplier has in
place appropriate technical and organisational measures to ensure a level of
security appropriate to the risk.
» A security measures appendix to your Data Compliance Schedule will
stipulate the Security measures the Supplier will be required to put in place as
a minimum.
» Not an exhaustive list .
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 82
Required Contract Provisions: Data Protection
82. Security Measures – continued
» Contractual provision to ensure that it is the Supplier’s responsibility to
ensure that the measures it puts in place are sufficient to comply the Data
Protection Legislation.
» Relevant legislative provision
› Article 32 GDPR & article 28 (3c) .
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 83
Required Contract Provisions: Data Protection
83. Data Breach
» The University is required to notify the Information Commissioner of any
personal data breach within 72 hours of becoming aware of it, unless that
breach is unlikely to result in a risk to the rights and freedoms of natural
persons.
» This is an assessment which the Information and Data Compliance team will
need to make. Given the time frames involved it is imperative that Data
Compliance Schedule includes provisions for data breaches .
» Relevant legislative provision
› Article 33 GDPR.
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 84
Required Contract Provisions: Data Protection
84. Requests from Data Subjects
» The legislation sets out clearly the steps which the University must take if a
data subject requests a copy of his/her personal data. In order to ensure
compliance with the legislation it is important that such requests are passed
as quickly as possible to the Information and Data Compliance team.
» Relevant legislative provision
› Articles 13-20 GDPR.
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 85
Required Contract Provisions: Data Protection
85. Audit
Demonstrate Compliance
The DP should make available to the DC all the necessary
information to demonstrate compliance.Allow carrying out
audits, inspections, by the DC or auditor that the DC has
mandated, and contribute to these checks.
Relevant legislative provision
› Article 28 (3h)GDPR.
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 86
Required Contract Provisions: Data Protection
86. Register ofTreatments
Demonstrate Compliance
Unless exempted in line with Art. 30 (5) GDPR, the DP should
maintain a register that lists all clients and describes the
treatments that its perform on their account.The content is set
out in Art. 30 (2) GDPR.
Relevant legislative provision
› Article 28 (3h)GDPR – Recital 82
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 87
Required Contract Provisions: Data Protection
87. Warning and Advice
The DP must inform the DC without undue delay if, under its
opinion, a DC's instruction infringes the GDPR or other Union or
Member State data protection law.
Relevant legislative provision
Article 28 (3h)
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 88
Required Contract Provisions: Data Protection
88. DataTransfers
» The rules governing the transfer of personal data outside the EEA are strict
and complex. Generally such transfers should be avoided if at all possible
although it is recognised that occasionally they may need to take place.
Where there is to be any transfer of data outside of the EEA an assessment
needs to be made as to the legal basis for that transfer, the adequacy of the
data protection legislation in that country and what other safeguards need to
be put in place.Accordingly, clause 5’s initial starting point is that transfers
outside the EEA are not permitted but where express approval for these is
given those transfers have to be restricted and carefully monitored.
» Relevant legislative provision
› Articles 13-20 GDPR /Model Contracts
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 89
Required Contract Provisions: Data Protection
89. DataTreatment on termination
» Return of data.
» Secure Deletion
» Relevant legislative provision
› Article 28 GDPR.
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 90
Required Contract Provisions: Data Protection
90. Indemnity
» The Data Compliance Schedule needs to include comprehensive indemnity
from the Supplier and a requirement for the Supplier to put in place adequate
insurance to cover it if the indemnity is called upon.
» It is recognised that often commercial agreements include limitations on
liability and more restrictive indemnities. In the circumstances, breach of the
Data Compliance Schedule should be expressly carved out of any limitation
on liability and this should be borne in mind when discussing the indemnities
in any commercial agreement.
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 91
Required Contract Provisions: Data Protection
91. Indemnity – continued
» Whilst it is recognised that on occasion suppliers may seek to resist the
indemnity in the Data Compliance Schedule however no variation to this
should be agreed without the Information and Data Compliance team’s prior
agreement.
» Relevant legislative provision
› Articles 83 GDPR.
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 92
Required Contract Provisions: Data Protection
92. Training
» Training is a key component of security and privacy by design and default.
» Relevant legislative provision
› Article 5,
› Article 28,
› Article 32,
› Article 35.
Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 93
Required Contract Provisions: Data Protection
93. Anjeli Bajaj - Information and Data Director, University of Warwick. Data Protection Officer 94
Type of
contract/agreement
Relationship Requirement T
e
m
p
l
a
t
e
Data sharing
agreement
Controller to controller Data sharing agreement
Controller to processor Draft data sharing agreement and attach data compliance schedule
Institutional agreement
where IDC are asked to
insert a DP schedule
Controller to controller Data sharing agreement
Controller to processor Insert data compliance schedule and where required a data sharing agreement
Supplier legal contract Check if any DP provisions and review. Separate data sharing agreement and data compliance schedule required. Clause in
supplier legal contract to be inserted referring to these documents.
Controller to processor Negotiating point begins with our data compliance schedule
Accreditation bodies Controller to controller Data Sharing Agreement
Auditors speaking to students Informed consent required
Controller to processor External auditing data provision agreement
Auditors Controller to controller Data Sharing
Controller to processor External auditing data provision agreement
Required Contract Provisions: Data Protection
94. Geek-DPR: how you still need ICT
Tim Rodgers, Compliance and information governance manager,
Imperial College London
20/12/2017 95
95. GDPR implications for research
Andrew Charlesworth, Reader in IT and the law, University of Bristol
20/12/2017 96
96. The GDPR and Research
Andrew Charlesworth
Centre for IT & Law
University of Bristol Law School
97. I must recognise … that the [Data
Protection] Act [1998] is of notorious
obscurity…”
Lindsay J. in Douglas v. Hello! Ltd (No.7) (2004)
“Hold our beer…”
The GDPR & UK Data Protection Bill
98. Background
• Cross-disciplinary post in Law & Computer Science (2001-2016)
• Author, Jisc DP Code of Practice for FE and HE (2001 & 2007)
• Empirical Researcher in a Social Sciences Faculty (2001–)
• Member/Chair, Law School Research Ethics Committee (2006-)
• Author, Jisc Data Protection and Research Data (2014-15)
• Member/Chair, University Research Data Access Committee (2015-
)
99. The GDPR: Issues I
• Anonymity & Pseudonymisation – R.26, 28 & 29 + Art.4(5)
• Further processing – R.50 + Art.5(1)(b) (+ Art.89(1) + R.156 + Art.9)
• Storage – Art.5(1)(e) (+ Art.89)
• Lawfulness of processing - Art.6(1)
• Consent - Art.6(1)(a) BUT Art.9(2)(j)
• Public interest - Art 6(1)(e) + R.45
• Legitimate interests Art.6(1)(f) + R.47 (are Universities ‘public authorities’?)
• Consent – R.33 + Art.7
• Special categories of personal data – Art.9 inc. Art.9(2)(j) (+Art.89)
• Also Art. 9(2)(g) - further alternatives in the substantial public interest
100. The GDPR: Issues II
• DSR: Information provided to data subject
• Where obtained from data subject - Art.13
• Where not obtained from data subject - Art.14(5)(b) (+ Art.89)
• DSR: Right to erasure – Art.17(3)(d) (+ Art 89)
• DSR: Right to object – Art.21(6) (+ Art.89)
• Freedom of expression and information – Art.85
• Processing for historical, statistical and scientific research
purposes – Art.89 + R.156.
101. The GDPR: Issues III
• Art.89(1) + R156 - requires safeguards for the processing of personal
data for research. If provided these derogations/special provisions
are enabled:
• Art.5(1)(b) and (e) - further processing and storage
• Art.9(2)(j) - processing of special categories of data
• Art.14(5)(b) - information requirements-
• Art.17(3)(d) - right to erasure
• Art.21(6) - right to object
• Technical and organisational approaches must ensure the processing
of personal data is limited to the minimum needed
• Anonymous data should be used instead of personal data where
possible
102. The GDPR: Issues IV
• Art.89(2) - Union or Member States can legislate further
derogations from the following data subject rights, inc:
• Art.15 - right to subject access
• Art. 16 - right to rectification
• Art. 17a - right to restriction of processing
• Art. 19 - right to object
• + others in R.156
• IF the conditions of A.89(1) are met; AND applying the right would
seriously compromise the purpose; AND the derogations are
necessary for the purpose to be achieved.
103. Data Protection Bill
• Currently Sch.2 Pt.6 s.25 & 26 – derogations under Art.86(2) GDPR
• Art. 15(1) to (3) (confirmation of processing, access to data and
safeguards for third country transfers);
• Art. 16 (right to rectification);
• Art. 18(1) (restriction of processing);
• Art. 21(1) (objections to processing).
• IF data is processed in accordance with Art. 89(1) AND for Arts.
15(1)-(3), the results of the research or any resulting statistics are
not made available in a form which identifies a data subject
104. Pragmatics I
• The EU is keenly aware of the potential impact of the GDPR on
research, both public & private.
• The existing framework for UK research compliance will remain broadly the
same.
• BUT there is scope for divergence in exemptions and derogations between EU
Member States, with implications for cross-border research collaborations.
• As a social sciences researcher and REC member, my key issues are:
• Education of researchers;
• Accountability and research governance;
• Addressing consent as both a legal and ethical requirement, and the alternatives
to consent.
105. Pragmatics II
• Different academic disciplines face varying challenges to existing
practices - avoid ‘one-size-fits-all’ solutions and ‘quick fixes’.
• RECs already address DP (to varying degrees) – they can identify discipline-
specific risks, good practice and problems with suggested ‘solutions’
• As RECs have varying expertise in DP, it is important that they are not
simply used as ‘gatekeepers’, but rather trained/developed as
‘facilitators’.
• Research training, research data management plans, workflow
• ‘privacy by design’ and ‘privacy impact assessment’ elements
• Accountability
• We do forms and training, but do we really do accountability?
Important information No fire alarms planned Evacuation meeting point to the left of the carpark – please follow RCP staff
Chapter 67 of the Bill says “… the controller must have regard to the professional qualities of the proposed officer, in particular.. The proposed officer’s expert knowledge of data protection law and practice…”
How do we do that?!!!
Consider what online systems are in use, and can take-over from non-central systems
Students enter contract – it’s a requirement that they submit their data for processing and they can’t withdraw their consent because of this. Same does not necessarily apply for marketing, where student may withdraw permission. BUT it’s good practice anyway because applicant may not be aware of the implications of their image/information being published.
Original GDPR document says that parents need to give consent to 18 but this can vary. UK Bill gives lower age limit (age 13?)
Office 365 etc uses EU-based data centres, kindly negociated via Janet/JISC
Data is used for administration, Value Added, E+D monitoring, ILR etc.
Data Protection Officer needs ‘teeth’ – i.e. the authority to enforce change in the organisation. This is sometimes difficult in the FE setting because of the emphasis on Teaching and Learning.
Some institutions perform regular Data Protection Audits – noting what is where and who holds it. Godalming College says ‘thou shalt store stuff in specified places’
There’s a lot of confusion, mixed messages, and different opinions around Data Protection. Different
One College in S7 performed a staff SAR under Data Protection Act, and was advised by ICO to provide every email about that person, and manually redact any 3rd party information - 60,000 emails!!
NFP = Notice of Fair Processing – on the applications system, available on website, online learning environment and staff portal
So why are we developing an information asset register or IAR?
IARs have been around for over a decade, but as a university it had not been compulsory for us to develop one like the rest of the public sector. This comes down to not being covered by Crown Copyright, which was the trigger for the creation of IARs originally. So we missed the pain in developing these earlier, only to have to catch up now. However, it has helped in developing our own IAR to have the examples of other public authorities who have already had to go through the process.
When deciding on why to develop an IAR, the LSE had to consider:
Mainly for the GDPR Article 30 requirements, which I’ll go through in more detail in the next slide.
But we also had some internal requirements as well. For example, the School uses third part data sets that come with licensing agreements. These might say that only staff and students at the LSE may use the dataset or that the data set can only be used on a non networked secure PC. These agreements need to be renewed but the School was not recording the renewal date anywhere. The IAR seemed the perfect place to start recording this information.
Another issue that came up is determining what level of secure destruction personal data might need. For example, it may be a requirement that a research funder or data provider requires that the School use a Degausser to magnetically destroy a hard drive. The IAR would give us a chance to record any data that needed particular care in destruction.
And underpinning all of this is trying to actually run a records management programme. We had a policy and guidance, got paper records to secondary storage and otherwise disposed of, but this requirement of the GDPR has been a way to introduce records management practice that in my opinion, we should have been doing anyway.
While the IAR should meet the requirements of the record keeping requirements, it is worth looking at Article 30 if you haven’t already just to ensure that you have covered everything listed in Article 30(1).
For example, this states that as a controller you shall maintain a record of processing activities and that ‘that record shall contain’ the name and contact details of the controller. For every type of personal data? Or can you record this once elsewhere? I think it most likely that most people will do the latter, but the article does imply one record which contains all of this information, which isn’t necessarily what the IAR can do. As we have developed ours at the School, we have not included the name and contact details of the controller on each entry. It is likely that as a published document as we intend the IAR to be, it can be added to the web on a page that contains the contact details.
Purpose of processing we have taken to mean lawful basis as set out in Articles 6 and 9, the latter covering special categories data. This is one of the fields in our IAR
A description of the categories of data subjects and categories of personal data – to a degree I think the current data protection register entry does this more clearly in grouping the data subjects and types of personal data together. The IAR will have the details for each information asset containing personal data, so we are moving away from that model. However, the information asset name and an associated description field should cover both these. For systems, we have developed a checklist as well which details the types of personal data held by the system. This will get closer to detailing each personal data field in those systems.
Categories of recipients – again this is grouped together better in the data protection register entry, but we have included a field for who can access the information asset that would cover recipients, including those outside the School.
Where applicable, transfers to third countries or international organisations. So if you never do this you don’t need to include it in your IAR.
Where possible, time limits. We are using the IAR to make decisions relating to retention of data easier, so have included both a retention and retention trigger field. I think that the 5th data protection principle makes this more compulsory than the where possible would suggest.
Where possible, security measures. We have covered this in our IAR, and again, I think that the fact that technical and organisational methods are set out in another article makes this more something you should cover.
The first thing I did was check the TNA guidance on developing IARs. This set out a basic methodology to follow, though strangely enough, via its digital continuity programme.
The next thing was to look at examples from other places. For example, the TNA template, the Department of Transport IAR itself, the template provided to NHS organisations as we have some health data that we process and we didn’t want to set out IAR up without ensuring it wasn’t compatible in case we had to follow the IG toolkit in the future.
The next process was looking at the different fields used in the examples. The first look through removed fields we would not require, though also showed some we had not though of e.g. make and model for any information assets tied to a particular device. The second was to determine terminology. The examples used different terms to mean the same or similar things. For example, the TNA template has a field called ‘What Does it Do’ that is the equivalent to our ‘Asset Description’ field. The Information Security Manager, Archivist and I went through the list I created from the first drafts of the IAR specification until we were happy with the number of fields, their field names, their descriptions and their groupings, which I’ll go through next. For example, we decided on one field to indicate personal data rather than two separate fields.
The specification was added as an appendix to an update records management policy, which was now called the Information Asset and Records Management policy, and signed off by the most senior management committee.
The core fields cover the basic information about the asset, so what is it called, who owns it, what does it contain, how long is the information kept, etc.
The information security fields covers access to the asset, the School’s information security classification – hard to apply before, what security measures does the asset need, including level of destruction required.
Business continuity was used to group the risks to the asset, support contacts if applicable, and back up. In other words, what we need to ensure the information asset is available.
The data protection fields cover the sorts of personal data (normal, special categories, both), the lawful bases that apply and details of any data processors.
Publication fields.
The data licence agreement fields, which were developed by looking at the agreements themselves and seeing what they had in common.
One question we have wrestled with is coverage. We developed another checklist for systems as they also need to cope with requests for deletion, portability, etc. We also have a systems catalogue that could take that information in. However, the IAR was intended to cover both structured and unstructured data. Separating out the systems data could stop us from having a full picture of our personal data. So at the moment, we intend the IAR to cover all sources of personal data, including research data sets and the big systems like SITS our student database.
For illustration, these are some of the core fields. The example used within the template includes Data Protection case files to show that unstructured data should also be included. This is one of the examples.
Aside from the DP case files, there is also a governor’s database example.
We do have a lot of work to do on this, particularly is we are to meet our end of January target, but we have two Bas starting soon to work on this project, so that should help.
The main issues so far have been size of the information asset, retention periods and lawful basis. I have been sitting down with staff to take them through it.
We haven’t got everything sorted out yet. We could have taken a project management approach and got all this sorted out before hand, but the deadline of 25th May is approaching and I thought it best to make a start and make the further decisions down the line as needed. So we still need to sort out
Where will we keep the data. What sources will we bring together e.g. the IAR template, the systems checklist, cloud system questionnaires? Will we use a spreadsheet, a list in SharePoint or a proprietary database? There are some good examples of the latter out there, but they have systems costs in and of themselves. However, the spreadsheet or SharePoint formats may not support keeping the IAR and interrogating it as well.
How we will maintain the IAR. TNA suggests a yearly review. Whatever method we use, I think at least for the first year or two we will have to offer a moratorium on older data that is only just being added to the IAR.
My final thought is that as a records manager who moved into information rights, this has been one of the first times that a records management task has been required rather than merely supportive for information rights work. This is one of the truly good things that GDPR has given records management as a profession.
DPB s.6 Meaning of “public authority” and “public body”
(1) For the purposes of the GDPR, the following (and only the following) are “public authorities” and “public bodies” under the law of the United Kingdom—
(a) a public authority as defined by the Freedom of Information Act 2000,subject to subsection (2),
(b) a Scottish public authority as defined by the Freedom of Information (Scotland) Act 2002 (asp 13), subject to subsection (2), and
(c) an authority or a body specified by the Secretary of State in regulations.
(2) The Secretary of State may by regulations provide that a person specified in the regulations that is a public authority described in subsection (1)(a) or (b) is not a “public authority” or “public body” for the purposes of the GDPR.
Under Article 6(1) of the GDPR, those public authorities are not permitted to use the legitimate interests basis "in the performance of their tasks"; Instead, by Recital 47, those tasks and their legal basis should be "provide[d] by law";
And, by Clause 7(c) of the Bill, where a task is "conferred on a person by an enactment", the legal basis is that it is necessary in the public interest.
