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?