EU cybersecurity requirements under current and future medical devices regulation


Published on

Presentation delivered at Q1 MEDICAL DEVICE CYBERSECURITY RISK MITIGATION conference in Washington on 25 July 2016 concerning EU cybersecurity requirements under current and future medical devices regulation

Published in: Health & Medicine
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

EU cybersecurity requirements under current and future medical devices regulation

  1. 1. EU CYBERSECURITY REGULATION FOR MEDICAL DEVICES Q1 conference 25 July 2016 Erik Vollebregt
  2. 2. EU amends devices related rules with profound changes• Medical Devices Regulation / IVD Regulation • General Data Protection Regulation • Network Information Systems Directive • Get it right or get it wrong – mistakes will impact your company severely
  3. 3. EU approach to cybersecurity Currently: • Medical devices Directives (AIMDD, MDD and IVDD) • Risk management under MDD (EN ISO 14971:2012) • Software life cycle management (EN ISO 62304:AC 2008) • Data Protection Directive security and integrity of data requirements Near future: • Medical Devices Regulation and IVD Regulation software design requirements • General Data Protection Regulation privacy by design and default requirements • Network Information Systems Directive
  4. 4. On our way to Snowden 2.0?
  5. 5. Medical devices regulation
  6. 6. Current rules • Simple yet complex, because security is matter of • risk management under medical devices rules (EN ISO 14971:2012) • security measures prescribed in EN 45502-1:2015 and in the EN 62304:AC 2008 • data security under Data Protection Directive (article 17) • This means no single clear set of clear standards exists in one single place
  7. 7. Risk management Reduce risk ‘as far as possible’ – no room for acceptable risks (EN ISO 14971:2012 Z annexes):
  8. 8. Risk management Most developed thinking in in EN 45502-1:2015
  9. 9. EN 62304 § 5.2.2 Software life cycle requirements re security Typical cybersecurity points for SW requirements content
  10. 10. General EU security regulations and standards • IEC 80001 – Application of risk management for IT-networks incorporating medical devices • Plays important role in Swedish competent authority Läkemedelsverket in 2009 in the first version of their guidance “Proposal for guidelines regarding classification of software based information systems used in health care”. • This is not a harmonised standard under the medical devices directives, because it is directed at clinical institutions and not to medical device manufacturers.
  11. 11. Future rules under MDR / IVDR • More emphasis on risk management in Annex I of the Regulations – reduction AFAP • Annex I, 11.2 MDR: Devices shall be designed and manufactured in such a way as to remove or reduce as far as possible: […] (e) the risks associated with the possible negative interaction between software and the IT environment within which it operates and interacts; • Specifc chapter on software design requirements in Annex I
  12. 12. Future rules under MDR / IVDR • New chapter on software design requirements (MDR chapter 14, IVDR chapter 13) • Annex I, 14.2 / 13.2: “For devices that incorporate software or for standalone software that are devices in themselves, the software shall be developed and manufactured according to the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.” • Annex I, 14.3a/13.3a: “The manufacturer shall describe minimum requirements on hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended..”
  13. 13. Future rules under MDR / IVDR New design requirements on access controls: • Annex I, 15.8 MDR: “Devices shall be designed and manufactured in such a way as to avoid unauthorized access to the device as far as possible that would hamper the device to run as intended.” • This requirement is not mirrored in the IVDR • Likely because the active devices chapter in the MDR (chapter 15) is not mirrored in the IVDR
  14. 14. Data Protection
  15. 15. Data Protection Directive
  16. 16. Personal data currently in the EU • Everybody agrees the current EU system is • Fragmented • Outdated • Unclear • But, it’s still a good system that has produced a lot of good practices, among others Article 29 WP opinions on security related subjects, e.g. WP 223 on IoT:
  17. 17. General EU security regulations and standards: data protection • Protection against e.g. alteration and unauthorized access have everything to do with cybersecurity, as these impact directly on safety and performance of the device. • Non harmonization of the Data Protection Directive is a big problem because it leads to the situation of member states taking different views on security terms requirements. • Dutch NCA refers to ISO 27000 family as informal harmonised standard • Dutch sause ISO 27002 mandatory standard in Dutch healthcare market (NEN 7510, 7512 and 7513)
  18. 18. General EU security regulations and standards • Currently authorities mainly approach cybersecurity issues via Data Protection Directive, which features a secutiry regime in Article 17(1):
  19. 19. Privacy by design obligations for medical devices • WP 223: Controller has responsibility for security of IoT devices • Parties purchasing OEM devices and solutions will want privacy by design compliance warranties
  20. 20. Privacy by design obligations for medical devices WP 223 on end of life devices and remote monitoring / measuring devices
  21. 21. General Data Protection Regulation (GDPR)
  22. 22. New General Data Protection Regulation 2016/679 • Prepare now! • Virtually everything we currently do will become more complicated, more expensive, more administratively burdensome • 261 pages, 108 of Recitals • Regulation shall apply from 25 May 2018 • Regulation enters into force on 24 May 2016 (published in the Journal on 4 May), but two year transition • No grandfathering of existing consents etc • Many clients target compliance by May 2017 to allow stress testing of systems • eg ISO audits, impact assessment and employing DP Officers
  23. 23. What stays the same? • “Personal Data” remains a cornerstone • All means reasonably likely to be used to identify an individual • Remains a dynamic test • Data can still become “personal” as a result of subsequent technological or other reasons • Privileged status of “data concerning health” (and data re racial or ethnic origin) requires extra care • Consent to processing (and purpose limitation) remains a cornerstone • Capacity to consent remains a matter of national law (eg minors or guardians) • Focus remains on each act of processing of personal data rather than the collection or holding of data. The data controller must verify that there is a legitimate basis for the processing • Steps taken to anonymise or pseudonymise data = processing • Export of personal data outside EEA only permissible with adequate level of protection • Research derogation remains
  24. 24. What changes? • One stop shop with a lead supervisory competent authority • Fines/penalties for breach • Up to 4% of annual worldwide turnover for serious breaches (eg requirements relating to international transfers or the basic principles for processing) • Up to 2% of annual worldwide turnover for other breaches • Data protection becomes a fundamental right • More access rights (e.g. data portability) • Impact Assessments required • Prior approval of impact assessment of each act of processing (sets of similar processing can be grouped) • Profiling requirements • Intelligible explanation of automated processing logic
  25. 25. What changes? • Privacy by design & by default • Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures (e.g. such as pseudonymisation, which are designed to implement data protection principles (e.g. data minimisation). • Implement appropriate technical and organisational measures to ensure that, by default, only personal data which are necessary for each specific purpose of the processing are processed (e.g. amount collected, extent of processing, storage period and accessibility.
  26. 26. What changes? • Consent requirements tougher • Pseudonymous data remains personal data regardless of the number and nature of steps taken to key code • Biological samples = identifiable data • Exemptions for processing without consent • Exemptions not suited for outsourced processing in eHealth / mHealth services and not drafted for regulatory clinical data obligations or health technology assessments • Technical standards • Commission can issue technical standards related to implementation of GDPR requirements • Mandatory Privacy Officer
  27. 27. Impact Assessment Article 35 • PIA prior to processing – similar operations with similar risks can be grouped • Count on all grant funded projects and clinical trails or investigations or registries that require ethics approval needing PIA • Authorities will make lists of operations subject to PIA • Prior consultation of DPA regarding residual risks (article 36)
  28. 28. Impact Assessment
  29. 29. Security Data controllers and processors should implement appropriate technical & organizational measures to protect data from loss or any form of unlawful processing • Article 32 defines security principles Security measures must take into account (recital 78): • Nature of the data to be protected and consequences of security breach • State of the art • Security by design • Aim to prevent unnecessary collection and further processing of personal data • Overriding principle: Plan-Do-Check-Act • Data breach notification (article 33/34) • to DPA (<72 hours) and to data subject • processor must inform controller
  30. 30. Known unknowns and wide open doors • This means that member states can still require geofencing, hosting accreditation and things like that for processing of genetic, biometric and/or health data! • Only restriction is that these cannot be contrary to the requirements of the internal market and must be proportionate
  31. 31. NIS Directive
  32. 32. NIS Directive • Imposes security obligations on “operators of essential services” in critical sectors and “digital service providers” - will be required to take measures to manage cyber risks and report major security incidents • The NIS Directive is expected to enter into force in August 2016 • EU Member States will have 21 months to adopt the necessary national provisions • Following this period, EU Member States have six months to identify operators of essential services • assess whether services are essential for the maintenance of critical social and economic activities
  33. 33. Scope Applies to separate devices, medical devices related end-to-end services or groups of networked medical devices
  34. 34. THANKS FOR YOUR ATTENTION Erik Vollebregt Axon Lawyers Piet Heinkade 183 1019 HC Amsterdam T +31 88 650 6500 M +31 6 47 180 683 E @meddevlegal B READ MY BLOG: