|
|
| Line 1: |
Line 1: |
| 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.<ref name="FFIEC_Out04">{{cite web |url=https://ithandbook.ffiec.gov/media/274841/ffiec_itbooklet_outsourcingtechnologyservices.pdf |format=PDF |title=Outsourcing Technology Services |author=Federal Financial Institutions Examination Council |publisher=FFIEC |date=June 2004 |accessdate=23 May 2021}}</ref>
| | 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. |
|
| |
|
| 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.
| | 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.<ref name="OverbyWhatIs17" /> 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.<ref name="WiederService11">{{cite book |title=Service Level Agreements for Cloud Computing |editor=Wieder, P.; Butler, J.M.; Theilmann, W. et al. |publisher=Springer |year=2011 |isbn=9781461416159}}</ref><ref name="RussoTheCloud18">{{cite book |title=The Cloud Service Level Agreement: A Supplement for NIST 800-171 Implementation |author=Russo, M.A. |publisher=Syber Risk |year=2018 |isbn=9781983156533}}</ref> However, let's look at a few of those aspects, from the perspective of the laboratory examining a CSP's SLA. |
|
| |
|
| '''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.
| | 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.<ref name="CurtisConsid20">{{cite web |url=https://astrixinc.com/considerations-for-cloud-hosting-your-laboratory-informatics-systems/ |title=Considerations for Cloud Hosting Your Laboratory Informatics Systems |author=Curtis Jr., D. |publisher=Astrix, Inc |date=24 January 2020 |accessdate=21 August 2021}}</ref> Does the SLA address "what"<ref name="CurtisConsid20" />: |
|
| |
|
| '''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.
| | * 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? |
| '''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.<ref name="BradyAGuide19">{{cite web |url=https://www.compliantcloud.com/a-guide-to-validated-software-as-a-service-saas/ |title=A Guide to Validated Software as a Service (SaaS) |author=Brady, N. |work=Compliant Cloud |date=06 August 2019 |accessdate=21 August 2021}}</ref>
| | * 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? |
| '''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.
| | * 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? |
| '''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.
| | * the CSP's disaster recovery process is and what you, the lab, should expect in case of various risks and disasters being realized? |
| | |
| '''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."<ref name="NavaleCloud18">{{cite journal |title=Cloud computing applications for biomedical science: A perspective |journal=PLoS Computational Biology |author=Navale, V.; Bourne, P.E. |volume=14 |issue=6 |at=e1006144 |year=2018 |doi=10.1371/journal.pcbi.1006144 |pmid=29902176 |pmc=PMC6002019}}</ref> 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<ref name="McDowallClouds20">{{cite web |url=https://www.csolsinc.com/blog/clouds-or-clods-software-as-a-service-in-gxp-regulated-laboratories/ |title=Clouds or Clods? Software as a Service in GxP Regulated Laboratories |author=McDowall, B. |work=CSols Blog |publisher=CSols, Inc |date=27 August 2020 |accessdate=21 August 2021}}</ref>:
| |
| | |
| * 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.<ref name="HuangTrust13">{{cite journal |title=Trust mechanisms for cloud computing |journal=Journal of Cloud Computing |author=Huang, J.; Nicol, D.M. |volume=2 |at=9 |year=2013 |doi=10.1186/2192-113X-2-9}}</ref> 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.<ref name="OverbyWhatIs17">{{cite web |url=https://www.cio.com/article/2438284/outsourcing-sla-definitions-and-solutions.html |title=What is an SLA? Best practices for service-level agreements |author=Overby, S.; Greiner, L.; Paul, L.G. |work=CIO |date=05 July 2017 |accessdate=21 August 2021}}</ref> Let's talk a bit more about that in the next subsection.
| |
|
| |
|
| ==References== | | ==References== |
| {{Reflist|colwidth=30em}} | | {{Reflist|colwidth=30em}} |
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.[1] 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.[2][3] 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.[4] Does the SLA address "what"[4]:
- 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?
References
