第壹步 資產識別
1.首先識別與在PaaS上軟件即服務(SaaS)應用開發相關的資產，然後為每壹個資產分配壹個數值。確定所有資產所屬的類別。下面是壹些例子：1.用戶：SaaS開發人員和SaaS用戶都應歸於這壹類別。每個用戶組的數值都應當基於開發和測試應用時所用去的平均工時數。
2.資源：這是指被PaaS開發人員使用以運行和存儲SaaS應用的資源。例如，Elastic Beanstalk使用了亞馬遜彈性雲計算(EC2)、亞馬遜簡單存儲服務、亞馬遜簡單通知服務、亞馬遜CloudWatch、彈性負載平衡以及自動縮放等功能。其數值應基於這些資源的所用即所付的支出。Elastic Beanstalk是免費的。
3.安全性：這就意味著加密機制、防火墻以及行業安全標準，其中包括了SecaaS(安全即服務)。其數值是基於用於實施安全措施的工時。
4.文檔：培訓手冊、管理準則、安全標準、物理標準、應急計劃、災難恢復計劃以及服務等級協議(SLA)等也只是文檔中的若幹示例而已。其數值是基於用於發布文檔所需的媒介類型的——如打印、在線或數字媒體(CD)等。
5.軟件：操作系統;漏洞測試工具;辦公工具(文檔、電子表格、演示文稿);日誌分析工具;以及編程語言(Java、 .NET、 PHP腳本程序語言、Node.js 編程語言、Python和Ruby) 都應被視為軟件。其數值應基於軟件的采購價格或用於在PaaS上進行SaaS應用開發所需的所用即所付支出。
第二步 漏洞與威脅識別
黑客並不是唯壹會利用PaaS漏洞的威脅來源。以下是威脅來源的其他壹些示例：
軟件設計缺陷可能會讓惡意SQL註入。
不正確的訪問控制配置可能會導致應用正在處理的存儲敏感數據被盜。
不正確的防火墻配置可能導致意外的PaaS停用。
由於雲計算的資源池和彈性特性而出現的數據恢復脆弱性。這意味著分配給壹位用戶的資源有可能會被意外地重現分配給另壹位不同的用戶。這樣，也就無法總是保證能夠為前壹位用戶恢復數據。
第三步 風險評估
用戶希望得到保證，即PaaS將持續地保持可用性，同時他們獲得更多流量資源的需求能夠得到滿足。對於不可用性風險的評估是壹種定量的方法。壹些示例包括：
PaaS在壹年中由於基礎設施即服務(IaaS)停用而變得不可用的估計頻率
由於不正確防火墻配置而受到PaaS攻擊的估計頻率
不能滿足SLA中承諾性能的估計頻率
支持PaaS運行的IaaS的網絡路由器和交換機發生不成功故障的估計頻率。
第四步 應用相關保障措施修補漏洞
執行成本效益保障措施是降低在PaaS上進行SaaS應用開發風險的壹種方法。下面是壹些例子：
應用已被正確設計，且沒有軟件缺陷。PaaS開發人員和雲計算架構師擁有了足夠的技能和經驗在PaaS上開發設計良好的應用。
用戶已根據他們不同的角色和/或數據敏感度對訪問控制配置進行了正確的設置。日誌記錄選項已被激活。
防火墻設置已被正確設置。入侵檢測系統和負載平衡器均已到位。壹個PaaS故障機制策略已得到增強。PaaS的輸入輸出流量數據已被加密。
第五步實施風險緩解策略
資產識別、漏洞與威脅識別、風險評估以及應用相關保障措施修補漏洞的具體實施過程會隨著具體組織的實際情況不同而有所差異。為了對整個過程實施標準化並降低相關成本，應實施風險緩解策略。
這個策略應包括AWS資源、編程語言以及在PaaS上用於開發、運行以及存儲應用的服務器(在前文所述的情況中，就是指Elastic Beanstalk)，而且因重大技術變革、用戶需求變更以及組織需求變更需對該策略進行周期性審查和更新。