MRS Operations Network: GDPR - Organisational Measures
•Download as PPTX, PDF•
1 like•754 views
This document summarizes key organizational measures required by the General Data Protection Regulation (GDPR) for MRS Operations Network, including: 1) Reviewing existing supplier contracts and arrangements to ensure compliance, undertaking audits of suppliers as needed. 2) Including GDPR requirements in new supplier selection criteria and contracts. 3) Requiring data protection impact assessments for high-risk data processing such as large-scale or special category data. 4) Establishing processes for personal data breach reporting to supervisory authorities and affected individuals as required.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to MRS Operations Network: GDPR - Organisational Measures
Similar to MRS Operations Network: GDPR - Organisational Measures (20)
More from MRS
More from MRS (20)
Recently uploaded
Recently uploaded (20)
MRS Operations Network: GDPR - Organisational Measures
- 1. MRS Operations Network: GDPR – Organisational Measures May 2018 Debrah Harding MRS, Managing Director
- 2. Session Topics Supplier Selection and procurement Contracts – new and existing suppliers Data Protection Impact Assessments Breach reporting
- 3. Supplier Selection & Procurement GDPR requires you to demonstrate compliance and to have in place appropriate technical and organisational measures to meet the requirements of accountability… Existing Suppliers: Review suppliers’ arrangements to determine if these are adequate for your purposes Undertake checks and/or audits to ensure assurances are matched with reality New suppliers Include GDPR arrangements as part of your selection criteria When choosing new suppliers ask for evidence of GDPR adherence e.g. policies, procedures, training arrangements, further sub-contraction, etc
- 4. Contracts – new and existing suppliers
- 5. Contracts GDPR requires contracts with processors or between data controllers: Written contracts with processors must include terms to: Only act on written instructions of DC Ensure people processing subject to duty of confidence Appropriate security measures Assist DC in providing subject access and allowing data subjects to exercise rights Assist DC in meeting obligations regarding security; data breach notification; DPIA’s Delete or return all personal data to controller as requested at end of contract Submit to audit/inspection and ensure meeting obligations by notifying DC Agreements with joint data controller should address: Research parameters e.g. outputs and standard for delivery of anonymised data; Re-contact consents Liabilities, assurances and indemnities Allocation of responsibilities on data subject requests, applicable privacy policies
- 6. Contracts GDPR action points for supplier contracts: Existing Suppliers: Review existing contracts Issue new contracts or agree contract ‘addendum’ replacing old data protection requirements with GDPR New suppliers Create new GDPR contracts Consider transfer clauses – any outside of the EEA? Transfers outside EEA must have adequate safeguards
- 8. DPIA: Tool for risk- based demonstrable compliance Organisations must fully consider the risks that processing poses to the fundamental rights and freedoms of individuals What does this mean? Identify risky processing activities Consider implications of the risk level Mitigate any risks DPIAs particularly relevant when a new data processing process, new suppliers, system or technology is being introduced Failure to conduct when required is Tier 2 Breach
- 9. When is a DPIA required? Processing “likely to result in a high risk to the rights and freedoms of natural persons”: Systematic and extensive profiling, with significant effects (GDPR) Large scale processing on a large scale of special categories of data or criminal convictions data (GDPR) Systematic monitoring of a publicly accessible area on a large scale (GDPR) New technologies (ICO) Large scale profiling or profiling of children (ICO) Matching datasets or combining datasets from different sources (ICO) Invisible processing (ICO) Tracking location or behaviour (ICO)
- 10. Who should be involved? Data Controller – is it the client or research supplier or both? If Joint it is reasonable to have a ‘lead’ which takes responsibility for DPIAs and other responsibilities People with appropriate expertise and knowledge of a project (internal and/or external) Designated Data Protection Officer (DPO)
- 11. How to conduct a DPIA? 1. Identify need for DPIA 2. Describe the processing 3. Consider consultation 4. Assess necessity and proportionality 5. Identify and assess risks (likelihood, impact/severity) 6. Identify measures to and mitigate risk 7. Sign off and record outcomes 8. Integrate PIA outcomes back into the project plan 9. Keep under review ICO (2018) Draft DPIA Consultation
- 12. DPIA Checklist Have staff been trained to consider DPIA at early point and on how to carry it out? Is DPIA included in policies, processes and procedures? Do you understand the type of processing that requires DPIA? Have you created and documented DPIA process (including approach where no DPIA required)? Do you ensure mitigation measures implemented? Are you aware when the ICO needs to be consulted?
- 13. Breach Reporting
- 14. Personal data breach notifications If you are made aware of a personal data breach Is the breach a risk to individuals? If yes tell supervisory authority (if no then document personal data breach) Is breach “high risk”? If yes tell affected individuals (if no end of process)
- 15. Data security breach notification process • Response to incident should include a recovery plan • Procedures for damage limitation1.Containment and recovery • Assess risks as these affect what you do once the breach has been contained • Consider potential adverse consequences for individuals (severity and likelihood of risk) 2.Assessing the Risks
- 16. Data security breach notification process • Establish process for notification to ICO, individual and controller 3.Notification • Investigate causes and evaluate effectiveness of response to it • Build in effective ways of detecting breaches • If necessary, then update your policies and procedures accordingly 4. Evaluation and Response
- 17. MRS guidance & awareness Guidance •MRS EFAMRO ESOMAR Guidance Note on Research Sector – Legal Bases (June 2017) •GDPR In Brief – 7 GDPR topics covered to date •Data Protection & Research: Guidance for MRS members (April 2018) •Fair Data, Impact, MRS Blogs and Articles Live and Recorded Webinars •GDPR Countdown (May 2017) •MRS AURA Client Side Research (November 2017) •Off the Starting Blocks (March 2018) •RAS GDPR (May 2018) •GDPR & Analytics (June 2018) Training and Events •MRS Roadshow (Leeds, Bristol, Edinburgh, Birmingham, London March to July 2018) •Association events e.g. EphMra; Cvent; MRG; EMA; •MRS GDPR and Data Privacy in Research Training (May 2018) •Company Partner Briefings (Ongoing)
- 18. MRS Operations Network • The Network is open to any who works in operations in any capacity, please email Company.Partners@mrs.org.uk stating your company name and job title to join. • We will be tweeting about this event using the hashtag #CPSops • The next event will be the “Oppies” on 13 September. The Deadline for entering is 03.05.2018 • Post-event feedback MRS is trialling an online feedback facility for events. A link will be sent to you after the event.
Editor's Notes
- Overview GDPR Impact on organisations and sector Steps MRS taking to assist implementation in the sector
- 1. What level of liability cap do you really need? While we all know that the DPAs can, in theory, fine up to 4% annual worldwide turnover, the likelihood of them doing so is very slim and that level of fine would only be seen in the most egregious data protection breaches. That risk can also to a large degree be managed by the controller by going through a thorough due diligence process, selecting a reputable supplier, and instructing that supplier to engage only in lawful processing activities. Higher value liability caps are likely only to be needed where the data, or the processing operations, are of a particularly sensitive nature. Suppliers are very unlikely to agree to significant liability caps in the majority of cases, so agree instead on a level of liability that represents a realistic reflection of the ‘riskiness’ of the processing. 2. What level of insurance do you have in place? If you’re a supplier, time to dust off those cybersecurity insurance policies and check them out - or go and get one if you haven’t already. Don’t look at just the value of the insurance you have in place, but consider too its scope - does it protect only against security incidents or does it extend to wider data protection regulatory breaches? Does it insure you against contractual claims? Are you insured on a ‘per claim’ or ‘all claims’ basis? If the policy was taken out before GDPR, does it need re-brokering in light of GDPR risks? Ultimately, as a supplier, you don’t want to expose your business to significant risks for which you may not have adequate insurance coverage. Equally, as a customer, there’s no point having enormous contractual liability coverage from your supplier only to find it is uninsured and will be bankrupted - and so unable to pay you - the first time you make a claim. 3. What are the liability triggers? Another important consideration is what triggers must exist for a customer to make a contractual claim against its processor for a data protection breach. If those triggers are carefully managed, a supplier may be prepared to agree to higher liability if it is not having to constantly look over its shoulder for every minor mishap. For example, if a customer requires prior consent every time a supplier wants to appoint a new subprocessor, the supplier may be reluctant to agree to a significant liability cap for fear that a simple failure to notify its customer about a new subprocessor may expose it to contractual liability. Conversely, if the supplier is given a general consent to engage subprocessors, it may accept a little more liability risk. Similarly, if there is a good dispute resolution clause in the agreement, then suppliers may feel better able to manage and resolve contractual complaints without fear that a customer will turn immediately to litigation - again encouraging it to accept a greater liability cap. 4. You don’t have to ask for, or give, indemnities. It’s very common for many data processing agreements these days to include indemnities, and the scope of some of these indemnities can be very wide indeed. An indemnity is essentially a contractual right to financial recovery on the occurrence of certain trigger events (so see point 3 above!), and recovery under an indemnity can be significantly greater than recovery under court-awarded damages. It’s very common to see wide-ranging indemnities in US contracts, but their use is far less common in European contracts. For that reason, if you’re a supplier, you might want to think about taking data protection indemnities out of your standard terms and offer them only as a fallback in negotiations; equally, as a customer, remember that you don’t need an indemnity to recover damages from your supplier and so removing an indemnity could be a lever for agreeing a higher liability cap. 5. What is the market standard? “What does everyone else do?” It’s a question that lawyers are asked so often. “I don’t want to offer any more liability than anyone else.” The truth is, right now, we don’t really know. Because the GDPR has not yet come into force, market practice around liability caps hasn’t yet arisen - but, rest assured, it will do, and 18 - 24 months from now, what is a ‘standard’ liability cap offering will be much clearer. Keep a watching brief on what your competitors are doing, and speak to peers whenever you can. 6. Context is king! There are so many other relevant considerations to take into account that it’s hard to enumerate them here. But consider too things like the life of the contract (easier to justify a higher cap for a long term contract than a short term contract), contract price (remembering that services are typically priced on a certain assumption of liability - and if liability goes up so too does price), and the degree of reciprocity in the contract (if you insist on unlimited liability from your processor, just remember it may well turn around and insist on unlimited liability from you too!)
- Although the concept of risk runs throughout the GDPR it is not specifically defined. Some examples cited in the Regulation, that are more likely to result in a high risk include: systematic automated profiling large scale monitoring of sensitive data systematic monitoring of a publicly accessible area on large scale Risk needs to be determined in the specific context of your own operations and there is no “one-size fits all” list. However consider in particular how you engage in activities: Processing sensitive data (ethnicity, political or religious beliefs and health, genetic or biometric data) involving vulnerable individuals or children processing personal data on a large scale automated profiling individuals likelihood and severity” of any negative impact of your processing activities on individuals by reference to the nature, scope, context and purpose of processing. For example a vulnerable individual may be particularly concerned about the risks of identification or the disclosure of information. Potential individual harms to think about include: discrimination, identity theft or fraud, financial loss, damage to individual reputation, loss of confidentiality, reversal of pseudonymisation or significant economic or social disadvantage. Implications: High risk then consider DPIA; Data breach notification; Record-keeping; Low risk then may not need to notify or to appoint representative if foreign based Mitigation: specifically you can implement specific suitable technical or organisational measures such as encryption to improve security; pseudonymisation or other steps to de-identify personal data or simply minimise the amount of personal data required for a project. To examine processing activities take a three prong approach: Identify any potential harms Evaluate the severity of the harm Consider the likelihood of the harm occurring. This will allow you to think about what you can do to minimise and mitigate the risks to individuals.
- The ICO is required by Article 35(4) of the GDPR to publish a list of types of processing we consider likely to be high risk and so require a DPIA. Our list, which is summarised above, is currently open for consultation until 13 April 2018.
- Although the concept of risk runs throughout the GDPR it is not specifically defined. Some examples cited in the Regulation, that are more likely to result in a high risk include: systematic automated profiling large scale monitoring of sensitive data systematic monitoring of a publicly accessible area on large scale Risk needs to be determined in the specific context of your own operations and there is no “one-size fits all” list. However consider in particular how you engage in activities: Processing sensitive data (ethnicity, political or religious beliefs and health, genetic or biometric data) involving vulnerable individuals or children processing personal data on a large scale automated profiling individuals likelihood and severity” of any negative impact of your processing activities on individuals by reference to the nature, scope, context and purpose of processing. For example a vulnerable individual may be particularly concerned about the risks of identification or the disclosure of information. Potential individual harms to think about include: discrimination, identity theft or fraud, financial loss, damage to individual reputation, loss of confidentiality, reversal of pseudonymisation or significant economic or social disadvantage. Implications: High risk then consider DPIA; Data breach notification; Record-keeping; Low risk then may not need to notify or to appoint representative if foreign based Mitigation:specifically you can implement specific suitable technical or organisational measures such as encryption to improve security; pseudonymisation or other steps to de-identify personal data or simply minimise the amount of personal data required for a project. To examine processing activities take a three prong approach: Identify any potential harms Evaluate the severity of the harm Consider the likelihood of the harm occurring. This will allow you to think about what you can do to minimise and mitigate the risks to individuals.
- Personal data breach” is “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed.” Important to note that the definition of a personal data breach is wide and for example includes unlawful destruction but tied into the requirement for strong security obligations Relevant Article 29 Working Party guidelines discuss the loss of availability of personal data and indicate that “If the lack of availability of personal data is likely to result in a risk to the rights and freedoms of natural persons, then the controller will need to notify”. Requirement to notify to the authorities without undue delay and not later than 72 hours … where there is a likelihood of risk … what exactly does that mean? Broad scope for discussion and may be an area where we can expect some guidance In addition to DPA’s also need to notify to data subjects where there is a likelihood of high risk so for example if you send out a cc instead of bcc but there is no other sensitive data no need to notify but if it contains results on individuals health status you will
- informing people about security breach important part of managing the incident but not an end in itself. Be clear about who needs to be notified and why e.g. individuals; the ICO; other regulatory bodies; other third parties such as the police and the banks; or the media