I'll offer some suggestions, although I don't like the origin of
this question; I don't mean this to be personal: It sounds like a case of "I know they are doing
something wrong, I just don't know
what."
CS Validation (or
Assurance, in some areas) is a
regulatory necessity only when the CS has been delegated some responsibility as spelled out in the regulations. Some common areas of regulatory responsibility where CS are used include:
- Production controls/testing (e.g. using computerized systems to control batch production in pharma)
- Calibrations and Equipment Maintenance
- Management of Records (storage, revision)
There may be others depending on the industry. Additionally: Many regulated industries may have special regulatory requirements around electronic approvals of records... but approvals themselves are "adjacent" to the other regulations.
In other words, for a particular set of US regulations: 21 CFR Part 11 describes necessary characteristics of electronic records/signatures if they are used... it is all about necessary implementation details and not necessarily foundational. But I digress.
I would NOT be so quick to shift this to QA, depending on the nature of the systems and how those systems are used in the business... no matter the industry. I was in the QA Non-Product Software space for years... so it isn't as if I can't see the sharp edges, and I don't want to downplay CSA/CSV as non-serious. I will write this: In my industry I never had an actual regulatory reviewer or auditor ever ask about the validated state of a computer system; they usually ask something like "what do you use?" and that was the totality of their ask. I hold onto my bitterness due to a series of 3rd parties that nurtured panic (and collected $millions) for no-value added work in the area of NPS validation.
If the system is working, and is not causing issues... I wouldn't go looking for trouble(*1).
Typically the shortcomings of having an IT team having most of the responsibility are:
- They often don't make changes in anything like a controlled way... sometimes not even in a planned way!
- They don't have a complete view of how the CS is actually fulfilling a regulatory requirement.
Typically the shortcomings of have a QA team having most of the responsibility:
- QA teams tend to approach NPS validation/assurance as "paperwork is queen"
- QA teams often default into "only knowing as much about a system as they want to know"... that is "I'm just Quality, someone else knows the answer."
(*1) There are some low-intensity efforts that could be done if they are not currently done. Without knowing the details of how CS is used in your pharma company I hesitate to make any detailed suggestions.
