Day 87 良いコントロール／悪いコントロール Good Controls / Bad Controls
[シリーズ構造] 柱F｜判断はどこで起きるのか ― リスクが行動に変わる瞬間
多くの組織は「コントロールがある」と考えていますが、実際には意図だけがあり、現実で機能する仕組みがないことも少なくありません。本稿では、判断を実際の行動に変える良いコントロールと、プレッシャー下で崩れる悪いコントロールを対比し、コントロールとは後付けではなく、意思決定が現実に変わる地点であることを示します。
▶ シリーズ全体マップ： 人間のしなやかさ ― サイバー判断力のために
▶ 柱F｜リスクとガバナンス 関連記事：
- Day 81｜リスクを語れる共通言語をつくる
- Day 82｜ネガティブリスクとポジティブリスク ― 不確実性の両面を統治する
- Day 83｜サイバーリスクの構造化 ― 「気になる話」を比べられるシナリオに変える
- Day 84｜リスク・トレランスという境界線 ― 限界が重要な理由
- Day 85 | リスク許容度とは何か ―判断を本当に変える問い
- Day 86 | 判断はどこで起きるのか ― リスクが行動に変わる瞬間
- Day 87 | 良いコントロール／悪いコントロール
良いコントロール／悪いコントロール
― 何が支え、何が崩れるのか
多くの組織は、「コントロールはある」と思っています。
けれど実際には、あるのは意図だけということが少なくありません。
守りたい。
防ぎたい。
間違えたくない。
その気持ちは本物です。
でも、意図だけでは、組織は動きません。
コントロールとは、意図が行動になる場所です。
――あるいは、行動にならずに終わる場所でもあります。
そこで止まれば、何も起きない。
通過すれば、現実が動く。
今日は、その分かれ目を見ます。
良いコントロールに共通するもの
決定を、実行可能にする。それが、良いコントロールの出発点です。
良いコントロールには、共通点があります。難しさでも、厳しさでもありません。
判断が揺れないための、構造です。
良いコントロールは、次のように振る舞います。
- 誰が実行しても、同じ結果にたどり着く
- 忙しくても、立ち止まって迷わなくていい
- 「やらない」という選択肢が、最初から用意されていない
- うまくいかなければ、すぐに分かる
- 誰が決めるのかが、事前に決まっている
ここで重要なのは、人の注意力や善意に依存していないことです。
一方で、よく見かけるのが、こんな指示です。
- 「気をつけてください」
- 「注意してください」
- 「ケースバイケースで判断しましょう」
これらは、コントロールではありません。
整った言葉を使った、期待です。仕組みではなく、希望に賭けている状態。
Day 86 で確認した、運用上のルールがあります。コントロール後の残余リスクは、リスク許容度の内側に収まっていなければならない。
これは、評価の話ではありません。進めるか、止めるかの話です。
だから、コントロールはゲートとして機能しなければならない。
- 残余リスクが許容度の内側なら、
説明責任を持って進む - 残余リスクが許容度を超えるなら、
現状のままでは進めない
良いコントロールは、止めるべきところで、きちんと止めます。
悪いコントロールは、通してしまう。
そして後から、こう言います。
「想定外でした」
でも本当は、想定外ではありません。
止める力を持たない仕組みを、コントロールと呼んでいただけです。
コントロールの価値は、結果が良かったかどうかではない。
本来止まるべきところで、止まれたか。
そこに、良いコントロールと悪いコントロールの差が、はっきりと現れます。
悪いコントロールに特有の、二つの壊れ方
悪いコントロールは、だいたい同じ壊れ方をします。
1）注意力依存型コントロール
記憶力、規律、善意に依存するもの。スライドの上では、正しく見えます。
でも、火曜日には壊れます。
忙しいとき。
人が足りないとき。
判断が重なったとき。
「覚えているはず」「分かっているはず」という前提は、現実の現場では、最初に崩れます。
2）重すぎて回らないコントロール
紙の上では、完璧。でも、スピードが出ない。
結果、どうなるか。
抜け道が生まれます。
そして、実際のコントロールはこう置き換わる。
「結局、誰が何とかできるか」
それはもう、仕組みではありません。
例えば、
1）緊急時アクセス（ブレークグラス）
悪い例
「緊急時のみ管理者権限を使うこと。後で共有してください」
良い例
緊急アクセスは「想定」ではなく発行されるもの。期限付き。自動失効。完全ログ。
翌営業日のレビューが自動生成される。
記憶ではなく、仕組み。
お願いではなく、ゲート。
2）データ持ち出し／ファイル共有
悪い例
「機密データを外部に共有しないこと」
良い例
機密ラベル付きファイルは、個人クラウドにアップロード不可。
外部共有は、宛先制限と有効期限が必須。
例外には、データオーナーの署名が要る。
これが「境界」です。
助言ではありません。
通れるかどうかのゲートです。
3）ベンダー導入／サプライチェーン
悪い例
「新しいSaaSを入れる前に、セキュリティ確認をしてください」
良い例
調達プロセスがゲートになる。契約前に、最低要件を強制：ログ、MFA、データ所在、インシデント通知SLA。例外が必要なら、説得はしない。エスカレーションする。署名する人が決まっている。
判断は、購入の中に固定される。
急いでいる人の裁量には任せない。
4）脆弱性対応
悪い例
「重大な脆弱性は、速やかに対応すること」
良い例
深刻度と、実際の悪用状況で期限を決める。期限があり、責任者がいる。
間に合わないなら、期限付きのリスク受容を文書化。
これは「早くパッチを当てろ」ではない。
許容度を、ゲートにしている。
5）バックアップ
（みんな「ある」と思っているコントロール）
悪い例
「バックアップは取っています」
良い例
自動化、監視、定期的な復元テスト。失敗すれば、特定の責任者にアラート。
復元できなければ、それはバックアップではありません。ただの保存です。
コントロールは、存在で証明されない。
復旧で証明される。
6）監視／検知
悪い例
「環境は監視しています」
良い例
明確なシグナルがある。閾値、SLO、アラート経路。オンコール体制と、ランブック。
そして、エスカレーション権限は事前に定義されている。
監視とは、眺めることではありません。
動いたときに、何をするかが決まっていることです。
悪いコントロールは、通してしまい、後で言います。
「想定外でした」
良いコントロールは、通してはいけないところで、止めます。
それが、コントロールの仕事です。
なぜ、良いコントロールは「退屈」に感じるのか
― そして、それこそが要点である理由
良いコントロールは、英雄的な対応を必要としません。
即興で何とかする場面を、減らします。判断に迷う瞬間そのものを、少なくします。
正しいことが、いちばん簡単にできる。
間違ったことは、静かにはできない。
それが、良いコントロールです。
悪いコントロールは、その逆をします。判断を仕組みに預けず、人に背負わせる。
だから、後で「物語」が生まれる。
頑張った話。
徹夜した話。
ギリギリで救った話。
でも、それは強さではありません。
仕組みが機能していなかった証拠です。
クロージング
標準やガイドラインは、手順を定義することはできます。
でも、判断そのものを消すことはできません。
ただし、コントロールには、標準にはできない役割があります。
判断を、持続させること。
判断を、繰り返せる形にすること。
良いコントロールは、「判断が行われた」ことを証明するためのもの。
悪いコントロールは、「判断したつもりになる」ためのもの。
明日は、どこまでが「ちょうどよいコントロール」なのか。
足りなさでも、やり過ぎでもない、その間にあるバランスの技術を見ていきます。
――――
[Series Structure] Pillar F | Where Judgment Happens ー When Risk Turns into Action
Many organizations believe they have controls, but often what exists is only intent, not mechanisms that function under pressure. This article distinguishes good controls that turn judgment into real action from bad controls that collapse when reality intervenes, and explains why effective controls are not add-ons, but the point where decisions become operational.
▶ 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
Good Controls / Bad Controls
What Holds, What Collapses
Most organizations think they have controls.
What they often have is intent.
Controls are where intent becomes behavior.
Or doesn't.
Today is the split: good controls vs bad controls.
Not by philosophy.
By whether they hold under pressure.
Controls are not "extra." They are the decision stage, made real.
Day 86 was the moment where evaluation turns into action.
Controls enter there--inside treatment--because controls are how treatment becomes real.
A control is not a checklist.
It is not "security."
It is a mechanism that turns judgment into repeatable action.
Or said another way:
Controls move judgment from people to process.
That is why controls are not an afterthought.
They are what makes decisions executable.
One level deeper: what good controls have in common
Good controls share traits:
- Anyone can run them and get the same outcome
- Even when busy, people don't have to hesitate
- "Not doing it" is structurally not an option
- If it fails, you know quickly
- Decision authority is defined in advance
In contrast:
- "Be careful / be aware / pay attention"
- "Decide case-by-case"
These are not controls.
They are hope with formatting.
The gate test (the only one that matters)
Day 86 gave us the operational rule:
Residual risk (after controls) must be within tolerance.
That means controls must behave like gates.
- If residual risk stays within tolerance → proceed, with accountability
- If residual risk exceeds tolerance → you cannot proceed "as-is"
A good control stops what must be stopped.
A bad control lets it through--and calls the outcome "unexpected."
Bad controls have two signature failure modes
They fail in one of two ways.
1) "Attention-based" controls
They depend on memory, discipline, and goodwill.
They work on slide decks.
They fail on Tuesdays.
2) "Too-heavy-to-run" controls
They are correct on paper.
Impossible at speed.
So bypasses appear.
And the real control becomes "who can get it done anyway."
Six practical contrasts (so it becomes obvious)
1) Break-glass / emergency access
Bad:
"Use admin access only in emergencies. Tell the team after."
Good:
Emergency access is issued, not assumed.
Time-bound. Auto-expiring. Fully logged.
Next-business-day review is automatically created.
Request vs gate.
Memory vs mechanism.
2) Data exfiltration / file sharing
Bad:
"Do not share confidential data externally."
Good:
Sensitive-labeled files cannot be uploaded to personal cloud.
External sharing requires recipient restrictions and expiry.
Exceptions require the data owner's signature.
This is what "boundary" looks like.
Not advice.
A gate.
3) Vendor onboarding / supply chain
Bad:
"Do a security check before buying a new SaaS."
Good:
Procurement is the gate.
Minimum requirements are enforced before contract: logging, MFA, data residency, incident notification SLA.
If you want an exception, you don't argue. You escalate. A named authority signs.
Judgment is fixed in the buying process.
Not left to whoever is in a hurry.
4) Vulnerability remediation
Bad:
"Critical vulnerabilities must be patched quickly."
Good:
Severity + exploit reality drives deadlines.
A due date exists. Ownership is named.
If it won't be met, the exception requires a documented risk acceptance with an expiration date.
This isn't "patch faster."
This is "tolerance as a gate."
5) Backups (the control everyone thinks they have)
Bad:
"We take backups."
Good:
Backups are automated, monitored, and tested.
Restore tests run on a schedule. Failures alert a named owner.
If you can't restore, you don't have a backup control. You have storage.
A control is proven in recovery.
Not in existence.
6) Monitoring / detection
Bad:
"We monitor the environment."
Good:
Clear signals exist: thresholds, SLOs, and alert routes.
There is an on-call path. There is a runbook.
And escalation authority is defined before the incident, not during it.
Monitoring is not watching.
Monitoring is knowing what to do when it moves.
Why good controls feel "boring" (and why that's the point)
Good controls reduce the need for heroics.
They reduce the number of moments that require improvisation.
They make the right thing the easiest thing.
They make the wrong thing hard to do quietly.
Bad controls do the opposite:
they produce stories.
Closing
Standards can define steps.
They cannot remove judgment.
But controls can do something standards can't:
They can make judgment durable.
And repeatable.
Good controls are how you prove the decision happened.
Bad controls are how you pretend it did.
Tomorrow, we'll look at the right amount of control--how much is enough, when it becomes too much, and the art of balance in between.