How to Build & Qualify the Cloud: Webinar Q&A + Recording

It's clear that building and qualifying the cloud for regulated applications is a hot topic right now, and our attendance numbers as well as the number of questions asked during the webinar (shown below) truly reflected that. 

Here's the recording:

Here's the copy of the slides to download

1). How do we qualify the big players like Amazon and Microsoft?

Basically, you review any ISO, SOC or other relevant certifications and audit reports available. By mapping the coverage of the certifications to regulatory expectations and reviewing the audit reports to ensure that the requirements of the certifications have been met, you can establish confidence that the regulatory requirements are satisfied. You can read our Qualification Guideline for more details on the approach that we recommend for the Microsoft cloud. 

2). Why would I run a high-risk FDA relevant app in a public cloud? 

It is a question of risk. You need to evaluate what level of risk the application, or more importantly, the processes or data that the application will manage and make a risk-based decision as to whether you feel comfortable running the application in a public cloud. You should also define the minimum controls that would be required to ensure you can offset the risks that you would have identified.

3). Data Storage...is this not elastic? 

Not quite. The cloud is built for scalability, however, this is not the same as elastic. The performance requirements and technical considerations for running larger databases in the cloud mean this storage is not completely elastic and requires some manual intervention.

For example, pure BLOB storage used by a custom application can be elastic up to 50 TB, however if you need actual ‘disks’ in a virtual machine, this plummets to 1TB per disk, and you can have only a set number (16 or 32 for the larger VM sizes), for a maximum of 32 TB – if you need performance you can expect to halve this number to 16 TB, or even more. The bottom line is you need monitoring to determine when you should increase this storage, as increasing is easy (to a point), but reducing is not as straight forward.

4). Which requirements are un-testable or unverifiable? 

Primarily, we could not verify Physical and Environmental Security requirements (e.g. Physical servers and related equipment are in a restricted location).  This is because the physical hardware is managed by Microsoft.  But we know that Microsoft is certified for ISO/IEC 27001:2005 and leveraged that certification as a rationale for not explicitly verifying the requirement ourselves.

5. How about encryption?

All data is encrypted in transit at every stage, from Cloud Storage > Application > User. Since data in the cloud is almost never ‘at rest’, data in transit is the key parameter. Additionally, the actual storage accounts, on top of being secured with SSL\TLS, are protected with ‘keys’ such that unauthorized access (i.e.: from another user outside the cloud subscription) is prohibited. As a side note, we could also implement data encryption at rest, however, this would require SQL Enterprise for our database, which can significantly increase the cost.

6). Migration of Business Critical Applications to the Cloud requires Checks & Balances (as a minimum) in order to establish Acceptance. What is the reason for not executing UAT or PQ?

In the webinar, we spoke about IaaS (infrastructure only). The last step in the 6-step process was to migrate applications (Saas).  We would do (and did do) acceptance testing (UAT or PQ) for the application, but not for the infrastructure.  We did not discuss the validation of application (SaaS) in the webinar, but this would be the next logical step.

7). Many pharmaceutical organizations are concerned about the location of their data and the data privacy laws for each country. How did you address country-by-country data privacy concerns? 

Our platform operates per ‘region’, and we would have 1 cloud environment per region which utilizes this data (i.e.US and Europe).  In this way, we can ensure the data never leaves the region specified by us (this was a big reason for choosing the Microsoft Azure platform. We have some visibility on the country as well, as we know where the Azure datacenters are located, however we cannot control specific country by country data (for example, Spain, Germany and England will have their data in the same Western Europe Datacenter, however clients in California will use the US datacenters).

8). Within the risk assessment, were there any HIGH risks and what were they? 

By nature of the cloud, prior to mitigation, malicious access was identified as high risk. It is important to note that since this was identified as a high risk, the mitigations put in place were very robust (including 2-factor authentication, monitoring and multiple firewalls) With these additional controls, the risk was reduced dramatically.

9). Maybe ISO14971 is implemented differently in Canada, but that is not a typical risk analysis document. If you are showing that to USA customers that is not adequate. 

ISO 14971 certification is not claimed by the Azure platform and does not relate directly to cloud infrastructure. We ourselves do not manufacture medical devices, and as such this doesn’t seem applicable. We followed the GAMP® 5 methodology for risk assessments, not ISO 14971.

10). You are attributing the certification to ISO 27001 to the equipment.  that is not correct.  the certification is to the QMS. 

ISO 27001 is specifically for Information Security Management, to which the Azure platform is certified. This certification ensures that standards for information security, to ensure proper controls are in place by the cloud provider. Although ISO27001 is a comprehensive certification for information security, it does require a comprehensive risk assessment and asset inventory, which would include the equipment

11). Have you received any feedback from customers, auditors or regulatory agencies around your process? 

We have been audited by several clients and our process was considered acceptable. In general, we have received positive feedback about the robustness of our approach.

12). Cloud connectivity such as latency during core business hours 12 noon-5pm can occur with regulated software (eCTD) connected to the cloud. Have you experienced this in your platform? How have you managed this? 

We constantly monitor our platform, and have not observed connectivity issues during peak business hours, and there are a few reasons for this.

To start with, we designed our cloud platform with availability in mind and part of this included performance. This means we have the ability to scale as required, and through planning and monitoring of operations, we always ensure proper capacity is allocated for smooth operations.

Secondly, with our cloud platform, our client base is actually spread over multiple time zones, and as such, there is less of a ‘business day’ than with a more traditional platform; the cloud is anytime, anywhere, and we find many people take full advantage of that. 

13). As far as I know, all traffic from and to Azure is encrypted. So why the additional requirement for not allowing access from anywhere? Doesn't that negate one of the many benefits: staff location independence?

Certainly, end-user access is allowed from anywhere, at any time to maximize productivity. The access restrictions mentioned in the webinar were specific for administrators, and that is much more tightly controlled (as this was identified as a significant risk in our Risk Assessment).

Since there is a small number of authorized and skilled administrators, additional access controls are put in place to prevent any event which would compromise the security of the platform.

High-level access is allowed only from trusted locations and goes through additional controls before someone actually gains access for administrative activities. For security reasons, we can’t disclose the exact process our administrators go through, but we can say it involves features such as two-factor authentication and advanced fraud alert functions. 

14). What would you consider to be the difference between qualification and validation? 

Infrastructure is qualified while applications are validated. With qualification, we demonstrate that the cloud system (equipment) is installed and operates according to specifications (i.e. what the manufacturer/vendor says it’s supposed to be). With validation, we demonstrate that the cloud system is fit for its intended use within the context of its business process (i.e. what the end-user needs it to do). 

15). Is Montrium offering services to help us (pharma company) qualify Azure? 

Yes. As part of our Professional Services offerings, we provide document templates for Azure qualification and we also offer consulting services to help clients implement a cloud strategy or deploy and qualify a cloud-based environment.