We are a medical device company and we are about to replace our Helpdesk software. The processes we manage via Helpdesk software are the standard ITIL processes including Incident Management, Service Request, Problem Management and Change Management. In summary, users will log their problems and requests through this system and the IT Service desk will resolve. The Change Management module will be used to control changes, typically software changes to the production environment. We will be following the standard implementation lifecycle i.e. Design > Develop > Config > Test > Deploy. We will be conducting extensive user acceptance training. What level of software validation is required ?
Can you clarify the scope of the software? Is it used to collect problem / incident information from the medical device (product) or your quality system processes? If so, then validation would likely be warranted (rigor scoped appropriately by risk assessment). If it is used to collect information about things outside that scope, then probably not.
The lifecycle and training have no bearing on the decision on whether to validate or not. (But if it does have to be validated, those aspects are important inputs.)
Thanks for your response Yodon and apologies for my delayed response. The Helpdesk will not process incidents or requests connected with medical devices but may be used to process incidents and requests relating to applications (ERP, QMS, SPC) that support quality and manufacturing processes.
No worries on the delayed response… no expiration date. 
From your feedback, it doesn’t sound like any validation would be expected from a regulatory perspective. Assess the impact if things went wrong. Will it adversely affect quality of product or records maintained? Things to consider would include security (if unauthorized access was allowed, would there be issues), data (if data is lost or corrupted, would you lose information vital to operations), maintenance (if security / OS patches break the system what is the impact), and general impact on operations (if the system failed in any way, what would the impact be).
Document your thought process and rationale for not validating or for reducing scope of validation.
A good method to follow is to have a Validation Master Plan (or Master Validation Plan) which establishes the process and decision logic for making such decisions.
Last point: the reason to validate shouldn’t be just to satisfy regulatory requirements. If you think about it, validating just makes good business sense. If you go to the time and trouble of implementing and deploying a system, wouldn’t it make sense to get a high level of confidence that the system will operate as needed?