LII:Choosing and Implementing a Cloud-based Service for Your Laboratory/Considerations when choosing and implementing a cloud solution

From LIMSWiki
Jump to navigationJump to search
-----Return to the beginning of this guide-----

6. Considerations when choosing and implementing a cloud solution

Quanta Computer cloud computing servers at COSCUP 20120819.jpg

Much has been said to this point about cloud computing, the importance of security to the technology, the risks inherent to it, and how to manage those risks. We've also looked at cloud computing within the realm of the laboratory and how security, risk, and risk management fit into the laboratory's concerns. Now it's time to take that knowledge and those concerns directly to the task of choosing one or more cloud services to implement in your lab. (Appendix 1 of this guide provides a list of profiles for top public, hybrid, and multicloud providers to consider.)

Prior chapters have highlighted the fact that choosing to move towards a cloud-based approach in your organization is a process in itself, a process deserving of a plan. Just as risk management is part of an overall cybersecurity plan, choosing and implementing a cloud project is part of an overall cloud migration plan.[1] By this point, you've hopefully already:

  • stated the goals of the cloud project and received management buy-in;
  • identified the project stakeholders;
  • developed scope and responsibility documentation;
  • examined and classified your existing—and future—data for criticality, sensitivity, cleanliness, suitability, etc.;
  • identified relevant risks associated with the five risk categories as part of an overall/enterprise risk management assessment; and
  • identified computing requirements and objectives, including the need for any data cleansing and migration tools.

Of course, there's more to the cloud migration plan, including documenting and training on processes and procedures, monitoring performance and security controls, and employing corrective action, but those come after you've chosen and implemented your cloud solution(s). The following sections examine what aspects to consider as part of that process, including what an average cloud service provider (CSP) should look like, what to look for in a CSP (including their service agreements), what your organization should ask of itself, and what your organization should be asking of the CSP.

6.1 What are the various characteristics of an average cloud provider?

This guide has, at least indirectly, addressed the question of what makes a cloud provider what they are. But let's collect some of those disparate thoughts spread across the prior chapters to paint a portrait of an average cloud provider. Broadly speaking, a cloud provider could be a public cloud provider such as Amazon Web Services (AWS) or Google Cloud, a hybrid cloud provider like Dell Technologies Cloud, a multicloud provider such as VMware Cloud, or any of thousands of software developers offering a software as a service (SaaS) option. These providers offer one or more services under various service models, using either their own cloud computing infrastructure, or—as is the case with some software vendors—through the use of another company's cloud computing infrastructure. But in the end, they are all offering a service. Yes, there is actually something tangible (a cloud product) associated with this service, but the actual provision, maintenance, security management, etc. of the product is part of the offered service to you, the customer.

A cloud service being both a service and a tangible product, the average cloud provider will also intertwine their service with their product as part of their interactions with your lab. When engaging with your lab, they will ideally[2]:

  • strike up a good rapport with your organization;
  • make a genuine attempt to understand your organization's needs;
  • assist you with envisioning the positive outcomes using the service;
  • be attentive to you feelings and concerns about their service;
  • provide testimonials and case studies; and
  • demonstrate how they are uniquely positioned to provide their service.

Again, being a service, the CSP will ideally have a knowledgeable and experienced team of individuals who understand the various aspects of providing a cloud service. It may be difficult to ascertain how knowledgeable and experienced the overall team is, but, assuming your communications become more than an initial inquiry, you may eventually reach a point where you're assigned a service agent. That person will hopefully be able to answer all your questions or be able to quickly get answers for you. Based upon the questions you ask of that agent, you should gain confidence in their knowledge about the product, as well as address how it relates to the industry your laboratory serves. If the cloud provider is providing a SaaS solution, they should be able to demonstrate the solution for you and provide additional feedback in a recorded question and answer session, all of which can be referred back to by your lab at a later date. Tangentially, the CSP and its service agent should also be able to guide you to documentation and even case studies demonstrating how they are able to help your laboratory be successful in the cloud, while also finding that success in a secure and regulated manner.

Through their interactions with you, the CSP should also be able to demonstrate expertise in security, compliance, and data migration. They may do this through meaningful conversation, as well as by making critical documents such as their SOC 2 audit report available to you. They will also discuss their shared responsibility model with you and what that means contractually. If certain aspects of security appear to be amiss from a proposed contract, the provider will ideally be flexible enough to attach additional clauses and assurances, where reasonable, to help alleviate your lab's security concerns. Data migration concerns should also be addressed by detailing the infrastructure behind the service you want to use and how that infrastructure may impact your lab and its data. This includes addressing the nuances of the CSP's cloud storage and archiving systems, as well as any risk management strategies that may impact your more sensitive data.

Finally, the CSP should be upfront about support, warranty, and costs. If your laboratory is operating on a twenty-four hour basis and something goes wrong at 2:00 a.m., the CSP should be there to provide support (as long as its stipulated for the services you're contracted for) at that hour. Those cloud services will also come with appropriate warranties for performance, compliance, non-infringement, etc.[3] And the costs provided to you, as well as future price changes, should be transparently communicated to you and your lab at all steps of the professional relationship.

6.2 What should your lab look for in a cloud provider?

Admittedly, it may appear that the previous section sets a relatively high bar for providers of cloud services. The reality of some cloud providers may be less than that ideal, however. For example, customer service may be lacking in some companies, or the agent assigned to work with you is having a rough patch and isn't addressing your lab's needs that well. The CSP's contract language may not be clear, the warranty less than ideal, or the security lacking for your lab's needs. It's even possible that the CSP doesn't have much experience working with laboratories to begin with. This requires strong initial reconnaissance (i.e., due diligence) on the part of your laboratory and its cloud project stakeholders, finding available options and running them through iterative filters to better vet those CSPs who are most likely to meet the lab's needs. And even then, after that internal due diligence—which may include a request for information (RFI)—it's possible that what those CSPs are offering doesn't completely agree with your lab's stated requirements, requiring careful evaluation of the differences in order to understand the potential effects and internal changes to organizational goals and service expectations.[4]

What should these initial filters look like? Aspects of the answer have been touched upon already in prior chapters, and some haven't. Let's break it down.

Service and deployment models offered: We've already talked at length about the various service and deployment models, their benefits and risks, and what they bring to the table for laboratories. In the end, the specifics of this important filter will be decided by the goals and requirements decided upon in your laboratory's cloud project planning.

Technologies used: Though cloud providers largely have relatively agnostic open-source architecture components, each may have a few nuances that would affect your deployment onto their service. Your laboratory's cloud project planning will have ideally identified any technology-specific nuances to your applications and data, which will further guide your filters. If other Google applications play a significant role in your organization's operations, Google Cloud may have a slight edge as far as integrations go.

Compliance offerings and security: Most labs work in some sort of regulatory environment. Those regulations may vary slightly from industry to industry (e.g., the regulatory demands for the cannabis testing lab will differ from those of the clinical testing lab), and how each cloud provider addresses them will differ, sometimes significantly. One would assume that, for example, a SaaS vendor offering a cloud-based laboratory information management system (LIMS) has baked in all the necessary regulatory considerations into their offering and underlying infrastructure, but this can't necessarily be taken for granted. This is where you ask the public cloud provider for their documented compliance certifications, attestations, alignments, and frameworks relevant to your lab that qualify their infrastructure, or ask the SaaS vendor to provide their own documentation on how their software—and, if applicable, any third-party infrastructure as a service (IaaS)—remains compliant or betters lab compliance in the cloud. Additionally, how the SaaS software vendor handles validation may be an important filter to consider.[5]

Shared responsibility: Whether through an outright model or by explaining in contract language, a CSP should be able to make clear the differences in responsibility for the security of a cloud service offering. It's always a plus when the CSP provides this information on their website, but you may have to ask a representative to explain the CSP's approach. Those who can't, or those whose responsibility burden isn't compatible with your laboratory's needs may get stuck in the filter.

Risk management and insurance: While your laboratory will most certainly need to address its own risk management practices, as well as whether or not cybersecurity insurance makes sense, don't forget to investigate these matters with any potential CSP. Are they willing to discuss their risk management strategies as applied to their software and infrastructure? Do they have cyber insurance, and if so, what are the details? These may not be deal-breakers, per se, but if you're splitting hairs between two providers, one with a solid cyber insurance policy and one not so much, it may be a determining factor.

Interoperability and portability: The question of interoperability and portability—the vendor lock-in question—may or may not be considered a major risk factor for your laboratory. But if ensuring your laboratory can pick up its data and applications and move them relatively painlessly to another CSP is a concern, you'll investigate these matters before deciding on your CSP. This may be particularly tricky with a SaaS provider; you may be able to extract your data from their application if they go bankrupt or you decide to move to a new application, but how portable will it be for the next migration?

Pricing, warranty, and support: Transparency at every pricing step is important for any laboratory trying to determine what the current and future budget for cloud services will be. It's especially imperative for laboratories funded in part by grants. As Navale and Bourne note in their discussion on cloud computing for biomedical science, "[c]loud vendors are seeking an all-in model. Once you commit to using their services, you continue to do so or pay a significant penalty. This, combined with being a pay-as-you-go model, has implications when mapped to the up-front funding models of typical grants."[6] As such, your lab will not only look for clear pricing but will also ask about any unanticipated "gotcha" fees and penalties that may apply to your use of the service. Investigating CSPs for their approaches to warrantying their services and products, and supporting them when things go wrong, should also not be overlooked.

Software development practices: Writing for CSols, a laboratory informatics consultancy, consultant Bob McDowall emphasizes several areas of a developer's software development practices that laboratories seeking a SaaS solution should consider. Can the SaaS vendor[7]:

  • describe their software development life cycle and how it benefits your lab?
  • provide reliable support for their application?
  • explain the virtual IT infrastructure running the software?
  • describe the GxP and other regulatory-based training staff have?
  • explain how the application is configured prior to laboratory validation?
  • explain its approach to risk management with any underlying IaaS supplier?
  • define in a clear manner the work to be performed and how it's expressed in any agreement?
  • batch "agile" cloud software releases into a single annual upgrade, vs. updating every quarter, for validated environments such as pharmaceuticals?

Trust and reputation: This may be one of the more difficult, or at least time-consuming, investigative steps when considering CSPs. Most CSPs will have a trust center or document explaining the myriad ways you, the customer, should put trust in their services (a one-to-one opinion). However, reputation is based on an aggregate of opinions from a community towards the CSP, which is, broadly speaking, based on experiences concerning the transparency, accountability, and value provided by the CSP.[8] The CSP usually supplies you with information concerning trust, but reputation is discovered not only through, e.g., case studies supplied by the CSP but also by having conversations with past and current clients of the CSP. In both cases, though a non-trivial process, your lab should take the time to pass any prospective CSPs through these filters.

Service-level agreement: A service-level agreement (SLA) defines the service expectations between the laboratory and the CSP, how meeting those expectations should be measured, and what should happen if those expectations are not met.[9] Let's talk a bit more about that in the next subsection.

6.2.1 Service-level agreements

At various points in this guide we've talked about various contracts and agreements, but only a little bit about SLAs. Last chapter we said the SLA essentially defines all the responsibility the cloud provider holds, as well as your laboratory, for the supply and use of the CSP's services. This is the "meat and potatoes" of the service paperwork that will cross your eyes. The SLA, in a sense, offers a set of primary legal protections and, ideally, clearly expresses the expectations placed at the feet of both parties. With a well-crafted, signed SLA, neither party can say they were unaware of a stipulation, responsibility, or expectation. By signing the SLA, the laboratory also admits that the document is largely representative of the technological or organizational goals of the lab, and the CSP of its goals.

SLAs will have numerous components to it addressing both the implementation and use of the service and the management aspects of the service, indicating what services are provided and excluded, the conditions of availability for the provided services, any differing service levels, each party's responsibilities, reporting processes, escalation and dispute procedures, remediation and indemnification methods, cost compromises, and contract change management.[9] It would be beyond the scope of this guide to provide broad information about all the elements of an SLA and how to approach them; entire books have been written about the subject over the years.[10][11] However, let's look at a few of those aspects, from the perspective of the laboratory examining a CSP's SLA.

In early 2020, laboratory informatics and scientific consultancy Astrix provided some key insights about SLAs for labs moving to the cloud. Astrix president Dale Curtis emphasized that when examining any SLA, ensure that it's largely addressing "what" questions rather than digging into the minutia of "how" questions; too much "how" and you start losing the other benefits inherent to the SLA.[12] Does the SLA address "what"[12]:

  • the specific parameters of the business-significant services offered to your laboratory are, and what happens when those parameters are not met?
  • the ownership rights to service data are for both parties, including discussion of the data request and return processes and their timelines, the format the data will be returned in, the retention times of your data after a CSP closure or contract termination, and the penalties for non-compliance?
  • your laboratory's rights to continue and discontinue services are "within and outside of contract renewal timelines," and what the associated costs and penalties may be?
  • the standards and regulatory requirements affecting the CSP's cloud service(s) are, giving you any rights to audit the service for compliance?
  • the incident resolution process looks like, and how long it will take to complete?
  • the change management process for updates and upgrades looks like, including how it will be communicated and scheduled?
  • the CSP's disaster recovery process is and what you, the lab, should expect in case of various risks and disasters being realized?

6.3 What questions should you ask yourself?

Cloud Computing (6648686983).jpg

Here we provide a concise listing of questions your organization should be asking internally at various steps of a cloud project. If you've followed a formal project management path, your lab may have asked many of these questions already during goal setting, scope setting, risk assessment, and requirement documentation. If so, fantastic; you have most of the answers. However, if prior cloud project management steps failed to address them, now is certainly the time, before you start your laboratory's provider research in earnest. While these questions are loosely ordered in a traditional project management path, their order is not significant otherwise. Just be sure your laboratory has considered or will be considering these questions.[13][14][15][16][17][18]

  1. What do we hope to achieve by transitioning operations to the cloud?
  2. Who among staff is best able to act as a go-between with the executive team in order to increase support for cloud adoption?
  3. Have we developed a comprehensive project plan with goals, objectives, benefits, etc. and how cloud computing factors into them?
  4. If not, who can be trusted to develop and implement such a cloud computing plan for our lab, or the organization as a whole?
  5. Do we fully understand the regulations and accreditation requirements that drive security for our organization and its data?
  6. What proficiencies and skills do lab technicians and IT staff currently have in computing, and cloud computing in particular?
  7. Have we polled our users and relevant stakeholders about how they currently use existing computing services and access their data as part of their workflow? (For example, if internet access isn't readily available in the lab, this will have to change with cloud.)
  8. What kind of data are we putting in the cloud?
  9. Has anyone conducted an independent assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of health or other sensitive data and information stored in our systems?
  10. Do we fully understand the informatics strengths and gaps within our organization?
  11. Do we fully understand the risks associated with cloud computing and how to best mitigate them?
  12. Are we willing to take the time to compare the operational effectiveness, costs, risks, and security concerns of multiple cloud providers before we make a decision?
  13. How bad can things go wrong if we (or the cloud provider) are attacked?
  14. What will we (and the cloud provider) do to proactively detect, prevent, and remediate security breaches?
  15. What will our back-up and protection mechanisms be to mitigate data loss due to fire or other catastrophic events both on-premises and in the cloud?

6.4 What questions should be asked of a cloud provider?

Here we provide a concise listing of 18 questions your organization should be asking any cloud providers being considered for your cloud project. (A broader list of questions is discussed in the next subsection about RFIs.) As part of the discovery phase of your formal cloud project, some of these questions may have been asked prior, but many of them will likely not have been addressed in prior discussions. Most of these questions have already been addressed in prior sections of this guide, but a "shopping list" is always handy, yes? Like the prior list, the ordering here means little, aside from perhaps an attempt at semi-logical progression from introduction to the provider to wrapping up agreements.[14][15][17][19][20][21]

  1. What experience do you have working with laboratory customers in our specific industry?
  2. Can your solution readily integrate with our other systems and business processes, making it easier for our end users to perform their tasks?
  3. What is the average total historical downtime for the service(s) we're interested in?
  4. Do we receive comprehensive downtime support in the case of downtime?
  5. Where are your servers located, and how is data securely transferred to and from those servers?
  6. Who will have access to our data (including subcontractors), and what credentials, certifications, and compliance training do they have?
  7. Will our sensitive and regulated data be stored on a machine dedicated to complying with the necessary regulations?
  8. How segregated is our cloud data from another customer's, i.e., will lapses of security of another customer's cloud affect our cloud? (It typically won't, but asking the question will hopefully prompt the provider to better explain how your data is segregated.)
  9. Do you have documented data security policies?
  10. How do you test your platform's security?
  11. What are your policies for security audits, intrusion detection, and intrusion reporting?
  12. What data logging information is kept and acted upon in relation to our data?
  13. How thorough are those logs and can we audit them on-demand?
  14. For HIPAA-eligible data (e-PHI) we may have, will you sign a business associate agreement?
  15. What happens to our data should the contract expire or be terminated?
  16. What happens to our data should you go out of business or suffer a catastrophic event?
  17. Can we use your interface to extract our data when we want, and in what format will it be?
  18. Are your support services native or outsourced/offshored?

6.4.1 Using a request for information (RFI) process

We've already talked about the RFI process in the previous chapter, so we won't rehash the specifics here. However, note that the 18 critical questions prior are also addressed, along with many others, in the cloud computing RFI questions posed in Appendix 3. Like the list of RFI questions to ask of MSSPs, the cloud computing RFI questions represent a thorough list of potential questions to ask of a cloud provider. Your lab will still want to keep any RFI derived from those questions succinct in order to get the most responses, keeping in mind that it doesn't need to address every question but rather have enough critical questions to narrow down your search to a few quality candidates. From there, you can return to the RFI questions and ask more pointed ones of those candidates you narrowed your list down to.

The format of the questions is the same as those found in the MSSP RFI, and there's even some crossover in several cases.


  1. "The Ultimate Cloud Migration Project Plan for SMBs". Buchanan Technologies. Retrieved 28 July 2023. 
  2. Charles, J. (13 July 2020). "7 Things You Need to Know About Selling Services". Small Business Trends. Retrieved 28 July 2023. 
  3. Parks, R.S.; Voorheis, K.; Glenn, H.M. (1 May 2018). "Key issues when contracting for cloud services". International Law Office. Archived from the original on 28 July 2023. Retrieved 28 July 2023. 
  4. Federal Financial Institutions Examination Council (June 2004). "Outsourcing Technology Services" (PDF). FFIEC. Archived from the original on 01 February 2022. Retrieved 23 May 2021. 
  5. Brady, N. (6 August 2019). "A Guide to Validated Software as a Service (SaaS)". Compliant Cloud. Archived from the original on 07 November 2020. Retrieved 21 August 2021. 
  6. Navale, V.; Bourne, P.E. (2018). "Cloud computing applications for biomedical science: A perspective". PLoS Computational Biology 14 (6): e1006144. doi:10.1371/journal.pcbi.1006144. PMC PMC6002019. PMID 29902176. 
  7. McDowall, B. (27 August 2020). "Clouds or Clods? Software as a Service in GxP Regulated Laboratories". CSols Blog. CSols, Inc. Retrieved 15 August 2023. 
  8. Huang, J.; Nicol, D.M. (2013). "Trust mechanisms for cloud computing". Journal of Cloud Computing 2: 9. doi:10.1186/2192-113X-2-9. 
  9. 9.0 9.1 Overby, S.; Greiner, L.; Paul, L.G. (5 July 2017). "What is an SLA? Best practices for service-level agreements". CIO. Retrieved 21 August 2021. 
  10. Wieder, P.; Butler, J.M.; Theilmann, W. et al., ed. (2011). Service Level Agreements for Cloud Computing. Springer. ISBN 9781461416159. 
  11. Russo, M.A. (2018). The Cloud Service Level Agreement: A Supplement for NIST 800-171 Implementation. Syber Risk. ISBN 9781983156533. 
  12. 12.0 12.1 Curtis Jr., D. (24 January 2020). "Considerations for Cloud Hosting Your Laboratory Informatics Systems". Astrix, Inc. Retrieved 21 August 2021. 
  13. Agilent Technologies (21 February 2019). "Cloud Adoption for Lab Informatics: Trends, Opportunities, Considerations, Next Steps" (PDF). Agilent Technologies. Retrieved 28 July 2023. 
  14. 14.0 14.1 Association of Public Health Laboratories (2017). "Breaking Through the Cloud: A Laboratory Guide to Cloud Computing" (PDF). Association of Public Health Laboratories. Retrieved 28 July 2023. 
  15. 15.0 15.1 "A Helpful Guide to Cloud Computing in a Laboratory". InterFocus Blog. InterFocus Ltd. 5 October 2020. Retrieved 28 July 2023. 
  16. O'Malley, K. (19 February 2021). "Is Moving Operational Technology to the Cloud a Good Idea?". Retrieved 28 July 2023. 
  17. 17.0 17.1 Eustice, J.C. (2018). "Understand the intersection between data privacy laws and cloud computing". Legal Technology, Products, and Services. Thomson Reuters. Retrieved 28 July 2023. 
  18. Donnelly, C. (8 April 2021). "The OVHCloud fire: Assessing the after-effects on datacentre operators and cloud users". ComputerWeekly. Archived from the original on 08 April 2021. Retrieved 28 July 2023. 
  19. Ward, S. (9 October 2019). "Cloud Computing for the Laboratory: Using data in the cloud - What it means for data security". Lab Manager. Retrieved 28 July 2023. 
  20. LBMC (24 February 2021). "Nine Due Diligence Questions to Ask Cloud Service Providers". LBMC Blog. Retrieved 28 July 2023. 
  21. Thomson Reuters (3 March 2021). "Three questions you need to ask your cloud vendors". Thomson Reuters Legal Blog. Archived from the original on 04 March 2021. Retrieved 28 July 2023. 

-----Go to the next chapter of this guide-----

Citation information for this chapter

Chapter: 6. Considerations when choosing and implementing a cloud solution

Title: Choosing and Implementing a Cloud-based Service for Your Laboratory

Edition: Second edition

Author for citation: Shawn E. Douglas

License for content: Creative Commons Attribution-ShareAlike 4.0 International

Publication date: August 2023