User:Shawndouglas/sandbox/sublevel45

From LIMSWiki
Jump to navigationJump to search

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

  1. Overby, S.; Greiner, L.; Paul, L.G. (5 July 2017). "What is an SLA? Best practices for service-level agreements". CIO. https://www.cio.com/article/2438284/outsourcing-sla-definitions-and-solutions.html. Retrieved 21 August 2021. 
  2. Wieder, P.; Butler, J.M.; Theilmann, W. et al., ed. (2011). Service Level Agreements for Cloud Computing. Springer. ISBN 9781461416159. 
  3. Russo, M.A. (2018). The Cloud Service Level Agreement: A Supplement for NIST 800-171 Implementation. Syber Risk. ISBN 9781983156533. 
  4. 4.0 4.1 Curtis Jr., D. (24 January 2020). "Considerations for Cloud Hosting Your Laboratory Informatics Systems". Astrix, Inc. https://astrixinc.com/considerations-for-cloud-hosting-your-laboratory-informatics-systems/. Retrieved 21 August 2021.