Re: Off-the-shelf SW S.O.P.; for non-product QSR regulated and non-regulated applicat
Might help to clarify things a bit. There's a wide array of types of software that I would consider 'subject' to the QSR. I'll try to be brief (but in doing so, may miss some stuff). Note: being subject to the QSR and "acquisition, testing, and usage" are quite different.
1) There is software used in the construction of software (e.g., compilers, IDEs, etc.). I would consider these subject to the QSR since they directly affect quality. If uncontrolled changes are made (patches, revision upgrades), you would not be able to re-create a particular build. We have typically not validated these systems with the rationale that the output IS 100% verified (or at least reasonably so).
2) Software used in support of software development (e.g., code repositories). Since these 'touch' the software and have change tracking concerns (security), they are subject to the QSR and probably should be validated (mostly from the perspective of change tracking and security, not general functionality).
3) There is software used in support of design (Solidworks, etc.). These, too, are subject to the QSR since they directly affect quality. These might need to be validated since it's likely the electronic records kept by the systems will be the official record.
4) There is software used in general support of the design effort (e.g., problem / issue tracking tools). Clearly these are subject to the QSR but depending on how you use them, may or may not require validation. (This point is argued ad nauseum in a variety of formats but so far my approach hasn't been cited as inappropriate - so far). I have always used these as just a means to print the final paperwork and so I don't validate. A very rational argument can be made that the electronic records may still be used (e.g., for tracking and trending after closure) so you have to decide for yourself. A risk-based (and documented) decision helps.
5) Software that is incorporated in deliverable software (libraries, protocol stacks, etc.) are clearly subject to the QSR. Some level of validation beyond saying it's sufficiently tested in the product testing is probably warranted (assessment of open issues, for one).
6) Enterprise level applications (MRP, ERP, etc.) are subject to the QSR as they touch various aspects of quality. These are almost always validated.
7) Enterprise level applications that DON'T touch quality (payroll systems, HR systems - that don't manage training records!!, etc.). Typically not subject to the QSR and are typically not validated (per standards; however, undoubtedly tested thoroughly).
I don't think you can cover ALL the types in a single SOP. What you'll want to do is have a Validation Master Plan to address how you manage non-product software that impacts quality and then have a (product) Test Plan to address anything that is incorporated in your product software.
Hope that helps. Probably way more than you expected but I didn't really see bounds in your question.