Phy-gital Roundtable: Breakfast Roundup from Germany and Netherlands

02 May '15 | Debjyoti Paul

German Shoppers: Meet Them in the Fast Lane to Phy-gital

15 January '15 | Ralf Reich

Shoppers Will Share Personal Information (But They Don’t Want to be “Friends”)

15 January '15 | Anil Venkat

Modernize or Perish: Property and Casualty Insurers and IT Solutions

14 January '15 | Manesh Rajendran

Benelux Reaches the Phy-gital Tipping Point: Omnichannel Readiness is Crucial

13 January '15 | Anil Gandharve

The New Omnichannel Dynamic: Finding Core Principles Across Industries

13 January '15 | Debjyoti Paul

Technology does not disrupt business – CIO day 2014 Roundup

02 December '14 | Anshuman Singh

Apple Pay – The Best Is Yet To Come

02 December '14 | Indy Sawhney

Digital transformation is a business transformation enabled by technology

01 December '14 | Amit Varma

3 Stages of FATCA Testing and Quality Assurance

06 October '14 | Raman Suprajarama

3 Reasons why Apple Pay could dominate the payments space

18 September '14 | Gaurav Johri

Beacon of Hope: Serving Growth and Customer Satisfaction

05 August '14 | Debjyoti Paul

The Dos and Don’ts of Emerging Technologies Like iBeacon

30 July '14 | Debjyoti Paul

What You Sold Us On – eCommerce Award Finalist Selections

17 July '14 | Anshuman Singh

3 Steps to Getting Started with Microsoft Azure Cloud Services

04 June '14 | Koushik Ramani

8 Steps to Building a Successful Self Service Portal

03 June '14 | Giridhar LV

Innovation outsourced – a myth or a mirage or a truth staring at us?

13 January '14 | Ramesh Hosahalli

What does a mobile user want?

03 January '14 | Gopikrishna Aravindan

Regulatory Compliance and Software Quality Assurance

Posted on: 02 June '11

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,

  • Retain knowledgeable and experienced professionals who 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 it

 

Mindtree Blog Archives

Mindtree blog Archives are a collection of blogs by various authors who have independently contributed as thought leaders in the past. We may or may not be in a position to get the authors to respond to your comments.