10.2 リスク、監査、保証

概要と動機

リスク、監査、保証とは、自分のソフトウェアと、それを築いて動かす組織に、何がうまくいかない可能性があるかを理解する実践です。それについて何をするかを決めます。それから、持っていると主張する統制が実際に働くことを証明します。経営幹部、規制当局、監査人、公衆に対して証明します。小さなチームでは、リスク管理はほとんど暗黙のものです。数人が全体像を頭の中に持っています。大きな企業や政府機関では、リスクを明示的で体系的にしなければなりません。誰一人として全体の面を見渡せません。失敗の結果は大きく、しばしば規制されています。信頼は、想定されるのではなく、示されなければなりません。

これは大きな組織にとって、三つの理由でより重要です。第一に、規模は露出を倍増させます。より多くのシステム、サプライヤー、データ、人、接続は、失敗する方法がより多く、失敗が来たときの影響範囲がより大きいことを意味します。第二に、大きな組織は外部の者(規制当局、監査人、取締役会、裁判所、市民)に答える立場にあり、彼らは保証ではなく証拠を求めます。第三に、集中は静かに忍び寄ります。共有のプラットフォーム、共通のサプライヤー、再利用されるコンポーネントは、どの単一のチームも気づかない単一障害点を作り出し、それでも企業全体を一度に落としえます。

この章は、デリバリーを官僚主義で窒息させずに、企業のリスク管理の規律をソフトウェアにもたらすことを目指します。うまく行えば、リスクと保証はエンジニアリングへの税ではありません。大きな組織が、規模で運用する権利を勝ち取る方法です。「私たちを信頼してください」を、「これが証拠です」に変えます。

主要原則

リスクは管理するもので、排除するものではない。 仕事は、リスクを受け入れられる水準まで特定し、評価し、処理し、監視することで、ゼロにできるふりをすることではありません。
リスクが生まれる所で所有する。 システムを築いて動かすチームがそのリスクを所有します。中央の機能は標準を設定して確認するのであって、説明責任を吸収しません。
主張より証拠。 示せない統制は、持っていない統制です。
時点ではなく継続的。 年次の監査はずれを遅すぎて捉えます。統制は、可能な所では継続的かつ自動的に監視すべきです。
サードパーティはあなたのリスクを引き継ぐ。 サプライヤーの弱点があなたの弱点になります。サプライチェーンのリスクはあなたのリスクです。
集中は第一級のリスクである。 統合による効率は、名指しして管理しなければならない単一障害点を静かに作り出します。
比例性。 統制の深さを結果に合わせます。すべてのシステムを最大の重要性として扱うことは、労力を無駄にして回避を育てます。

推奨事項

企業のリスク管理をソフトウェアに適用する

リスクを比較して合算できるよう、組織全体で共通のリスクの枠組みと語彙を採用します。各重要なシステムにリスク登録簿を保ち、個々の登録簿をポートフォリオの視点に積み上げます。各リスクについて、可能性、影響、所有者、現在の統制、処理の決定(受け入れる、緩和する、移転する、回避する)を記録します。職務を分けるために、「スリーラインズ」モデルを使います。チームが自分のリスクを所有して管理し(第一線)、リスクとコンプライアンスの機能が方針を設定して異議を唱え(第二線)、内部監査が独立に保証する(第三線)。チームがそれぞれ推測する代わりに、組織がどれだけのリスクを負う意思があるかを知れるよう、頂点で明示的なリスク選好を設定します。

サードパーティとサプライチェーンのリスクを保証する

サプライヤーを、そして同じくらい重要なこととして、推移的なオープンソースのコンポーネントを含むソフトウェアの依存関係を、目録にします。各サプライヤーを、それが持つアクセスと重要性に比例して評価します。良い証拠がすでに存在する所では、質問票を再発明するのではなく、認められた証明(プロバイダーのセキュリティ統制に関する独立した監査報告であるSOC 2や、ISO 27001の報告など)に頼ります。脆弱性が公になった瞬間に「影響を受けるか」に答えられるよう、利用するコンポーネントにソフトウェア部品表(SBOM)を要求します。サプライチェーンの完全性をパイプラインに組み込みます。出所を検証し、成果物を固定して署名し、ビルドに入るものを制御します。セキュリティ、侵害の通知、監査権、出口の条項を契約に書き込みます。サプライヤーを、オンボーディングの時だけでなく、定期的な周期で再評価します。

監査証跡、証拠、継続的な統制の監視を築く

稼働の副産物として証拠を生むようにシステムを設計します。重要な行動の、不変で、タイムスタンプ付きで、改ざんが明らかな監査ログを捉えます。誰が、何に、いつ、どの承認で、何をしたか。それらのログを、記録されるその人々自身による変更から守ります。自動化されて継続的に監視される統制を好みます。不適合な変更をブロックするポリシー・アズ・コード、必須のレビューを徹底するパイプラインのゲート、統制の状況をリアルタイムに示すダッシュボード。継続的な統制の監視は、監査を、証拠を再構成する定期的な大慌てから、保証の安定した流れに変えます。次の年次レビューではなく、数時間以内にずれを捉えます。

事業継続と災害復旧を統治する

システムが失敗したら、組織が何を、どれだけ速く続けなければならないかを知ります。工学的な都合ではなく事業のニーズに基づいて、サービスごとに復旧時間と復旧時点の目標(RTO/RPO)を設定するために、事業影響分析を行います。それから事業継続と災害復旧(DR)の計画を維持し、(組織が飛ばすのはここですが)実際にテストします。完全なフェイルオーバーとバックアップからの復元の訓練を含む、定期的な演習を行います。テストされていないバックアップとテストされていないフェイルオーバーは、能力ではなく想定です。システム間の依存関係を、本物の災害の最中ではなく前に理解できるよう、これを企業の水準で統治します。

集中リスクと単一障害点を管理する

多くのサービスが一つのものに依存している場所を意図して探します。単一のクラウドリージョン、一つの認証プロバイダー、一つの主要なサプライヤー、一つのデータベース、一人の人。個々のチームには見えないので、これらの集中をポートフォリオの水準で地図にします。最も重要なものについては、冗長性、マルチリージョンあるいはマルチサプライヤーの戦略、グレースフルデグラデーションで集中を減らし、追加のコストと複雑さを誠実に量ります。効率のために集中を受け入れる所では、それを、テストされたバックアップ計画を伴う、意識的で文書化され所有された決定にします。失敗するまで誰も気づかなかった偶然にしてはいけません。

トレードオフ: 長所と短所

アプローチ	長所	短所
重い正式な統制	強い保証。監査と規制当局に対応できる	デリバリーを遅くする。チェックボックスのコンプライアンスと回避を招く
軽量でリスクベースの統制	速い。労力が本物の露出に集中する	成熟した判断が必要。リスクの評価がまずいと隙間
時点の監査	なじみがある。明確な合否の瞬間	ずれを遅く捉える。監査の日のためだけに準備するインセンティブ
継続的な統制の監視	ずれの早期検知。監査の大慌てが少ない	前もっての自動化への投資。ツールと計装のコスト
統合/単一のサプライヤー	低いコスト。より単純。量のてこ	集中リスク。単一障害点。ロックイン
冗長性/マルチサプライヤー	レジリエンス。単一障害点なし	高いコストと複雑さ。保守して保護するものが増える

繰り返されるトレードオフは、保証対速度です。解決は、比例性に自動化を加えたものです。一律の重い統制は全員を遅くし、さらに悪いことに、チームにコンプライアンスを、ゲーム化される劇場として扱うよう教えます。純粋に軽量な統制は、すべてのチームが持つわけではない判断に依存します。進む道は、統制の深さを結果に合わせ、統制をデリバリーのパイプラインに自動化して、保証が事後に取り付けられるのではなく、築く行為から生まれるようにすることです。集中のトレードオフ(効率対レジリエンス)に普遍的な答えはありません。各重要な依存関係について、受け入れたリスクを文書化し、バックアップ計画をテストして、意識して決めてください。

チームで議論すべき問い

統制の深さが結果に合うよう、システムをどう重要性で分類しますか。 比例性は、保証対速度の緊張への解決です。すべてのシステムを最大の重要性として扱えば労力を無駄にしてチームにコンプライアンスをゲーム化するよう教え、何も重要でないとして扱えば、無防備なところを捕まります。各システムを頂点で設定されたリスク選好に結びつける明示的な階層づけが必要で、リスクの低い社内ツールと、市民向けの給付システムが、同じ統制を負わないようにします。議論に証拠を持ち込んでください。システムの一覧、それぞれが持つデータと影響範囲、現在適用されている統制を並べ、どちらの方向のミスマッチも探します。答えは、何をパイプラインに自動化し、何を人間の判断に任せるかを変えるべきで、チームに、推測ではなく日々のトレードオフの明確な根拠を与えるべきです。合意された階層がなければ、比例性は単なる言葉です。
次に重大な依存関係が脆弱性を公表したとき、数分以内に「影響を受けるか」に答えられますか。 広く使われるコンポーネントが壊れたとき、素早く対応する組織は、推移的なオープンソースの依存関係を含め、コンポーネントが使われているすべての場所を対応づけるSBOMの目録をすでに持っています。誠実な答えが数日、あるいは「見に行かなければならない」なら、その隔たりが、封じ込められた対応と大慌ての違いです。証拠を持ち込んでください。依存している実際のライブラリを一つ選び、それを出荷しているすべてのサービスを列挙するのにどれだけかかるかを計ります。答えは、パイプラインでのSBOMの生成、成果物の固定と署名、出所の検証への投資を駆動し、露出が調査ではなくクエリになるようにすべきです。これはサプライチェーンのリスクで、サプライヤーの弱点はすでにあなたの弱点です。
どのサービスが完全なフェイルオーバーとバックアップからの復元の訓練を受け、どれだけの頻度で、合格したことを誰が承認しますか。 テストされていないバックアップとテストされていないフェイルオーバーは、能力ではなく想定で、組織はこれを、前ではなく本物の災害の最中に発見します。サービスごとに事業のニーズから復旧時間と復旧時点の目標を設定するために事業影響分析を行い、それから訓練の頻度をそれらの階層に結びつけます。証拠を持ち込んでください。最も重要なサービスで、最後に完全な復元が実際に端から端まで演習されたのはいつで、記載されたRTOを満たしましたか。答えは、結果がリーダーシップに報告される、日常的でシステム横断のDR演習の予定を生むべきです。企業の水準でのガバナンスこそ、単一のチームには見えないシステム間の依存関係を表面化させるからです。効率のために単一リージョンや単一サプライヤーへの集中を受け入れる所では、それを、テストされたバックアップ計画を伴う、意識的で文書化され所有された決定にしてください。
どの統制が稼働の副産物として自動的に証拠を生み、どれが依然として監査の時に誰かが証明を組み立てることに依存していますか。 示せない統制は持っていない統制で、監査を落ち着いて切り抜ける組織は、誰も集めることを思い出さなくても、パイプラインが重要な行動の不変でタイムスタンプ付きの記録を出す組織です。相反する引力は本物です。統制をポリシー・アズ・コードと継続的な監視に自動化することは、前もってエンジニアリングの労力がかかり、時点の証拠収集は、年次の大慌てが来てずれがすでに何か月も蓄積しているまでは安く感じられます。議論に証拠を持ち込んでください。上位数個の統制について、その証明が今、改ざんが明らかなストアにあるか、ログが記録する人々がそれを変更できるか、四半期分の活動を再構成するのに何時間かかるかを尋ねます。答えは、手作業の証明より、継続的な統制の監視とパイプラインのゲートへの投資を導くべきです。企業と政府の設定では、最も強い立場は、監査人に生きた統制のダッシュボードへの読み取りアクセスを与えることで、監査を、定期的な再構成から、証拠の安定した流れの継続的なサンプリングに変えます。
スリーラインズは実際に分離された職務として働いていますか。それとも、所有が曖昧になって、システムを築く人々がそれを保証もしていますか。独立性がモデルの要点のすべてです。チームは第一線で自分のリスクを所有して管理し、リスクとコンプライアンスは第二線で方針を設定して異議を唱え、内部監査は第三線で独立に保証し、それらの役割が互いに崩れ合うと、保証は自己採点の宿題になります。緊張は、リスクの所有をデリバリーチームに押し出すと、中央の機能に吸収させるより遅く論争的に感じられることですが、中央による吸収は、リスクが実際に生まれる所から説明責任を静かに取り除きます。証拠を持ち込んでください。最近の重要なリスクの決定を地図にして、誰がそれを所有し、誰が異議を唱え、誰が独立に保証したかを名指しし、それから単一のグループがそのうち二つの役を演じていないかを確認します。議論は、リスク選好が頂点で明示的に設定されているかも表面化させるべきです。なければ、各チームがどれだけのリスクを負うか推測するからです。規制対象の企業や政府機関では、システムを築いたチームとは別の、残余リスクを正式に受け入れる説明責任のある職員は、しばしばあれば良いものではなく厳格な要件です。
多くのサービスが静かに一つのものに依存しているのはどこで、ポートフォリオの水準でその集中を誰が所有していますか。 単一のクラウドリージョン、一つの認証プロバイダー、一つの主要なサプライヤー、一つのデータベース、あるいは一人の人への統合は、本物の効率と量のてこを届けますが、各チームは自分の一部しか見ないため、どの個別のチームにも見えない単一障害点も同じくらい確実に作り出します。誠実なトレードオフは効率対レジリエンスで、普遍的な答えはありません。冗長性とマルチリージョンあるいはマルチサプライヤーの戦略は、お金、複雑さ、保護する面の増加と引き換えにレジリエンスを買います。証拠を持ち込んでください。共有の依存関係のポートフォリオ水準の地図を試み、単一の停止が多くのサービスに連鎖するチョークポイントを探し、それからそれらの集中のどれを実際に誰かが所有しているかを確認します。答えは、最も重要な依存関係について、偶然の集中を、意識的で文書化され、緊急時の計画がテストされた決定に変えるべきです。企業と政府のポートフォリオでは、単一リージョンの市民向けサービスをさらすリージョンの停止は、まさに規制当局と公衆が後から精査する失敗なので、災害の最中ではなく前に地図にしてください。

セクター別の視点

スタートアップ。 少数の人員でリスク部門に割く滑走路がないなら、保証を別の機能ではなく、築くことの副産物にしてください。エントリごとに所有者と処理の決定を伴う短いリスク登録簿を一つ保ち、一から統制を書くのではなくクラウドプロバイダーのSOC 2報告に頼り、依存関係の欠陥が着地した日に「露出しているか」がクエリになるよう、パイプラインでSBOMを生成します。最も目立つ集中を声に出して名指ししてください。通常はデプロイできる一人で、知識が一つの頭に閉じ込められないよう、誰かをその人にペアで付けます。

小規模事業者。 専任のリスクや監査の専門家はおらず予算も厳しいので、保証を築くのではなく買ってください。そうでなければ自分で用意しなければならない証拠をすでに運ぶ、SOC 2やISO 27001の証明を持つサプライヤーを好みます。限られた労力を結果が最も大きい所に使ってください。誰も保守しない手の込んだ枠組みより、一つのリスク登録簿と月次のバックアップからの復元訓練のほうが勝ります。契約を統制として扱い、サプライヤーとの合意に侵害の通知と出口の条項を書き込んで、彼らのリスクを盲目的に引き継ぐ量を減らします。

大企業。 決定的な問題は、多くのチームにわたる規模なので、スリーラインズのモデルを運営し、取締役会水準のポートフォリオの視点に積み上がるサービスごとのリスク登録簿を保ち、チームが推測するのをやめるよう頂点で明示的なリスク選好を設定してください。重要な統制をパイプラインで徹底されるポリシー・アズ・コードとして符号化し、年次の監査に備える代わりに、監査人に生きた統制のダッシュボードへの読み取りアクセスを与え、単一のチームには共有のチョークポイントが見えないので、ポートフォリオの水準で集中リスクを地図にします。比例性がスローガンではなく本物になるよう、明示的な重要性の階層で統制の深さを結果に合わせます。

政府。 調達規則、透明性、公的な説明責任がすべての選択を形づくります。説明責任のある職員が残余リスクを受け入れる正式な認可のプロセスに従い、認可が一度きりの証明書ではなく継続的な状態になるよう継続的な監視を保ち、ベンダーの契約に監査権とデータの可搬性の条項を書き込みます。単一リージョンの市民向けサービスをさらすリージョンの停止は公的な問題になるので、最も重要なサービスにマルチリージョンのフェイルオーバーとテストされた復元を義務づけ、災害復旧の演習の結果を固定の周期でリーダーシップに報告します。

事例

スタートアップ。 患者データを扱う6人のヘルステックのスタートアップは、リスク部門に払う余裕がないので、保証を築くことの副産物にします。共有のドキュメントに、エントリごとに所有者と処理の決定を伴う短いリスク登録簿を一つ保ち、金曜日のスタンドアップでレビューします。一から自前の統制を書くのではなく、クラウドプロバイダーのSOC 2報告に頼り、依存関係の欠陥が着地した日に「露出しているか」に答えられるようパイプラインでSBOMを生成し、テストされていないバックアップは希望にすぎないので、毎月バックアップからの復元訓練を行います。また、最も目立つ集中リスクを声に出して名指しします。デプロイできる唯一の創業者で、知識が一つの頭に閉じ込められないよう、二人目のエンジニアを彼にペアで付けます。

大企業。 決済企業は、継続的な規制の精査のもとで運営します。スリーラインズのモデルを運営し、取締役会水準のダッシュボードに積み上がるサービスごとのリスク登録簿を保ち、重要な統制を、デプロイのパイプラインで徹底されるポリシー・アズ・コードとして符号化します。変更の承認、アクセスの付与、設定の変更は、改ざんが明らかなストアに不変の監査イベントを出します。年次の監査に備える代わりに、監査人に生きた統制のダッシュボードへの読み取りアクセスを与え、監査を連続的な証拠のサンプリングに変えます。広く使われるオープンソースのライブラリが重大な欠陥を公表したとき、同社のSBOMの目録は「どこが露出しているか」に数分で答えます。

政府。 国の政府機関は、どのシステムも運用される前に、正式な認可のプロセスに従います。文書化された統制、独立した評価、残余リスクを受け入れる説明責任のある職員を要求します。認可が一度きりの証明書ではなく継続的な状態になるよう、継続的な監視を維持します。かつてリージョンのクラウド停止が、市民向けの給付システムの単一リージョンへの依存を露呈させました。その対応として、機関はポートフォリオ全体で集中リスクを地図にし、最も重要なサービスにマルチリージョンのフェイルオーバーとテストされた復元を義務づけ、今ではその結果がリーダーシップに報告される、定期的な災害復旧の演習を行っています。

ビジネスケース: 動機、ROI、TCO

リスクと保証の見返りは、避けられた壊滅的な損失に支配されます。大きな侵害、規制上のペナルティ、重要なサービスの長引く停止、サプライチェーンの侵害。これらの出来事は個々にはまれですが、個々には莫大です。避けられた単一のインシデントが、保証プログラム全体の複数年のコストを上回りうるのです。損失の回避を超えて、成熟した保証は、証拠がパニックの中で組み立てられるのではなく自動的に生産されるので、コンプライアンスの継続的なコストを下げます。規制対象の事業を獲得し、顧客のデューデリジェンスを通過するのを容易にします。そして、すでに自分の露出を知っているので、インシデント対応を速めます。

採用のコストには、リスクと監査の職員、監視と証拠のツール、統制をパイプラインに自動化するエンジニアリングの労力が含まれます。採用しないコストは、防げなかった大惨事の期待値に、手作業の監査準備の緩やかな税と、あらゆる公的な失敗の後に複合する評判の毀損を加えたものです。リーダーシップに論拠を示すときは、少数のもっともらしい最悪のケースとその可能性を定量化してください。継続的な統制の監視を、大きく予測できない時折の損失を、小さく安定して予測できるコストと交換するものとして枠づけます。総所有コストを強調してください。一度自動化された統制は、以降毎年、監査のコストを下げ続けるからです。

アンチパターンと落とし穴

チェックボックスのコンプライアンス。 本物の統制が機能していないのに、監査人を満足させる文書を作ること。
監査日の劇場。 年次の監査の前の数週間だけ準拠し、残りの一年はずれるシステム。
墓場としてのリスク登録簿。 一度埋められたら二度と見直されず、実際の決定から切り離された登録簿。
テストされていないDR。 一度も演習されたことがなく、したがって必要なときに機能しないバックアップとフェイルオーバーの計画。
ロゴによるサプライヤーの信頼。 有名なベンダーは安全だと証拠なしに想定し、推移的な依存関係を完全に無視すること。
見えない集中。 誰も結果としての単一障害点を所有しないまま、効率のために一つのリージョン、サプライヤー、人に統合すること。
デリバリーのブロッカーとしての保証。 比例性のない重い中央の統制で、チームが迂回し、保証がまったくない影のシステムを作ること。
行為者が編集できるログ。 監査される人々が変更できる監査証跡は、何も証明しないこと。

成熟度モデル

レベル1: 開始。 リスクはインシデントの後に反応的に扱われます。共有の枠組みも登録簿もありません。統制は文書化も検証もされず、監査は痛みを伴う手作業の大慌てです。集中とサプライヤーのリスクは検討されず、単一障害点は、失敗したときにだけ表面化します。

レベル2: 発展。 基本的な実践が現れますが、チームごとに異なります。主要なシステムにはいくつかのリスク登録簿が存在し、監査に通るよう統制の枠組みが採用されていますが、準備は手作業で時点のものです。主要なサプライヤーはオンボーディングの時に評価され、その後はされません。バックアップは存在しますがめったにテストされず、単一障害点の一部しか知られていません。

レベル3: 標準化。 スリーラインズのモデルと共通の枠組みが文書化され、組織全体で徹底されて、露出を比較して積み上げられる一つのリスクの語彙を与えます。多くの統制がパイプラインに自動化され、継続的な監視が主要な統制をカバーします。SBOMを含むサプライヤーと依存関係の目録が保守され、DRは予定に沿ってテストされ、集中リスクは個々のチームに任されるのではなく、ポートフォリオの水準で地図にされます。

レベル4: 管理。 保証は、単に文書化されるのではなく、ベースラインに対して測定され制御されます。統制のカバレッジ、ずれの検知時間、記載されたRTOとRPOに対するDR訓練の合格率、公表の後の「影響を受けるか」に答える平均時間、記載されたリスク選好に対する残余リスクがすべて指標として追跡され、リーダーシップに報告されます。ベースラインからの逸脱は行動を引き起こし、打ち切りの基準と是正の期限は証拠に基づいて徹底され、すべての重要な実行か中止かの決定は、主張ではなく数字に照らして行われます。

レベル5: オーケストレーション。 保証は継続的に改善され、組織全体に統合されています。監査人は生きた証拠をサンプリングし、リスク選好は、リスクの状況が移るにつれて適応する比例した統制を駆動し、サプライチェーンの完全性はパイプラインで検証されます。DR演習は日常的でシステム横断で、集中の決定は意識的で、所有され、緊急時の計画がテストされ、リスクと保証はポートフォリオと戦略の計画に織り込まれているので、組織は露出が変わるにつれて統制を再均衡させます。

議論のためのアイデア

チームが日々のトレードオフに実際に使える、意味のあるリスク選好をどう設定しますか。
パイプラインで自動化される統制と、人間の判断を要する統制の正しい境界はどこですか。
効率のために集中リスクを受け入れるのが正しい判断なのはいつで、その決定を時間とともにどう誠実に保ちますか。
小さな推移的な依存関係と、深いアクセスを持つ重要なベンダーとで、どれだけのサプライチェーンの保証が比例的ですか。
継続的な統制の監視は、独立した監査を完全に置き換えられますか。それとも独立性は、人間の部外者を要求しますか。
リスクと保証の機能が、チームが迂回するデリバリーのボトルネックになるのを、どう防ぎますか。

要点

リスクは受け入れられる水準まで管理され、生まれる所で所有され、主張ではなく証拠で証明されます。
ずれが早期に捉えられ、証拠が運用の副産物として生産されるよう、時点の監査より継続的で自動化された統制の監視を好みます。
サードパーティとサプライチェーンのリスク(推移的なオープンソースの依存関係を含む)はあなたのリスクです。目録にし、SBOMを要求し、出所を検証します。
事業継続とDRは、テストされて初めて能力です。テストされていないバックアップとフェイルオーバーは想定です。
集中リスクと単一障害点は、個々のチームには見えないポートフォリオ水準の関心事です。地図にして、統合を意識的で緊急時の計画がテストされた決定にします。
ビジネスケースは避けられた大惨事に支配されます。大きく予測できない時折の損失を、小さく安定して予測できるコストと交換します。

参考文献とさらなる読み物

ISO 31000, Risk Management: Guidelines
ISO/IEC 27001 and 27005, Information Security Management and Information Security Risk Management
NIST, Risk Management Framework (SP 800-37) and Security and Privacy Controls (SP 800-53)
NIST, Secure Software Development Framework (SP 800-218) and Cybersecurity Framework
Committee of Sponsoring Organisations of the Treadway Commission (COSO), Enterprise Risk Management: Integrating with Strategy and Performance
AICPA, SOC 2 Trust Services Criteria
The Open Group, FAIR (Factor Analysis of Information Risk)
Betsy Beyer et al., Site Reliability Engineering (Google)
Institute of Internal Auditors, The Three Lines Model