What Data Integrity Means For Validation

After much fanfare, the general data protection regulations (GDPR) was approved by the EU parliament on April 14, 2016. The enforcement date for this regulation is May 25, 2018. If companies are not in compliance at that time the potential for heavy fines is inevitable. The EU general data protection regulation replaces the data protection directive 95 /46/EC and was designed primarily to harmonize data privacy laws across Europe and to protect and empower all Eve’s citizens data privacy and reshape the way organizations across the region approach data privacy. The regulation has a profound impact on businesses that operate in the EU. Maximum penalties may be as high as 4% of annual global turnover or €20 million (whichever is higher).

In recent years, we have seen massive data breaches at companies which has exposed private information and other sensitive information without consent. Many of these breaches have been due to cyber-attacks against companies of different sizes. The newspapers are full of such data breaches. The new GDPR regulation requires that breaches be reported to the relevant regulator without undue delay and where feasible, within 72 hours of becoming aware of it unless the breach is unlikely to result in a risk to the right and freedom of individuals. Data subjects must be informed without undue delay with the breaches likely to result in a high risk to the data subjects’ rights and freedoms unless the data has been rendered unintelligible to any third party (for example by encryption). Data processors are required to inform data controllers of any breach without undue delay.

What does all this mean for validated systems?

If you operate in the EU and your validated systems include sensitive data or data which may be of a personal nature, such as patient information, you are subject to the guidelines included within the GDPR regulation. You also need to look at data integrity and security practices around the validated system. We recommend strongly the Cybersecurity Qualification (CyQ ) discussed in a previous post. The CyQ assesses a firm’s readiness to protect itself against the cyber-attack. This could go a long way to meeting the requirements of GDPR since the cyber security qualification requires documentation of your security controls.

I recommend reading GDPR and getting used to it before May 2018. Assess your controls within your validated systems environment to determine how vulnerable your systems really are and your readiness to comply with this regulation. I assure you more will be forthcoming about this topic in the months to come.  WATCH THIS SPACE.

Installation Qualification (IQ) in the Cloud

Installation Qualification (IQ) is designed to ensure that systems are installed in a consistent, repeatable manner.  For on-premise systems, validation engineers typically install enterprise software from pre-defined vendor media.  Formerly, media was inserted into corporate servers and the full installation process is documented.  The purpose for installation qualification sometimes gets lost in the weeds.  Given the complexity of today’s enterprise and desktop systems in virtualized cloud environments , the need for installation qualification has never been greater.

The question often gets asked, “… how do you conduct installation qualification in the cloud?”  The answer to this question requires the need to think differently about how software is deployed in today’s validated systems environments.

Cloud deployment models include Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS).  The validation strategy changes depending on the deployment model.  In all models, the virtualization, servers, storage and networking are managed by the vendor.  In the PaaS model, the runtime, middleware and O/S are also managed by the vendor.  It should be noted that cloud services are typically provisioned using automated tools thus, the installation process is not the same as with on-premise environments.

Therefore, to conduct IQ in cloud requires four essential stages:

  • Observation or Documentation of the Provisioning Process
  • Draft Installation Qualification Test Scripts For Pre-Approval
  • Execute Pre-Approved IQ Test Scripts
  • Summarize Installation Qualification Phase

We recommend for all cloud models the observation (to the extent possible) the provisioning process.  For some applications such as SaaS, this may not be possible.  You should observe the setup and configuration of all virtual servers and parameters used to load software.  The sequence of events may be key.  We have observed with some applications that the provisioning process (which itself is automated) may fail for a variety of reasons.  Thus, do not think it strange that the provisioning process does not successfully complete on occasion.  That is why, whenever possible, we observe this process.  For example, we conduct a lot of validation exercises for Microsoft Dynamics 365 using Microsoft Lifecycle Services to support provisioning.  We can observe this process to document the installation qualification process for the system.

It is important to note that the principles of validation still endure.  You STILL must ensure that your cloud environment is established using a consistent, repeatable process.  It is NOT the case that since you are in the cloud, you and eliminate IQ testing.  This is not a good idea nor best practice.

Once the provisioning process is complete, you can create your IQ test scripts and conduct installation qualification testing in the same manner as before.  It is important to note that the IQ process is still relevant for validation testing today.  In the cloud environment, you must conduct your supplier audits collecting the Service Organization Control reports discussed in one of my previous posts.  A thorough process will help ensure data integrity and quality as you deploy enterprise applications.  Are you ready for the cloud?