Bloggo back to the blog
Compliance & Software Quality Assurance-->
Software compliance in a regulated environment is a serious business concern and is no simple matter. Companies are faced with an ever increasing number of regulations but in addition have to ensure they maintain and validate the compliant state for the life of the software. In the financial industry, SOX Sarbanes-Oxley, was enacted to protect shareholders from fraudulent practices. In the EU, similar legislation called Solvency has been enacted upon insurance companies. For software used in the pharmaceutical industry the FDA enacted legislation call CFR21 Part11. In healthcare, HIPAA Title II includes an administrative simplification section which mandates standardization of healthcare-related information systems and protecting information assets of patients. In the shipping and logistics industries, Home Land Security has enacted several regulations contained in the Office of Foreign Assets & Controls, OFAC, and special designated nationals. Penalties for non-compliance quickly reach into the many thousands of dollars and the negative public exposure can damage a company’s reputation. In the case of non-compliant software, your company might be forced to go back to paper until all the exposures are mitigated. My experience spans most of the above and for some companies I actually held the title of compliance officer. I used to joke with my colleagues that I look good in orange overalls and don’t forget to wave when you see my on the side of the highway cleaning litter. Thankfully that never happened.
What was common across the above regulatory bodies is that they would only state what data and/or processes was under regulatory compliance however they provided no insight as to how to attain the compliant state. With that in mind, I would listen to interpretations and opinions about compliancy and what others in my industry were doing. In the end, it was my company’s appetite for risk that guided what was actually performed and validated. Risk adverse companies would error on the side of thorough validation whereas risk accepting companies would seek for the minimum level of validation. As QA professionals you still need to articulate where the risk line meets the level of validation and the effort/cost to attain it. When I was dealing with the CFR Part11 I was surprised to find out that all adjacent hardware/applications used in conjunction with regulated data, (i.e. Documentation, Requirements & Test Case Management Repositories, Defect Tracking, Source Code)were all under regulatory compliance if they processed regulated data. Each system had to be validated and certified to be compliant before it was authorized to be used with the application under test. An auditor once told me there is only thing worse than having no controls; it is thinking you have controls.
Some helpful hints as you encounter regulated applications
• Retain knowledgeable and experienced professionals that understand regulations
• Attend seminars and alike to increase your exposure to what is going on in your industry
• Look for software that is designed specifically for compliance and buy rather than build
• Understand what risks and impacts will surface due to non-compliance
• Document your processes and follow them
• Segregate your regulated data from the rest. No need to apply the level of validation where it is not needed
• Perform an internal audit and cite exposures. Follow with an action plan
• Pay for a 3rd party external audit (if the risks are high enough) to reduce exposure
Communicate (quantify) the effort to attain the compliant state and more so, what will it take to maintain.