私なら、部門間で繰り返し止まる意思決定を起点に、サイバーセキュリティの運営モデルを設計する。セキュリティ部門が問題を発見しても、予算、技術者、変更の時間枠を握る人は別々だ。CEOとして、それぞれの権限を結び付け、選択の余地があるうちに判断し、実行できる条件を整えたい。
議題として受け付ける条件
私が議長となり、CISO、技術、財務、運用、関係事業の責任者と月次レビューを行う。対象は、同じ人員を取り合う案件、果たされない部門間の依存関係、安全対策と事業上の約束の衝突など、経営の裁定が必要な問題だ。担当者の権限と資源で解決できる仕事は、その担当者に実行を委ねる。
提案には、何を決めてほしいか、決定期限、根拠、実行可能な選択肢と必要な能力を添えてもらう。既存の委任で解決できない理由も必要だ。優先順位を上げる案なら、代わりに遅れる仕事とその影響を示す。移される負担が見えなければ、部門ごとの要望を並べても比較にはならない。
待つ案も、その間の保護と待てなくなる条件を含めて検討する。資料が不足する場合は、誰が何を確認すれば選択が変わり得るかを定める。ただし、確認を待つことで安全に決められる時点を過ぎるなら、現時点の根拠で判断する場を早める。資料の形式を理由に判断を先送りしてはならない。
資源を約束できる人が決める
出席者には、今回の選択に必要な資源を確約する権限を求める。予算承認だけでは技術者の予定は確保できず、人員の確保だけでは運用の変更枠は開かない。誰がどの資源を動かせるかを別々に確認する。代理人にも、その決定に必要な委任がなければならない。
持ち帰り承認が必要なら、未承認の部分、承認者、回答期限を残す。条件付きの意向を実行指示として扱うと、現場は確保されていない人員を前提に動いてしまう。後回しになる仕事の責任者にも変更を伝え、会議後に両方の優先順位が元のまま残る事態を防ぎたい。
最終決定者を明示し、顧客への被害、遅延の代価、運用上の実現可能性、残るリスクで選ぶ。全員一致を行動の条件にはしない。ただし、異論がどの根拠や前提に向けられているかは記録する。そうすれば、実行中にその前提が崩れた際、反対意見を単なる感情として見落とさずに済む。
月次会議が儀式になるとき
月次という周期は点検の機会であり、判断を待たせる理由ではない。次回会議より早く決定期限が来る案件は、経営の判断を前倒しする。緊急のインシデントは即時対応の経路を使う。待つ間に選択肢が消えれば、会議はすでに時間が決めた結果を追認するだけになる。
部門別の進捗報告で議題が埋まることも問題だ。「対応中」という説明では、共有資源の衝突は解けない。私は必要な決定を中心に議題を組み、同じ争点が戻った場合には、委任の不足、依存先の未対応、前回決めた優先順位が守られていないことを区別する。それぞれで必要な介入は異なる。
「原則賛成」で終えることにも注意したい。資金、日程、暫定措置の担当が未確定なら、実行条件は整っていない。その不足を未完了の約束として残し、次の確認では埋まったかを問う。会議を開いた事実や同意の表明を、仕事が進んだ証拠として扱わない。
判断を実行へつなぐ記録
決定記録には、問題、根拠、比較した案、選んだ理由、残る異論、決定者とその権限を残す。実行責任者、資源の約束、依存先、完了条件も必要だ。会議にいなかった人が読んでも、何を始めてよいか、何が未承認か、変化があれば誰に戻すかが分かる形にする。
確認済みの事実と仮定は分けておく。とりわけ、権限の範囲、業務継続の可能性、人員の空きは、実行前に変わり得る。後で判断を改める際は、元の理由を消さず、どの新しい根拠が変更につながったかを追記する。最新の結論だけでは、同じ衝突が再発した理由を検討できない。
延期する仕事については、暫定的な保護の担当者、検証方法、成り立たなくなる条件も記す。決定期限は判断を促し、実施予定は作業の時期を定め、再検討条件は前提の変化を捉える。それぞれを明示すれば、次の会議を待たずに判断を開き直す根拠になる。
取締役会へ上げる境界
NIST CSF 2.0は、戦略、役割、方針、監督をGovern機能に位置づけている。私はその成果に照らして体制を点検する。月次会議は私が提案する実装である。取締役会は戦略的なリスクの境界を承認し、経営陣は対策の選択と実行を担う。
上申の条件は、承認済みの境界を超えるか、取締役会の専決事項に当たることだ。部門間の不一致や費用増だけで、経営の判断を取締役会へ移さない。一方、全員が賛成しても境界を超える権限は生まれない。該当する案を進める前に、必要な取締役会の決定を求める。
境界の適用が曖昧なら、該当する条項と案件を示し、権限を持つ人に確認する。日程の圧力を理由に、曖昧さを許可と読み替えない。
その際は、触れる境界、境界内の代案、求める判断、待つ間の保護を示す。暫定的な保護の責任は経営陣に残る。取締役会には重大な逸脱、未解決の異論、実行の証拠を伝える。CISOには私の説明に異議を唱えられる直接の経路を確保し、監督が私の報告だけで完結しないようにする。
仮定の例で保護を試す
給与計算と顧客請求が、特権アクセスを分離するために同じ技術者を必要とすると仮定する。これは方法を示す例である。私は双方の責任者と、次の支払い義務、露出している権限、実施可能な暫定制限を比べる。強く要求した部門を優先するだけでは、待つ側のリスクが判断から抜け落ちる。
最初の変更枠を給与計算に割り当て、請求側は自分たちの枠までアクセスを制限する案もある。財務は追加の業務負荷を受け入れ、技術と運用は人員と日程を確約する必要がある。制限に伴う手作業を誰も担えないなら、その案はまだ実行可能とはいえない。
制限を採用する前に、禁止したい特権操作が止まり、必要な請求業務は続けられるかを検証する。実際のアクセス経路を対象に、旧権限や別の入口で迂回できないか、記録で結果を確認できるかも調べる。設定画面が変わっただけでは、業務で保護が成立した証拠にならない。
検証後も異常なアクセスと追加作業の滞留を誰が確認するか決める。制限の解除は本対策の完了確認に結び付け、予定日の到来だけでは解除しない。
必要な業務まで止まるなら、制限の方法や作業順序を見直す。迂回できる制限を、待つ理由には使わない。代案も承認済みの境界を超えるなら、進める前に取締役会へ判断を求める。暫定策が技術的に動くことと、残るリスクを受け入れる権限があることは別の確認である。
再検討を始める具体的な条件
私は、合意した日程確定の時点で請求側の技術者を確保できなければ、担当者が直ちに資源配分の再検討を始めると定める。暫定制限の検証失敗も、元の案の保護前提を崩す。変化を示す根拠を持ち寄り、待機の継続、順序の変更、代替の保護を比較し直す。
次回レビューでは、資金が付き、仕事が予定に入り、保護が機能し続けたかを確認する。このモデルは、期限に選択を奪われる前に権限ある判断ができたか、取締役会が記録から行動までたどれるかで評価したい。取捨選択と資源の約束が実行に結び付いてこそ、会議に意味がある。