Lab Manager | Run Your Lab Like a Business

Considering the Cloud

Despite all the hype being tossed around, the cloud is a logical evolution of previous systems.

by John Joyce, PhD
Register for free to listen to this article
Listen with Speechify

Data Protection, System Maintenance, and GXP Compliance Are Just the Beginning

The term “cloud computing” reputedly came from the common use on flowcharts of a cloudlike symbol to represent the Internet. In common usage, “the cloud” is a very loosely defined term. The cloud can be used to store data, as a backup medium, as a processing platform, and in any number of other ways. The National Institute of Standards and Technology has a much more specific definition of what cloud computing is, but many people use the term much more broadly—and actually, a significant portion of people do not understand it at all. One of the cloud’s main features is its elasticity. This simply means that as your memory or processing needs change, the system can automatically adjust its resources to your requirements.

Despite all the hype being tossed around, the cloud is simply a logical evolution of previous systems. Because of its elasticity, it is frequently preferred for processes during which the computing or storage demands can change significantly and suddenly. With the cloud, you have to pay for only the resources that you actually use. You do not have to purchase hardware capable of handling your maximum processing or memory load. This frequently allows you to launch prototype projects for evaluation that you would never get approved if you had to purchase all of the equipment. You will frequently find the cloud used with so-called big data projects, but other applications using the cloud include Gmail and similar services.

Related Article: INSIGHTS on Data Management Systems: Operating in the Cloud

When considering the cloud to host the data system for either a clinical or a chemical laboratory, there are additional factors that you must consider:

  • First, and perhaps most important, is the laboratory you are attempting to automate one that is required to conform to GXP regulations? If so, you must consider how these regulations affect your ability to take advantage of the cloud. Exactly which regulations are relevant depends on your type of laboratory, the objective of the laboratory, where it is, and where it ships products. Additionally, this evaluation must be done before signing a contract and implementing a system, or you are just begging for an inspector to start issuing citations.
  • How is your data acquired? Do you anticipate controlling instruments through this cloud system? Is this control time-sensitive?
  • How is validation of your system maintained? This issue is tightly coupled with the issue of how change control is handled and who handles it.
  • How do you go about auditing this cloud data system? Can you gain access to the data center to perform the audit— or even determine where the data is actually stored?1

A very good introduction to these issues, particularly regarding the regulatory impact, can be found in the writings of Dr. R. D. McDowall,2 a highly respected expert in the field of automated laboratory system validation. In his evaluation, McDowell eliminates a variety of unsuitable cloud configurations, but concludes that a SaaS system—where each customer is running its own instance of the application with its own database, in its own virtual machine—does have advantages for the customer. Cloud latency can be addressed using a local interface box to actually collect data and control instruments.

One of the major factors you have to accept when using the cloud, no matter your purpose, is that your data is passing outside of your control and you must trust your cloud provider to protect it. For some users this is untenable; others find ways to live with it. This is one of the reasons you want to vet your cloud supplier very carefully and to validate its procedures as much as possible. Two critical procedures to start with are the way data is transferred and the way the application program interface (API) works, as this is your portal into the cloud. If your data is not encrypted while being transferred, it’s time to look for another vendor immediately. The API should also be secure, requiring identity verification before executing any process. When the data is not actually being used, the best practice is to keep it encrypted.

Related Article: Halting Hackers

When considering, implementing, or using a cloudbased data system, it is expedient to be on good terms with your organization’s IT group, as they can supply vital input into items to consider when generating a service level agreement (SLA) and contract for the system. To be blunt, this can sometimes be a ticklish interaction that may put your management and negotiating skills to the test. The important thing is that the intent of both sides is to successfully implement the project, not to make it something that they can leverage others with.

For IT to be willing to trust that everyone involved knows what they are talking about, it helps if you have personnel with sufficient computer expertise and, ideally, experience working with the IT staff. It is also important to get the IT team involved early in the process, as they generally control the network infrastructure and the organization’s interface with the Internet. This interaction is important for several reasons. As some types of instruments generate GB-size files, the IT staff must ensure that its infrastructure is capable of handling such a load. This might require them to upgrade network switches and cabling or to contract for a higher data rate connection to the Internet so that your operation doesn’t effectively lock up the entire organization’s network.

In addition to the IT group, it is prudent to have someone from your legal department on the team drafting the SLA and the contract. While many cloud providers go out of their way to maximize the uptime of your operation, some are not quite as straightforward. You need the legal team to ensure that all of your requirements are explicitly covered in either the SLA or the contract, including when the SLA kicks in and what the vendor will do in the event of a system failure. This should include not only how the system will be configured, but details of how change control is handled. For systems requiring regulatory validation, the upgrade of a driver or DLL without your knowledge can void the entire validation. Another reason to have your legal department on board is that currently it is still unclear which nation’s laws apply, as the data may be stored in multiple places around the globe. That is more than a bit worrying, as some nations’ laws could be construed as being in conflict with others’.

Another thing the SLA should cover is how the company will protect your data. This might include such things as who has access to the encryption keys and how the company’s people are screened to help eliminate the possibility of in-house data theft, as well as more mundane things such as who is responsible for backing up the system, how the system is backed up, and how the company confirms that this backup has been done and is functional. Note that while some existing SLAs might cover availability to the application on the virtual machine, they don’t necessarily guarantee access to the data or accept liability for any data lost.1

There is one additional issue you should be aware of when making the decision as to which type of cloud to use, if any. This issue doesn’t actually address whether your data has been exposed or not—just whether you are aware of it. While your cloud provider might encrypt all of your data and pledge not to release the encryption keys, thanks to the Patriot Act (with the obvious inference that anybody who objects to it is unpatriotic) and associated laws, the federal government needs only to send your provider a national security letter (NSL)3 demanding whatever they want, even if it is your entire database: “They do not require prior approval from a judge, only the assertion that the information demanded is relevant to a national-security investigation.” 4 Even better, this letter usually includes a gag order that makes it a crime for the cloud provider even to admit that it has received an NSL, let alone to notify the affected customer. This makes it possible to siphon off your data without your even being aware of it. Admittedly, the government could send the letter to you directly, but then you would know what they were doing. Even the Justice Department’s Inspector General has found serious FBI abuses of the NSL power. A similar scenario based on older laws5 is currently being used by the U.S. government in trying to acquire data from Microsoft that is stored in Ireland. If you don’t like this approach, a good place to start is to write your congressman.

Related Article: National Security Controls on Science & Technology are Broken and Should be Restructured

It is for this reason—so that cloud providers couldn’t release your information even if they wanted to—that developers are working on a scheme that would allow the customer to hold all of the encryption keys. Do keep this in mind when deciding where to store your data.

These are not all of the things to consider when deciding whether to use a cloud service, but hopefully this article has highlighted some concerns for you to start thinking about.


1. McKendrick, J. 9 Questions to Ask Before Signing a Cloud Computing Contract. Forbes. 2013; published online Jan. 14.   (accessed Sept. 15, 2015).

2. McDowall, R.D. Is Cloud Computing Right for Your Laboratory... or Are You Living in Cloud Cuckoo Land? Spectroscopy Online. 2012; published online April 1.  (accessed Sept. 15, 2015).

3. ACLU. National Security Letters. Am. Civ. Lib. Union. 2015; published online July 30. (accessed July 30, 2015).

4. Bustillo, M. What It’s Like to Get a National-Security Letter. New Yorker. June 27, 2013. (accessed July 31, 2015).

5. Gould, J. US Effort to Grab Data from Microsoft in Ireland Should Frighten All Firms Using the Cloud Overseas. Nextgov. 2015; published online Aug. 20.  (accessed Sept. 15, 2015).