June 2022
The biggest fear companies deal with when moving to cloud apps is related to losing control over their applications. How can we maintain ownership while a third party has the ability to change our application?
The answer is creating a process that gives you better control over the system without stopping or delaying updates. The foundation for this process is a risk based approach.
The changes in the technology we use are also leading to a change in the terms we use in software validation
For Example, consider if the traditional IQ document is still applicable when using off-the-shelf SaaS applications. In my view, the IQ should fit to what is actually installed so the traditional templates will probably not work.
Another example for changes in methodology is the double V model. As vendors are creating more complicated off-the-shelf setup, the validation activities performed by the vendor are crucial when validating the applications in your organization. Therefore, the vendor will be expected to have a V model deliverables and supporting documentation but the organization using the application should perform its own V model or at least a partial one, to cover the changes and adoption to its needs, procedures and requirements.
Another item to consider is who is responsible for backup and disaster recovery. Do not assume it’s the vendor's responsibility on the one hand, and on the other hand having a full disaster recovery plan internally may not be feasible for some of the solutions commonly used in the market.
Focus on the risks
Have a detailed risk matrix generated based on a technical and functional analysis of the system together with the introduced changes. Having a full understanding of the impact of changes and upgrades is critical in order to successfully own SaaS applications.
Then, review this risk matrix with a focus on the higher risks. This is the time to exercise critical thinking and understand where things can go wrong based on the system recommendations.
At last, you should create an action plan which tests tasks you perform. Again - focusing on higher risks.
This approach will bring you to a place where you own your processes, you own your system and its changes and you understand why you are doing specific tests, not just running them!
Let’s take a look at what a SaaS validation process can look like
SaaS validation is an ongoing process that starts with an SOP that supports ongoing assessment. This is unlike the traditional project based approach, where we defined the validation scope prior to every cycle.
In the suggested modern process, consider having the assessment scope in the SOPs and work instructions in order to avoid unnecessary document preparations before the impact is clear.
The process starts with a periodic risk analysis where we will review the release notes, identify the impact of changes performed either by your company’s IT team, the app vendor or the platform vendor.
This step is critical as the results of the risk and impact analysis step are a key factor in creating a reliable and ongoing process.
Once we have a clear understanding of the changes to the system, review the associated risk with each change and get your team’s view on ways to mitigate these risks. This is the time to use the joint experience of your team to get a good action plan based on the identified risks. If you already follow CSA guidance, the action plan would be a combination of scripted and unscripted testing. If your company is still following the traditional CSV, the action plan should be a list of the tests required to mitigate the identified risks.
After completing the risk analysis phase, it’s time to review and update the validation documents. Remember, we are talking about an ongoing process which will take place every few months so we expect document updates rather than writing new versions from scratch.
If you are required to perform testing as part of your action plan, review and update the validation plan, requirements and finally the validation protocol itself.
It’s important to note that when implementing ongoing processes, it is possible to have validation cycles which will not require any documentation update. For example: a review which is performed after a platform update and has no identified impact on the processes in use by your company. In that case, you need to be able to document the process and the risk analysis decisions. Make sure your SOPs support this scenario when adopting an ongoing approach.
The 3rd step includes executing the test steps as described in the action plan and updating the traceability matrix. For companies following the CSA guidance, this step will include all test steps - scripted and unscripted. One tricky question you may get is how to handle the traceability matrix if you choose not to do full testing of all items. Since we are talking about an on-going approach, it is unlikely to retest all the system every upgrade. Therefore, we focus on testing elements with higher risk associated with them and combine unscripted testing if the CSA guidance was adopted by your company.
This change in approach means that in the traceability matrix, you may have requirements without test steps in the current execution. In order to make sure all requirements were tested, you may choose one of following alternatives:
Having reference to tests from previous validation cycles in the traceability matrix so you will have test reference to each requirement. Or, alternatively, reference only the steps performed in the current validation cycle and keep the previous traceability reports as reference to the new report. This option is possible when working with digital validation platforms which allow easier accessibility and reference to historic data.
The 4th step includes writing a validation summary once all test steps are executed successfully and passed. This step is similar to the traditional execution methodology. However, in the suggested modern approach, after completing the validation summary, we would add KPI updates and coordination of the next validation cycle.
Reasons to include automation in your validation cycle
- Automation reduces human dependencies which is one of the main reasons for error.
- Automation minimizes recurring tasks in the process and makes it more effective and efficient. This is especially true when implementing an ongoing approach.
- Automation allows you to use experienced personnel for critical thinking rather than repeatable tasks - performing the validation activities is still the company’s responsibility. Focus the efforts of your team on the important risks.
- Automation is key in creating consistency and accuracy - Automation and digitalization will help in creating clear and consistent deliverables.
- Lastly, save time & money - Like in any other field, technology is the future. You can’t go digital and keep your historic manual process. Now’s the time to embrace automation.
About Validify
Validify Inc. is a Salesforce partner, the vendor of Validify, a Salesforce application that automates the risk analysis and computer system validation (assurance) processes for regulated companies, managing their product related processes on the Salesforce platform. Validify is an automated solution providing risk analysis of any Salesforce org and generating all necessary verification and validation documents based on risk and other predefined, configurable parameters. Validify also provides a real-time status of your org’s compliance and identifies changes in your org automatically.
About the author
Ido Raz is a Co-Founder and CEO of Validify, a cloud technology and Salesforce enthusiast, former CTO of a Salesforce application company and PMP certified. With years of experience in Salesforce, design & delivery of compliance solutions for regulated industries.
Want to hear more or book a demo? Click here
