実際の、過去の、推定された、または推定された露出係数（EF）なしで単一損失期待値（SLE）を計算することはできません。定量分析をカバーするほとんどのINFOSECリスク管理トレーニング資料に欠けているのは、一般的なリスク定義[リスク= f（アセット、脅威、脆弱性）]をEFに変換する方法について多くのガイダンスを提供していないことですSLEおよびALE式。私は今オンラインで見ました、そしてそれをうまくカバーしている人は誰も見ませんでした。
リスクが存在するためには、悪用する脆弱性とその脆弱性に対する脅威が存在する必要があります。これらの脅威には、発生の確率もあります（観測された攻撃に基づく場合があります）。脅威の確率は、定量分析では年間発生率に変換されます。したがって、EFは主に脆弱性と脅威が発生したときの資産への影響に基づいています。
リスクごと（脅威ごと/脆弱性ペアごと）のEFの多くは、0 EFまたは1 EFとなり、リスク分析ワークロードの一部が削減されます。また、EFの見積もりを行う際に、脆弱性を削減または排除するために導入されている緩和策を検討するのにも役立ちます。
単純な0および1 EFのいくつかの単純な例：
資産：オンラインでアクセス可能な銀行口座の残高
脅威：ハッカーは釣りの電子メールを使用して銀行口座のログインを取得し、口座を空にします
- 脆弱性：HUMINT：アカウントホルダーがユーザーIDとパスワードを明かすようにだまされる
- 緩和策：なし
- 銀行口座残高に対する結果のEF：1.0
脅威：ハッカーは釣りの電子メールを使用して銀行口座のログインを取得し、口座を空にします
- 脆弱性：HUMINT：アカウントホルダーがユーザーIDとパスワードを明かすようにだまされる
- 緩和策：銀行では、外部の残高送金をオンラインで開始することを許可していません。銀行が口座番号やルーティング番号をオンラインで表示しない
- 銀行口座残高に対する結果のEF：0.0
脅威：ハッカーがソーシャルメディアサイトから盗んだユーザーID /パスワードの最近のリストを使用
- 脆弱性：HUMINT：多くのアカウント所有者がすべてのサイトで同じパスワードを使用し、AUTHEN：多くのサイト（この銀行を含む）が自分の電子メールアドレスをユーザーIDとして使用します
- 緩和策：銀行にはインプレースの2要素認証があります
- 銀行口座残高に対する結果のEF：0.0
他のほとんどのリスクについては、推定EFを決定するために、脆弱性、脅威、および脆弱性緩和策を評価する必要があります。リスクに応じてEFのベースとなる実際の観測データが多くない場合、これらの個々のSLEは大幅に範囲外になる可能性があります。集計された年間損失予測にまとめると、個々のEFの見積もりが不十分なため、非常に大きな誤差が生じる可能性があります。
ただし、銀行業界を例にとると、長年にわたって運用されている銀行の場合、詳細な損失データ（サイバー関連の損失を含む）があります。銀行は実際に、これらの値（EF、SLE、ARO、ALE）を、これまでの履歴に対して非常に正確に計算し、将来の損失の予測に使用できます。
また、詳細な損失履歴があれば、銀行は新しい緩和策（2要素認証など）の実装に関する費用対利益の分析を比較的正確に行うことができます。
- その軽減策を実装および展開するための総コストの見積もりを決定します。
- 一定期間（たとえば、10年）にわたる現在のEFを指定して集約ALEを計算します。
- 緩和策が影響するEFを微調整します。
- 同じ期間の新しい集約ALEを計算する
- 新しい集約ALEと現在の集約ALEの差を計算します（これは、新しいALEが理想的には現在のALEよりも小さいという点で利点が期待されます）。
- メリット（損失削減）が実装の総コストよりも大きい場合は、それを実行します。利益（損失削減）が実装する総コストよりも大幅に少ない場合、費用対利益の分析では、緩和策を実装しないことをお勧めします。