Periodic Reviews vs Re-Quelification for PLC/SCADA

Hi everybody!!

I have performed the periodic reviews of all our PLC/SCADA systems, in which we ask for training, security, critical diagrams, specifications, backups, change control, incidents, etc.

The question is, if everything goes good with the periodic review, is it necessary to perform a re-qualification of the system? or can I prove that my SCADA system is “ok” with out a re-qualification?.

Thanks in advance!

The purpose of the periodic review is to demonstrate control of the system and that the system is fit for it intended use based on the data you have available during the review period. If the conclusion is that users are trained, the system is secure and data retention is under control, change controls have been minimal or robustly tested during implementation etc. then it would be safe (low risk!) to conclude that your system remains in a validated state with no further testing required. If there have been a significant number of changes, especially major changes to the system, or deviations associated with the system then it is fair to say that your system in its current validated state is presenting a high risk for some reason. You would want to establish the root cause and then base your re-qualification strategy around any remediation required.

If you immediately work on the assumption that you need to keep re-qualifying the system then why perform the risk-based periodic review in the first place?

Thanks erez, I’m agree with you, the question is because some colegues told me that it is necesary peform a periodic review once a year and the re-qualification each three or four years depending on the complexity of the system. But you said well in the second paragraph of your reply.

Regards!!

If your (internal) procedures say that you have to perform a periodic review once a year & re-qualification every 3 or 4 years, they you need to (irrespective of the logic of doing so).

I don’t fully agree with erez’s approach. Changes, I believe, should be rolled out in a controlled fashion and only after the system has been validated with the changes. Getting into discussions about “significant” changes and “major” changes tends to get controversial. When you roll out changes, you identify the risks, identify the validation required, and then do it.

There is some merit, I believe, in doing a periodic review. If, for example, you’ve deployed on a system that you don’t have complete control of (e.g., OS patches applied by the IT department over a holiday period), then a periodic review can be used to at least recognize that something may have changed and allow for any remedial actions (like a short retrospective validation). There also may be cases where the network configuration is changed which, in some cases, could impact validation.

I will certainly agree with erez that the system should continually be re-qualified (as changes are incorporated) and that certainly minimizes the need for a periodic review (and eliminates the 3 or 4 year review). But those things need to be addressed in your Validation Master Plan.