Day 91 リスク許容度を「意思決定ルール」にする Risk Tolerance as Decision Rules
[シリーズ構造] 柱F｜判断はどこで起きるのか
リスク許容度は、判断を変えてこそ意味を持ちます。本稿では、許容度を単なる上限値ではなく、誰が・いつ・何を決められるのかという意思決定ルールとして再定義します。
許容度が運用に落ちると、会議は短くなり、エスカレーションは予測可能になり、「様子見」は選択肢ではなくなります。
▶ シリーズ全体マップ： 人間のしなやかさ ― サイバー判断力のために
▶ 柱F｜リスクとガバナンス 関連記事：
- Day 81｜リスクを語れる共通言語をつくる
- Day 82｜ネガティブリスクとポジティブリスク ― 不確実性の両面を統治する
- Day 83｜サイバーリスクの構造化 ― 「気になる話」を比べられるシナリオに変える
- Day 84｜リスク・トレランスという境界線 ― 限界が重要な理由
- Day 85 | リスク許容度とは何か ―判断を本当に変える問い
- Day 86 | 判断はどこで起きるのか ― リスクが行動に変わる瞬間
- Day 87 | 良いコントロール／悪いコントロール
- Day 88 | コントロールが多すぎる組織は、なぜ疲弊するのか
- Day 89 | 「多さ」ではなく「効く」統制
- Day 90 | 境界シグナル（KRI）を、判断から行動へ
- Day 91 | リスク許容度を「意思決定ルール」にする
リスク許容度を「意思決定ルール」にする
リスク許容度は、意思決定が変わる瞬間にだけ、意味を持ちます。
理論でもない。ポリシーの美しい文言でもない。
会議の場で。時間が足りないときに。プレッシャーがかかった状態で。
多くの組織は、リスク許容度を「声明」として定義します。
けれど本当に必要なのは、それを意思決定のルールに落とすことです。
誰が判断できるのか。
どこで止まるのか。
影響の大きさに応じて、進むのか、止めるのか。
権限、ゲート、そして影響度に紐づいたstop / go のロジック。
これは、「リスク基準を置き、分析結果をその基準と照らして、追加の対応が必要かを判断する」という標準的な考え方を、私自身の経験を通して、現場で実際に使えるはしごに翻訳したものです。
ISO 31000 でいうリスク評価とは、リスク分析の結果を、確立されたリスク基準と比較し、追加対応が必要かどうかを決める行為。
リスク許容度とは、その判断を、人に任せきりにしないための、組織としての「線引き」です。
「許容可能なリスク」から「許される意思決定」へ
許容度を、単なる上限値として扱う。それが、いちばん典型的な失敗です。
上限は、行動を決めません。
問うべきなのは、これです。
このリスクがこの段にあるとき、何が許され、何が許されないのか。
同じスコアでも、意味はまったく変わります。
中核業務に直結するリスクを、可逆な支援業務と同じ作法で裁くことはできない。だから、「許容度」という言葉の解釈で揉めるのをやめる。
はしごを置く。
許容度のはしご（権限 × デフォルト姿勢）
一段目 -- 中核業務／基幹資産
許容度：極小
姿勢：防ぐ／作り直す／エスカレーション
デフォルト：リスクが下がるか、経営が明示的に判断を引き受けない限り、進めない
二段目 -- 重要だが、止まっても立て直せる業務
許容度：限定的
姿勢：条件付きで進める
デフォルト：着手時点から、代替統制と監視が動いている場合に限り、進める
三段目 -- 中核ではない業務・支援的な機能
許容度：中程度
姿勢：期限付きで受ける
デフォルト：受ける判断を記録し、レビュー周期を定義したうえで、進める
四段目 -- 低影響／やり直しが効く
許容度：高め
姿勢：委ねる
デフォルト：軽量な統制とサンプリングで、進める
判断の関所（許容度を二値化する）
関所のない許容度は、最後には「見ておきます」に崩れます。
関所は、プレッシャーがかかった場面でも、判断を二つに分ける。
進めるか。
止めるか。
つまり、交渉を減らします。
各段で、最低限これを決めます。
- 誰が判断するのか（権限）
- 何が揃っていればよいのか（根拠）
- どの統制が、すでに動いている必要があるのか
- 着手時点から、どの監視が回っている必要があるのか
- 引き返し方（元に戻す手順）
これは、作法の話ではありません。判断を逃がさないための、構造です。
NIST の RMF でも、残ったリスクを「それでも進む」と判断する責任は、最終的にその結果を引き受ける人にしか持てない、という前提が置かれています。
許容度とは、話し合うための言葉ではない。止めるために、置くものです。
例A｜クラウド変更管理（本番基盤・プラットフォーム）
第一段 -- 顧客影響が直撃する領域（影響範囲が大きい）
強い関所を置く。
リリース前に、必ず揃っていること：
- 残ったリスクを引き受ける責任者が明確になっている
- 戻し方が「書いてある」だけでなく、実際に試されている
- 監視が開始時点から有効（サービス目標が定義され、異常時の呼び出し先が決まっている）
- 独立した目での確認が終わっている（変更管理会議、または指定された承認者）
どれか一つでも欠けていたら：進めない
第二段 -- 重要だが、止まっても立て直せる業務
条件付きで進める
必須：
- 業務の責任者が受け入れ、セキュリティ／基盤側も合意している
- 代替策がすでに動いている（段階的な反映、影響を絞る仕組み）
- 監視と手順の責任者が明確
- 影響が広がらないよう、範囲が定義・制限されている
第三段 -- 中核ではない業務・社内向け支援
期限付きで受ける
必須：
- 例外として記録され、再確認日が決まっている
- 元に戻すのが容易
- 軽い監視が入っている（抜き取り確認、エラー傾向の把握）
第四段 -- 影響が小さく、やり直しが効く
委ねる
必須：
- 同僚による確認と自動テスト
- 事後の抜き取り確認・監査
例B｜脆弱性の例外（修正・更新を先送りする判断）
第一段 -- 外部に直接さらされる経路（認証、決済、個人情報につながる部分）
「いつもの例外」は不可
必須：
- 経営レベルで、残ったリスクを明示的に引き受けている
- 代替策が実際に効いていることが確認できている
（防御、分離、悪用対策、検知） - 短い期限と、再確認の計画がある
代替策が効いている確証が持てないなら：例外は認めない
第二段 -- 重要だが、露出は限定的
必須：
- 業務責任者とセキュリティの合意
- 統制と監視がすでに動いている
- 期限が追跡され、解消まで管理される
第三段 -- 期限付きの例外
必須：
- 責任者が受け、是正の予定がある
- 定期的な見直し
第四段 -- 衛生管理を前提に先送り
必須：
- 記録し、後で抜き取り確認
- 「軽微」を見えなくしない
例C｜外部サービス・取引先の受け入れ（クラウドサービス／ベンダー）
第一段 -- 規制対象データ、本番への接続、または中核への依存
契約・接続の関所（進む／止める）
契約・接続前に必須：
- セキュリティ確認が完了している
（約束ではなく、裏付けがある） - データの流れが整理され、権限が最小限に設計されている
- 事故時の通知と確認権限が契約に入っている
- 切り離し・移行の道筋が定義されている
不足が残る場合は、経営が判断を引き受ける
どれか欠けたら：受け入れない
第二段 -- 重要な取引先（データは限定）
必須：
- 確認完了と改善計画
- 継続監視と更新時の確認点
第三段 -- 支援的な取引先（低感度）
必須：
- 簡易確認と最低限の統制
- 年次、または条件付きの再確認
第四段 -- 影響の小さいツール
必須：
- 標準的な購買確認
- 軽い抜き取り監査
ここでの要点
重要なのは、起きやすさと影響の大きさをはっきりさせ、統制の強さを「想定」ではなく、実際に効いているかで判断すること。
これは、リスク評価の基本作法です。
会議で崩れないスコアリング
良い意思決定が壊れるのは、前提が暗黙のままだからです。
だから、短い強制質問で前提を表に出します。
- 最悪の、現実的なインパクトは何か
- それを誰が吸収するのか（顧客／運用／人）
- 「間違っていた」と早く分かるシグナルは何か
- どれくらいの時間で引き返せるのか
- そのシグナルが無視されたとき、誰が責任を持つのか
これは、議論を遅くするためではありません。
誤った安心を削るためです。
そして、スコアは「正確さ」のためにあるのではない。
同じ会議で、性質の違うリスクを並べて議論するためにあります。
最小限の軸は、これで足ります。
- 起こりやすさ
- 何が、どれだけ壊れるのか
- プレッシャー下でも本当に効く、という確信
最初から、足し合わせない。
次元ごとに、分けて話す。
そのほうが、会議で折れにくい。
結び
許容度が意思決定のルールになると、
- 会議は、短くなる
- エスカレーションは、予測できるようになる
- 受け入れる判断は、「作業」ではなく責任になる
- そして、「監視します」は、答えにならなくなる
許容度は、チャートに引く一本の線ではありません。
共有された、組織の動き方そのものです。
明日は、積み上げの話をします。
個々の判断が、どう重なり、企業全体のリスクの姿になるのか。
そこを扱います。
今日からできること（最初の1週間でやること：3つだけ）
- 「許容度のはしご」を4段で仮決めする（まずは1つの領域だけ）例：本番基盤／顧客影響が直撃する領域から始めて、「段1〜4」を暫定で置く（名前とデフォルト姿勢だけで良い）。
- 最初の段に"関所（進む／止める）"を1つだけ作り、必須条件を3つに絞る「誰が判断するか」「何が揃っていればよいか」「引き返し方（戻し方）」の3点だけを固定して、"見ておきます"に崩れない二値判断にする。 例外（受容）を1件だけ"期限・監視・無効条件"つきで作り直
- 許容度を声明ではなく運用にする最短距離は、受容を「作業」ではなく「責任ある判断」に戻すこと。まずは1件、期限と再確認、監視シグナル、無効条件まで書く。
―――
[Series Structure] Pillar F | Where Judgment Happens
Risk tolerance only matters if it changes decisions. This article reframes risk tolerance from a static limit into clear decision rules--defining who can decide, when to stop or proceed, and what must be true at each level of impact. When tolerance becomes operational, decisions accelerate, escalation becomes predictable, and "we'll monitor it" stops being an answer.
▶ Series overview: Series Overview -- Human Flexibility for Cyber Judgment
▶ Other posts in Pillar F (Risk & Governance):
- Day 81 | Building a Shared Language for Risk
- Day 82 | Negative vs. Positive Cyber Risk -- Governing Both Sides of Uncertainty
- Day 83 | Structuring Cyber Risk -- Turning Concerns into Comparable Scenarios
- Day 84 | Risk Tolerance as a Boundary -- Why Limits Matter
- Day 85 | Defining Risk Tolerance -- The Questions That Actually Change Decisions
- Day 86 | Where Judgment Happens ー When Risk Turns into Action
- Day 87 | Good Controls / Bad Controls
- Day 88 | Why Over-Controlled Organizations Burn Out
- Day 89 | "Effective" Controls, Not "More"
- Day 90 | KPIs/KRIs That Drive Action
- Day 91 | Risk Tolerance as Decision Rules
Risk Tolerance as Decision Rules
What Actually Changes at Each Level
Risk tolerance only matters if it changes decisions.
Not in theory. Not in policy language.
In real meetings, under time pressure.
Most organizations define tolerance as a statement.
What they need is tolerance as decision rules: authority, gates, and stop/go logic tied to impact.
That is the operational version of setting risk criteria--and then actually evaluating risk against them. More precisely: I'm translating the standards' "criteria + evaluation" logic into a ladder you can actually run in the real world based on my experience. Risk evaluation, in ISO 31000 terms, is comparing risk analysis results against established criteria to decide where additional action is required.
From "Acceptable Risk" to Allowed Decisions
Treating tolerance as a limit is the common failure mode. Limits don't guide action.
The real question is:
When a risk sits at this tier, what decisions are allowed--and which are not?
The same numeric score can mean very different things. A risk touching a mission-critical service cannot be governed like a reversible support process.
So we stop arguing about the word tolerance and build a ladder.
The Tolerance Ladder (Authority + Default Posture)
Tier 1 -- Mission-Critical Services / Core Assets
Tolerance: Very low
Posture: Prevent, redesign, or escalate
Default rule: Do not proceed unless risk is reduced or formally owned at executive level
Tier 2 -- Important but Recoverable Services
Tolerance: Limited
Posture: Conditional proceed
Default rule: Proceed only if compensating controls and monitoring are live on Day 1
Tier 3 -- Noncritical / Support Functions
Tolerance: Moderate
Posture: Time-bound acceptance
Default rule: Proceed with documented acceptance and a defined review cadence
Tier 4 -- Low-Impact / Reversible Activities
Tolerance: Higher
Posture: Delegate
Default rule: Proceed with lightweight controls and sampling
The point isn't the labels. Each rung permits different decisions.
Decision Gates (Make Tolerance Binary)
Tolerance without gates becomes, "We'll watch it."
Decision gates make tolerance binary under pressure.
For each tier, define gates for:
- Approval authority
- Evidence required
- Controls that must already be operating
- Monitoring active on Day 1
- Reversal plan (how we back out)
This reflects a simple truth: risk acceptance is a real decision with accountable ownership--not a vibe. In NIST RMF terms, the authorization decision (explicit acceptance of risk) is the responsibility of the authorizing official and cannot be delegated.
Example A -- Cloud Change Management (Production infrastructure / platform)
Tier 1 -- Critical customer-facing service (high blast radius)
Hard gate. Must be true before deploy:
- Executive owner named for residual risk
- Rollback plan tested (not just written)
- Observability live: SLOs + paging ownership active Day 1
- Independent review completed
If any gate fails: no deploy
Tier 2 -- Important but recoverable service
Conditional proceed. Must be true:
- Risk accepted by service owner with security/platform sign-off
- Compensating controls live (feature flags, canary, progressive rollout)
- Monitoring and runbook owner assigned
- Deployment constrained to defined blast radius
Tier 3 -- Internal tool / support workflow
Time-boxed acceptance. Must be true:
- Ticketed acceptance with revisit date
- Straightforward backout
- Lightweight monitoring (sampling, error budget watch)
Tier 4 -- Low-impact, reversible change
Delegate. Must be true:
- Peer review and automated tests
- Post-change sampling or later audit
Example B -- Vulnerability Exception (Deferred patch or remediation)
Tier 1 -- Internet-exposed auth, payment, or PII path
No "business as usual" exceptions. Must be true:
- Named executive signs residual risk
- Compensating controls verified (WAF, segmentation, exploit prevention, detection)
- Short expiry date and retest plan
If compensating controls aren't provably working: no exception
Tier 2 -- Important, limited exposure
Must be true:
- Owner and security approve
- Controls and telemetry in place
- Expiry date tracked to closure
Tier 3 -- Time-bound exception
Must be true:
- Owner accepts with scheduled remediation
- Periodic review cadence
Tier 4 -- Defer with hygiene
Must be true:
- Logged and sampled later
- "Low" must not become invisible
This is how we keep likelihood and impact explicit while making control strength real (not assumed)--a core risk assessment discipline in NIST's guidance.
Example C -- Third-Party Onboarding (SaaS / vendor risk)
Tier 1 -- Regulated data, production access, or core dependency
Stop/go onboarding gate. Must be true before contract or integration:
- Security due diligence complete (evidence, not promises)
- Data flows mapped; least-privilege access designed
- Incident notification and audit rights in contract
- Exit plan defined
- Executive owner signs residual risk if gaps remain
If any gate fails: no onboarding
Tier 2 -- Important vendor, limited data
Must be true:
- Security review complete with remediation plan
- Monitoring and renewal checkpoint defined
Tier 3 -- Support vendor, low sensitivity
Must be true:
- Basic questionnaire and minimal controls
- Annual or trigger-based review
Tier 4 -- Low-impact tooling
Must be true:
- Standard procurement checks
- Lightweight sampling audit
Scoring That Survives Meetings
Good decisions fail when assumptions stay implicit. Use a short forcing function:
- Worst credible impact if we're wrong?
- Who absorbs it--customers, operations, people?
- What signal tells us early we're wrong?
- How fast can we reverse?
- Who is accountable if the signal is ignored?
This doesn't slow decisions. It prevents false confidence.
Scoring isn't there to be accurate. It's there to make different risks discussable in the same meeting.
A minimal rubric that holds:
- Likelihood (plausibility)
- Impact (objective harmed, severity)
- Control strength (confidence under pressure)
Score separately. Don't collapse early. Disagreement is easier one dimension at a time.
Closing
When tolerance becomes decision rules:
Meetings get shorter
Escalations become predictable
Acceptance becomes accountable
And "we'll monitor it" stops being an answer
Risk tolerance stops being a line on a chart. It becomes shared operating logic.
Tomorrow, we'll look at Aggregation and Roll-Up--how individual decisions combine into enterprise-level exposure.
References 出典・参照文献
- ISO 31000:2018 (official standard page) -- Risk management -- Guidelines
https://www.iso.org/standard/65694.html - ISO 31000:2018 (PDF copy) -- includes the risk evaluation phrasing ("compare risk analysis results with established risk criteria...")
https://governance.ie/uploads/files/Internal Control/ISO310002018.pdf - NIST SP 800-30 Rev. 1 -- Guide for Conducting Risk Assessments (landing page)
https://csrc.nist.gov/pubs/sp/800/30/r1/final - NIST SP 800-30 Rev. 1 (PDF)
https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-30r1.pdf - NIST SP 800-37 Rev. 2 (PDF) -- Risk Management Framework for Information Systems and Organizations
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf - NIST RMF Quick Start Guide -- Authorize Step FAQs (PDF) -- "authorization decision... cannot be delegated"
https://csrc.nist.gov/csrc/media/projects/risk-management/documents/06-authorize step/nist rmf authorize step-faqs.pdf - NIST SP 800-39 (PDF) -- Managing Information Security Risk (Frame / Assess / Respond / Monitor)
https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-39.pdf - NIST SP 800-137 (PDF) -- Information Security Continuous Monitoring (ISCM)
https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-137.pdf - NIST SP 800-53 Rev. 5 (CSRC landing page) -- Security and Privacy Controls
https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final - NIST SP 800-53 Rev. 5 (PDF)
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf - ISACA Journal (2018, Vol. 4) -- Integrating KRIs and KPIs for Effective Technology Risk Management
https://www.isaca.org/resources/isaca-journal/issues/2018/volume-4/integrating-kris-and-kpis-for-effective-technology-risk-management - COSO -- Risk Appetite: Critical to Success
https://www.coso.org/critical-to-success