Software Quality Assurance and 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 the insurance companies. For software used in the pharmaceutical industry, the FDA enacted legislation called CFR21 Part 11. 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 Specially Designated Nationals.
Penalties for non-compliance quickly reach into 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 would look good in orange overalls and “don’t forget to wave when you see me 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 process was under regulatory compliance but never provided insights on 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 and Testing 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 CFR Part 11, 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 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 one thing worse than having no controls; it is thinking you have the controls.
Here are some helpful hints as you encounter regulated applications,