User:Shawndouglas/sandbox/sublevel1

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.

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.

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." 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:

• 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. 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. Let's talk a bit more about that in the next subsection.