Difference between revisions of "User:Shawndouglas/sandbox/sublevel1"

From LIMSWiki
Jump to navigationJump to search
Tag: Reverted
Tag: Reverted
Line 1: Line 1:
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.
[[File:Cloud Computing (6648686983).jpg|right|350px]]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.<ref name="AgilentCloud19">{{cite web |url=https://www.agilent.com/cs/library/whitepaper/public/whitepaper-cloud-adoption-openlab-5994-0718en-us-agilent.pdf |format=PDF |title=Cloud Adoption for Lab Informatics: Trends, Opportunities, Considerations, Next Steps |author=Agilent Technologies |publisher=Agilent Technologies |date=21 February 2019 |accessdate=21 August 2021}}</ref><ref name="APHLBreaking17">{{cite web |url=https://www.aphl.org/aboutAPHL/publications/Documents/INFO-2017Jun-Cloud-Computing.pdf |format=PDF |title=Breaking Through the Cloud: A Laboratory Guide to Cloud Computing |author=Association of Public Health Laboratories |publisher=Association of Public Health Laboratories |date=2017 |accessdate=21 August 2021}}</ref><ref name="IFAhelp20">{{cite web |url=https://www.mynewlab.com/blog/a-helpful-guide-to-cloud-computing-in-a-laboratory/ |title=A Helpful Guide to Cloud Computing in a Laboratory |work=InterFocus Blog |publisher=InterFocus Ltd |date=05 October 2020 |accessdate=21 August 2021}}</ref><ref name="O'MalleyIsMov21">{{cite web |url=https://www.securityroundtable.org/is-moving-operational-technology-to-the-cloud-a-good-idea/ |title=Is Moving Operational Technology to the Cloud a Good Idea? |author=O'Malley, K. |work=SecurityRoundtable.org |date=19 February 2021 |accessdate=21 August 2021}}</ref><ref name="EusticeUnder18">{{cite web |url=https://legal.thomsonreuters.com/en/insights/articles/understanding-data-privacy-and-cloud-computing |title=Understand the intersection between data privacy laws and cloud computing |author=Eustice, J.C. |work=Legal Technology, Products, and Services |publisher=Thomson Reuters |date=2018 |accessdate=21 August 2021}}</ref><ref name="DonnellyTheOVH21">{{cite web |url=https://www.computerweekly.com/news/252498983/OVHCloud-datacentre-fire-Assessing-the-after-effects-on-datacentre-operators-and-cloud-users |archiveurl=https://web.archive.org/web/20210408103340/https://www.computerweekly.com/news/252498983/OVHCloud-datacentre-fire-Assessing-the-after-effects-on-datacentre-operators-and-cloud-users |title=The OVHCloud fire: Assessing the after-effects on datacentre operators and cloud users |author=Donnelly, C. |work=ComputerWeekly |date=08 April 2021 |archivedate=08 April 2021 |accessdate=21 August 2021}}</ref>


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">{{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> 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.
# What do we hope to achieve by transitioning operations to the cloud?
 
# Who among staff is best able to act as a go-between with the executive team in order to increase support for cloud adoption?
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" />:
# Have we developed a comprehensive project plan with goals, objectives, benefits, etc. and how cloud computing factors into them?
 
# If not, who can be trusted to develop and implement such a cloud computing plan for our lab, or the organization as a whole?
* the specific parameters of the business-significant services offered to your laboratory are, and what happens when those parameters are not met?
# Do we fully understand the regulations and accreditation requirements that drive security for our organization and its data?
* 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?
# What proficiencies and skills do lab technicians and IT staff currently have in computing, and cloud computing in particular?
* 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?
# 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.)
* the standards and regulatory requirements affecting the CSP's cloud service(s) are, giving you any rights to audit the service for compliance?
# What kind of data are we putting in the cloud?
* the incident resolution process looks like, and how long it will take to complete?
# 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?
* the change management process for updates and upgrades looks like, including how it will be communicated and scheduled?
# Do we fully understand the [[Informatics (academic field)|informatics]] strengths and gaps within our organization?
* the CSP's disaster recovery process is and what you, the lab, should expect in case of various risks and disasters being realized?
# Do we fully understand the risks associated with cloud computing and how to best mitigate them?
# 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?
# How bad can things go wrong if we (or the cloud provider) are attacked?
# What will we (and the cloud provider) do to proactively detect, prevent, and remediate security breaches?
# 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?


==References==
==References==
{{Reflist|colwidth=30em}}
{{Reflist|colwidth=30em}}

Revision as of 17:57, 4 February 2022

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.[1][2][3][4][5][6]

  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?

References

  1. ↑ Agilent Technologies (21 February 2019). "Cloud Adoption for Lab Informatics: Trends, Opportunities, Considerations, Next Steps" (PDF). Agilent Technologies. https://www.agilent.com/cs/library/whitepaper/public/whitepaper-cloud-adoption-openlab-5994-0718en-us-agilent.pdf. Retrieved 21 August 2021. 
  2. ↑ Association of Public Health Laboratories (2017). "Breaking Through the Cloud: A Laboratory Guide to Cloud Computing" (PDF). Association of Public Health Laboratories. https://www.aphl.org/aboutAPHL/publications/Documents/INFO-2017Jun-Cloud-Computing.pdf. Retrieved 21 August 2021. 
  3. ↑ "A Helpful Guide to Cloud Computing in a Laboratory". InterFocus Blog. InterFocus Ltd. 5 October 2020. https://www.mynewlab.com/blog/a-helpful-guide-to-cloud-computing-in-a-laboratory/. Retrieved 21 August 2021. 
  4. ↑ O'Malley, K. (19 February 2021). "Is Moving Operational Technology to the Cloud a Good Idea?". SecurityRoundtable.org. https://www.securityroundtable.org/is-moving-operational-technology-to-the-cloud-a-good-idea/. Retrieved 21 August 2021. 
  5. ↑ Eustice, J.C. (2018). "Understand the intersection between data privacy laws and cloud computing". Legal Technology, Products, and Services. Thomson Reuters. https://legal.thomsonreuters.com/en/insights/articles/understanding-data-privacy-and-cloud-computing. Retrieved 21 August 2021. 
  6. ↑ 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. https://web.archive.org/web/20210408103340/https://www.computerweekly.com/news/252498983/OVHCloud-datacentre-fire-Assessing-the-after-effects-on-datacentre-operators-and-cloud-users. Retrieved 21 August 2021. 
Retrieved from "https://www.limswiki.org/index.php?title=User:Shawndouglas/sandbox/sublevel1&oldid=46149"