Regulatory Open Forum

 View Only
  • 1.  QMS Software Validation - Environmental risk

    Posted 28-Jan-2019 15:32
    Hello fellow RAPpers,

    I'm using ISO 80002-2:2017 for a current software validation project and I ran into a part that I don't understand. In the "Analysis of process failure risk" section, there are three types of risk listed out: 
    1. Risk of harm to humans;
    2. Regulatory risk;
    3. Environmental risk

    I understand 1 and 2 but in the Environmental risk description it included both physical and virtual environment.
    Does anyone have an example of a virtual environmental risk? 
    Would it be a risk of the software to the environment or the risk of the environment on the software? Both? 

    Thank you for your help,

    ------------------------------
    Maddi Myers
    Regulatory and Quality Project Manager
    Edina MN
    United States
    ------------------------------


  • 2.  RE: QMS Software Validation - Environmental risk

    Posted 28-Jan-2019 16:30
    Hi Maddi.

    Let me start out with the fact that I am not very familiar with this ISO standard so my assumptions might be completely off the mark in this response.  If they are, please accept my apologies in advance.  With that said, I would read this to be environmental risk for something going wrong with the software and the environment being exposed to something that could cause damage.  I think about this in the classic "chemical company" way (yes, I was a regulatory person for one of the largest chemical companies in the world in an earlier lifetime!) where the software is essentially managing the production process of when to add which chemical under what circumstances and how to control the reaction such that you don't have a release of the chemical or precursors into the environment.  The other possibility to think about is the risk of the software to the enterprise itself.  Could the software cause errors with other systems within the company?  If so, how would they be detected?  Or could the software allow for an attack on the company's other systems from outside the organization (or worse from inside the organization) where the access point is through say a web-enable software system.

    Like I said, I am not readily familiar with the standard itself, but these are the two paths that I find that might make a certain amount of sense.  Look forward to other's insights on this one!​

    ------------------------------
    Victor Mencarelli
    Director Regulatory Affairs
    United States
    ------------------------------