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

From LIMSWiki
Jump to navigationJump to search
(Blanked the page)
Tag: Blanking
Line 1: Line 1:
==6. Considerations when choosing and implementing a cloud solution==
[[File:Quanta Computer cloud computing servers at COSCUP 20120819.jpg|right|400px]]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.<ref name="BuchananTheUltimate">{{cite web |url=https://www.buchanan.com/cloud-migration-project-plan/ |title=The Ultimate Cloud Migration Project Plan for SMBs |publisher=Buchanan Technologies |accessdate=28 July 2023}}</ref> 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<ref name="Charles7Things20">{{cite web |url=https://smallbiztrends.com/2016/10/selling-services.html |title=7 Things You Need to Know About Selling Services |author=Charles, J. |work=Small Business Trends |date=13 July 2020 |accessdate=28 July 2023}}</ref>:
* 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.<ref name="ParksKey18">{{cite web |url=https://www.internationallawoffice.com/Newsletters/Tech-Data-Telecoms-Media/USA/Hunton-Williams-LLP/Key-Issues-When-Contracting-for-Cloud-Services |archiveurl=https://web.archive.org/web/20210331232429/https://www.internationallawoffice.com/Newsletters/Tech-Data-Telecoms-Media/USA/Hunton-Williams-LLP/Key-Issues-When-Contracting-for-Cloud-Services |title=Key issues when contracting for cloud services |author=Parks, R.S.; Voorheis, K.; Glenn, H.M. |work=International Law Office |date=01 May 2018 |archivedate=28 July 2023 |accessdate=28 July 2023}}</ref> 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.

Revision as of 22:44, 27 July 2023

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.