監査人が「ほぼ毎回」見つける指摘事項を先回りして潰す

IT監査（J-SOX のITGC評価、ISMS内部監査、SOC2 監査、上場準備の予備監査など）には頻出する指摘パターンがあります。監査人は短い期間で被監査企業のITを評価するため、まず「過去に多くの企業で発見された論点」から確認していきます。逆に言えば、その論点を先回りして整備しておけば監査が大幅にスムーズになります。

本記事では、当社が中堅・中小企業のIT監査支援を通じて頻繁に目にする15の指摘事項を、(1) 指摘される理由、(2) 是正の具体策、(3) 再発防止──の3点で解説します。基礎理解はIT監査とは、IT統制とは、J-SOX ITGC実装ガイドを併せてご参照ください。

15項目の俯瞰

領域項目頻度
アクセス管理1. アクセス権棚卸しが未実施／形骸化★★★
2. 退職者・異動者のアカウントが残存★★★
3. 特権IDが共用されている／棚卸しなし★★★
4. パスワードポリシーがNIST準拠でない★★
5. 多要素認証が一部ユーザー未適用★★
変更管理6. 本番環境への直接修正の証跡がない★★★
7. 開発・テスト・本番の職務分離が不十分★★
8. リリース承認の記録が口頭・メールのみ★★
運用管理9. バックアップのリストアテストが未実施★★★
10. ジョブ監視・障害対応の記録不備★★
ログ・モニタリング11. ログ保持期間の根拠が不明確★★
12. 異常検知のレビュー記録がない★★
外部委託・SaaS13. 委託先評価／SOCレポートの確認不備★★★
14. SaaS管理者権限の集中・棚卸しなし★★
15. シャドーIT・部門個別契約の未把握★★

指摘1：アクセス権棚卸しが未実施／形骸化

指摘される理由：J-SOX ITGCでもISMSでも、年1回以上のユーザーアクセス権限レビュー（User Access Review）が必須要件です。実施していない、または実施しているが「全員OK」とハンコだけついて終わっているケースが多発します。

是正策：

  • 対象システムを基幹システム・M365・業務SaaS・ネットワーク機器・クラウドの5領域でリストアップ
  • 四半期に1回、各システムの管理者がユーザー一覧をエクスポートし、所属長がレビュー（在籍／業務必要性／権限レベル）
  • 是正アクション（権限剥奪・降格）を記録し、Excel/Sharepointで証跡化
  • Entra IDのAccess Reviewsなど自動化ツールの活用

再発防止：四半期末の業務カレンダーに固定タスクとして登録、所属長レビューを必須化（記録なきレビューは「未実施」扱い）。詳細はアクセス権棚卸しの実装ガイド。

指摘2：退職者・異動者のアカウントが残存

指摘される理由：監査人は人事システムの退職者リストとIT側のアクティブアカウントを突合します。退職者がアクセス可能な状態が1人でも見つかると、これだけで重要指摘になります。

是正策：

  • 人事退職フローとIT無効化フローを連動（人事台帳のステータス変更で即無効化）
  • 退職日のEOD（End of Day）で全アカウントを「サインイン無効」化（即削除はNG、30日保持）
  • 業務SaaSも対象。M365だけ無効化して業務SaaSが残存するケースが多い
  • 月次で退職者リストとアクティブIDを突合、差分があれば即対応

再発防止：人事のオフボーディングチェックリストにIT項目を組み込む。ひとり情シス退職時の90日オフボーディングのチェックリストも参照。

指摘3：特権IDが共用されている／棚卸しなし

指摘される理由：administrator、root、共用Gmailなど共用アカウントは「誰がいつ何をしたか」の追跡ができないため、ITGCでは原則禁止です。共用パスワードがDocs/Excel等で平文管理されている事例も指摘対象。

是正策：

  • 個別管理者IDへの分離（管理者ロールを個人IDに付与）
  • 真にやむを得ない共用IDは PAM ツール（CyberArk、HashiCorp Vault、Azure PIM等）でチェックアウト管理
  • 四半期に1回の特権ID棚卸し（保有者・付与日・付与理由）
  • JIT（Just-In-Time）アクセスで「必要なときだけ昇格」

再発防止：Microsoft Entra Privileged Identity Management、AWS IAM Identity Center等のJIT機能を導入し、平時は一般権限、必要時だけ昇格する運用へ移行。

指摘4：パスワードポリシーがNIST SP 800-63B準拠でない

指摘される理由：日本のIPAガイドラインも近年NIST準拠に整合しており、定期変更を強制している、複雑性要件で覚えにくい運用になっている等の旧式ポリシーは指摘されます。

是正策：

  • 定期変更を「強制」から「漏洩疑い時のみ強制」へ
  • 最低長を14文字以上、辞書攻撃の常用パスワードをブロックリストで弾く（Microsoft Entra Password Protection等）
  • 多要素認証を必須化し、パスワードへの過度な依存をやめる
  • パスワードマネージャの導入と業務利用の許可

再発防止：パスワードポリシーは年1回見直し、最新ガイドラインに整合しているか確認。

指摘5：多要素認証が一部ユーザー未適用

指摘される理由：「役員はMFAが煩わしいので除外」「サービスアカウントはMFA非対応のため除外」等の例外が放置され、攻撃者の侵入経路となるリスクとして指摘されます。

是正策：

  • 条件付きアクセスで全ユーザーMFAを強制（除外は最小限）
  • サービスアカウントはマネージドID／証明書認証へ移行
  • 除外がやむを得ない場合は補完統制（IPアドレス制限、専用デバイス等）を文書化

再発防止：Microsoft Entra のサインインログを月次レビューし、MFA未通過の認証がないか確認。

指摘6：本番環境への直接修正の証跡がない

指摘される理由：J-SOX ITGCの「変更管理」では、本番環境への変更がすべて承認・テスト・記録されているかを確認します。緊急対応で本番直接修正が行われ、後追い記録がない場合は重要指摘になります。

是正策：

  • 変更管理プロセスの文書化（依頼→影響評価→承認→テスト→本番反映→事後確認）
  • 緊急変更は「事後72時間以内に書面化」のルールを設定
  • 変更チケットシステム（ServiceNow、Jira Service Management、freshservice等）の導入
  • 本番反映ログとチケットを自動紐付け

再発防止：変更チケットなしでの本番反映を技術的に禁止（CI/CDパイプラインで承認チェック）。

指摘7：開発・テスト・本番の職務分離が不十分

指摘される理由：開発担当者が本番環境にも書込権限を持っている、テスト環境のデータが本番からマスキングなしでコピーされている等は職務分離（SoD）の不備として指摘されます。

是正策：

  • 開発者は本番への書込不可、リリース担当者のみが本番反映できる権限分離
  • 本番データのテスト環境への持ち込みは禁止または匿名化必須
  • SoDマトリクスの作成（誰がどの環境で何ができるか）

再発防止：四半期SoDレビューで権限交差をチェック。

指摘8：リリース承認の記録が口頭・メールのみ

指摘される理由：「Slackで承認しました」「メールで部長OK出てます」では監査証跡として弱い。承認者・承認日・承認内容の3点が改ざん不能な形で残っている必要があります。

是正策：

  • 変更チケットシステムで承認ワークフロー化（承認ボタンで電子証跡）
  • メール承認の場合は所属長＋IT責任者の2名承認、メーリングリストCC必須
  • 承認記録の保管場所をルール化（〇〇システム、保管期間〇年）

再発防止：チケットなき変更を技術的に防止（承認IDがないとデプロイできない）。

指摘9：バックアップのリストアテストが未実施

指摘される理由：「バックアップは取得しているが、復元したことがない」状態は監査人がもっとも警戒する論点です。実際のディザスタ時に復元できないリスクとして指摘されます。

是正策：

  • 年1回以上のリストアテスト（テスト環境への復元実施）
  • テスト結果の文書化（実施日、対象、所要時間、結果、課題）
  • RPO（目標復旧時点）／RTO（目標復旧時間）の妥当性評価
  • クラウドバックアップ（Azure Backup、AWS Backup等）の活用

再発防止：年次BCP訓練の一部としてリストアテストを組み込む。

指摘10：ジョブ監視・障害対応の記録不備

指摘される理由：夜間ジョブの異常終了、障害アラートの対応記録が口頭・メモ書きで残されており、再発防止策が組織で共有されていないと指摘されます。

是正策：

  • インシデント管理プロセスの整備（発生→記録→対応→クローズ→振り返り）
  • 運用ランブックの整備（過去事例、対応手順、エスカレーション）
  • 月次インシデントレビューで再発防止策を共有

再発防止：チケットシステムでインシデント管理し、月次・四半期で傾向分析。

指摘11：ログ保持期間の根拠が不明確

指摘される理由：「90日」「1年」といったログ保持期間の根拠（法令、規程、契約）が示せない。あるいは規程と実態が乖離している。

是正策：

  • ログ管理規程の整備（種別・保持期間・保管場所・アクセス権）
  • 主要法令の要求期間を確認：個情法（保有期間）、電帳法（7年）、サイバー対策（最低90日推奨）、PCI DSS（1年）
  • 実装：M365監査ログは標準90日、E5/Audit Premiumで1年〜10年

再発防止：詳細は上場準備のログ管理・監査証跡保持の実装を参照。

指摘12：異常検知のレビュー記録がない

指摘される理由：SIEM/EDRからアラートは出るが、誰が見て、どう判断したかの記録がない。アラートが鳴りっぱなしで放置されている事例も。

是正策：

  • アラートのトリアージプロセス整備（重大度別の対応SLA）
  • 誤検知のチューニング履歴を記録
  • MDRサービスへの委託検討（24時間体制）
  • 月次セキュリティレポートの作成と経営層レビュー

再発防止：アラート→トリアージ→対応→クローズの記録をチケット化。

指摘13：委託先評価／SOCレポートの確認不備

指摘される理由：M365、Salesforce、AWS等のクラウドサービスを利用しているが、各サービスのSOC1/SOC2レポートを取得・レビューしていない。委託先評価の証跡が残っていない。

是正策：

  • 主要クラウドサービスのSOC1/SOC2 Type II レポートを取得
  • レビュー結果を文書化（CUEC、Bridge Letter、例外事項）
  • 委託先評価チェックリスト（情報セキュリティ・財務・継続性）の整備
  • 年1回の再評価

再発防止：詳細はSaaS／クラウドサービスのIT監査論点を参照。

指摘14：SaaS管理者権限の集中・棚卸しなし

指摘される理由：M365のグローバル管理者が情シス1名に集中、業務SaaSの管理者が部門担当者に固定で誰も棚卸ししていない、退職者が管理者として残存している等。

是正策：

  • SaaS管理者権限の台帳化（サービス／管理者ID／付与日／業務理由）
  • 四半期棚卸しと過剰権限の剥奪
  • 2人以上の管理者体制（ひとり情シスでも経営者をバックアップ管理者に）

再発防止：新規SaaS導入時に「管理者2名以上」を必須要件化。

指摘15：シャドーIT・部門個別契約の未把握

指摘される理由：情シスが認知していないSaaSが部門で使われている、個人クレジットカード立替で導入されている等。情報資産台帳に未登録。

是正策：

  • クレジットカード明細・経費精算の月次レビュー（サブスク系を抽出）
  • CASB（Cloud Access Security Broker）／Microsoft Defender for Cloud Apps等で発見
  • SaaS導入申請プロセスの整備（情シス事前審査）
  • 許可SaaS／禁止SaaSのリスト整備

再発防止：定期的なシャドーITスキャンと社員教育。

監査前の準備と監査中の対応

15項目を「監査の3ヶ月前から先回り是正」する手順です。

時期アクション
監査3ヶ月前セルフチェックを15項目で実施し、ギャップを特定
監査2ヶ月前是正計画を策定（クイックウィン優先）
監査1ヶ月前主要な是正を完了、エビデンスを整理
監査2週間前監査人とのキックオフ前準備（資料提出依頼への準備）
監査中ヒアリング対応、追加エビデンス提出、回答内容の社内共有
監査後30日指摘事項の是正計画策定と次年度監査への反映
⚠️ 「指摘ゼロ」を目指しすぎない

軽微な指摘は誰でも受けます。重要なのは「重要指摘ゼロ」と「指摘事項に対する誠実な是正姿勢」を示すこと。隠すよりオープンに是正計画を提示するほうが監査人の信頼を得られます。

BTNコンサルティングのIT監査対応支援

BTNコンサルティングでは、IT監査の予備診断（15項目チェック）、是正実装、監査人対応の伴走支援を提供しています。J-SOX ITGC、ISMS、SOC2、上場準備のIT監査いずれにも対応可能です。情シス365のお客様には監査対応の標準サポートとして提供しており、年次監査前の3ヶ月集中是正もスポット対応できます。

💡 関連サービス

→ 情シス365（IT監査対応支援を含む）
→ J-SOX ITGC実装ガイド
→ IT棚卸し・IT監査の進め方
→ アクセス権棚卸しの実装ガイド
→ SaaSのIT監査論点

まとめ

IT監査の指摘事項には強い再現性があります。アクセス管理5項目、変更管理3項目、運用管理2項目、ログ・モニタリング2項目、外部委託・SaaS 3項目──の計15項目を先回りして整備しておけば、監査の大半はスムーズに進みます。重要なのは「完璧」を目指すのではなく「誠実な是正」を示すこと。指摘ゼロより、指摘への是正姿勢のほうが監査人に評価されます。