見出し画像
Photo by ibaraki_nakai

初心者のためのIT統制マニュアル

gch

これは CAMPFIRE Advent Calendar 2023 2日目の記事です。

こんにちは、岩崎です。なんやかんやで今年もアドベントカレンダーの季節がやってきました。

さて今回は何を書こうと思ったのですが、採用やマネジメントについては去年書いたので、今年は最近担当しているが一度も文章としてはアウトプットしたことがないIT統制について書くことにしました。

ちょうど最近チームに新しいIT統制担当の方が入られましたし、主にその人に向けて「初心者のためのIT統制マニュアル」というタイトルで書いてみようと思います。ただ、その人は全く初心者ではないのですが笑。
その人以外にも、この記事がIT統制担当になったものの、これから何をすればいいかわからないという人の道標になれば幸いです。


IT統制担当になった経緯

はじめに、私がIT統制担当になった経緯から話していきたいと思います。数年前、当時エンジニアチームのマネージャーだった私は、いきなり内部監査室の人から監査についての重厚なチェックリストを渡され埋めるように言われました。また、内部統制コンサルの人とのミーティングにも同席させられ、わけもわからず質問に答えていました。

渡されたチェックリストはどう見ても現代の一般的なWeb企業の開発運用とは乖離しており、20年前のエンタープライズ企業を想定しているように見えました。開発と運用の分離、ウォーターフォールとオンプレミスを前提としており、おそらくデプロイは数ヶ月に一回で、自動テストなどは考慮されておらず、そして異常なほど各所で承認の証跡を残すことが求められていました。

これは一体なんなんだろう、そしてどう答えればいいんだろう、これらを全て実現しないといけないのだろうか、だとしたら開発スピードが極端に落ち事業にも影響が出るだろうし、開発体験が悪化することで場合によっては退職者も出てくるのではないかなど、様々な思いが頭を駆け巡りました。

これはしっかり勉強して向き合わないと大変なことになる、そう思い、当時内部統制初心者だった私は猛勉強することになります。

それから内部統制やIT統制についての本を数冊買って何周もし、同時にネット上に落ちている様々な内部統制についてのドキュメントや各社の実践事例を読み込みました。また、当時から会社に関わってくれていた内部統制コンサルの人と話す中で、杓子定規ではない実際的な内部統制の感覚を掴んでいきました。おかげさまで、今では社内で一番内部統制やIT統制について詳しくなったと自負しています。

内部統制とは

「財務報告に係る内部統制の評価及び監査の基準」によれば、内部統制とは「基本的に、業務の有効性及び効率性、財務報告の信頼性、事業活動に関わる法令等の遵守並びに資産の保全の4つの目的が達成されているとの合理的な保証を得るために、業務に組み込まれ、組織内の全ての者によって遂行されるプロセスをいい、統制環境、リスクの評価と対応、統制活動、情報と伝達、モニタリング（監視活動）及びIT（情報技術）への対応の6つの基本的要素から構成される。」と定義されています。なんのこっちゃですね。

簡単に言うと、内部統制とは「企業が事業活動を健全かつ効率的に運営するための仕組み」のことであり、全ての上場企業には金融証券取引法のもと、「財務報告に係る内部統制報告制度」、いわゆるJ-SOXへの対応が義務付けられています。つまり、IPOを目指す全ての企業はこの内部統制への対応が必要になってきます。内部統制の効果は多岐に渡るため、仮にIPOを目指さないにしても、内部統制を実施して業務の有効性及び効率性や財務報告の信頼性、コンプライアンスの遵守を図ることは一定のメリットがあるといえるでしょう。

ちなみに、金融証券取引法とは別に、会社法においても一定の大規模企業に対しては内部統制に関する対応を求める規定が置かれており、この場合は未上場の企業も内部統制の対象になります。また、金融証券取引法と会社法における内部統制の意味合いはやや異なります。この記事では主に金融証券取引法における内部統制報告制度について話していきますが、興味がある人は会社法の方も調べてみてください。

J-SOXとは

上記の金融証券取引法に基づく内部統制報告制度は、一般的にJ-SOXとかJ-SOX法と呼ばれています。これはなぜかというと、アメリカですでにSOX法という法律があり、J-SOX法はこのSOX法の日本版という位置付けだからです。

SOX法とは、2000年代初頭にアメリカで起きたエンロン事件（エネルギー大手エンロンの粉飾決算事件）などをきっかけに生まれた企業改革法で、法案を提出した議員の名前を取って通称「Sarbanes-Oxley Act」（サーベインス・オクスレー法、略称SOX法、正式名称は Public Company Accounting Reform and Investor Protection Act of 2002：上場企業会計改革及び投資家保護法）と呼ばれています。

SOX法では、企業に財務情報の透明性と正確性の確保を厳しく求め、会計処理上の不正や誤謬を防ぐ「内部統制」を整備することが義務付けられており、実際の運用にはCOSOフレームワークやCOBIT、ISO/IEC 38500などが利用されています。

COSOキューブ

J-SOXもこのCOSOやCOBITの影響を大きく受けており、若干項目の違いはあるものの、COSOフレームワークで定義されているものとほぼ同様の基準が示されています。また、経済産業省が出している「システム監査基準」及び「システム管理基準」や「JIS Q 38500」など、世界的なフレームワークを参考にして作成された日本独自の基準が参照されることも多いです。

SOX法とJ-SOX法の違い

SOX法と比べてJ-SOX法が異なる点は以下になります。

・最新の情勢を反映し、COSOフレームワークの目的に「資産の保全」が、基本的要素に「ITへの対応」が追加
・是正が必要な評価の区分から「重大な不備」「軽微な不備」が「不備」としてまとめられた
・ダイレクトレポーティングではなくインダイレクトレポーティングを採用

この中で特に大きな違いは最後の「ダイレクトレポーティングではなくインダイレクトレポーティング」、つまり監査人自身が直接、内部統制の効果を検証・試験することはできないという点にあります。

内部統制のやり方

実際に内部統制に取り組むとなったら、何をすれば良いのでしょうか。ここについては明確な定義があるわけではありませんが、上述の「実施基準」などいくつかの基準、指針が公開されているため、それらをベースに考えていくことになります。

一般的に必要な作業は3点セットと呼ばれる、「業務記述書」、「フローチャート」、「RCM（リスクコントロールマトリクス）」の作成と、各種ルールやドキュメントの整備、そして必要に応じたシステムの導入です。

具体的には、はじめに財務報告の信頼性に直結する業務を洗い出し、業務記述書やフローチャートを作成、そしてRCMから潜在的なリスクを抽出して統制を組み立て、必要に応じてフローやシステムを整備していきます。

以下は「実施基準」に記載されている3点セットの例です。

業務記述書
フローチャート
RCM

この3点セットについては、特にフォーマットは決まっていないため、各社で自由に作成して問題ありません。ただし、RCMについてはリスクやコントロールとともに、財務諸表を作成するための要件（アサーション）が含まれていることが望ましいと思われます。

また、一度これらのルールやドキュメントを作成したとしても、企業が上場している限り、監査は毎年繰り返されます。もちろん最初の労力と比べれば作業の量は減りますが、それでも一度構築して終わりではないということは認識しておくべきでしょう。

IT統制のやり方

IT統制とは、ITシステムに関するコントロールのことです。内部統制の基本的要素の一つとして「ITへの対応」が挙げられているため、内部統制の一部としてIT統制も必要になります。ここでいうITとは社内システムだけでなく、もしあなたの会社が主力となるWebサービスを展開していた場合、そのWebサービスも対象になります。

さらに、このIT統制は「IT全社統制」、「IT全般統制」、「IT業務処理統制」の3つに分けられます。この中でも特に重要なのは「IT全般統制」と「IT業務処理統制」です。

IT全社統制

IT全社統制とは、「全社的な内部統制」の一環として会社及び連結グループで実施される統制で、IT全般統制、IT業務処理統制を支える根幹となるものです。

具体的には、内部統制全体にとって必要なIT戦略や方針の策定、リスクの考慮といった経営レベルでのコントロールが該当します。IT全社統制はIT統制担当者が直接的に意識することはあまりありませんが、もし経営陣がITについて詳しくなさそうなら相談に乗ってあげましょう。

IT全般統制

IT全般統制（ITGC: IT General Control）とは、IT業務処理統制が有効に機能する環境を保証するための統制活動を指します。

言い換えると、システムの運用に関する統制がこのIT全般統制であり、具体的には、権限管理は適切か、テストは実施されているか、バックアップは取られているか、システム開発のフローが適切に定められており、勝手にリスクのあるコードが本番反映されることはないかなどが確認されます。

「実施基準」では、IT全般統制の具体例として以下の項目が挙げられています。
・システムの開発、保守に係る管理
・システムの運用・管理
・内外からのアクセス管理などシステムの安全性の確保
・外部委託に関する契約の管理

また、詳細については、日本公認会計士協会が発表するIT委員会実務指針第6号「ITを利用した情報システムに関する重要な虚偽表示リスクの識別と評価及び評価したリスクに対応する監査人の手続について」、及びIT委員会研究報告第46号「重要な虚偽表示リスクと全般統制の評価」などに記載があります。

これらの資料をベースに、IT全般統制用のRCMを作成し、システム開発規程や情報セキュリティ管理規程なども引用しながら、具体的なリスク及び統制フローを埋めていくと良いでしょう。

IT業務処理統制

IT業務処理統制（ITAC: IT Application Control）とは、業務を管理するシステムにおいて、承認された業務が全て正確に処理、記録されることを確保するために業務プロセスに組み込まれた統制を指します。

IT全般統制が運用統制なら、このIT業務処理統制はアプリケーションレイヤにおける統制を意味します。ちなみに、このIT業務処理統制の対象になるのは、財務報告の信頼性に係る業務処理のみです。

IT全般統制と同様、IT業務処理統制についても「実施基準」に以下の具体例が挙げられています。
・入力情報の完全性、正確性、正当性等を確保する統制
・例外処理（エラー）の修正と再処理
・マスタ・データの維持管理
・システムの利用に関する認証、操作範囲の限定などのアクセス管理

また、日本公認会計士協会IT委員会研究報告47号「業務処理統制に関する評価手続」にて詳細が例示されています。IT業務処理統制は財務報告の信頼性に直結するため、非常に重要な統制です。

こちらについてもRCMをベースにしつつ、各統制に対してシステムを用いて自動化するべきところは自動化していきます。

内部統制のポイント

ここからは、実際に内部統制を行う上での陥りやすいアンチパターンや統制のポイントについて説明していきます。

会社一丸となって取り組む

内部統制は一見何の付加価値もない、誰にでもできる仕事に見えるため、窓際社員（という言い方は好きではないですが）がアサインされるケースも多々あるそうです。しかし、内部統制は失敗するとコストだけが膨れ上がり、余計なプロセスが増え、現場は混乱し、企業価値を大きく毀損しかねないリスクを孕んでいます。内部統制を進める際はきちんとプロジェクト化し、経営陣から経理、システム担当などの各部署のキーマンをアサインして密にコミュニケーションを取りながら進めることが重要です。

経験者を活用する

内部統制について勉強することは言うまでもなく大切ですが、私のような素人がいくら本やインターネットで勉強したとしても、実際の感覚を知らないため、監査法人と対峙する際にはどうしてもわからないところが出てきます。一般的にはどうなのか、他の会社はどうなのか、この統制はやり過ぎなのか、もっと上手いやり方はないのかなどです。
社内でも外部でも良いですが、実際に監査法人とやり取りした経験があり、幅広い実務感覚を持っている公認会計士がいると、内部統制をスムーズに進めることができます。

監査法人を頼みの綱にしない

上述したように、J-SOXの大きな特徴としてインダイレクトレポーティングを採用している点があります。また、公認会計士法などでは監査の独立性が強く謳われています。つまり、J-SOXにおいて、仕組み上監査法人は内部統制評価作業を手伝うことはできません。
よくあるアンチパターンとして、これを知らずに何でもかんでも監査法人に質問してしまい、一向に統制が終わらないケースがあります。
監査法人は立場上直接的なアドバイスはできないため、当たり障りのない回答しか言えないですし、そもそもSOX法が生まれた背景を考えれば、より保守的な回答になるのは当然です。
そうではなく、主体的に統制を組んでこちらから説明する姿勢が重要になってきます。質問するにしても、オープンクエスチョン（丸投げの質問）は避け、極力こちらから提案した内容を協議する形が好ましいでしょう。

統制の範囲を絞る

もう一つのよくあるアンチパターンとして、評価範囲を広げすぎるケースがあります。基本的に、一度評価範囲と定めて監査法人と合意した内容は翌年以降も引き継がれるため、不必要に評価範囲を広げてしまうと、対応コストが莫大になるリスクがあります。これを避けるために、初期の段階で適切に評価範囲を絞ることが重要です。
よく勘違いされていますが、J-SOXが対象にしているのは、内部統制の4つの目的のうち「財務報告の信頼性」のみです。ですので、他の「業務の有効性及び効率性」、「事業活動に関わる法令等の遵守」、「資産の保全」はどれだけビジネス上重要な内部統制であったとしても、財務報告の信頼性に影響しなければ評価対象から省くことができます。
もちろん、上記の内部統制を行うことも企業全体のガバナンスやビジネスリスクを考えると重要ですが、少なくともJ-SOX対応においては不要なため、きちんと優先順位をつけ、監査法人に説明する際はここを意識しておく必要があります。
また、IT統制についても、軽微な文言変更やバグ修正にまで重厚なフローを適用していてはとても業務が回りませんし、その必要はありません。上記の財務報告の信頼性に直結するかどうかを基準としつつ、例えばITILの「標準的な変更」、「通常の変更」、「緊急の変更」などを引用し、リスクが少ない変更については「標準的な変更」としてプロセスを簡略化していくことが重要です。

手動統制も併用する

これもたまに勘違いされていますが、IT統制 = 業務処理プロセス全てを完全に自動化することではありません。たとえ手動であったとしても、きちんと統制が取れていれば問題ないですし、人の手とシステムを併用したIT依存統制や、スプレッドシートなどのEUC統制も選択肢としてはあり得ます。この点を理解しつつ、初めは手動統制で構築し後々自動化を検討することも視野に入れると良いでしょう。

監査法人と同じプロトコルで話す

エンジニアからすると、システム同士が同じプロトコルで話さないと当然通信できないと思うのですが、これは監査対応においても当てはまります。
内部統制監査に出てくる概念や用語は非常に専門的であるため、ここを理解した上で監査法人と向き合うことが重要です。
内部統制についての一通りの資料を読み込んだ上で、可能であれば会計知識も身につけ、既存の文脈やフレームワークに乗っかって話すと非常にスムーズにやり取りを進めることができます。逆にそれをしないと、全く話が噛み合わず、内部統制対応はどんどん遅延していくことになります。

最新の技術やフレームワークについては、統制側面から論理的に説明する

はじめに触れた「20年前のエンタープライズ企業を想定しているようなチェックリスト」にどう向き合えば良いかですが、答えとしては「監査法人が見慣れているRCMなどのフレームワークに沿って回答し、補足としてアジャイルやクラウド、DevOpsなどの面から説明する」です。
日本のJ-SOX及び各種基準などの資料は記述が古く、最新の技術やフレームワークを反映していないように見えます。しかし、全く反映されていないわけではありません。
例えば、アジャイルについては最近のシステム監査基準及びシステム管理基準に記載があり、監査においては「アジャイル開発手法の本来の意義を損なわないように留意しつつ、監査実施のタイミング、サイクル、作業負荷、及び 監査証拠の範囲･種類などを特定して計画を立案する」べきとされています。また、ドキュメントについてもホワイトボードや付箋なども資料として活用できるとあります。
さらに「クラウドコンピューティングサービスを利用するような場合には、 システム監査自体を実施することが困難なケースがあることに留意する」との記載もあり、監査法人に対してもアジャイルやクラウドを用いた環境については柔軟に監査対応を行うことが求められているのです。
日本における内部統制資料は、グローバルな潮流を踏まえた上で定期的にアップデートされています。ですので、最新の世界状況を参照して説明を試みるのも有益です。
例えば、「State of DevOps Report」によると、変更諮問委員会（CAB: Change Advisory Board）の有無とシステムの安定性との間に相関関係はないとされています。

おわりに

以上、簡単ではありますがIT統制及び内部統制の概要とポイントについて解説してみました。本来はもっと深掘って説明したかったのですが、それをやると一冊の本になってしまうので、、笑

IT統制はポイントを抑えれば決して難しい作業ではありません。権限管理が適切になされ、テストも実施されており、バックアップは取られ、システム開発のフローが適切に定められた上で勝手にリスクのあるコードが本番反映されることがない状況は良いに決まっています。あくまでも過剰な統制や間違った統制が問題なのです。

まとめるとIT統制とは、本来当然行うべき対応について、内部統制の文脈を理解した上で、監査法人と同じ言葉で構築、説明していく作業であるといえます。ただそれだけなのです。


この記事が気に入ったらサポートをしてみませんか？