雲端運算的風險

22 min readMar 30, 2023

雲端運算的崛起是一種"On-Demand業務模型"以及"應用程式的組合、基礎設施和資料"的新運作模型的根本轉變，因為它們是使用雲端提供的虛擬服務。 這些技術和商業變革對當前的員工的工作實踐產生了影響。企業需要了解技術層面的影響，以及它們如何協同作業。其中一個關鍵部分是分析和評估所涉及的風險。

例如，在多租戶雲端系統和多數企業為尋求規模經濟而使用共享資源，導致企業依賴於公有雲服務。這會給雲端服務的租戶(也就是一般企業)以及雲端服務的SI和雲端提供商(如三大雲AWS/Azure/GCP,以下簡稱CSP)帶來哪些伴隨風險？風險將如何影響租戶對服務水準和效能的期望？

對於任何考慮使用雲端運算的企業來說，這都是一個基本問題。正如美國政府雲端運算的 Proposed Security Assessment and Authorization所提出的：

採用雲端運算技術的決定是基於風險的，而不是基於技術的

所有企業，無論大小，都需要建立正確的決策框架和治理機制才能成功駕馭雲端運算。這些依賴於分析和評估風險的能力。

本文+將介紹如何理解與雲端運算相關的主要風險。使用的方法是卡內基梅隆大學軟體工程研究所 (CMU SEI)所開發的風險管理法 — 馬賽克法(Mosaic approach)。

風險管理

風險管理是所有企業(無論大小)的核心業務活動。例如，我們可以在ICAEW(Institute of Chartered Accountants in England and Wales)製作的關於中小企業風險管理的簡報文件中找到基本原則的摘要。 Treadway 委員會COSO(Committee of Sponsoring Organizations)是一些關於企業風險管理的重要工作的來源，它已經發展成為一門重要的學科。 而現在變成了標準風險管理框架 :ISO 31000。

風險管理有時被老闆認為是不必要的開支，是一項可以忽略的苦差事(對風險管理來說也是"接受該風險")。這是與風險可以避免的想法相反的極端。一家經營良好的企業會”避免有毒的風險”，但會”接受可控風險”，並盡量減少風險，就可獲得可觀的利潤。良好的風險分析通常表明，預先存在的擔憂實際上可能並不是真正的風險。 如果應用得當，風險管理可以創造和保護價值。

馬賽克法以傳統風險管理為基礎並加以延伸，為管理複雜的系統性風險提供了一個框架。它通過檢查多種狀況和潛在事件的綜合影響，全面了解目標的風險。 雲端風險是一個協作和租賃問題。當企業使用雲端運算時，所產生的相互關聯的服務是IT部門可能無法完全控制的並因此產生風險。傳統的戰術風險管理( tactical risk management)是為"低度不確定性"和"少數互連的環境"而設計的，但雲端運算是在"高度不確定性和動態變化"的互連系統環境中運作。對於使用雲端運算生態系中運營的現代企業來說尤其如此。

風險評估

當考慮開發和部署新業務解決方案的規劃時，企業需要評估其任務風險 — 影響規劃實現其關鍵目標能力的系統性風險。任務風險來自對最終成果有強烈影響的因素。這樣的因素稱為驅動因素。驅動因素通過匯總情況和潛在事件的衝擊來啟用系統性的風險管理方法。

企業最初評估這些風險，並在解決方案開發和運營期間定期重新評估它們。當解決方案運作時，評估會包含對影響風險的解決方案參數的測量。

評估任務風險通常意味著要考慮許多複雜的、相互關聯的因素。雲端運算的使用會影響其中的許多因素，有時是負面的，有時是正面的。

任務風險評估不是一個簡單的過程。例如，它可能需要面談、文件審查和小組會議。這顯然需要付出大量的人力物力與時間等此類的資源。然而，將這種資源投入到大型且複雜專案的系統風險管理方法中將會得到回報。即使在初步評估階段，在沒有理由付出巨大資源的情況下，考慮所涉及的風險時，也值得遵循馬賽克法的一般思路。

本文討論是雲端運算可能產生負面影響的因素。雲端運算產生積極影響的因素有很多，這些都會有CSP與SI在宣揚它，在此就不再贅述。

風險傳達

公司老闆如果收到投資雲端運算專案的請求，就會希望了解投資回報率和投資風險。老闆們尋求做出價值判斷並與可用的已知效能基準資料進行比較，以評估專案成功的可能性。老闆們想了解在決定批准雲端專案或評估雲端服務的使用時可能需要考慮的任何差距或風險領域。

在大型企業中，風險決策通常由幾個人共同做出，然後他們必須向管理團隊的其他成員解釋。這意味著需要以清晰易懂的方式傳達風險資訊。在組織外部傳達風險資訊也可能很重要；例如，股東。

風險管理是實施企業架構專案時使用的一項重要技術(可以參考TOGAF的風險管理)。企業架構師將通過在設定架構願景時進行概要分析，在開發業務架構時進行詳細分析來滿足C-Level們對風險資訊的需求。

每種風險的衝擊和概率分別進行評估，然後結合起來給出風險曝險程度的指標。這些量化數字中的每一個都使用具有五個等級尺度：

Minimal
Low
Moderate
High
Maximum (or Critical)

這使得專案風險可以圖表來呈現。例如，下圖中的風險曝險摘要來自對B公司(公司描述請參閱企業的雲端服務採購一文)的專案初始風險分析。 (衝擊、概率和曝險值在其他公司的其他專案情況下會有所不同。)

它顯示了"財務、災難恢復和系統品質"等風險的主要曝險。財務和系統品質風險是該專案固有的，因為沒有人可以確定那些是有用的。但是，可以通過資料備份排程來減輕災難恢復風險。分析讓老闆清楚地知道他們正在承擔哪些風險，哪些可以減輕，哪些必須接受。

雲端運算的任務風險

需要考慮的與雲端相關的主要任務風險如上述B公司案例所示：

該解決方案不符合其財務目標。
該解決方案不適用於企業的組織和文化。
由於所涉及的雲端服務難以整合，因此無法發展該解決方案。
該解決方案不符合其法律、合約和道德義務。
發生災難，解決方案無法從中恢復。
該解決方案使用的外部雲端服務不足。
解決方案的系統質量不夠好，無法滿足企業的需求。

重要的是要清楚地定義每項風險，還要解釋所涉及的因素並為每項評估提供理由。下圖呈現了B公司對某個雲端服務初步評估的基本原理概要。完整的評估應該有更多的細節。雖然記分卡圖表清楚地傳達了風險概況，但大多數的人在採取具體行動之前通常需要更多資訊。 在同一基礎上進行重複的風險評估至關重要。 如果沒有對因素和決策理由的明確解釋，就不可行。

該公司沒有評估服務整合和外部服務風險，因為它沒有使用任何外部雲端服務。系統品質是一種複雜的風險，需要一個獨立的概率評估報告。其結果會轉入總體評估。

財務面

該解決方案無法滿足其財務目標是一項任務風險。許多很好的解決方案因無法實現收入和利潤目標而被放棄。 財務風險的影響幾乎總是至關重要的。

商業模式寫在文件上通常看來很棒，但當它們付諸實踐時，數字可能會大相徑庭。 讓成本與工作負載(也就企業的IT系統)直接相關，進而與企業的收入相關，雲端運算確實降低了一些風險。但它對其他因素的影響不同，有時甚至是負面的。

評估雲端 ROI 風險概率時要考量的關鍵因素是：

利用率(utilization)
速度(speed)
規模(scale)
品質(quality)

這些因素內建於大多數的ROI 模型中，並影響企業的投資、營收、成本和時間的主要數字。這些數字與計劃的偏差表明主要數字可能存在偏差，因此無法實現預期的投資回報率。

組織與文化(可能是企業使用雲端運算最重要的)

導入雲端運算可能需要對企業的組織和文化進行重大變革。我們能否說服一家具有“we do it our way(我們有自己的做事方式)”文化的傳統公司使用外部標準化服務？ 我們是否必須裁撤整個 IT 部門？工會有甚麼反應？

導入雲端運算第一個衝擊的是IT部門，之後衝擊繼而往外擴散。如果沒有企業的高層甚至是企業老闆的支持，哪麼雲端導入要嘛沒有達到預期的效益，要嘛會比建地端機房外加一堆IT人員的模式還浪費企業的資金。

採用基於雲端運算的企業業務流程的公司必須對業務轉型有明確的執行願景和方向。這個計劃無疑的需要得到高層管理人員的支持，他們必須對要實現的目標有一個清晰的願景，並為實現它制定明確的戰略。這應該包括：

為雲端服務和運作在上面的應用程式的採購或實施建立清楚的路線圖
協調利害關係人和競爭策略以獲得存儲、運算、網路和應用程式的共識，以避免需求都是一個個獨立的
確定試點和示範，以建立信心並在企業中建立對雲端服務的支持和使用
在內部或與服務合作夥伴一起培養過渡技能和雲端技術知識，以確保了解和管理技術風險

企業必須能夠做出改變，以足夠快的速度使用雲端運算的特性: on-demand provisioning，以獲得隨之而來的業務效益。 雲端旨在成為總體交付速度的階梯式變化。企業必須能夠加快步伐以利用這一點。

企業的財務結構，尤其是其收費方式(吃到飽的哪種)，可能需要重新定義以適應雲端運算的業務模型。

傳統的作業方式可能需要改變。這不僅僅影響 IT 部門。業務部門使用的基礎架構或應用程式不受企業直接控制的這一事實可能意味著企業內各單位的作業方式的改變。這將需要教育訓練，並且可能會遇到員工的抵制。

通常公司越大歷史越久所遭遇的抵制就會越大，因為太多資深員工早已習館這一二十年來的作業方式與流程。讓他們改變是企業高層管理團隊要做的，第一步就是改變員工的心態。相反的，雲端運算運用的最成功的反而是新創公司，因為他們沒有組織或文化障礙。再來就是變動很快的產業，因為它們所處的產業本身每天就是在變化。

服務整合

隨著雲端運算應用的發展，企業開始使用使用多種雲端服務，並且需要將它們相互整合也與內部系統整合。例如，某集團希望將旗下所有子公司的IT系統整合使用，該企業集團希望將基於雲端的協作服務與其他服務一起使用，以取代預計淘汰的一些應用程式。這些服務必須彼此整合，並與將繼續的應用程式的服務整合。

存在無法將雲端服務與現有系統以及彼此整合的風險。這種風險是至關重要的；如果系統無法建立，則無法使用。可以通過考慮介面轉換成本、更改現有系統的能力和可用技能來評估服務整合風險。

介面轉換成本是在介面不完全相容的情況下提供中介軟體來連接服務的成本。如果服務被設計為通用套件的一部分，或者適合特定產業參考模型，則介面可能是相容的。否則，我們應該檢查它們在多大程度上具有相容的語法、相容的語義並適合通用流程模型，或者支持合適的互操作性協定和架構。

通常，語法轉換(syntactic conversion)相對簡單，語義轉換(semantic conversion)是可能的但代價高昂，但如果服務具有完全不同的流程模型，那麼整合可能會非常困難。

類似的考量適用於改變既有系統的能力。企業應該評估它是否可以在稍作改動的情況下使用，或者是否需要打掉重練。在後一種情況下，風險很高。

以靈活、適應性強的方式組裝和客製來自不同CSP的多種雲端服務，同時維護安全、備份和治理機制，需要大量技能。 這種服務組合意味著使用它們的應用程式將需要變得更加“鬆散耦合(loosely coupled)” — — 開發是為與整合層(integration layer)一起作業而不是底層基礎設施。企業應該評估內部擁有這些技能的程度，以及聘請專家顧問的成本。如果需要對舊有系統進行重大變更，企業可能會發現必要的技能不需要再存在，無論是在企業的內部還是外部。

合規

滿足合規義務的需求我們已在企業的雲端運算願景與決策一文中進行了討論。對於企業的每項義務，企業應該評估不履行義務的風險。

除了評估與企業的系統相關的風險外，企業還應該評估與使用的外部服務相關的風險。對於使用雲端服務的專案，這通常是最重要的合規風險來源。

法規或公司政策可能要求資料位於特定的地理區域或法律管轄區，以保持安全，保持其完整性和機密性，或者在特定時期內在線上保存或歸檔。這尤其適用於個人和財務資料。

不遵守這些規定的衝擊差異很大。對於法律要求，取決於規定的處罰和執法制度。對於道德義務，影響可能包括企業聲譽的損失，這可能反過來反映在產品育服務的市佔上。

依賴外部CSP會增加不合規的可能性。即使企業的合約在地點和保密性方面提供了必要的保證，不可抗力因素也可能會阻止CSP履行這些合同。例如，對於雲端環境中的資料傳票的法律訴訟結果會是什麼，這些資料甚至可能不在企業的租約下，但已被CSP其他租戶放置在同一套系統上？那麼對企業聲譽會產生什麼影響？

由於像這樣的問題，合規性是一個重要的雲端風險領域。所有要使用雲端運算的企業都將這種影響評為關鍵，但我們在企業的雲端服務採購一文中提到的A公司案例是唯一一家給予它顯著可能性的公司。它們必須符合歐盟法規。 A公司相信他們可以做到這一點，但這是一個複雜的領域，A公司將風險概率評為中等。

營運持續管理

企業有時需要對計劃外事件做出反應並從中恢復。至於合規性，企業應該評估與使用的外部服務相關的風險，以及評估與自身系統相關的風險。

導致 IT 能力重大損失的災難（例如火災、洪水和地震）是可能影響內部系統或CSP系統的事件案例。還有其他類型的事件，例如CSP的併購、意外破產或合約取消，可能會影響CSP並需要類似的回應。

使用雲端運算會使回應變得更加困難，因為企業對相關 IT 資源的控制或可見性較低。不過，通常購買企業等級的保固服務通常可以緩解此一問題。但此類的服務對台灣一般中小企而言可能是一筆不小的負擔。

作為風險分析的一部分，企業應該確定可能傷害企業的預期外事件，並評估它們的概率和衝擊。企業可能還希望為中斷的雲端服務或毀損資料的不可預期事件做出一般規定。

識別風險後，企業可以將降低風險概率或減輕其影響的系統設計元素構建到系統中。例如，一個有效的備份和回復過程，將備份副本保存在與資料不同的位置，或者保存在自己的地端機房中，可以將災難的影響從嚴重轉變為輕微的。

系統品質

這是解決方案無法滿足業務單位需求的風險。系統品質的重要性在品質：我們在建立雲端運算的投資回報率一文中提到，更好的服務帶來更好的利潤。品質差的影響是減少利潤和投資回報率損失。

至於合規性和災難恢復風險，企業應該評估與自身使用的外部服務相關的系統品質風險，以及評估與自身的系統相關的風險。

我們在企業的雲端服務採購一文中提到的B公司案例進行的第一次系統品質評估展示了系統品質的風險因素。不出所料，由於該產品尚未在市場上試用，這表明功能和用戶滿意度等高度影響因素的失敗概率很高。 (與下圖中心的距離表示影響概率的大小。)如果這些風險成為現實，並且產品不能滿足其用戶，那麼專案將失敗，老闆的錢就丟進水裡了。

外部服務

如果企業使用的是外部雲端服務，那麼企業應該評估它們不夠適當的風險。

如果解決方案依賴於外部雲端服務來提供必要的基礎設施或功能，那麼影響可能會很嚴重。但如果有退出策略，影響會較小，就像我們在企業的雲端服務採購一文中所述。

要考慮的因素包括外部服務的系統品質及其CSP的適合性。

可以使用與評估企業自身的解決方案的系統品質相同的因素來評估外部雲端服務的系統質量。 案例的B公司對與使用外部 PaaS 服務相關的風險所做的評估如下所示。

儘管這些因素與評估整體B公司解決方案的因素相同，但這些因素所呈現的數值不同。它們通常毫無關聯。例如，PaaS 服務的使用者是 ViWi 開發人員，他們對開發平台的滿意度並不像B公司的客戶對最終產品的滿意度那麼重要。另外，PaaS平台已經很成熟了，不盡如人意的可能性很小。

使用雲端運算的企業依靠CSP來完成許多傳統上在內部完成的事情。企業應該評估CSP的品質，因為存在CSP不適合的風險；例如，它被證明是不可信的，或者太小間容易倒閉。

所涉及的許多因素 — — 例如財務穩定性、規模、聲譽和業績記錄 — — 與企業所依賴的一般傳統供應商的因素相似。在雲端運算的背景脈絡下，企業應該特別關注CSP在滿足 SLA、客服回應(視企業買甚麼等級的客服服務)以及願意分享給CSP有關服務運營和系統架構的資訊方面的記錄。

在涉及資訊時，企業需要記住這一條 — “現實佔有，九勝一敗(Possession is nine-tenths of the law)”。例如，CSP可以出於自身目的以難以偵測或證明的方式使用或出售租戶(也就是一般企業)資訊。 CSP品質評估應包括可信度。

系統品質風險因素

上面定義的系統品質取決於以下因素:

功能性(functionality)
效能(performance)
可管理性(manageability)
安全性(security)
使用者滿意度( user satisfaction) — 也就是企業的客戶

這些因素中的前四個因素的要求我們已在我們在企業的雲端服務採購討論過，使用者滿意度取決於這四個因素。

1.功能性

系統沒有具備"必要功能"的風險取決於企業使用的外部雲端系統的類似風險，以及與雲端運算無關的因素，例如規範的品質。

如果企業依賴具有複雜功能的 PaaS 或 SaaS 服務，這可能是一個重要的考量因素。

B公司依賴於他們使用的雲端平台中的重要功能。他們已經發現沒有符合他們要求的PaaS服務，所以風險概率是確定的。然而，影響只是中度的；他們可以通過在自己的系統中使用開源軟體來克服平台功能的不足。

2.效能

效能包括可用性(availability)和可靠性(reliability)、可恢復性(recoverability)、吞吐量(throughput)和回應能力(responsiveness)。

可用性取決於可靠性。從風險分析的角度來看，MTBF 可靠性因素決定了風險概率，而 MTTR — — 系統修復所需時間的可能值 — — 決定了其影響。

容錯性(Fault tolerance)是影響可用性風險概率的一個因素。完全容錯的設計沒有SPOF( Single Point of Failure)，並且通常在一個服務時間區間內積累多個故障。軟體容錯設計包括異常處理和task rollback。對於這樣的系統，失敗的概率會很低。

可恢復性是從故障中恢復的能力。如果系統出現故障，可能會遺失一些資料。如果故障發生在運算單元上，則丟失的資料量將取決於應用程式如何處理資料；寫得好的軟體，資料量可以很小。如果故障發生在存儲系統中，則損失可能很大。使用冗餘存儲可以將這種可能性降到最低。

許多公司如果丟失了保留在 IT 系統上的所有資料，就會倒閉。通常的做法是通過備份來去除這種衝擊。例如，每日備份限制了 24 小時資料遺失的影響。

如果系統運行良好，其吞吐量與工作負載相同。但存在無法處理所需負載的風險。在評估此風險時，企業應該考慮系統應支援的吞吐量等級範圍、等級變化的可預測程度以及負載變化的處理方式。

如果使用雲端服務，可以在風險和成本之間做出權衡。使用比滿足預期負載所需的資源更多的資源配置系統會降低無法處理負載的可能性，但會增加成本。如果可以動態配置系統，則可以將這種過度配置保持在最低限度，但必須考慮負載變化的速度以及額外資源上線的速度。

可以通過在系統之間分配提供的負載來降低過載的可能性。在配置資源時，CSP通常有一些方法可以做到這一點， A公司使用集中式資料庫，無法對運算單位進行分區。 B公司可以輕鬆做到這一點，因為不同的微服務可以在不同的系統上運行。

在評估系統回應不足的風險時，應考慮系統應有的回應時間、回應時間的允許可變性以及對回應可預測性的需求。

3.可管理性

可管理性包括可配置性、回報和故障管理等因素。對它們的需求我們已在企業的雲端服務採購討論過。如果不能滿足這些需求，最好一點情況下會增加客戶的不滿意度，最壞的情況下會導致系統完全掛掉。

Provisioning management對於雲端服務尤為重要。 A公司評估雲端服務在其解決方案中的可管理性風險影響為高，主要是因為需要動態的資源配置。

4.安全性

資料在企業自己的機房中，提供了一種企業在雲端中失去的控制感。雲端服務通常通過網際網路存取的，在評估安全性時必須考慮到這一點(不過要拉一條與雲端機房的網路專線可能另當別論)。這並不是說雲端運算就一定不安全，只是需要不同的角度去考量安全性，要使用更現代的安全模型。企業必須調整傳統的安全模型以適應雲端運算需求並考慮端到端(end-to-end)的安全性，包括企業的內部存取控制和使用者管理政策。與安全威脅相關的風險分析是一門重要的專業學科。 ISC2 的CCSP專門針對雲端運算的安全做出全面性的討論。

在企業的雲端服務採購一文討論了終端使用者存取控制、供應商存取控制、資源分區、安全日誌記錄和威脅回應的需求。沒有滿足這些需求可能會導致系統和資料無法使用、財務損失、敏感資訊洩露、不符合隱私法規以及聲譽受損。它還可能導致系統的完整性受到攻擊，從而導致破壞或資料外洩。例如，這可以通過植入惡意軟體或運用現有軟體漏洞來實現。

有兩個因素會增加企業在雲端上發生安全漏洞的可能性。 一是需要依賴SI來進行部分資安控管。另一個是使用來自不同SI服務的系統中的資安控管，這些可能會引入未考量到的區域漏洞的可能性。

考量到其運營可能中斷和客戶資訊遺失，A公司將安全漏洞的影響評估為高，但並不嚴重。它評估的可能性很低，因為它信任合作廠商，只有它的員工(不過可能有內賊，我們需要其他方法才能管控)才能控制操作和存取客戶資訊，並且它會有標準的存取控制機制。如果它決定讓合作廠商存取該系統，以提高生態系統生產力，則必須重新評估安全風險。

PS.關於企業員工風險管控，請參閱本部落格Teramind- 員工風險控管與生產力一文

5.使用者滿意度

從邏輯上講，使用者滿意度是上述其他系統品質的結果。實際上，應該單獨考量和評估。我們可能還是存在著使用者對系統不滿意的明確風險，即使它看起來具有足夠的功能性、效能、可管理性和安全性。

在設計時，企業需要查看是否諮詢了領域專家(SME)以及是否進行了使用者測試來評估使用者滿意的可能性。當系統上線時，採取主動措施來衡量使用者滿意度。這作為品質指標的重要性我們已經在建立雲端運算的投資回報率一文中討論過。

持續風險評估

在決定使用雲端運算或哪種形式的雲端運算時，會進行初始風險評估。本文到現在都是討論"初始風險"。但是風險分析並不是在系統開發開始時就結束，然後就不管了。 隨著環境的變化，它應該在系統的整個生命週期中重複的評估。

解決方案架構開發

TOGAF的第 31 章：風險管理中描述了風險管理作為企業架構不可或缺的一部分的重要性。本節說明了此原則在 A公司的雲端解決方案中的應用。

該專案的初始風險評估呈現出，在組織和文化、合規性和災難恢復方面存在重大風險(如下圖)。

"組織和文化"風險的出現部分是因為公司內部普遍存著保守文化(因為公司包袱過多)。但是，該專案得到了大老闆的支持。 CEO明確表示不會容忍反對意見(CEO說:不想配合的可以走人)。同時，該公司將提供優惠的離職獎勵金，鼓勵企業不再需要的 IT 員工離職。

合規風險與GDPR立法有關。 A公司決定將所有資料保存在歐盟區域內，以確保所有客戶和員工資料保密，並使客戶和員工檢視他們的個人資料。高階管理層認為這是一種道德義務，也意味著公司遵守所有該遵守的法律。該解決方案將使用的 IaaS 服務的含義是，它必須將所有資料保存在歐盟範圍內，並使這些資料只能由 A公司授權的人員存取。這是企業的雲端服務採購中"選擇階段"的強制性要求。

為了提供災難恢復，將有一個備用 IaaS CSP。所有資料的副本將定期存儲在該備用的CSP的系統中，並且將有一個應急計劃，以便在主要CSP遭受災難時將營運轉移到該CSP。災難的影響將處於非關鍵等級(non-critical level)，但仍可能會中斷營運和遺失一些資料。

系統品質風險在效能方面 — -
旺季期間每日備份之前的一次故障可能會導致資料遺失，這將影響全年 10% 的銷售額 — — 這將在財報中得到非常明顯的反映。設計人員決定修改系統，將交易資料的副本寫入CSP另一個區域的雲端機房。這是一個很好的例子，說明有效的風險評估如何在看似強大的企業運轉大機器中找到一個“最薄弱環節”。

此風險緩解過程的效果是將所有曝險降低到可接受的水準。

風險評估將在架構開發的重要階段重複進行，以確保曝險水準繼續在可接受的範圍內。

雲端服務的選擇與採購

選擇雲端服務後，應審查與每個雲端服務相關的風險。合約條款的談判應設法降低買方的風險(前提是企業要夠大，不然只能接受CSP的公版合約)。談判後剩餘的風險水準是做出選擇時需要考慮的因素。A公司確定了三個滿足需求且價格合理的 IaaS 供應商。

第一個是大型跨國CSP。第二個是一家小型本地CSP，提供極其便宜的月租費率。第三個是位於另一個歐盟國家的中型CSP。

A公司對每個潛在CSP進行風險評估，並比較結果。系統質量風險相當均勻，但CSP不夠合適的風險各不相同：大公司的風險很小，本地小公司的風險中等，中型CSP的風險低。儘管具有成本優勢，但他們評估本地CSP(IaaS 2) 的風險太大。中型CSP(IaaS 3) 的風險略高於大型跨國CSP，但出於成本考慮而被選中。

解決方案營運

在營運過程中，還應酌情重新評估風險。以下為B公司的範例。

專案在六個月後重新評估風險。服務已經上線，解決了服務整合、系統質量、對外服務等問題。此外，雖然銷售額低於預期，但投資回報率因素有所改善。總體風險情況非常不同，而且更加積極。

在這種情況下，評估對於決定是否繼續該專案至關重要。更常見的是，賭注較低。然而，風險確實會隨著專案的生命週期發生變化。這可能意味著系統修改和營運變動，即使取消專案不是問題。