Day 96 人間を守るコントロールとは What Does a "Human-Protecting" Control Look Like?
[シリーズ構造] 柱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 | リスク許容度を「意思決定ルール」にする
- Day 92 | サイバーリスクを、組織の中で「生かす」
- Day 94 | "5分"で届かなければ、届かない
- Day 95 | 本当にリスクを下げる、個人のパフォーマンス
- Day 96 | 人間を守るコントロールとは
人間を守るコントロールとは
~その統制は、人を強くするか。人を壊すか。~
私たちは、KRIを設計し、閾値を決め、赤になったら動く仕組みを整えてきました。
そして、許容度を「上限値」ではなく「意思決定ルール」に落としました。
それでも、最後に残る問いがあります。

統制は、誰を守っているのか。
守るべき対象は、システムだけではありません。
本当に守るべきなのは、意思決定し、運用し、緊急時に立ち上がる人間です。
多くの組織で、コントロールは「安全のため」と言いながら、結果としてこうなります。
- 手順が増える
- 承認が増える
- 書類が増える
- 例外処理が増える
- そして、現場の判断力が削られていく
これでは、事故が減る前に、人が疲弊します。
人が疲弊した組織は、必ずどこかで判断が鈍り、シグナルが見えなくなり、赤を隠すようになります。
人間を守るコントロールとは、統制で人を縛ることではありません。
プレッシャー下でも、人が正しく判断できるようにするための「環境設計」です。
コントロールは「安全装置」ではなく「判断の補助輪」です
まず、前提を置きます。
人間は間違える。
しかも、忙しいときほど、疲れているときほど、正しい判断は難しくなる。
だから、統制の役割は「人を責めること」ではなく、間違いが事故にならないようにすることです。
ここでコントロールがやるべき仕事は、3つです。
- 選択肢を減らす(迷いを減らす)
- 正しい行動をデフォルトにする(頑張らなくていい状態にする)
- 失敗しても戻れるようにする(回復可能性を組み込む)
この3つを満たすと、統制は"追加の作業"ではなく、疲労を減らす装置になります。
「人を壊すコントロール」の特徴(そして、なぜ危険か)
人を壊すコントロールには、典型パターンがあります。
1) 「守っているつもり」の手順増殖
チェックリストが増え続け、目的が曖昧になり、最後は儀式になる。
忙しいときに破られる統制は、統制ではありません。
それは「平時の安心」を買っているだけです。
2) 判断ではなく"免責"を生む
「承認があるから大丈夫」「ルール通りだから大丈夫」
こうして、当事者の判断が弱くなり、危険な兆候(KRIの変化)が見えなくなる。
3) 現場を"沈黙"に追い込む
赤を出すと怒られる。報告すると負ける。
この空気が生まれた瞬間、組織はKRIやダッシュボード以前に壊れます。
人間を守るコントロールの設計原則
人間を守るコントロールは、次の4つで設計できます。
原則A:コントロールは「行動」を指定する(解釈させない)
KRIで「赤」になったのに、会議で「どう読む?」が始まったら終わり。
同じように、コントロールでも「どう運用する?」が毎回議論になるなら、それは弱い。
- 何をするか
- 誰がやるか
- いつまでにやるか
- 何が揃っていれば完了か
ここまでを"書いてある"ではなく"運用される形"に落とす。(Day 90の「シグナルは動くためのもの」に直結します)
原則B:「関所」を置く(進む/止めるを二値化する)
人を守る統制は、曖昧にしません。
プレッシャー下でも判断がぶれないように、止める/進めるの関所を用意します。
これは、許容度を意思決定ルールにする、あの発想です。
「話し合うための言葉」ではなく、「止めるための線引き」。
原則C:例外(受容)を"墓場"にしない
例外は必ず出ます。
ゼロにするのではなく、腐らせない。
- 期限
- 監視(どのKRIで見張るか)
- 無効条件(何が起きたら取り消されるか)
- オーナー(誰が引き受けるか)
これがない例外は、人間を守りません。
「いつの間にか危険な状態に慣れる」ことを加速させます。
原則D:コントロールは"最前線の人"の疲労を減らす
人間を守る統制は、現場にこう言える必要があります。
- 「この統制で、判断が楽になる」
- 「この統制で、夜間呼び出しが減る」
- 「この統制で、事故のとき戻れる」
もし現場が「また増えた...」と感じるなら、設計が負けています。
統制は正しさの証明ではなく、継続可能性の設計です。
例:人間を守るコントロールは、こういう形になる
以下は、実装のイメージです(どれも「人間の判断を助ける」方向に寄せています)。
- 変更管理:
ロールバックが"書いてある"ではなく"試されている"を関所にする - インシデント対応:
赤になったら自動でチケット(タスク)が起票され、担当と期限が生まれる - 脆弱性例外:
例外は「期限・監視・無効条件」つき。条件が来たら自動失効 - ボード報告:
5分で「A/Bの判断」まで届くように、選択肢を2つに絞る
統制は「ちゃんとしている感」ではなく、判断→行動→回復の流れを摩擦なくするためにあります。
結び
人を守れない統制は、リスクを下げない
これまで見てきた通り、KRIも、許容度も、ボード報告も、個人評価も、すべて同じ一点に収束します。
リスクは、現場の判断が生きている組織でしか下がらない。
だから私たちが作るべきコントロールは、人を縛る枠ではなく、プレッシャー下で人を守る構造です。
人間を守る統制は、こういう顔をしています。
- 解釈させない(行動が決まっている)
- 関所がある(止める/進めるが二値で決まる)
- 例外が腐らない(期限・監視・無効条件・オーナー)
- 最前線の疲労を減らす(継続できる)
そして、それができたとき。
統制は"作業"ではなく、組織の判断力になります。
今日からできること
- 現場が一番しんどい「統制」を1つ選び、"人を守る4原則"で採点する(A〜Dで×が出る場所を特定)
- 「関所(進む/止める)」を1つだけ作り、必須条件を3つに絞る(忙しい週でも守れる形にする)
- 例外を1件だけ"期限・監視・無効条件・オーナー"つきで作り直す(墓場から在庫へ戻す)
―――
[Series Structure] Pillar F | Where Judgment Happens
This article explores what it means to design security controls that truly protect humans, not just systems. Rather than treating people as "the weakest link," it reframes controls as mechanisms that work with human behavior, cognition, and real-world decision-making to reduce risk in practice.
A human-protecting control is observable, actionable, and aligned with how people actually act under pressure -- not just a checklist on paper. Human-protecting controls go beyond training and rules: they shape choice architecture, support judgment under stress, and transform signals into daily decisions that keep risk within tolerance.
▶ 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
- Day 92 | Cyber Risk Living Inside Enterprise Risk Management
- Day 94 | If It Doesn't Land in 5 Minutes, It Doesn't Land at All
- Day 95 | Individual Performance That Actually Reduces Risk
- Day 96 | What Does a "Human-Protecting" Control Look Like?
What Does a "Human-Protecting" Control Look Like?
(Not controls that look strict. Controls that keep people effective under pressure.)
We've spent days talking about KRIs, risk tolerance, controls, and how "Red" has to force action--not discussion. A system can have perfect dashboards and still fail.
Because the last question is not "Is the system controlled?"
It's this:
Who does our control system protect--when time is short and stakes are high?
If our controls protect the spreadsheet but exhaust the people who operate the business, we don't reduce risk--we just push it downstream until humans become the failure point.
This post is Day 95: controls designed to protect humans.

What we mean by "human-protecting"
A human-protecting control is not a moral statement. It's an operating design.
It is a control that:
- reduces cognitive load when volatility is high,
- prevents silent drift and hidden work,
- makes "the safe action" the default action,
- and keeps recovery possible when things go wrong.
In other words:
A good control doesn't demand heroics. It makes heroics unnecessary.
The failure mode: controls that look strong but break people
Many organizations accidentally design controls that feel reassuring to governance but harm execution.
Common patterns:
1) Controls that multiply steps without reducing uncertainty
Checklists grow. Approvals grow. Forms grow. But the underlying uncertainty stays the same.
Busy weeks arrive, and the control gets bypassed--because it's not survivable.
A control that can't survive busy weeks is not a control. It's decoration.
2) Controls that shift accountability into "process compliance"
"We followed the process" becomes the substitute for judgment.
This is dangerous because it trains the organization to optimize for defensibility, not risk posture.
3) Controls that punish visibility
If producing a Red signal leads to blame, teams learn to delay reporting, downgrade severity, or reframe incidents.
The system doesn't become safer--it becomes quieter.
Human-protecting controls: 4 design rules
If we want controls that protect humans and reduce risk, we can design them with four rules.
Rule A -- Controls must specify behavior, not invite interpretation
If a control requires a meeting to interpret it, it will fail under pressure.
A workable control ships with:
- what action is required,
- who owns it,
- by when,
- and what "done" means (evidence / state change).
This is the same principle as deterministic R/A/G: we remove interpretation so action can start immediately. Source
Rule B -- Build gates: make decisions binary when pressure is high
Tolerance only matters when it changes decisions. Limits alone don't decide anything--gates do.
Human-protecting controls create stop/go structure:
- proceed only if conditions are true,
- otherwise stop or escalate,
- and the authority is explicit.
This prevents drift into "we'll keep an eye on it." Source
Rule C -- Exceptions must not become a graveyard
Exceptions are inevitable. The failure is letting them decay into invisible risk inventory.
A survivable exception has:
- an expiry date,
- a review date,
- a monitored signal (what tells us it's drifting),
- and void conditions (what cancels the exception immediately),
- plus a named owner who is actually accountable.
If any of these is missing, the exception is not "flexibility."
It's unmanaged accumulation.
Rule D -- A control is only "good" if it reduces frontline fatigue
Ask the most honest question:
Does this control make the on-call week easier or harder?
Human-protecting controls reduce fatigue by design:
- default-safe paths (secure-by-default configs),
- automation that creates owned work items (not just alerts),
- reversible deployments (tested rollback),
- clear escalation paths that trigger resource movement--not just notifications.
If the lived experience is "we added another step," we probably didn't add control--we added burden.
Examples: what human-protecting controls look like in practice
These are not "more controls." They are better-shaped controls.
- Change management: "Rollback exists" is not enough.
Human-protecting version: rollback is tested, and "no tested rollback = no deploy." (A gate.) - Incident response: "Alert sent" is not enough.
Human-protecting version: Red generates a ticket with owner, deadline, and required action. - Vulnerability exceptions: "Accepted risk" is not enough.
Human-protecting version: time-bound exception with monitoring and explicit void conditions.
These controls protect humans by removing ambiguity and reducing the number of fragile handoffs.
Closing: controls that don't protect people don't reduce risk
We can't build risk governance on the assumption that humans will always notice, remember, interpret, and act correctly--especially when they're tired.
Controls that protect humans have a consistent shape:
- no interpretation meetings (behavior is specified),
- clear gates (stop/go is binary under pressure),
- exceptions with hygiene (expiry + monitoring + void conditions + owner),
- reduced frontline fatigue (default-safe, automated, reversible).
That's how controls stop being paperwork and become organizational judgment.
References
- Centers for Disease Control and Prevention. (2011). Public health guide for improving safety culture in healthcare settings(contains background on the Swiss Cheese model and related safety concepts). PubMed Central. https://pmc.ncbi.nlm.nih.gov/articles/PMC8514562/
- Donella Meadows Project. (n.d.). Leverage points: Places to intervene in a system[PDF]. https://donellameadows.org/wp-content/userfiles/Leverage_Points.pdf
- Marx, D. (2013). Just culture: A foundation for balanced accountability and patient safety. Ochsner Journal, 13(3), 400-406. https://pmc.ncbi.nlm.nih.gov/articles/PMC3776518/
- National Institute of Standards and Technology. (2011). Information security continuous monitoring (ISCM) for federal information systems and organizations(NIST Special Publication 800-137). https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-137.pdf
- National Institute of Standards and Technology. (2012). Guide for conducting risk assessments(NIST Special Publication 800-30 Revision 1). https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-30r1.pdf
- National Institute of Standards and Technology. (2012). Computer security incident handling guide(NIST Special Publication 800-61 Revision 2). https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf
- National Institute of Standards and Technology. (2020). Integrating cybersecurity and enterprise risk management (ERM)(NIST Interagency Report 8286) [PDF]. https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8286.pdf
- National Institute of Standards and Technology. (2020). Integrating cybersecurity and enterprise risk management (ERM)(NIST Interagency Report 8286). https://csrc.nist.gov/pubs/ir/8286/final
- National Institute of Standards and Technology. (2020). Security and privacy controls for information systems and organizations(NIST Special Publication 800-53 Revision 5). https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf
- National Institute of Standards and Technology. (2021). NIST RMF QSG: Authorize step FAQs[PDF]. https://csrc.nist.gov/csrc/media/projects/risk-management/documents/06-authorize step/nist rmf authorize step-faqs.pdf
- National Institute of Standards and Technology. (2024). Implementation examples for the NIST Cybersecurity Framework 2.0[PDF]. https://www.nist.gov/document/csf-20-implementations-pdf
- National Institute of Standards and Technology. (2024). The NIST Cybersecurity Framework (CSF) 2.0(NIST CSWP 29) [PDF]. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf