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.