ポリシー未整備でも監査は通せる:「やらない」ことを説明するための防御論理
社員数100名、情シスは実質1名。 そんな中で親会社(本国)や監査法人から「IT監査」の通達が来ると、多くの担当者は目の前が真っ暗になります。
「パスワードポリシー規定を見せてください」 「ログの定期レビュー記録は?」 「特権IDの貸出申請フローは?」
無いものばかりを突っ込まれ、「不備(Deficiency)」のレッテルを貼られる恐怖。 しかし、ここで**「すみません、まだ手が回っていなくて作れていません」と謝るのは最悪の回答**です。それは「管理放棄」とみなされるからです。
逆に、**「そのリスクは認識していますが、当社の規模とリソースを鑑みて、意図的に『規定を作らない』という判断をしています」**と答えることができれば、それは立派な「マネジメント(リスク受容)」となります。
本稿では、リソースの限られた一人情シスが、完璧なポリシー整備を行わずに監査を乗り切り、かつ実質的な説明責任を果たすための「防御論理(ロジック)」を解説します。
1. 監査人が見ているのは「書類」ではなく「意思決定」
まず大前提として、監査人は「御社を100点満点のセキュリティ企業にすること」が仕事ではありません。「経営陣がリスクを把握し、コントロールできているかを確認すること」が仕事です。
したがって、以下の2つの状態には天と地ほどの差があります。
- 管理不足: 「忙しくて考えていませんでした(リスク未認知)」
- リスク受容: 「リスクは知っていますが、コスト対効果が見合わないので対策しないと決めました(リスク認知済)」
我々が目指すのは常に後者です。これを専門用語で**「リスク受容(Risk Acceptance)」**と呼びます。 経済産業省の「情報セキュリティ管理基準」においても、リスクへの対応方針として「低減」「回避」「移転」に加え「保有(受容)」が認められています。
2. 具体的な「防御ロジック」の構築
では、具体的な監査項目に対し、どのように「やらない」ことを説明すればよいのでしょうか。 以下の3つのカード(論理)を使い分けます。
カード①:リスク受容(Risk Acceptance)
「そのリスクの発生確率とインパクトは、対策コストを下回ります」という主張です。
- 監査指摘: 「BYOD(私物スマホ利用)の利用申請書と誓約書がない。規定を作るべきだ」
- 防御ロジック:
「当社は100名前後の組織であり、全社員の顔とデバイスが見える範囲にいます。現時点でMDM(モバイルデバイス管理)を導入するコスト(月額数万円+管理工数)は、紛失リスクによる想定損害額と比較して過大であると判断しました。したがって、性善説に基づく運用を経営判断として許容しています」
- ポイント: 「経営判断」という言葉が最強の盾です(ただし、経営者の合意は必要です)。
カード②:代替統制(Compensating Control)
「Aという(高価な)対策はしていませんが、Bという(安価な)対策で同等の効果を出しています」という主張です。
- 監査指摘: 「特権ID(Admin権限)の貸出管理簿がない。誰がいつ管理者権限を行使したか追跡できない」
- 防御ロジック:
「仰る通り、申請フローや管理簿は作成していません。しかし、当社のシステムはGoogle Workspaceに統合されており、特権操作は全てシステムログ(Audit Log)として改竄不可能な状態で自動記録されています。手書きの管理簿よりも正確な証跡があるため、これをもって管理としています」
- ポイント: 「アナログな管理規定」を「システムによる自動化」で代替します。SaaS環境では特に有効です。
カード③:重要性(Materiality)の欠如
「そこを守らなくても、会社の存続に関わるような致命傷にはなりません」という主張です。
- 監査指摘: 「社内ファイルサーバーのアクセスログを定期的にレビューしていない」
- 防御ロジック:
「当社のファイルサーバーには、財務情報や個人情報などの機微情報は格納しない運用としています(機微情報は別システムで管理)。したがって、ここのアクセスログを毎月チェックすることは、**リスクに対して過剰な統制(Over Control)**となります。インシデント発生時の事後追跡用にログ保存のみを行っています」
- ポイント: 「守るべき資産(Asset)」の重要度が低いことを示し、対策不要論を展開します。
3. 「やらない」と判断したことをドキュメント化する
口頭で説明するだけでは、言った言わないの水掛け論になります。 ここで作成すべきなのが、**「リスク受容・例外管理台帳(Risk Acceptance Register)」**というA4一枚のExcelシートです。
ポリシー(規定)を作る代わりに、この「言い訳リスト」を作ります。
| No | 監査項目(想定) | 現状(As-Is) | 対応方針 | 理由(ロジック) | 承認者 |
|---|---|---|---|---|---|
| 1 | 私物スマホ管理 | MDMなし、規定なし | 受容 | コスト対効果が見合わないため。パスコードロックのみ口頭指導。 | 社長 |
| 2 | パスワード変更 | 定期変更なし | 代替統制 | 総務省ガイドラインに準拠し、定期変更を廃止。代わりにMFAを必須化。 | 情シス部長 |
| 3 | 業者入館記録 | 入退室ログなし | 受容 | オフィスがワンフロアで見通しが良く、不審者は即座に検知可能なため。 | 総務部長 |
監査で突っ込まれたら、すかさずこのシートを出します。 「ああ、その件ですね。それについては昨年検討し、こういう理由で『やらない』と決定済です」 これを見せられた監査人は、それ以上突っ込めません。なぜなら、**「経営層がリスクを理解してサインしている」**からです。監査人の本来の指摘相手である経営者が「それでいい」と言っている以上、外部の人間が「いや、ダメだ」とは言いにくいのです。
4. 将来への布石:いつ「やる」のか
もちろん、「一生やりません」では通りません。会社が成長すればリスクも変わります。 「今はやらない」の裏側に、**「この条件になったら見直す(再評価)」**というトリガーを設定しておきましょう。
- 社員数が150名を超えたら、MDM導入を検討する。
- ISMS/Pマークを取得することになったら、入退室管理を導入する。
- 上場準備に入ったら、特権ID管理ツールを入れる。
これを伝えると、監査人は「継続的な改善プロセス(PDCA)」が回っていると判断し、安心します。 「現状維持」ではなく「状況に応じた柔軟な判断」であることをアピールするのです。
結論:監査とは「対話」である
監査対応を「テスト」だと思ってはいけません。100点を取る必要はないのです。 それは、会社のリスクに対する姿勢を説明する「対話(コミュニケーション)」の場です。
一人情シスは、手足(実作業をする時間)は足りませんが、頭(ロジック)で戦うことはできます。 「できない」と嘆く前に、「なぜやらないのか」を言語化してください。 その論理構築こそが、貴社のITガバナンスにおける最強の防壁となります。
参考資料
- 経済産業省:情報セキュリティ管理基準
- リスク受容のプロセスについて記載があります。
- 中小企業における現実的な対策レベルの参考になります。
AIに相談するためのプロンプト(テンプレート)
監査人からの鋭い指摘に対し、慌てずに「論理的な反論(言い訳)」を用意するためのプロンプトです。
あなたはシステム監査対応の専門家(元監査人)です。
一人情シスである私が、監査で以下の「不備(Deficiency)」を指摘されました。
記事にある防御カード(1.リスク受容、2.代替統制、3.重要性の欠如)を使って、この指摘を「指摘事項」ではなく「観察事項(Observation)」や「問題なし」に軟着陸させるための回答ロジックを作成してください。
# 監査人からの指摘
* 指摘内容: [例: 「特権ID(Admin)の利用申請ワークフローが存在せず、事後承認も行われていない」]
* 補足: [例: 実際は私一人しかAdminがおらず、申請も承認も自分で行うことになるため無意味だと思っている]
# 自社の状況
* システム環境: [例: Google Workspaceのみ。ログはシステム側で自動取得されている]
# 出力してほしい内容
1. **防御ロジックの構築**: 「なぜワークフローを作らないか」を、怠慢ではなく「合理的なリスクコントロール」として説明する文章。
2. **リスク受容台帳への記載案**: 今後同じことを聞かれないようにドキュメント化するための、簡潔な記載文言。