Under 21 CFR part 11, it is required to validate the electronic systems that deal with electronic records and signatures. It demands documentation to show compliance with the regulations stated under. This documentation was found heavy and strenuous to the companies. Then the FDA produced “Computer Software Assurance for Production and Quality System Software” draft guidance in 2022.
Read below to know more about Computer Software Assurance, its role, process and more.
What Is Computer Software Assurance (CSA) In Pharma?
The computer Software Assurance is an approach, a risk-based one, for establishing and maintaining the confidence that the software will perform the activity for which it is intended for. It considers the risk of the device’s compromised safety and quality and determines the level of assurance activities or effort needed to establish such a confidence in software.
Computer Software Assurance VS Traditional Software Validation?
The major difference between Computer Software Assurance and Computer System Validation is that the prior is a risk-based approach whereas the latter is focused on the system as a whole. Key points and their influence in CSA and CVS are given in the table below.
| Feature | Computer Software Assurance (CSA) | Computer Software Validation (CSV) |
| Risk based approach | + | – |
| Process based | – | + |
| Testing focused | + | – |
| Documentation focused | – | + |
| Reduced time and cost | + | – |
| Testing features, functions or operations with high risk rather than a comprehensive validation of entire system | + | – |
| Increased chances of script level, manual errors, bugs or configuration errors | – | + |
Also Read: Regulatory Information Management Software
Role Of CSA In Pharma & Medical Device Regulatory Compliance
As per 21 CFR part 820.70 (i), it is required to validate the software used in production or quality systems before its approval and issuance. Computer Software assurance allows for the validation but in a risk-based approach and helps in establishing and maintaining a validated state through the entire lifecycle of the software used for production or quality systems. It also allows for continuous performance monitoring.
Computer Software Assurance involves assessing the software for its safety and reliability and it also helps to assess whether the software systems maintain the accuracy and reliability of the data. It is the least burdensome approach and doesn’t need to validate the entire system but in turn the validation happens proportional to the risk level.
By allowing manufacturers to make use of risk-based testing, unscripted testing, continuous performance monitoring, and data monitoring, as well as validation activities performed by other entities like the developers, suppliers, etc the computer software assurance approach provides flexibility and agility in helping to assure that the software maintains a validated state which is consistent with the 21 CFR part 820.70(i).
Computer Software Assurance calls for ensuring product safety, quality and efficacy, data integrity, clear documentation…, which all contributes to patient safety which automatically calls for regulatory compliance.
Computer Software Assurance Process In Pharma
The CSA process can be divided into 4 parts. They are shown below:
Identification Of The Intended Use
Determine whether the software is intended for use as part of production or quality system.
Generally, software can be categorized into 2, Direct Impact and Indirect Impact.
- Direct Impact: The one that is being used directly as a part of production or quality system process
- Indirect Impact: The one that is used to support the production or quality system process.
Determine which category your software falls into. While determining the intended use, it is important to understand the features, functions and operations of the software thoroughly. When the software complexity increases, every function, feature or operation can have different intended use and each of them can contribute to different risk in the quality of the product. Identifying the intended use will aid in the determination of a risk-based approach.
Where Does 21 CFR Part 820.70(i) Apply To?
21 CFR part 820.70(i) applies to both the categories, direct and indirect impact. Software that is intended to be used directly as production or quality system
- Production processes, inspection, collecting, testing and processing of the production data.
- Quality system processes, collection/processing of quality system data, maintenance of the quality record established as per the Quality System regulation.
Determination Of Risk-Based Approach
Determination of the level of risk occurring If the software has compromised to function as it is intended to be.
The foreseeable risks are identified, classified and suitable assurance activities are determined in a risk-based approach. A way to perform this for medical devices will be to list out all the likely failures and classify them based on the occurrence and impact. A heat map example used to perform risk assessment is given below:
OCCURRENCE | IMPACT | |||
| High | Medium | Low | ||
| High | Intensive Check | Intensive Check | Standard Check | |
| Medium | Intensive Check | Standard Check | Minimal Check | |
| Low | Standard Check | Minimal Check | Minimal Check | |
The risk-based approach of the Computer Software Assurance suggests classifying software as high process risk or not high process risk. Determine the risk level if the software is to fail to perform as intended, high process risk or not high process risk.
High process risk is when the software fails to perform as it is intended to be which may result in quality problems and foreseeably compromises the safety. Eg: A software that can inspect, measure and analyze the acceptability of the product without manual intervention.
Not high process risk is when the software fails to perform as it is intended to be but it may not cause any quality risk problems that foreseeably compromises the safety. Eg: A software that is used in monitoring and managing Corrective and Preventive Actions (CAPA).
Proper execution of this step is required for the determination of assurance activities that are appropriate.
Determination Of Suitable Assurance Activities
Identification and implementation of assurance activities which equals the risk level.
For high process risk, the assurance level must be proportionate with the medical device risk. Level of assurance must be proportionate with the process risk for not high process risk. Process risk is any failure that has the potential for compromising the production or quality systems.
Testing Methods Used
The test methods used are scripted testing and unscripted testing.
FDA suggests to perform scripted testing for a high process risk. As the name suggests, scripted testing involves writing down the actions, step-by-step. The actions performed by the tester along with the objective evidence must be documented. 2 types of scripted testing can be done: Robust scripted testing and Limited Scripted Testing.
- Robust Scripted Testing: The entire software is tested to make sure that the existing working system is not affected by new functionalities or features.
- Limited Scripted Testing: This is a combination of scripted and unscripted testing.
Unscripted testing is suggested by FDA for a not high process risk. Unscripted testing is an approach of dynamic testing, and the tester do not follow a step-by-step instruction and doesn’t need a large amount of documentation. To perform this kind of testing, the tester must have adequate knowledge about the software features, process flow and SOP’s. Unscripted testing can be
- Ad-hoc Testing: Random testing of the software features without following a specific test protocol or documentation of the evidence.
- Error- guessing: The testing is done based on the knowledge of the tester about past failure or failure modes.
- Exploratory Testing: To design and execute tests, the tester makes use of their own experience.
Establish Suitable And Sufficient Records
Capture appropriate and sufficient evidence that demonstrates the software was assessed and it performs as intended to be.
FDA requires evidence for each and every action that is claimed to be done. Proper documentation must be done. To prove that the software function, feature or operations are assessed and performed as intended, objective evidence is demanded by the FDA. Elements needed to be documented are:
- Software’s (feature, function or operation) intended use
- Software feature, function or operation risk determination
- Based on the assurance activities, description of the testing performed (type, aim, activities)
- When and who (name) details of the testing/assessment conducted.
- Conclusion statement that declares the test acceptability
- Issues found like deviations or failures… and its disposition
- An established review and approval (when appropriate). Eg: date and signature of an individual (with signatory authority) when necessary.
Strategies For CSA Compliance In Pharmaceutical Industry
Compliance with Computer Software Assurance is essential to make sure that the software is performing its functions as it must be and can be trusted. Regulatory authorities require software to be validated and CSA is done in a risk-based manner. Here are some strategies for the compliance of CSA in pharmaceutical industry:
Understanding Computer Software Assurance and knowing that it is a least burdensome approach when compared to Computer System Validation. Follow a risk-based approach rather than testing the entire system. This allows for a faster approach to identify the level of assurance activities to be conducted.
CSA calls for increased flexibility compared to CSV. Training the employees to increase their expertise and knowledge on the software as well as computer system assurance must be implemented. CSA documentation is not exhaustive when compared to CSV. So, the documentation burden is decreased.
Staying updated with the applicable regulatory requirements and the CSA guidance is important in CSA compliance.
Challenges In Implementing CSA In Pharma
Some of the major challenges in implementing Computer Software Assurance in pharma are:
- Regulatory Contradictions: The CSA guidance document states that the infrastructure supporting software like the networking or continuity of the operations do not require qualification or documentation. This is in contradiction with the EU GMP Annex 11 which demands the qualification of IT Infrastructure.
- Requires knowledge: For error guessing and exploratory unscripted testing, the testing is conducted based on the knowledge and experience of the tester. The tester needs to know about the software thoroughly like the working knowledge, process flow, failure modes and history of failures.
- Testing of new software: Unscripted testing like the exploratory and error- guessing cannot be done on new software as these are conducted based on prior knowledge and experience of the tester with the software. In this case, it is forced to conduct scripted testing.
- Documentation: As per the CSA guidance document it is stated that unscripted testing doesn’t need a large amount of documentation. Still elements to be recorded have been listed out which equals scripted testing.
- People based vs Process based: People based is unscripted testing and process based is scripted testing. When compared to process based, for companies people based is riskier. The latter depends on the knowledge depth and experience of the tester.
Since this is a new approach introduced by the FDA, there might be incomplete or difficulty in understanding. Moreover, companies may still prefer to go with the traditional, more established method.
Also Read: Best Pharma Labeling Management Software
Conclusion
Making the shift to CSA can feel a bit overwhelming at first — especially if your team has been following the same validation routine for years. We’ve spoken to clients who weren’t sure whether changing their approach was worth the effort. But once they gave it a shot, most were surprised by how much time and effort it saved them.
We’ve seen many teams hesitate, not because they don’t care about compliance, but because the process feels unfamiliar. That’s exactly where the right support can make a difference.
At Artixio, we don’t just follow the regulations — we work alongside you to make them practical. Whether you need help understanding CSA from the ground up or just want a better way to approach validation, we’re here to walk you through it.
Want to talk? Drop us a note at info@artixio.com.
FAQ’s
What are the four steps involved in the CSA framework?
The four steps involved in the CSA frameworks are identification of intended use, determination of risk-based approach, determination of assurance activities and establishing suitable records.
Which testing method does not require a test plan?
Unscripted Testing is the testing method that does not require a scripted step-by step procedure. This type of testing is dynamic and is conducted depending on the tester’s experience and knowledge about the software.
Why is it important to conduct Computer Software Assurance?
It is important because it is a part of regulatory compliance. As per the regulations of 21 CFR the software used in production and quality systems is required to be validated. After which only the approval and issuance is allowed. It also gives a confidence that it will perform as it is intended to be.
When are scripted and unscripted testing used?
FDA recommends to use scripted testing for high process risk and unscripted testing for a not high process risk.
