内部統制を「リスク(脆弱性)に打つ実装戦略」として理解し直す【CySec復習ログ#3】

Last updated at 2026-07-26Posted at 2026-06-21

はじめに

ISMS を学んでいると、ある段階で「内部統制」という言葉に出会います。少し前の私は、ここでつまずきました。

ISMS のリスクマネジメントまではなんとか追えたのに、急に登場する「内部統制」「IT統制」「COSO」「整備状況評価」といった言葉が、実装側の景色とうまくつながらなかったのです。しかも「統制(Control)」という語感のせいで、私は内部統制を「ルールでガチガチに縛ること」「アクセスを制限すること」だと思い込んでいました。

ところが学び直してみると、内部統制の本質はそこではありませんでした。本質は、リスク(正確にはその一部である「脆弱性」)に対して、どの対策を、どこに、どれだけ打つかという実装戦略です。チェックリストを上から潰す作業ではないのです。

この記事は、CySec(東京電機大学が提供する社会人向けのサイバーセキュリティ教育プログラム「国際化サイバーセキュリティ学特別コース」)で学んだ内容を、自分の言葉で整理した復習ログです。本シリーズの通し番号では #3 にあたります。想定読者は、少し前の私と同じく「ISMS のリスク管理までは学んだが、『内部統制』という実装側の言葉でつまずいている学習者」です。

この記事の軸になる主張を、先に1行で書いておきます。

内部統制とは「リスクのある場所」を狙って打つ対策であり、打てるのは脅威ではなく脆弱性の側だけである。

読み終えたとき、「内部統制=制限・チェックリスト」という先入観がほどけて、「自社の対策を分類してみよう」「自分の現場でリスクシナリオを描いてみよう」と手を動かしたくなれば成功です。なお私自身まだ学習中なので、間違いがあれば指摘していただけると助かります。

前回(第1回・前後編=#1/#2)までで、ISMS の歴史とリスクマネジメント(ISO 31000)を扱い、物語のゴールである「ガバナンス(経営者の責任)」まで進めました。今回(#3)は、その経営の話を現場の実装へ降ろしていきます。

内部統制とは ── Control は「制御」ではなく「組織内の圧力」

まず言葉の出どころからほどきます。内部統制は Internal Control の訳語です。ここで私が最初に誤解したのが、Control を「制御」と読んでしまったことでした。

ここでの Control は、機械を制御するような意味ではありません。組織内部にはたらく「圧力(規律)」 のことです。対になる概念として External Control(外部統制)があり、これは法律や監査といった、組織の外からはたらく圧力を指します。

種類	圧力のかかる方向	例
Internal Control(内部統制)	組織の内側から	体制・ルール・手続き・チェック・暗号化
External Control(外部統制)	組織の外側から	法律・監査・規制当局

さらに腑に落ちたのは、内部統制が ISMS でいう 「管理策(Control)」と同じもの だという点です。ISO/IEC 27001 を日本語化したとき、訳を受託した側が Internal Control を「内部統制」と訳しました。ただ「統制」という語が強すぎたため、現在は「管理策」という穏やかな言葉が主に使われています。言い換えると、こうです。

セキュリティ管理策 = セキュリティ内部統制 = セキュリティ Internal Control

ISMS で学んだ「管理策」と、内部統制の文脈で出てくる「統制」は、もとは同じ Control です。別物に見えていたのは、単に訳語の都合でした。

内部統制は「当たり前の機能」の集合

では具体的に何が内部統制なのか。身構える必要はなく、組織にもともと存在している「当たり前の機能」がすべて内部統制です。

組織体制そのもの
ルール・手続き
標準化・明文化(ドキュメントを整備して共有すること)
チェック(複数人で確認すること)
確認・レビュー(上司の承認)
技術的な対策(暗号化など)

種類はバラバラですが、いずれも「目的の達成を脅かす何か」に備える仕組みである点で共通しています。物理的な IDカードも、業務の指標(KPI / KGI)も、開発と運用を分ける「職務の分離」も、すべて内部統制です。

経営の話とつながる ── 会社法・SEC・NISC

ここで #2 のゴールだった「ガバナンス」と直接つながります。内部統制は、もはや現場だけの話ではなく、経営者の責任として法律に書き込まれています。

会社法(日本): 「業務の適正を確保するための体制(=内部統制システム)の整備」を決定することは、取締役会の専決事項です(会社法362条4項6号)。さらに大会社(資本金5億円以上または負債200億円以上)では、この決定が義務づけられています(同条5項、具体的な体制は会社法施行規則100条)。サイバーセキュリティ対策も、この「内部統制システム構築の基本方針」に含まれると考えられます。つまり、取締役会でセキュリティ対策を決議せよ、ということです。
SEC(米国): 米国 SEC は2023年7月26日、上場企業に対し、重大なサイバーセキュリティインシデントの開示を義務づける規則を採択しました。Form 8-K の Item 1.05 を使い、「インシデントが重要(material)だと判断した日」から原則4営業日以内に開示します。起点が「発生日」でも「公表日」でもなく「重要性を判断した日」である点が、実務上のポイントです。
NISC(日本): NISC は「企業経営のためのサイバーセキュリティの考え方」(2016年8月2日)で、サイバーセキュリティを「費用」ではなく経営への「投資」と位置づけるべきだとしています。

なお、講義では「KADOKAWA は4営業日を待たずに公表していた」という例が挙がりました(2024年6月のランサムウェア事案)。ただし KADOKAWA は日本企業であり、上で挙げた SEC の4営業日ルールは米国上場企業向けの規制です。両者は規制の対象がそもそも異なるため、ここは「重大なインシデントはもはや隠せない時代になった」という時代感をつかむ例として受け取るのがよさそうです。

サイバーセキュリティはやむを得ない費用ではなく、投資である。

この一文が、内部統制を「コスト」ではなく「経営判断」として捉え直す入口になります。

チェックリストアプローチへの違和感 ── 統制は「リスクのある場所」に打つ

ここで、この記事の主張の核心に入ります。

内部統制を学ぶと、「やるべき統制のリスト」が大量に出てきます。私は当初、これを上から順に潰していけばよいのだと思っていました。これが チェックリストアプローチ です。

しかし講義では、このアプローチが明確に批判されていました。理由はこうです。

内部統制は、独立して存在してはいけない。リスクのある場所にだけ存在しなければならない。

リストに載っているからという理由だけで、必要のない WAF を導入する。それは「無駄な内部統制」です。コストをかけたのに、守るべきリスクがそこになければ意味がありません。逆に、リストにない場所に重大なリスクが潜んでいたら、チェックリストはそれを見逃します。

ここで、#2 で学んだリスクの定義が効いてきます。

リスクとは、目的の達成を阻害する要因(不確実性)である。

リスクがない場所に統制を打てば、それは過剰な統制です。だから内部統制を考えるときは、まず「どこにリスクがあるか」から始めなければなりません。リストを起点にするのではなく、リスクを起点にする。この順番の逆転が、私にとって一番の学びでした。

ちなみに、この「過剰な統制をやめる」という発想は、パスワードの世界でも起きています。かつて「パスワードは定期的に変更すべき」という統制が常識でした。ところが NIST は SP 800-63B(Digital Identity Guidelines) で、その方針を転換しました。最新の Rev.4 では、次のように定期変更を明確に禁止しています。

検証者および CSP は、利用者にパスワードを定期的に変更することを要求してはならない(SHALL NOT)。
— NIST SP 800-63B Rev.4 §3.1.1.2

ここで注目したいのは、語の強さです。旧 Rev.3(2017年公表・2020年更新)までは「要求すべきではない(SHOULD NOT)」という推奨でした。それが Rev.4(2025年8月確定)で「要求してはならない(SHALL NOT)」という禁止へと強化されています。NIST 文書において SHALL NOT は、逸脱を許さない必須要件です。「定期変更はやめたほうがよい」から「やめなければならない」へ、踏み込みが一段強まったわけです。

なぜここまで強くしたのか。定期変更を強制すると、利用者がかえって単純で推測しやすいパスワードを選んだり、末尾の数字を1つ増やすだけの小細工をしたりするからです。良かれと思った統制が、逆にリスクを上げていました。いまは複雑な短いパスワードより、長いパスフレーズが推奨されています。「リスクのない(あるいはリスクを生む)統制はやめる」という、まさにチェックリスト批判と同じ思想です。

なお、似た番号で SP 800-53B という別文書がありますが、こちらは統制ベースライン(管理策の選び方)を扱うもので、パスワードの話とは別物です。私も最初これを混同しかけたので、番号には注意してください。パスワードの定期変更の話は 63B(Digital Identity Guidelines)であって、53B(コントロールベースライン)ではありません。

COSOモデル ── 内部統制のデファクトスタンダード

内部統制には、世界的なデファクトスタンダードのモデルがあります。それが COSO です。

COSO は Committee of Sponsoring Organizations of the Treadway Commission(トレッドウェイ委員会支援組織委員会)の略です。この組織が "Internal Control – Integrated Framework" を1992年に公表し、2013年に改訂しました。内部統制の教科書、と考えてよい存在です。

COSO による内部統制の定義は、おおむね次のとおりです。

内部統制とは、3つの目的の達成に関して合理的な保証を提供することを意図した、事業体の取締役・経営者およびその他の構成員によって遂行される「プロセス」である。

ここで押さえる軸は2つあります。5つの構成要素と、3つの目的です。

5つの構成要素(統制環境が土台)

構成要素	英語	役割
統制環境	Control Environment	組織の気風を決める土台。誠実性・倫理観・能力。他の4要素の基礎
リスク評価	Risk Assessment	自社にとってのリスクを識別・分析する
統制活動	Control Activities	目的達成に必要な方針と手続き(物理統制・職務の分離など)
情報と伝達	Information & Communication	必要な情報を識別・伝達する。上下・横・組織内外
モニタリング	Monitoring Activities	内部統制の質を継続的に評価する

5要素のうち、統制環境がほかの4つの土台になっている点が重要です。COSO はこれを箱を積み上げた立体図(通称 COSOキューブ)で表します。本記事では Mermaid で土台構造だけ抜き出します。

図は下が土台です。統制環境(最下段)が崩れると、その上に積んだ要素はすべて不安定になります。組織の気風や倫理観がゆるい会社では、いくら個別の手続きを精緻にしても機能しない、ということです。

3つの目的

目的	中身
業務(Operations)	事業活動が効果的・効率的になされていること
報告(Reporting)	報告に信頼が置けること
コンプライアンス(Compliance)	関連法規に適合していること

報告(Reporting)については、補足があります。もとは Financial Reporting(財務報告、有価証券報告書など)に重点がありました。粉飾決算をした会社の破綻が相次いだことが背景にあります。その後、財務に限らない報告全般へと広がり、いまは単に Reporting と呼ばれます。

内部統制の限界 ── 合理的な保証であって絶対ではない

COSO の定義には「合理的な保証(Reasonable Assurance)」という言葉が入っています。これは「絶対の保証ではない」という意味です。限られた時間・限られた情報のなかで下した判断には、構造的な限界があります。

限界	中身
判断ミス・不注意	人が関わる以上ゼロにできない
共謀	チェックする側とされる側がグルだと機能しない
経営者による内部統制の無視	トップが意図的に無視すれば統制は崩れる
想定外の事象の発生	当初のリスク評価で考えられなかった新たなリスク

共謀の例として、担当者の作業を課長がチェックする仕組みがあっても、2人が結託していれば素通りする、という話が挙がりました。IT の世界では、海外の攻撃者が大手企業の従業員を買収し、VPN の認証情報を聞き出した事例があります。どれだけ統制を重ねても、人間の悪意の共謀には弱い。だからこそ COSO は「合理的な保証」という言葉で、最初から限界を引き受けています。

統制の階層 ── 組織レベルが最重要

内部統制は、組織のどの粒度ではたらくかで階層構造になっています。

ここで一番大切なのが、組織レベル統制(全社レベル統制) です。講義でも繰り返し強調されていました。

組織レベル統制が有効でない限り、プロセスレベルがどれほど優れていてもダメ。

たとえば現場の業務手順がどれほど精緻でも、会社としての IT 戦略やセキュリティポリシー(=組織レベル統制)が機能していなければ、土台が抜けています。下の階層をいくら磨いても、上の土台が無効なら全体が崩れる。COSO で「統制環境が5要素の土台」だった話と、同じ構造がここにも現れています。

なお、組織レベル統制とプロセスレベル統制の関係でよく出る話題が、クラウドとオンプレミスの比較です。クラウドは事業者が日々セキュリティリスク評価を回しているため、リスク対策の観点では一般に有利です。自社だけで同じ頻度の評価を続けるのは難しいからです。ただしクラウドには、海外にデータがロックインされうるといった別のリスクもあるため、バックアップの取り方などを別途考える必要があります。

統制の8種類 ── 時系列で「予防・発見・回復・継続」に分ける

ここは、すぐ実務で使える分類です。内部統制は、はたらき方によって8種類に分けられます。英語の綴りもあわせて覚えると、ニュアンスがつかみやすくなります。

#	種類	英語	はたらき	例
1	予防	prevention	リスクの発生を直接予防する	FW・WAF
2	抑止	deterrence	リスクを起こす行為を思いとどまらせる	監視カメラの存在告知
3	検知	detection	リスクが発現したことを発見する	EDR・SOC
4	制限	limitation	発現時の影響を最小限にする	マイクロセグメンテーション
5	是正	correction	統制の手法・強度を見直して改善する	設定見直し
6	回復	recovery	発現前の状態へ速やかに戻す	バックアップからの復旧
7	監視	monitoring	統制が有効に機能しているか確認する	EDR の稼働監視
8	認知	awareness	教育・啓発で人の行動を変える	awareness training

この8種類を、リスク発現の時系列に沿って4つのフェーズへまとめると、頭に入りやすくなります。

フェーズ	含まれる統制	タイミング
予防	prevention / deterrence	リスクが発現する前
発見	detection	発現した瞬間
回復	recovery / limitation	発現したあと
継続	monitoring / awareness / correction	全期間を通じて

いくつか補足します。制限(limitation) は、1端末を1セグメントに区切って、乗っ取られても被害が横に広がらないようにする、といった「被害の封じ込め」です。認知(awareness) は、日本語の「知識を教える」より広い概念です。英語圏では awareness training と呼ばれ、「変なメールを開いてしまった後に、自分で判断して CSIRT に連絡する」ところまで、行動の判断を含めて鍛えるトレーニングを指します。知識だけでなく、いざというときの意思決定まで含むわけです。

ここで一度、手を止めて試してほしいことがあります。いま自社でやっているセキュリティ対策を、この8種類(または4フェーズ)に分類してみる のです。

私がやってみると、「予防」に偏っていて「回復」や「認知」が手薄だと気づきました。FW も WAF も入れているのに、いざ侵入されたときの復旧手順は曖昧だったのです。分類すると、自社の対策の偏りが可視化されます。なお、この8分類は20年ほど前の枠組みがベースなので、より新しい整理を求めるなら NIST のフレームワークも参照するとよいです。

IT統制 ── 全般統制とアプリケーション統制

内部統制のうち、IT に関わるものが IT統制 です。ここは2つに大別されます。

種類	英語	何を守るか	例
IT全般統制	General Control(ITGC)	アプリが安全に稼働する「土台」	システム開発・変更管理・運用管理・セキュリティ
ITアプリケーション統制	Application Control	アプリに組み込まれた個別の統制	入力チェック・マスタ更新チェック・認証・暗号化

イメージとしては、IT全般統制は「アプリが乗っている土俵(開発・変更・運用・セキュリティのプロセス)を整える統制」で、アプリケーション統制は「アプリの中に機能として埋め込まれた統制」です。入力フォームのバリデーションや、データを暗号化して保存する処理は、アプリケーション統制にあたります。一方、その開発プロセスやサーバの運用管理がきちんと回っているかは、IT全般統制の話です。

両者は補完関係にあります。アプリ内のチェックがどれだけ精緻でも、その変更管理がずさんで誰でも本番にコードを入れられるなら、土台(全般統制)から崩れます。

有効性評価の2段階 ── SOC 2 の Type1 / Type2 と対応する

統制を導入したら、それで終わりではありません。その統制が本当に効いているかを評価します。評価は2段階です。

段階	評価名	何を見るか	タイミング
①	整備状況評価	設計が有効か(リスクを許容レベルまで下げられる設計か)	導入前の机上評価
②	運用状況評価	設計どおり実際に機能していたか	導入後(最低でも半年)

具体例で考えます。WAF を入れるとして、まず「WAF を入れれば不正侵入リスクは下がるのか、そもそも何を入れるべきか」を導入前に机上で評価するのが 整備状況評価 です。これは設計の評価なので、導入前に行えます。

導入してしばらく(最低でも半年ほど)運用したあと、「実際にアラートは上がったか、不正侵入された形跡はなかったか」を確認するのが 運用状況評価 です。設計が机上で正しくても、運用してみたら期待どおり機能していなかった、ということは起こりえます。だからこそ、設計と運用を分けて2段階で評価します。

この2段階評価は、クラウドの監査制度 SOC 2 とそのまま対応します。SOC 2 は米国公認会計士協会(AICPA)の枠組みで、Type1 と Type2 があります。

評価の段階	SOC 2	見ているもの
① 整備状況評価	SOC 2 Type1	一時点での統制の「設計」
② 運用状況評価	SOC 2 Type2	一定期間(通常3〜12ヶ月)の「運用の有効性」

整備状況評価が Type1、運用状況評価が Type2 に対応していると考えると、両方が一気に腑に落ちます。AWS や Azure は SOC 2 Type2 を取得しており、内部統制とリスク評価を回し続けていることが、期間をかけて保証されています。これは顧客に開示されます(ただし顧客になる前には、なかなか開示してもらえないのが実情です)。

日本独自の制度として ISMAP(政府情報システムのためのセキュリティ評価制度)もあります。講義では「SOC 2 Type2 を通っていれば取れる」という主張がありました。ただし正確には、ISMAP は独自の監査制度であり、SOC 2 や ISMS と監査項目の多くが整合するため、監査期間をそろえれば負担を軽減できる、という関係です。SOC 2 Type2 を取れば自動的に ISMAP も取得できる、というわけではない点に注意してください。

リスクシナリオの描き方 ── 詳しく描くほど脆弱性が見えてくる

ここがこの記事の目玉であり、私が一番「実装に効く」と感じた話です。

統制を「リスクのある場所に打つ」には、そもそもリスクがどこにあるかを知る必要があります。そのための技術が、リスクシナリオを詳細に描くことです。

まず、リスクの分解から始めます。#2 で学んだとおりですが、実装の観点ではもう一段ぶんかいします。

リスク = 脅威 + 脆弱性

ここで決定的に重要なのは、対策を打てるのは「脆弱性」の側だけ だという点です。脅威(海外の攻撃者など、組織の外にある悪意)そのものは、こちらでどうにもできません。攻撃者をなくすことはできないのです。できるのは、攻撃が成立する余地である「脆弱性」を塞ぐことだけです。

では、脆弱性はどうやって見つけるのか。ここで「リスクシナリオを詳しく描く」が効いてきます。講義で示されたのは、標的型攻撃を段階的に詳細化していく例でした。同じインシデントを、解像度を上げながら描き直します。

段階	シナリオ	新たに見えてくる脆弱性	打てる対策(例)
1	標的型攻撃を受け、顧客情報が盗まれた	(まだ漠然)	(対策点が見えない)
2	社員が添付ファイルを開いてマルウェアに感染した	メールの添付を開いてしまう	認知(訓練)・添付の無害化
3	C&Cサーバに遠隔操作され、ファイルサーバの顧客情報が盗まれた	外部への不審な通信を止められない	出口対策・通信監視(検知)
4	シグネチャ型のウイルス対策が検知できず感染した	既知パターンに頼った検知	振る舞い検知・EDR(検知)
5	盗まれた情報がクラウドストレージに送信され流出した	クラウドへの持ち出しを制御できない	DLP・Webフィルタリング(制限)

注目してほしいのは、段階1では対策点がまったく見えないのに、解像度を上げて「どこで」「何が起きて」を具体化していくほど、赤字部分(=脆弱性)が次々に浮かび上がってくることです。そして脆弱性が見えれば、それぞれに打つべき統制(右端の列)が決まります。8種類の統制が、ここで分類の道具として効いてきます。

ポイントは、汎用的なシナリオでは脆弱性が見えてこないことです。

汎用シナリオではなく、自社の業務・環境に即した詳細なシナリオ をどれだけ描けるかが鍵。詳しく描くほど、脆弱性(=対策点)が見えてくる。

ここでも、ぜひ手を動かしてみてください。

自分の現場で起きうるインシデントを1つ選び、段階1から段階5まで解像度を上げて書いてみる。 各段階で増える脆弱性に、8種類のどの統制を当てるかをマッピングしてみる。

私は自分の関わるシステムでこれをやってみて、段階3〜4で「通信の監視がほぼ手つかず」という穴に気づきました。漠然と「不安だ」と思っていたものが、シナリオを書くことで具体的な対策点に変わったのです。これが「リスクに打つ」の実感でした。

ただし実務上の難しさもあります。脆弱性は、サーバやネットワークの設定だけでなく「業務プロセス」の中にも潜みます。IT の設定状況は評価できても、業務プロセス上の脆弱性まで IT 部門が評価できるのか、という課題が残ります。そして「どこまで対策すべきか」は、最終的には経営者が損害をどこまで許容できるか、という経営判断に帰着します。許容できないリスクには打つ、許容できるなら打たない。ここで再び、内部統制が経営の話(#2 のガバナンス)とつながります。

まとめ

この記事では、内部統制を「制限・チェックリスト」という先入観から引きはがし、「リスク(脆弱性)に打つ実装戦略」として理解し直しました。最初に掲げた主張をふり返ります。

内部統制とは「リスクのある場所」を狙って打つ対策であり、打てるのは脅威ではなく脆弱性の側だけである。

学んだことを、講義のまとめにあった7原則の形で整理します。

内部統制は、リスクを低減するために必須である(コストではなく投資)。
内部統制は、脆弱性に打つ(だからこそ脆弱性診断とシナリオ作成が重要)。
どこに打つかは、達成したい目標のビジネス的な優先順位による(判断は経営戦略そのもの)。
どれだけ打つかは、目標とするレベルによる。
内部統制は単体で戦わない。複数の統制が補完し合い、総合的にリスクを下げる。
内部統制は合理的な保証を与える(絶対ではなく、限界がある)。
内部統制は、有効性の評価が大切(整備状況=設計、運用状況=実運用の2段階)。

そして、この記事で手を動かしてほしかったことは2つでした。

自社の対策を 8種類(予防・発見・回復・継続) に分類し、偏りを見つける。
自分の現場のインシデントを 段階1から5まで詳細化 し、見えてきた脆弱性に統制をマッピングする。

内部統制は、リストを上から潰す作業ではありません。リスクのある場所を見極め、脆弱性に狙って打つ実装戦略です。そう捉え直すと、ISMS で学んだ「管理策」が、急に自分の現場の話として動き出します。ここまで読んでいただき、ありがとうございました。

参考

本記事で挙げた規格番号・条文・年号は、次の一次情報で確認できます。記事中の内容は学習時点のもので、最新は各サイトで確認してください。

COSO(Internal Control – Integrated Framework): https://www.coso.org/guidance-on-ic
NIST SP 800-63B(Digital Identity Guidelines。パスワードの定期変更に関する記述): https://pages.nist.gov/800-63-4/sp800-63b.html
SEC: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure(2023年): https://www.sec.gov/newsroom/press-releases/2023-139
e-Gov 法令検索会社法(362条・施行規則100条): https://laws.e-gov.go.jp/law/417AC0000000086
NISC「企業経営のためのサイバーセキュリティの考え方」: https://www.nisc.go.jp/
ISMAP(政府情報システムのためのセキュリティ評価制度): https://www.ismap.go.jp/
AICPA SOC 2(System and Organization Controls): https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2
AWS SOC FAQ(AWS が SOC 2 Type II 報告書を提供している根拠): https://aws.amazon.com/compliance/soc-faqs/

※ 参考文献(講義): 安田浩ほか『企業リスクとIT統制』(2007年, ASCII出版)。
※ 「KADOKAWA が4営業日を待たず公表した」「ISMAP は SOC 2 Type2 を通っていれば取れる」は講義での例示・主張に基づくものであり、本記事では一次情報をもとに相対化して記述しています。