3.2.2 Product Risk Assessment and Mitigation

This category deals with process steps for those who are developing a new app, or an upgrade to an app, prior to its being deployed to consumers. Degrees of risk should be assessed and mitigated according to the intended use of the app. In general, risk management should manage security, privacy, safety, and other types of risks such as potential app failure scenarios, events that could lead to undesirable outcomes, probability and severity of risk, and mitigations or resolutions. One size does not fit all. For example, if apps handle sensitive personal information or give health interpretation or advice, higher degrees of risk are involved than for apps that do not collect personal information or do not interpret or advise. If some information identified during this step should be disclosed to consumers, that is stated in the “Informing Consumers/Users” section.

Related Regulations and Standards

While mobile computing environments may introduce some specific threats not present in non-mobile computing, the principles of risk management are the same across environments, so some standards and regulations are cited, even though they are not mobile-centric. Documents (listed alphabetically below) were sources of some cMHAFF criteria for risk assessment. Other useful references on risk assessment are listed in the Appendix. While some are realm-specific, they have much material that is applicable beyond their countries. Realms are listed in parentheses, if not explicit in the title.

• Andalusian Complete list of recommendations on design, use and assessment of health apps
  http://www.calidadappsalud.com/en/listado-completo-recomendaciones-app-salud/
• British Standards Institution Publicly Available Specification (PAS) 277:2015 Health and wellness apps – Quality criteria across the life cycle – Code of practice:  Recommendations and guidance throughout the app’s product development life cycle
• French Good Practice Guidelines on Health Apps and Smart Devices (Mobile Health or mHealth). https://www.has-sante.fr/portail/upload/docs/application/pdf/2017-03/dir1/good_practice_guidelines_on_health_apps_and_smart_devices_mobile_health_or_mhealth.pdf
• National Institute of Standards and Technology NISTIR 8144 Assessing Threats to Mobile Devices & Infrastructure, The Mobile Threat Catalogue (USA)
  https://nccoe.nist.gov/sites/default/files/library/mtc-nistir-8144-draft.pdf (context and background information)
  https://pages.nist.gov/mobile-threat-catalogue/application.html#vulnerable-applications  (actual catalog of threats, specifically the “Vulnerable Application” category, which is the part of the threat catalog closest to cMHAFF)   
• Open Web Application Security Project (OWASP) Top 10 Mobile Security Risks: https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10  This is focused on app developers, so most of it is pertinent to cMHAFF, and for each risk, there are suggested mitigations.
• OWASP Secure Coding Practices Quick Reference Guide. https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide. This provides resources for developers that can assist in implementing secure coding practices. It is recommended that developers adopt secure coding practices so that applications are developed with an emphasis on security vs having to apply security measures to protect the application. 

Implementation Guidance

While later sections in this standard include specific security and privacy controls to be applied to consumer mobile health apps, all products addressing health issues, regardless of their type, must be subjected to an overall risk analysis. This risk analysis may uncover the need for additional security controls over-and-above the conformance statements included in this document. As such, a risk analysis provides an additional layer of considerations such that conformance statements are not misused as a simple checklist in which it is assumed all security risks have been addressed if an app is in compliance with the conformance statements in this standard. For an app/product, the risk analysis should be conducted for the target environment(s) where the app will actually be used by consumers. Because of the diversity of consumers, such a risk analysis is wider ranging and more challenging than a risk analysis for the development organization’s own environment.