詳解: IT統制とIT監査
本記事の位置づけ
IT統制やIT監査に係る本のうち、業務処理統制側との繋がりにフォーカスしたものが少ないような気がするというお気持ちツイート（ポスト）をしたところ、想定外に反応が多かったので、僭越ながら自分で書いてみることにしました。
IT統制の本、ITACの類型やITGCの具体的な中身を説明してるものは数多あるんですが、肝心のITACの識別〜ITGC評価範囲の特定のところが充実してるものは見かけない気がします
— NFSQ (@NF_SQ_08) November 5, 2023
実務上、会計士とIT監査人の双方がお互いに任せてしまいがちな部分ですし、需要はありそうな気がするんですが…
IT統制に係る説明では、例えば「ITGCはプログラム開発・変更、運用管理、アクセス管理、委託先管理を見るべし」のような、コントロールベースチックなものが多いように感じているので、そもそもの考え方や理念に遡及できるような記事にできればよいなと思っています。ちょっと長いですが、ぜひお付き合いください。
監査人の方は日々の業務の参考に、被監査側の方は監査人の視点を覗き見る記事としてご覧ください。
ご感想やご意見、誤りの指摘大歓迎です！
noteのコメント機能を有効にしていないので、ぜひX（@NF_SQ_08）にご意見お寄せください。
※この記事に記載の内容はすべて個人の見解であり、現在または過去に所属した組織の意見を代表するものではありません。また、本記事に記載の内容を踏まえて内部統制を整備・評価・監査したとしても、会計基準や監査法人の内部基準、および各種監査基準の要求が満たされることを保証しない点をご了承ください。
IT統制の目的
内部統制の目的
改めて述べるまでもないことですが、IT統制は内部統制の構成要素ですから、当然内部統制の目的の中にIT統制も位置付けられることになります。
内部統制活動は、企業が直面するリスクを適切に管理し、事業価値の向上に資するリスク対応（ポジティブなリスクへの挑戦とネガティブなリスクの抑制）を実現するために導入される、リスクマネジメントの構成要素の一部です。
したがって、内部統制の目的を正しく理解するためにはリスクマネジメントの全体像を把握することが有用です。COSO ERMフレームワークでは、リスクマネジメントの全体像を次のように図示しています。
また、ERMの定義については、「組織が価値を創造し、維持し、実現する過程においてリスクを管理するために依拠する、戦略策定ならびに実行と一体化したカルチャー、能力、実務」であるとされています。（訳文をPwC View’s Vol.12 Jan, 2018 より引用）
このフレームワークの説明の詳細を説明すると、それだけでも1冊の本になってしまいますのでここでは深く踏み込みませんが、重要なのは一番左に「MISSION VISION. ＆ CORE VALUES」が位置付けられており、そのための「BUSINESS OBJECTIVE」であって、リスクマネジメントによってそれらの達成を支えることで「ENHANCED VALUE」が実現されると記されている点です。
言い換えると、内部統制活動を含むリスクマネジメントは自己目的的であってはならず、あくまでビジョンやミッションの達成のための手段であることを念頭に置く必要があります。コンプライアンス領域の方が、経営者に対してインパクトのある示唆を提示するためには、こうした視線が極めて重要なのではないでしょうか。
IT統制の目的
IT統制の目的はと問われると、情報セキュリティ（可用性、完全性、機密性）を保持すること回答するのが一般的かと思います。もちろんその回答も正しいですし、情報システムが社会基盤の一部と認識されている今日においては、情報セキュリティの担保の必要性は改めて議論するまでもないものなのかもしれません。
しかしながら、改めて考えてみると、例えば財務報告の信頼性を担保する目的でIT統制を整備するときと個人情報の保護を目的としてIT統制を整備するときで機密性の重要性は同程度でしょうか。あるいは、SaaS事業者と不動産会社でシステムの可用性の重要度は同程度でしょうか。
こうした問いに根拠をもって回答するためには、情報セキュリティが損なわれたときに具体的にどのような損害や業務支障が生じるのかを検討する必要があります。したがって、IT統制の整備・運用・評価においても統制の構築を自己目的化することなく、統制の導入によってコントロールしたいリスクがなんであるのかを意識することが重要になります。
COSO（2017）では既にCOSO CUBEが廃止されてしまっているためあくまで考え方の参考という位置付けにはなりますが、IT統制は自己目的的に導入するものではないという観点は日本版COSO CUBEを参照するとイメージしやすいかもしれません。ITへの対応が内部統制の目的ではなく内部統制の基本的要素の一つとして描かれていることを確認できます。
IT統制整備のアプローチ
IT統制に限らず、統制整備のアプローチはコントロールベースアプローチとリスクベースアプローチに大別されます。改訂監基報315号でリスク検討の重要性が強調されたように、昨今のトレンドはリスクベースアプローチを重視する方向にありますが、あらためて両者を比較してみましょう。
コントロールベースアプローチ
ガイドラインやチェックリストなど、あらかじめ一覧化された要求項目に沿って統制を整備するアプローチを指します。日本においてよくチェックリスト的に利用されるガイドラインとしては個人情報の保護に関する法律に関するガイドラインやFISCの安全対策基準などが挙げられます。
コントロールベースアプローチの長所としては、法令への準拠性を担保するうえで漏れが生じにくいこと、対外的説明責任を果たしやすいこと、専門的な知見を有する人員を確保できない場合においても最低限必要な統制を整備できることなどが挙げられます。
一方で短所としては、要求項目のすべてに対して一様に対応することで費用対効果が悪化することや、基準への準拠が自己目的化してしまうこと、基準でカバーされていないリスクが検討されずに放置されやすいことなどが挙げられます。実際、新興のリスクへの対応を進言しても「基準に書いてないからやらなくてよい（余計な対応である）」と判断されてしまうといった経験をお持ちの方もいるのではないでしょうか。
リスクベースアプローチ
包括的なリスクアセスメントを起点として、重要性の高いリスクから優先的に対応していくアプローチを指します。リスクベースアプローチの手法はCOSOやCOBITなどで紹介されており、そうしたフレームワークを参照しながら具体的な統制内容を検討していくことになります。
リスクベースアプローチの長所としては、うまく導入できれば費用対効果に優れること、リスクアセスメントを必ず実施するためリスク状況をより正確に把握できること、環境の変化に応じて柔軟にリスク戦略を更新できることなどが挙げられます。
一方で短所としては、有効なリスクアセスメントには専門性が求められること、リスクに応じた統制を一から検討しなければならず時間と労力を要することなどが挙げられます。実際、基準やガイドラインを読みながら、「リスクベースアプローチが重要なのはわかったけど、結局何をやればいいんですか？！」となった経験をお持ちの方もいるのではないでしょうか。
結局どちらを採用すればよいのか
冒頭でも述べた通り、仮にこれが試験問題なのであれば「リスクベースアプローチを採用すべき」が正解になると思います。
コントロールベースアプローチの項目で紹介したFISC安全対策基準（第9版）もリスクベースアプローチの必要性が記載されていますし、現在コントロールベースアプローチのベースラインとして利用されているガイドライン群も、本質的にはリスクベースアプローチを指向しているものが多いのではないかともいます。
ガイドラインを参照しながらリスクアセスメントを実施してリスクの洗い出し、統制の整備と進めていくのが理想的ではありますが、ゼロベースで検討を進めるのはやはり現実的ではありません。
リスクアセスメントの実務においては、むしろ逆向きのアプローチが一般的なのではないかと思います。つまり、ガイドラインを出発点として、組織の実情に鑑みて過剰なものは削減し、組織固有の要因に起因するリスクへの対応を追加することで、既存のガイドラインをカスタマイズするアプローチです。統制目的を踏まて複数のガイドラインを融合させたものをベースラインにすることもあります。
いわばコントロールベースとリスクベースのハイブリッドのようなアプローチですが、こうしたアプローチを採用する場合には、ガイドラインの要求事項の根拠となっているリスクを十分に理解することが重要です。各リスクが組織にどの程度影響するのかを検討し、リスクの重要性に応じて統制活動に係るリソースを按分することで、先人の知恵の結晶であるガイドラインをベースにしながら効率的にリスクベースアプローチを導入できるのではないでしょうか。
IT監査の類型
保証業務とは：合理的保証、限定的保証、AUP
監査という言葉からまず連想されるのは、多くの人にとって財務諸表監査なのではないかと思います。財務諸表監査は会計監査人が独立した第三者として、被監査会社が作成した財務諸表に重要な虚偽表示がないことに対する積極的な保証を与えるものですが、そもそも「保証」とは何でしょうか。
JICPAのサイトでは次のように説明されています。
保証業務とは、適合する規準①によって主題②を測定又は評価した結果である主題情報③に信頼性を付与することを目的として、業務実施者④が、十分かつ適切な証拠を入手し、想定利用者（主題に責任を負う者を除く。）⑤に対して、主題情報⑥に関する結論を報告する業務をいいます。
大意としては、ある主体が報告した内容（主題情報）が信頼に足るものかどうかについて第三者としての意見を表明するものといえるかと思います。
引用元のサイトでも紹介されている通り、意見の表明の水準にはいくつかレベルがあり、「適正に表示されている」などの積極的保証（合理的保証）、「適正でないと判断する要素は見当たらなかった」などの消極的保証（限定的保証）のほかに、実施した手続と確認した事実を報告するのみで意見は表明しないAUP（合意された手続業務）が存在し、監査人による検証の深度が大いに異なります。
後続で紹介するように、IT関係で「監査」と呼ばれる業務には多様なものがあるのですが、実際の保証水準が積極的保証なのか消極的保証なのか、あるいは保証を与えるものではないのかを見極めることが重要です。会計監査人であれば、「監査」は積極的保証、「レビュー」は消極的保証といったように用語を使い分けることが多いかと思いますが、情報発信者がこうした慣行に従っているとは限らないため個別の確認が必要です。
「監査」と名の付くものすべてが財務諸表監査と同水準の検証を必要とするものではないという点については、下記の記事でも紹介しているのでよろしければご参照ください。
財務諸表監査におけるIT監査
財務諸表における内部統制の評価の一環として実施されるIT統制の評価は、IT監査やシステムレビューなどと呼ばれます。財務諸表監査自体が積極的保証を与えるものですから、その一環として行われるIT監査についても同様の水準で検証されることが一般的です。
しかしながら留意しなければならないのは、積極的保証の対象はあくまでも財務報告に重要な虚偽表示が含まれていないことに対してであり、IT統制が有効であることに対してではないことです。SOX監査（内部統制監査）の一環としてIT統制が検証されている場合においても、監査人が意見を表明するのはあくまでも財務報告に係る内部統制全体の有効性に対してであり、IT統制のみを切り出して意見を表明するものではありません。
検証対象も財務報告に関係する領域に限られてくるため、例えば財務諸表監査の一環でIT統制も監査を受けているからという理由で、情報セキュリティ監査を省略するようなことはできないということになります。
SOCレポート
業務受託会社が対外的に内部統制の有効性を示す目的で監査法人に保証を依頼し、その評価結果として監査法人が発行するレポート（保証報告書）をSOCレポートと呼びます。SOCレポートの類型は下図の通りです。
これらのレポートは監査法人による監査を受けており、「報告書の主題」に記載されている統制目的について内部統制の有効性が検証され、監査人がレポートの記載内容について積極的保証を与えるものになります。（だからこそ、財務諸表監査においてSOC1レポートに依拠することができます）
SOCレポートは必ずしもIT領域に限って発行されるものではありませんが、代表的な発行者としてクラウドサービス事業者が挙げられるかと思います。SOC1レポートの範囲がITGCであるような場合には、一見するとセキュリティ目的で発行されているSOC2と内容が重複する部分もあるかもしれません。しかしながら、統制目的に応じて検証される内容が異なることが想定されるため、財務諸表監査目的でSOC2を利用する、セキュリティ監査目的でSOC1を利用するといったことは推奨されず、どうしてもやむを得ない場合であっても十分な注意が必要になります。
認証制度における準拠性監査
認証制度によっては、申請にあたって第三者による検証結果の報告が求められます。代表的な例としてはISMS認証やISMAP認証が挙げられます。
こうした認証制度への対応を目的とした準拠性の監査ないしレビューの深度は認証制度ごとに異なります。例えばISMS認証では規定類の確認が主である一方で、ISMAP認証であれば統制の運用状況も含めて検証されます。
また、あくまで認証制度が要求する項目についての検証になるため、何が検証されていて何が検証されていないかを個別に確認する必要があります。
やや話はそれますが、認証を取得する会社のおいては、仮に認証が要求する検査が規定類の検証のみであるような場合においても、内部監査機能などを活用して実効性をもって統制が運用されていることを定期的に自主点検することが推奨されます。そうした活動によって、認証対応が形骸化して認証のための認証となってしまうことを予防できるとともに、認証更新対応がスムーズに行えることも期待されます。
法制度に基づく認証（事業ライセンスの付与など）の条件として、制度によって定められた項目を外部監査人が検証しなければされないとされているようなケースもあり、そうしたケースはAUPと区分されること想定されます。暗号資産交換事業者の分別管理に係るAUPが例として挙げられますが、国によっては税務恩典を利用するための条件としてAUP結果の提出を求めているケースもあります。
任意監査としてのシステム監査
法制度や認証の要求がない場合であっても、情報システムの安定かつ安全な運用の維持を目的として定期的に統制の運用状況を評価するようなケースや、公知のガイドラインや社内規定に従ってシステムが管理運用されていることを確認する自主点検として準拠性監査を実施するようなケースがあります。
ある程度以上の規模の会社であれば、情報システム管理規定などで内部監査人または外部監査人による定期的な監査の必要性が定義されているのではないでしょうか。こちらについても保証水準は監査目的次第であり、例えば外部関係者に対して情報システムの管理状況の有効性に係る説明責任を果たさなければならないような場合には外部監査人による保証を求めることになるでしょうし、あくまで広義の内部統制活動の一環であれば内部監査による検証結果を内部でのリスク分析に活用するということも考えられます。
すべてのシステムを監査対象とすることは現実的ではないため、重要性の高いシステムを順次選定して監査対象としていくことになりますが、監査項目については選定されたシステム固有の状況を加味してカスタマイズする必要があります。
例えば、システム管理基準やシステム監査基準をベースラインにしながら、個人情報を有するシステムについては個人情報保護法の観点を追加したり、事業継続上の重要性が高いシステムにおいてはBCPの観点を追加したりといった調整が考えられます。
ただし、システム監査においては内部統制の有効性を検証することになりますので、財務諸表監査のように実証手続によって強力な心象を得ることは現実的ではなく、積極的保証を与えることは通常想定されません。
あくまで監査目的に応じた手続きを設定し、その範囲内で重要なリスクが識別されたかどうかについての意見を表明する消極的保証にとどまるものと想定されます。
プロジェクト監査
情報システムの新規導入や更改がスムーズに行われるように、プロジェクトと並走してプロジェクト管理上の課題を適時い検知・改善していくための監査、もしくは完了したプロジェクトが適切な管理下にあったのかを事後的に検証するための監査を指してプロジェクト監査と呼んだりします。
前者の場合にはThree Line Defenseにおける第三線の役割、後者の場合には炎上案件の調査報告などの役割を担うことが想定されます。
こちらも任意監査には違いないので、観点としては上述の任意監査としてのシステム監査と同じものが挙げれますが、システム監査はリリース済みのシステムの保守・運用を監査対象としてシステムの安定的な運用を脅かすようなリスクがないかを検証することが一般的であるのに対して、プロジェクト監査においてはシステム開発プロセスやプロジェクトマネジメントの在り方を監査対象としてリリース後の安定的な運用を脅かすリスク要素の検証とともに、システム開発のQCD（品質・コスト・納期）を計画通りに達成できるようによりアジャイルな見直しの材料としていく点に特色があるため、別枠で紹介してみました。
（補論）スマートコントラクトの監査
ブロックチェーンの利活用を検討する企業が増えてくる中で、スマートコントラクトの信頼性が論点となることがあります。本記事執筆時点においては、スマートコントラクトの監査という言葉はセキュリティ面での検証を指すことが一般的であるように思われます。財務諸表監査の一環で行われるITACの検証に相当するものではない可能性が高いため、財務諸表監査の一環として依拠を検討する場合には安易に依拠することなく監査のスコープを確認することが重要になります。
セキュリティの専門家による脆弱性のレビューのほかに、コンペ形式で不特定多数の開発者にレビューをしてもらうような仕組みも出てきており、レビューの新しい形が生まれつつあるように思えます。
※この仕組みについてはCodeFoxさんのこちらの記事が参考になります。
現在の保証の考え方の中では、不特定多数によるレビューの結果に依拠する（保証業務によって検証されたものと同程度の白井精があると認める）ことは現実的ではないかと思いますが、もしかしたら、こうしたインセンティブ設計に基づくレビューによって与えられる保証の程度について、今後新しい議論が生まれてくるのかもしれません。
財務諸表監査におけるIT監査の全体像
監査基準
財務諸表監査の一部として実施される手続ですから、一般に公正妥当と認められる監査の基準に沿って手続きを実施することになります。
なお、JICPAは一般に公正妥当と認められる監査の基準を次のように説明しています。
企業会計審議会により定められた「監査基準」、「監査に関する品質管理基準」、「監査における不正リスク対応基準」及び公認会計士協会の「監査実務指針」をいう。
「監査基準」は、全ての公認会計士が財務諸表監査において準拠すべきもので、「監査の目的」「一般基準」「実施基準」「報告基準」により構成されている。
IT監査に係る要素は、これら基準の構成要素として各所に記載されています。例えば、監査基準報告315号にはIT環境に係るリスク評価が含まれていますし、ITリスクへの対応への詳細についてはＩＴ委員会研究報告第57号「ＩＴの利用の理解並びにＩＴの利用から生じるリスクの識別及び対応に関する監査人の手続に係るＱ＆Ａ」などが公表されています。特に研究報告第57号は情報処理統制の評価に関して具体的な指針を示しており、手続きのイメージが付きやすいのではないでしょうか。
また、監査基準ではありませんが、IT全般統制に係るJ-SOX対応に資する情報を事業会社に提供する資料として、経済産業省よりシステム監査基準追補版が公表されています。あくまで事業会社が内部統制を整備する際に参考にする情報という位置づけですが、IT全般統制における評価観点を確認するうえでも参考になるかと思います。
被監査会社によるITへの依拠の特定
IT統制に関する解説においては、IT業務処理統制をIT全般統制が支え、IT全般統制をIT全社統制が支えると説明されます。これ自体は間違いなく正しいのですが、IT統制の評価にあたって、「なるほど、IT全社統制を理解してIT全般統制の評価に反映、その結果をさらにIT業務処理統制の評価に反映するれ場佳いのか」と理解するのは危険です。考え自体は正しいのですが、それだけで完結してしまうと検討事項が不足していしまいます。（特にIT統制の評価から監査に入った方はこうした考えに陥りがちかもしれません）
ここまでお読みくださった方であればすでにお気づきかもしれませんが、こうした理解には監査の目的、すなわち、「財務諸表の信頼性を検証する目的で」という要素が決定的に欠落しています。
そもそも会社が財務諸表作成の観点においてITに依拠しているとは、財務数値の処理にITを利用しているということであり、ビジネスプロセスの中にITが組み込まれていることを意味します。したがって、IT統制の重要性はビジネスプロセスの重要性に紐づけてのみ検討することができるといえます。これこそが、IT監査人が業務プロセスを理解し、会計監査人がITを理解しなければいけない理由です。
会社のビジネスを中心に会計とITがつながっており、会計上の重要性の中でIT統制の評価範囲が検討され、そのうえで前述の通りIT全社統制やIT全般統制の状況を踏まえてIT業務処理統制を評価することになります。全体像をまとめると、下図の通りになります。
詳細は後述しますが、ここでは基幹システムから会計システムへのインターフェースが財務数値の作成上重要なIT統制（ITAC）であり、会社は当該処理に関してITに依拠しているといえます。
監査計画におけるITへの依拠の特定
会社のビジネスプロセスを起点に財務数値の作成におけるITへの依拠を識別する方法を述べてきました。
SOX監査（内部統制監査）であればITへの依拠が識別されてそれが重要である（キーコントロールである）場合には評価範囲に含めるべきでしょう。
一方で、財務諸表監査目的のみである場合、費用対効果をより慎重に検討する必要があります。先ほどの全体像の図を見てみると、インターフェースの評価１つのためにITGCの評価対象が2システム増え、IT全社統制も評価対象となっています。IT統制を評価したことがある方なら想像がつくかと思いますが、これはそれなりに時間と労力を要します。
仮にほかにITへの依拠が存在せず、かつデータ量・データ形式を検討したときに、基幹システムと会計システムから１年分のデータをすべて抽出して突合することが現実的に可能なのであれば、IT統制に依拠することなくデータを突合して差異がないことを検証するほうが効率的かもしれません。言い換えると、会社が依拠するIT統制を識別したうえで、IT統制そのものを評価するのではなく、IT統制の有効性を実証的に検証する手続きです。基幹システム側のデータが改ざんされていないことの検証は当然必要ですが、データベースアクセスのみを評価対象とする、あるいは直接外部証憑と突合して買い残がないことの心証を得るなどの手続きを加えても、ITGCを2システム分フルスコープで評価するよりは効率的であると想定されます。
ここまで会社が依拠するITの機能を監査人が評価しないというパターンについて述べてきましたが、逆のパターンについても検討が必要です。すなわち、会社が依拠しないITの機能に監査人のみが依拠するケースです。
例えば返品処理に係る実証手続にあたって、基幹システムから「返品一覧」という帳票を母集団資料として出力することを考えましょう。会社は内部統制上この一覧を利用しておらず、母集団情報を取得する目的で基幹システムから監査のためにSQLで取得したデータであるとします。
この時、監査人は「返品一覧」の網羅性や正確性に依拠していることになり、出力機能と基幹システム上場のデータの信頼性というITの機能に依拠していることになります。したがって、監査人は「返品一覧」の信頼性を検証しなければこれを母集団資料として利用することができません。
検証の方法はITGCの評価だけでなく外部証憑との突合など様々な選択肢がありますが、こうした監査人による依拠についてももれなく考慮してIT統制の評価手続きを設計することが必要です。
このように、会社によるITの依拠をベースに、監査人によるITへの依拠範囲を費用対効果も踏まえながら検討することが必要です。
会社のRCMからIT統制を抽出し「会社のRCMに書いてない」という理由でITACが見落とされるようなケースをしばしば目にしますが、監査人は（特にSOXであれば）RCMも含めて評価すべきであり、監査計画がRCMに依拠するようなことがあってはなりません。業務部門で作成するRCMがIT統制について詳述していることはむしろ少ないということを念頭に、丁寧なウォークスルーを通じてITの要素を識別し、そのそれぞれについて評価の要否並びに評価アプローチを検討することで、会社・監査人のそれぞれが依拠するITの機能を識別できるようになるのではないでしょうか。
ITへの依拠を支える情報処理統制の特定
改訂監基報315では、従来の自動化された業務処理統制（ITAC）という表現に代わって、「情報処理統制」という言葉が使われています。これは自動化統制よりもより広い範囲を包含する用語なのですが、まずは監査基準報告書315実務ガイダンス第１号「ＩＴの利用の理解並びにＩＴの利用から生じるリスクの識別及び対応に関する監査人の手続に係るＱ＆Ａ（実務ガイダンス）」の解説（A4）を見てみましょう。（IT研究委員会57号とほぼ同内容ですが、最終更新日がこちらのほうが新しいようです）
企業の統制活動における内部統制には、情報処理統制とＩＴ全般統制が含まれます（監基報315付録３第20項）。
情報処理統制とは、情報のインテグリティ（すなわち、取引及びその他の情報（データ）の網羅性、正確性、正当性）のリスクに直接対応する、企業の情報システムにおけるＩＴアプリケーションの情報処理又は手作業による情報処理に関連した内部統制です（監基報315第11項(9)）。
また、情報処理統制は、企業の情報に関する方針が有効に適用されるための処理又は手続であり、自動化されている場合（すなわち、ＩＴアプリケーションに組み込まれている。）と手作業の場合（例えば、インプット又はアウトプットに係る内部統制）があり、他の情報処理統制やＩＴ全般統制を含む他の内部統制に依拠することがあるとされています（監基報315のA5項）。
決して新しい観点が増えたわけではなく、実務上はこれまでも検討・対応されていた観点ではある（もしくはされているべきであった観点ではある）のですが、この解説だけでわかる人はおそらくもともと理解されている方だけなのではないかという気がします。
重要なのは太字の部分です。ITACの検討においては、「自動化統制」という名前の通り、自動処理にフォーカスした検討・検証がなされる傾向にありましたが、そもそも情報システムの中で処理されるデータはシステムの中で自動的に生成されたものではなく、その入り口としては外部から入力されてきたものであることを考えると、自動化された部分だけを検証するだけでは不十分であることがわかります。
この観点は、同ガイダンスA20にて次の通りに解説されています。少し長いですが、重要な内容なのでそのまま引用します。
１．企業が作成した情報
企業が作成した情報は、監査人の利用目的に照らして「企業が内部統制において利用する情報」と「監査人が監査証拠として実証手続において利用する情報」に大別することができます。企業が作成した情報は、元データ・ロジック・パラメータによって生成されており、利用目的の如何を問わず、情報のインテグリティの担保が重要となります。
２．監査手続
・ＩＴアプリケーションの理解、元データの特定企業が作成した情報がＩＴアプリケーションによって作成されている場合、監査人はまず、情報がＩＴアプリケーション内のどのデータに基づいて作成されているかという点につき理解します。
・ＩＴアプリケーションの処理の理解・検証
監査人は仕様書の閲覧などにより、情報の作成に関するＩＴアプリケーションの処理機能を把握し、そのロジックが目的に照らして適切であるか否かを確かめます。
・元データの信頼性（正確性、網羅性、正当性）
監査人は元データと総勘定元帳や補助元帳などの数値との突合を行い、その正確性、網羅性を確かめます。また、非財務情報についても、外部証憑と突合するなど、その正確性を確かめる点にも留意します。上記の他、データの作成プロセスを理解することで、そのデータが承認を得た正当なデータであることを確かめることもあります。
・入力パラメータの正確性
情報の作成に当たって、パラメータを手入力で設定する場合は、入力されたパラメータが目的に照らして適切であるか否かを確かめます。上記理解を確認するためには、データのインプットから情報作成までのプロセスの再実施を行うことが有効です。また、企業が作成情報の正確性や網羅性の維持に関連する内部統制を構築している場合は、その内部統制を識別・評価します。
情報はシステムに入力（Input）され、処理（Process）され、出力（Output）されて初めて有効に活用されるものであり、完全に自動化されている部分はこのプロセス全体の一部にすぎません。「情報処理統制」は、こうした観点を含めた用語であり、入力・処理・出力の一貫した流れの信頼性を担保するための統制、すなわち元データ・ロジック・パラメータのすべてについて誤りが生じないようにするための統制を指しているといえます。
前述のインターフェースを例にすれば、インターフェースされるデータ、すなわち出荷データの入力作業に係る統制も情報処理統制に含まれることになります。また、インターフェースされた後のデータを売上一覧として出力されているなどがあるのであれば、その出力時にパラメーターを正しく設定するための統制も情報処理統制として検討することになります。
こうした要素をもれなく検討するためには、まずは業務プロセスからシステムへの取り込み、システム内での処理、システム外への出力という一気通貫の流れを、初めから最後までもれなく把握しなければなりません。こうした観点からも、ウォークスルーの時点からIT監査人が積極的に関与するとともに、会計監査人がIT監査人に業務プロセス理解に基づく適切なインストラクションを与えることがますます重要になってきているといえます。
アサーションに基づく検証項目の設定
ここまでの内容で情報処理統制の識別、すなわちITへの依拠及びそれを支える周辺統制を評価に組み込む際の検討事項について述べてきました。本節では、より具体的な検証内容について述べていきます。
例えば先述のインターフェースのおいて、その検証によって確認したい事項は何でしょうか。言い換えると、インターフェースに紐づくリスクは何なのでしょうか。統制はリスクへの対応として導入するものですから、インターフェースを自動化統制として識別するのであれば当然対応するリスクが事前に識別されていてしかるべきです。ジュニアスタッフにこうした質問をすると、一番多く帰ってくる答えが「インターフェースが正常に完了せずデータの正確性や網羅性が損なわれるリスク」といった内容のものです。
この回答が間違いとは言いませんが、よくよく考えてみると「インターフェースが失敗したら何が起こるか」という回答にすぎず、結局何が問題なのかがよくわかりません。そこで、さらに続けて「データの正確性や網羅性が損なわれると何が困るのか」と問うてみると、私の経験では少なくない割合が返答に窮していました。これは、例に挙げたような回答をする方の頭の中では、情報処理の文脈での「正確性と網羅性」が、財務報告ないし財務諸表監査におけるアサーションとしての「正確性と網羅性」と混同されており、監査上のアサーションを正しく把握できていないにもかかわらず理解したつもりになってしまっているのだと推測します。
財務諸表監査における内部統制は原則として何かしらのアサーションに紐づけられます。インターフェースをITAC、すなわち自動化された業務処理統制として識別するのであれば、当然それ自身もアサーションに紐づけられていてしかるべきです。
基幹システムに記録された売上が全て正確に会計システムに連携され、適切な期の仕訳として登録されるという流れの一部としてインターフェースが識別されているのであれば、正確性・網羅性・期間配分あたりのアサーションあたりと紐づけられるべきでしょう。そしてここで言う正確性と網羅性は、「情報処理がエラーなく完了することによりデータの完全性が保たれる」と言う意味ではなく、「すべての売上実績が、正確な金額で後続のシステムに取り込まれ、適正な売上仕訳が計上される」と言うことを意味しています。
したがって、元の質問である「インターフェースに紐づくリスクは？」という問いに対しては、「会計システムに売上データを連携する過程でデータの網羅性や完全性が損なわれることで、売上勘定の正確性・網羅性・期間配分の適切性が損なわれるリスク」くらいまで言えるとよいのではないでしょうか。つまり、下図の通りの全体像を理解し、インターフェースの話をしながらも必要に応じて自在に試算表まで遡れるようにしておくことが理想的です。
ここまでリスクを整理できて初めて、インターフェースのテスト手続きを詳細に設計することができます。インターフェースの評価にあたって、連携されているデータ（テーブルデータのカラム）すべてを機械的に突合して検証することは可能ですが、インターフェースの仕組みが複雑になると膨大な工数がかかることになります。この点はのちの章でPCAOB対応を念頭に詳述しますが、簡単な例を挙げると、検証すべきデータ項目が増えると、その分だけ元データの信頼性の検証の手間が増えます。したがって、合理的に検証対象のデータを限定しないと膨大な工数が必要になってしまいます。
この絞り込みの根拠となるのが前述したリスクの理解です。インターフェースが担保したいリスクが売上データの正確性・網羅性・期間配分の適切性なのであれば、検証すべきは出荷額・出荷数量・出荷日あたりのデータであり、その他にも連携されているデータがあったとしても、評価対象には含めなくてもよいかもしれません。こうした観点から、会計監査人はIT監査人に対して、IT監査人の手続に依拠したいアサーションを正確に伝え、検証対象のデータ項目が監査計画に沿ったものとなっていることを確認することが望まれます。
一方でIT監査人には、会計監査人から十分なインストラクションが与えられなかった際に仮説を立てて検証項目を設定し、それによって検証したいアサーションを担保できるのか会計監査人に確認を求めることができる能力が期待されます。よくあるのは、会計監査人から「売上データの検証」というオーダーを受けて金額の正確性と網羅性のみを検証したところ、実は日付データ（出荷日データなど）にも依拠しなければならなかったということが後から発覚するようなケースです。IT監査人もアサーションを理解していれば、期間配分の適切性のアサーションが含まれているのに日付データがインストラクションに含まれていない時点で、会計監査人に注意を促すことができるかもしれません。
また、インターフェースのような機能はバックエンドの仕組みですから、会計監査人や業務部門の担当者も正確な情報を持っていないこともあります。
実際、自動仕訳の仕組みについて会計監査人や業務部門の理解と実際の仕組みが異なるケースはよく見受けられます。業務部門はインターフェースデータを受け取った会計システムにおいて自動仕訳が生成されるものと認識していたものの、実際には基幹システム側で勘定科目も含めて用意しており、会計システムは連携されたデータを内部マッピング表などを参照して適切な科目に割り当てているだけだったというようなものが挙げられます。
こうした認識齟齬を業務プロセスのウォークスルーの過程で識別することはほぼ不可能です。したがって、情報システム部へのヒアリングや実データの検証を通じて、IT監査人がインストラクションと実情の齟齬に気づき、会計監査人及び業務部門に適切に情報共有することが期待されます。
IT全般統制評価対象システムおよび評価範囲の特定
ここまで長々と情報処理統制の話をしてきましたが、ようやくIT全般統制の話に進めます。全般統制の各項目の評価について詳述すると、いよいよ記事が終わらなくなってしまうので、本記事では評価範囲の特定に絞って取り扱います。
IT全般統制の評価範囲（評価対象システム）とは情報処理統制が識別されているシステムであるというのが最もスタンダードな回答であり、「財務報告に係る内部統制の評価及び監査の基準」の「３．財務報告に係る内部統制の評価の方法」「（３）業務プロセスに係る内部統制の評価」「⑤ ＩＴを利用した内部統制の評価 」の図でも概ねそのように示されているようです。
しかし、これで必要充分であると結論付けてしまうと話が終わってしまうので、今回はもう少し踏み込んだ検討をしていきます。
例えば、次のような統制記述を考えてみましょう。
「基幹システムから会計システムに、日次で出荷情報をインターフェースにより自動連係する」
まず、基幹システムと会計システムが評価対象システムの候補として真っ先に上がるでしょう。そして実際、その２つのみを評価対象とし手続を進めることも多いかと思います。
しかしながら厳密に考えると、この「日次で」という部分はいったいどのように担保されているのでしょうか。基幹システムと会計システムの内部機能によってジョブ実行タイミングも制御されているのか、あるいはJP1などのジョブスケジューリングツールを利用しているのか、この統制記述からのみではうかがい知ることができません。
この例のように、IT全般統制の評価に含めるべき、もしくは少なくとも含める必要があるかを検討すべきシステムであるものの、情報処理統制の理解やRCMのレビューの過程で識別されないものが存在します。代表例としては、ジョブ管理ツールとレポーティングツールが挙げられるでしょう。
特に、データ抽出元のシステムを直接参照せず、抽出したデータをもとにビューをツール内に作成し、そこからレポートを出力しているようなツールについては、レポーティングツールとデータソースのシステムの両方を評価対象に含めるべきか、慎重な検討が必要になります。
（特にPCAOBのような厳しい審査が想定される場合には、刺されやすいポイントの一つでもあると思います。）
ちなみに、表現こそ異なっていますが、レポーティングツールの観点は監査基準報告315付録5第11項でも次のように言及されています。
レポート作成機能を備えたＩＴアプリケーションがある一方で、別のレポート作成アプリケーションを利用する企業もある（すなわち、レポートライター）。その場合、ＩＴの利用から生じるリスクの影響を受けるＩＴアプリケーションを決定するために、監査人は、システムから生成されるレポートの源泉を識別する必要がある場合がある（すなわち、レポートを作成するアプリケーションとレポートの生成に使用するデータソース）。
さて、そうした付随的なシステムも含めて評価対象システムを決定した次に考えるべきは、評価対象とする全般統制の具体的な範囲です。先ほどの例を踏襲すれば、基幹システムとジョブ管理ツールの評価範囲が全く同じとなると、費用対効果に疑問符がつくのではないでしょうか。
ジョブ管理ツールのようなパッケージシステムとオンプレミスの基幹システムでは当然評価範囲が異なってきてしかるべきですし、ジョブを利用しない機能しか情報処理統制として識別されていないシステムであれば、ジョブ管理の全般統制を評価対象外にできるかもしれません。
また、財務諸表目的のみの監査において、依拠するプログラムを全て正確に特定できており、タイムスタンプやリリースログの査閲などによってプログラムに変更がないことを十分な信頼性をもって確認できるのであれば、プログラム修正に係る手続を省略ないし簡略化できるかもしれません。
特によく見かけるのが、アプリケーションアクセス制限の情報処理統制が識別されておらず、システムによる職務分掌の実装に依拠していない手続となっているのに、なぜかアプリケーションアクセス権を評価しているようなケースです。アプリケーションアクセス権の評価が本当に不要かどうかという点にももちろん慎重な判断が必要ですが、仮に本当に不要であるのであれば、アプリケーションアクセス権の統制はスコープアウトできるのではないでしょうか。（この点は後続のITAC各論でも詳述します）
このように、IT全般統制の評価においても、統制一つ一つについて「対応するリスクは何か？」を財務数値へのインパクトに紐づけて検討することが重要です。統制内容を裏返してリスクとするのではなく、あくまでリスクが先に来るはずであり、それに紐づけて統制が設計されるということを理解することで、少しでも効率的な監査が実現できるのではないでしょうか。
IT環境およびIT全社統制の理解
私の把握している限りにおいて、監査基準報告315ではIT全社統制という言葉は利用しておらず、IT環境の理解に係る説明として相当する内容に触れています。「財務報告に係る内部統制の評価及び監査の基準」のなかでも「全社統制」の説明はあるもののIT全社統制にフォーカスした説明はなされておらず、「財務報告に係る全社的な内部統制に関する評価項目の例」の中で「ITへの対応」の評価項目が例示されているにとどまっている印象です。
ちなみに、監査基準ではありませんが、「システム管理基準追補版」では用語として「IT全社統制」を明示的に定義しています。
全社的な内部統制は企業全体に広く影響を及ぼし、企業全体を対象とする内部統制であり、基本的には企業集団全体を対象とする内部統制を意味する。
IT全社的統制
企業の統制が全体として有効に機能する環境を保証するためのITに関連する方針と手続等、情報システムを含む内部統制。 連結グループ全体としての統制を前提とするが、各社、事業拠点ごとの全体的な内部統制をさす場合もある。
これらの情報を踏まえてリスクの観点から定義しなおすと、IT環境の特性に起因する全社的なリスクを低減するために導入される統制がIT全社統制であるといえるのではないでしょうか。
そうであるのであれば、IT全般統制の評価範囲が識別されている情報処理統制の種類に応じて変化すべきであるのと同じように、全社統制に求められる要素はIT環境に応じて定められるものであると考えられます。
例えばパッケージシステム1つのみを利用しているような会社であれば、大仰な情報システム管理規定は必要ないかもしれないですし、多数の自社開発システムが複雑に絡み合っているような会社においては、全社的に統一された手順でシステムが管理されるよう、規定の整備及びその遵守状況の確認が求められるかもしれません。
では、そもそもIT環境とは何でしょうか。監査基準報告書315実務ガイダンス第１号「ＩＴの利用の理解並びにＩＴの利用から生じるリスクの識別及び対応に関する監査人の手続に係るＱ＆Ａ（実務ガイダンス）」A6を見てみると、次のように書いてあります。
監査人が実施する企業のＩＴ環境の理解の程度は、一律なものではなく、リスク評価手続における監査人の判断に基づいて、必要かつ十分な範囲と深度で実施することになります。監査基準報告書315第24項によると、監査人は、リスク評価手続を通じて得た、重要な取引種類、勘定残高及び注記事項に関する企業の情報処理活動の理解等により、財務諸表の作成に関する企業の情報システムと伝達を理解しなければならないとされています。
（中略）
情報システムに対する監査人の理解には、企業の情報システムにおける取引の流れや情報処理に関連するＩＴ環境が含まれます。これは、企業がＩＴアプリケーションや関連するその他のＩＴ環境を利用することにより、ＩＴの利用から生じるリスクが高まる場合があるためです（監基報315のA128項参照）。そして、企業のビジネスモデルや当該ビジネスモデルがＩＴをどの程度活用しているかを理解することにより、情報システムにおいて利用が想定されるＩＴの内容と利用の程度についての有用な情報を得られる場合がある（監基報315のA129項参照）とされています。監査人は、ＩＴ環境を理解する際に、情報システムにおける取引の流れや情報処理に関連する特定のＩＴアプリケーション及びその他のＩＴ環境を識別し、その内容や数を理解することに重点を置く場合があります。ＩＴアプリケーションのプログラム変更、又は、取引や情報を処理又は保存するデータベース上でのデータの直接修正により、取引の流れ又は情報システム内の情報が変更されることがある（監基報315のA130項参照）とされています。
さらに、監査人は、重要な取引種類、勘定残高及び注記事項に関連する、企業の情報システムにおける情報の流れを理解するのと同時に、関連するＩＴアプリケーション及びそれを支援するＩＴインフラストラクチャーを識別することがある（監基報315のA131項参照）とされています。
（中略）
なお、監査基準報告書315付録５第４項において、ＩＴ環境を理解する際に監査人が考慮する事項の例と、企業の情報システムにおいて用いられるＩＴアプリケーションの複雑性に基づくＩＴ環境の一般的な特性の例が示されています。
長々と書いてありますが、ざっくりと要約すると、「財務報告にかかわる重要な情報処理統制を識別し、関連する情報システムを特定するとともに、識別された各システムの特性を理解したうえで監査手続に反映すべし」というようなことが書かれています。しかし、これだけではここまで述べてきた情報処理統制～IT全般統制の評価範囲の特定の手続についての説明にとどまっているようにも見えます。より具体的な事例が記載されている監査基準報告書315付録５第４項を見てみましょう。
自動化の範囲及びデータの利用に関する事項
・処理手続の自動化の範囲及び自動化された処理手続の複雑性
・情報処理においてシステムが生成するレポートに企業が依拠する範囲
・データの入力方法
・ＩＴは、内部又は外部を問わず、アプリケーション、データベース又は関連するその他のＩＴ環境の間での情報伝達を、システム・インターフェースを通じてどのように実施するか。
・会計記録又はその他の情報がデジタル形式で保存されているかどうか及び保存されたデータの場所を含む、情報システムによって処理されるデジタル形式のデータの量と複雑性
ＩＴアプリケーションやＩＴ基盤に関する事項
・アプリケーションの種類
・ＩＴアプリケーションとその基礎となるＩＴ基盤の性質の複雑性
・第三者によるホスティング又はＩＴのアウトソーシングの有無
・企業が財務報告に影響を与える新技術を利用しているかどうか。
ＩＴプロセスに関する事項
・ＩＴ環境のメンテナンス担当者（セキュリティとＩＴ環境の変更を管理するＩＴサポート人材の数とスキルレベル）
・アクセス権を管理するプロセスの複雑性
・ＩＴ環境に対するセキュリティの複雑性。特にウェブベースの取引又は外部とのインターフェースを含む取引がある場合における、ＩＴアプリケーション、データベース及びその他のＩＴ環境のサイバーリスクに対する脆弱性等
・ＩＴ環境に対するセキュリティの複雑性。特にウェブベースの取引又は外部とのインターフェースを含む取引がある場合における、ＩＴアプリケーション、データベース及びその他のＩＴ環境のサイバーリスクに対する脆弱性等
・ＩＴ環境内の変更の程度（例えば、ＩＴアプリケーションに関連するその他の環境の追加、又はＩＴアプリケーション若しくはそれを支援するＩＴインフラストラクチャーの著しい変更）
・期中に重要なデータ変換があったか。ＩＴ環境の変更があった場合には、その内容と重要性及びデータ変換の有無
添付の表より最左列のみを抜粋
担当者のスキルやセキュリティの観点など、一般的な観点も追加されていますが、やはり評価対象システム毎に個別に検討する事項との重複も多いようです。アクセス権の管理方法などのポリシーは全社的に適用されることが想定されるためここに含まれることに違和感はありませんが、個別のシステムの種類（パッケージ、自社開発など）は評価対象システム毎に異なるものであり、IT環境の要素であることには違いないのですが、やはりIT全般統制の検討において特に考慮すべき事項であるように思われます。
長くなってきてしまいましたが、「財務報告に係る内部統制の評価及び監査の基準」の「財務報告に係る全社的な内部統制に関する評価項目の例」より、「ITへの対応」の項目も確認してみましょう。
・経営者は、ＩＴに関する適切な戦略、計画等を定めているか。
・経営者は、内部統制を整備する際に、ＩＴ環境を適切に理解し、これを踏まえた方針を明確に示しているか。
・経営者は、信頼性のある財務報告の作成という目的の達成に対するリスクを低減するため、手作業及びＩＴを用いた統制の利用領域について、適切に判断しているか。
・ＩＴを用いて統制活動を整備する際には、ＩＴを利用することにより生じる新たなリスクが考慮されているか。
・経営者は、ＩＴに係る全般統制及びＩＴに係る業務処理統制についての方針 及び手続を適切に定めているか。
「ITへの対応」という項目なので当たり前といえば当たり前ですが、こちらはより企業によるIT利活用一般を想定した内容になっています。私見ですが、ここで挙げられている評価項目の評価対象となっている要素こそ、本来IT環境として確認されるべきものであるように思います。
例えば、ITに係る戦略がビジネス戦略に即して策定されていることや、時代の流れに沿った更改計画の検討状況を確認することは、企業がITにどれだけリソースを割き、どのようなリターンを期待しているかを理解することにつながります。仮に何の計画も持っていないような企業であれば、ITに対する感度が低く、したがってIT統制の浸透度合いもあまり期待できないかもしれないというリスク評価につながるかもしれません。
また、ここには記載されていませんが、情報教育やセキュリティ対策への投資の方針や、組織内における情報システム部の立ち位置とった情報も参考になります。特にグループ企業においては、各社が独立した情報システム部門を持っている場合と情報システム部の機能が親会社によって統括されている場合では、内部統制の遵守状況に差があると想定されます。
IT全社統制の評価においては、監基報や内部統制基準に記載されている観点だけでなく、こうした企業がITに向き合うカルチャーを構成するような要素に係る情報も収集することで、リスク水準をより正確に把握できるのではないでしょうか。
なお、近年はサイバーセキュリティリスク評価の要請が強まっていますから、FWやDMZの設置、EDRの設定状況といったリスク低減措置の有無や、NISTやISMSなどの公知のガイドラインに沿ったセキュリティリスクアセスメントの実施状況も合わせて確認できるとよいでしょう。一方で、こうしたリスクならびに統制はあくまで全社的なレベルのものであり、会計システムをはじめとする財務報告にかかわるシステムがランサムウェアなどの被害を受けて適時開示ができなくなるリスクを個別具体的に識別するのであれば、IT全般統制の一部としてバックアップやリストアの統制を評価することも選択肢になります。リスクに応じた手続きを、適切なレイヤに組み込むことが重要です。
IT統制の不備に伴う監査手続の追加
情報処理統制の不備
情報処理統制に不備が識別された場合、その統制に紐づけられたアサーションについて追加的な心証を得るための追加手続が必要になります。特に、自動計算や自動仕訳のような頻繁に実行される処理に誤りがあった場合は、影響金額を正確な把握と財務数値の修正が求められます。
このケースにおいては、IT監査人が発見した事実を正確に会計監査人に連携し、会計監査人から経理部門などの関連部門に報告と修正対応を求めるといった流れが必要になります。また、改善状況の確認においてもIT監査人と会計監査人が連携し、必要に応じて業務部門と情報システム部の連携をサポートする役割を担うことになります。
期中に不備の改善を完了したい場合には、プログラムの改修なども含めたタイムラインを関係者間で早急に調整し、改善並びに改善後の監査に係るスケジュールを作成することが求められます。
IT全般統制の不備
IT全般統制は直接アサーションに紐づけられるものではなく、プログラムの処理の一貫性やデータの完全性の担保を通じて、全般統制に依拠する情報処理統制に紐づけられたアサーションに間接的に影響を及ぼします。
したがって、IT全般統制で不備が識別された場合には、不備の影響がアサーションにまで及んでいるかどうかを確かめることになります。
例えばデータベースアカウントに過剰な権限が付与されるような不備が識別されたとしても、データベースの操作ログなどを通じて過剰な権限が行使された実績がないことを確認できれば、アサーションへの影響は生じていないと結論付けることができます。
このようにIT全般統制の範囲内で追加的な情報を入手して完結させることができれば理想的ですが、十分な心象を得ることができなかった場合には、潜在的に影響を受けうる情報処理統制すべてについて全般統制の不備のもとでも依拠可能であるかを個別に検討し、依拠できないと結論付けた場合には実証手続の拡大や代替的な統制の評価によって監査リスクを低減させることになります。
IT全社統制の不備
IT全社統制はIT全般統制よりもさらにアサーションとの距離が遠いため、不備が識別された場合の影響も必然的に広く浅くなります。
例えば、情報システムの管理に係る手続きが一切定義されておらず、正式に定義されたIT統制が存在していないようなケースが想定されます。
この場合は、個別の情報処理統制への影響を評価するよりも、ITに依拠するという監査計画を根本から見直して実証手続に寄せることを検討するという流れになるでしょう。
一方で、規定類の更新が適時に行われていないケースはどうでしょうか。その場合は、実運用を確認して本来規定に明文化されるべきであったルールが実業務上は既に適用されていることを確認できれば、軽微な不備であり監査計画や情報処理統制への影響は僅少であるという結論も十分に合理的であるように思えます。
あるいは、通常想定されない極端な例ですが、SOX監査（内部統制監査）を試みたところ、内部監査部門がIT統制を取り扱っておらずThree Line Defense における3rd Lineが存在しないであったと言うようなことがあれば、質的重要性から開示すべき重要な不備となるかもしれません。
このように、IT全社統制はアサーションへの距離が遠いがゆえに、万一不備が識別された場合にはより総合的な判断が求められるといえるかもしれません。
IT統制の不備の被監査会社への報告
IT統制における不備のコミュニケーションにおいても、基本的な進め方は業務処理統制の不備と変わりません。しかしながら、とくにIT全般統制においてはアサーションとの紐付きが見えにくく、報告を受けたマネジメントがリスクを過小に認識してしまう傾向があるように思います。
例えば、「プログラム変更管理の承認について、25サンプルのうち1件の承認漏れがありました」と言う報告を受けたとして、「で？」となるのではないでしょうか。あるいは、「プログラム変更の承認が網羅的になされないことで、システムに未承認のプログラム変更が加わるリスクがあります」と報告されたとしても、危機感もあまりなく改善策も見えてこないので、注意するよう周知徹底するといったなんとも形式的な改善策に帰着してしまうかもしれません。（実際、これはよくある話なのではないでしょうか）
報告において事実を伝えることはもちろん重要ですが、より重要なことはその根本原因の特定とそこから得られる示唆をどこまで伝えることができるかではないかと思います。
先ほどのプログラム変更管理の例を用いるのであれば、根本原因が担当者交代により新任スタッフがミスをしてしまった場合と、緊急案件であれば担当者の判断で承認をスキップしてよいという暗黙のルールが存在したという場合ではリスクは当然異なります。
したがって、リスクの報告にあたっては、統制によって担保することが期待されていたリスクをそのまま裏返して伝えるのではなく、根本原因に応じたリスクを伝えて改善策を講じるに資する情報を提供する必要があります。
担当者交代に起因するのであれば引き継ぎ体制の見直しが対応策になるでしょうし、暗黙のルールに起因するのであればルールの明確化と残余リスクに対する事後的な統制の導入が対応策になるでしょう。
報告を受ける側の目線からしても、後者のケースの場合にはほかにも暗黙のルールで運用しているような実態があるかもしれず、規定の形骸化の潜在的なリスクを想定した手続を今後の内部監査手続に組み込んでいくということも検討できるかもしれません。（少々大仰な内容を書いてしまいましたが、リスクを針小棒大に伝えて危機感を煽るようなことはあってはならず、リスクレベルの実態に即した報告をすることが重要であることは言うまでもありません。）
こうした根本原因の分析に基づく改善策の協議、潜在的なリスクの可能性といった内容を議論できると、有意義な報告として被監査会社にも価値を感じてもらえるのではないでしょうか。
財務諸表監査におけるITACの類型と評価観点
ITAC評価の基本観点
ITACの評価において、その類型によらず検討すべき要素として、次の4つが挙げられます。
元データの信頼性
情報処理統制の項での説明の繰り返しになりますが、システムによって処理されるデータは外部から入力されたものであり、入力ミスがあればITACに不備がなくても期待する結果を得ることはできません。
したがって、ITACが処理する客体であるところのデータがどのように入力されており、なぜそれが正当なデータであるといえるかを検討する必要があります。
なお、財務諸表監査目的のみの場合は監査人が元データと外部証憑を直接突合することで確認できますが、SOX監査の場合は、内部統制によって元データの信頼性が担保されていることを確認する必要があり、その統制もITACと合わせてキーコントロールとして識別されるべきということになります。処理パターンの網羅性
統制記述の上では簡潔な記載になっている場合であっても、処理の詳細を追ってみるとフラグに応じて処理が分岐しているようなケースがあります。例えば、売上レポートが海外売上と国内売上の両方を載せており、国内売上はデータをそのままDBから取得して表示している一方で、海外売上は外国通貨建ての売上額と為替データをDBから取得してレポーティング処理の過程で円に換算しているといったものが考えられます。
こうしたときに、「ITACなので1件見ればよし！」として国内売上のみを検証してしまうと、海外売上についての検証が不足してしまうことになります。
したがって、依拠するITACについては処理を一気通貫で理解し、分岐がある場合にはそのすべてのパターンを網羅する前提で評価を進めることが望まれます。評価対象外にする分岐がある場合は、それが監査上依拠しない要素であることを慎重に確認する必要があります。業務要件への準拠性
ITACはあくまで自動化された業務処理統制ですから、業務目的を達成できるような処理が実装されていることが当然求められます。
したがって、会計監査人や業務部門が理解しているITACの処理内容と、IT監査人や情報システム部が理解しているプログラムが実行している実際の処理内容が確かに一致していることも検証の中で確かめる必要があります。（自動計算の項で具体例を挙げて説明します）期中を通じた処理の一貫性
これは言うまでもないことかもしれませんが、プログラムに変更が加わり期中に処理内容が変わってしまえば、その前後で出力内容は変化します。したがって、期中に変更が発生している場合には、その変更がそもそも業務要件に照らして適切なのかを検討するとともに、適切なのであれば変更の前後それぞれについてITACの評価をすることが望まれます。（一方を評価しないケースもありますが、その際は変更内容が依拠する機能に影響するものではないことを十分慎重に確認する必要があります）
これら基礎的な観点に加えて、ITACの類型に応じて求められる個別の論点も確認していきましょう。
キーレポート
キーレポートの評価にあたっては、その出力方法が重要な論点になります。出力方法としては次のパターンが想定されます。
埋め込みプログラムにより制御されており、ユーザは出力ボタンを押す以外の操作はしない、もしくはジョブにより定期的に出力される
埋め込みプログラムではあるものの、一部のパラメーターをユーザーが出力時に指定する必要がある
ユーザが都度クエリ（SQLコマンドやレポーティングツールのカスタムレポート機能など）を作成して帳票をデザインする必要がある
2や3の場合においては、ユーザが指定したパラメーターやクエリが内部統制のデザインに即したものであったのかをどのように担保するのか、あるいは内部統制の実施者がどのように担保しているのかを確認する必要があります。例えば、今年の7月の売上を出力すべきところ誤って去年の同月のデータを出力してしまったときに、帳票の利用者がそれに気づく仕組みがなければ誤った経営判断につながってしまうかもしれません。
入力した条件も合わせてレポートに出力されるのであれば、レポートの内容と合わせてそれを確認するような統制が想定されますが、実務上必ずしもそのようなレポートばかりではないかと思います。そうした場合には、実際に入力した条件をスクリーンショットなどの形で併せて提出するという対応が一般的な印象です。
このスクリーンショット制度はその有用性について大いに議論が分かれるところですが、特に内部統制監査対象のレポートなのであれば、何かしらの手段で出力条件を事後的に確認できるようにしておくことが求められます。財務諸表監査目的のみなのであれば、監査人が本来想定される条件でレポートを再出力し、実証的に条件が正しかったことを証明することも選択肢になるでしょう。
なお、レポートがデータベースからデータを正確かつ網羅的に取得し帳票として出力するという機能性については、IT全般統制が有効であることを前提に1件のみのテストで十分とできるものの、こうしたパラメータ設定やクエリ入力に関する統制はマニュアル統制に分類されるため、母集団件数に応じた複数サンプルを評価することが求められる点は注意が必要です。
インターフェース
インターフェースの検証においては、IT全般統制の評価対象システムの項でも触れたように、ジョブ管理システムや中継システムを漏れなく特定し、そのそれぞれについて依拠の程度を検証し、全般統制の評価要否を検討することが求められます。
また、複数システムに跨る処理であるため異常終了が生じる可能性も他の統制に比して高く、エラーハンドリングの統制の有効性の評価も検討対象になるでしょう。
データ処理の観点としては、一度送信したデータを再送しないような処理をどのように実装しているかを理解する必要があります。もし十分な制御がなく、ジョブの手動実行をトリガーに売上データなどを二重送信できるようになっている場合には、後続に補完的な統制がないかなどの追加的な検討が求められます。
インターフェースのより詳細な評価観点は後続の章でも記載するため、興味がある方はそちらもご覧ください。
自動計算
自動計算においては、計算に利用されるパラメータの妥当性の確認がポイントになるかと思います。
四則演算が正しいことを再実施などにより確認することももちろん必要な手続きではありますが、この部分に誤りが生じる可能性は比較的低く、小数点や端数の処理以外で大きなエラーはあまり生じないかと思います。
基本観点の項で記載した「元データの信頼性」と「業務要件への準拠性」の内容と重なりますが、例えば「180日間販売実績がなかった商品については評価損を計上し、在庫価格を6割まで減らす」というような業務になっており、システム上の設定が「180日間販売実績がなかった商品については評価損を計上し、在庫価格を7割まで減らす」となっていたとしましょう。
このとき、IT監査人が業務要件に十分な注意を払っておらず、自動計算の正確性のみを検証した場合、「100円*0.7で70円になっている。ヨシ！」と判断してしまうかもしれません。
自動計算の処理量が多ければ多いほどこうした設定ミスの影響額が大きくなるため、会計監査人とIT監査人の双方が評価内容に認識の齟齬がないかをしっかりと確認することが重要になります。
コンフィグレーション
コンフィグレーションの設定については、設定の変更方法と適用範囲を理解することが重要です。
例えば、すべての在庫について移動平均を適用しているような場合には、原価計算メニューの設定画面から「移動平均」のラジオボタンを選択すれば十分かもしれません。
一方で、商品の種類ごとに評価損計上のルールが異なるような場合には、データベースのなかで商品ごとの設定が管理されており、ユーザ画面からではなくデータベースメンテナンスによってのみ更新できるようになっているかもしれません。
特に後者をコンフィグレーションの自動化統制として評価するような場合には、厳密にはすべての商品と評価損率のパターンを全て把握して各商品それぞれについて設定状況内容が要件の通りであることを確認することが求められるでしょう。
試査による評価を採用するのであれば、各パターンについて必要充分なサンプルを取得して評価できるように、サンプル件数を慎重に選択する必要があります。
アプリケーションアクセス制限
アプリケーションアクセス権においては業務上の職務分掌をシステム上な権限に正確に反映させることが重要になります。したがって大前提として、アプリケーションアクセス制限を業務処理統制におけるキーコントロールとして識別した時点で重要な操作（例:仕訳承認）も合わせて識別されている必要があります。ここで言う重要な権限とは財務数値に関わると言う意味での重要性であり、一般的なシステム監査で考慮すべきより広範な権限（個人情報の閲覧権限など）とは意味合いが異なる点には留意しましょう。
また、業務分掌上同時に付与されるべきでない権限の組み合わせ（権限コンフリクト）が存在する場合は、そうした権限が誤って同時に付与されることを予防する仕組みが統制に組み込まれていることも確認する必要があります。
アクセス権限の評価においては、重要な操作を実行可能にする権限であると識別された権限以外にその操作を実行可能な権限がないことをまず評価し、次にそれらの権限を保持するアカウントが業務分掌に鑑みて確かに適切であることを確認することになります。
権限構成が単純であればユーザ一覧から重要な操作を実行可能なアカウントを直ちに特定可能かもしれませんが、例えばSAPのような権限構成が複雑なシステムを評価する場合はIT監査人の関与が望まれます。
そうしたケースにおいては、IT監査人がシステムの権限構成を理解し、識別された重要な操作の実行を可能にする権限を網羅的に特定して権限保有アカウントを漏れなく会計監査人に報告し、会計監査人が権限保持が各ユーザの職位職責に照らして妥当であるかを判断することになります。
また、業務分掌の観点以外から識別される重要な権限として、重要なシステム設定値（コンフィグレーション）の変更権限が挙げられます。必ず識別しなければならないわけではないかもしれませんが、ユーザが随意に変更できるような状態になっていないことは何かしらの方法で確認することが望ましいでしょう。
さらに、アプリケーションアクセス制限がキーコントロールとなることにより、自動的にアプリケーションアカウントのメンテナンス権限がアプリケーションレベルの高権限として識別されることになります。
IT全般統制の評価においてアプリケーションレイヤのアクセス権評価が求められているのにアクセス制限のITACが識別されていない場合や、重要な権限が具体化されていないような場合には、リスクの識別があいまいなまま手続きが進んでいる可能性があるため注意が必要です。
その他自動処理（自動仕訳など）
上記に挙げた典型的なITACの他にも、自動仕訳や会社固有の自動処理が識別されることがあるかと思います。
しかしながら、多くの場合は上記のパターンの組み合わせで対応できると考えます。
例えば自動仕訳であれば、仕訳パターンを全て把握することを起点に、パターン訳の識別子となっているパラメータを特定してその設定状況が適切であること確認することになるでしょうが、これはコンフィグレーションの要素です。仕訳作成時に通貨換算などがあれば自動計算も含まれるかもしれません。あるいは、エラーにより仕訳が作成できなかった場合にエラーレポートが出力されて手作業により入力される運用であるならば、エラーレポートをキーレポートとして評価する必要もあるでしょう。
このように、基礎的なITACの基礎的な評価観点を抑えることで、仮に初めて遭遇するような処理に対応しなければならなくなったとしても、落ち着いてリスクを識別して評価手続きを策定できるのではないでしょうか。
（補論1）EUCはITACの論点なのか
IT統制を取り扱う際、EUCの評価が論点となることがあります。EUCの処理そのものはITACに区分されるでしょうし、マクロでゴリゴリに自動化された処理があるのであれば、そのコードを解読して業務要件との正確性や処理の正確性を検証することになるでしょう。
この手続き自体は一般的なITACの評価と何ら変わりません。前述の通り、ITACの基礎的な類型の評価観点を組み合わせることで十分に対応できるかと思います。
一方でEUCに特異であるのは、その性質上、開発・保守と業務の職務分掌が担保されていない傾向にあり、大規模なシステムに比べて業務ユーザが処理内容を変更しやすいという点です。RPAであれExcelであれSpreadSheetであれAccessであれ、書籍やネット上の情報を参照しながら業務ユーザが開発・保守・運用することも多いと思います。
業務上の利用者が処理内容を直接変更できる場合、業務上の利用者が不正な意図をもって特定の処理をプログラムに挿入するケースや、バグ修正の際などに不要な変更を加えてしまい業務要件と処理内容が乖離してしまうようなケースが生じえます。また、Excelの関数などは事後的に実際に使われた関数を特定することが極めて困難であり、可監査制が低いこともEUCの特徴でしょう。
こうした観点はいずれも本来IT全般統制の変更管理に含まれるべき要素です。どうしてもEUCの評価が必要な場合には、マクロにロックをかける、定期的に変更状況のレビューをするなど、実施可能な全般統制を依拠したい処理ごとに導入していくことになるでしょう。１Excelが1システムというイメージです。
したがって、全般統制に相当する統制の導入可否を踏まえて、EUCに依拠するのか代替的なマニュアル統制を導入ないし識別するのかを検討する必要があるといえます。
（補論2）内部監査におけるITACの評価
内部監査人がITACを評価する際の課題として、比較的リスクの高いマニュアル統制にリソースを割きたい中、限られた人員をどれほどITACの評価に割り当てるのかという観点があるのではないでしょうか。
また、監査人自身が評価の必要性を感じていたとしても、やはり自動化されており変更がなければ不備は識別されないだろうという感覚から、城跡者に対して評価の必要性を説明することが難しいケースもあるのではないかと推察します。
SOX対応として求められている最低限の頻度としては、監基報330よれば3年に1回以上ということになるでしょう。
A36．以下のいずれにも該当する内部統制について、過年度の監査で入手した監査証拠に依拠するかどうかは、監査人の職業的専門家としての判断による。
(1) 最後に運用評価手続を実施した後から変更されていない
(2) 特別な検討を必要とするリスクに関連しない
さらに、これらの内部統制の運用評価手続のインターバルも職業的専門家としての判断によるが、第13項(2)に記載しているとおり、少なくとも３年に１回の実施が必要である。
A37. 一般的に、重要な虚偽表示リスクの程度が高いほど、又は内部統制に対する依拠の程度が高いほど、運用評価手続を実施しない期間があるとしても、運用評価手続のインターバルは短くなる可能性が高い。内部統制の運用評価手続のインターバルを短くする要因、又は過年度の監査において入手した監査証拠に全く依拠できなくなる要因には、以下の事項が含まれる。
・ 統制環境の不備
・ 監視活動の不備
・ 内部統制の重要な部分の手作業による実施
・ 内部統制の運用状況に重要な影響を及ぼす人事異動
・ 内部統制の変更の必要性を示す環境の変化
・ 全般統制の不備
あくまで個人的な見解ですが、コンフィグレーション、特にデータベース内でメンテナンスされるべき設定値関係の要素については、もう少し頻繁にチェックしてもよいのではないかなとはという気はします。
これは、ソースコードに比べて変更難易度が低いほか、個別に設定するコンフィグレーションであれば設定が必要な項目が増えていたり、前回評価時に処理パターンを網羅的に確認できていなかったりと、自動化統制の中では不備が識別されやすい領域という印象があるためです。
また、業務部門や情報システム部門へのヒアリングのみにより変更有無を確認しているようなケースもまま見受けられますが、担当者変更などにより回答担当者が変更を把握していない場合や、把握はしていても重要性が低い変更であるがゆえに失念しているというケースもあるため、3年に1回の評価頻度とするのであれば、タイムスタンプや移送ログの査閲を通じてプログラムに変更が生じていないことについてより強い監査証拠を収集することが望ましいのではないかと思います。
PCAOB水準のIT監査：インターフェースを例に考える
厳しい審査基準で名高いPCAOBですがIT統制の評価においてもその厳しさに例外はありません。PCAOB水準でインターフェースを評価するとき、初年度であれば1本あたり100時間はかかるともいわれ、そうした費用を回避するために代替的なマニュアル統制を導入するケースもあるそうです。
本項ではPCAOB水準での評価観点を追いかけることで、インターフェースに付随するリスクをより詳細に理解していきます。（図を描いたほうが絶対にわかりやすいのですが、時間の都合で省略します、ご容赦ください……）
業務プロセスのRCMに記載されていそうな統制記述を先に例示しますので、どのくらいの手続になりそうか予想してから読んでみてください。
＜統制＞
販売管理システムに登録された売上実績の情報は、日次の夜間バッチで会計システムに自動連係される。
では、さっそく手続きを見ていきましょう。
業務要件の確認
インターフェースによって出そうされるデータのうち、具体的にどの項目について監査上依拠することを計画しているかを明確にします。ここでは、売上金額・売上数量・販売日・勘定科目コードについて依拠しており、受信先テーブルで自動仕訳を作成していると仮定しましょう。元データの信頼性の確認
売上金額・売上数量・販売日・勘定科目コードの情報のそれぞれが、どのように蒸留システムに取り込まれるかを確認し、ミスなく正確に取り込まれるための統制がマニュアル統制のキーコントロールとして評価されていることを確認します。また、取り込みルートが複数ある場合には、そのすべてについて確認が必要になります。
（勘定科目コードが勘定科目マスタから取り込まれているような場合には、勘定科目マスタの更新権限についてアクセス権の評価を検討します。）データの取り込み先テーブルの特定
システムに入力された売上金額・売上数量・販売日・勘定科目コードのそれぞれが、データベース上のどのテーブルのどのカラムに登録されているかを把握します。以降、特定したカラムについて処理を追いかけていくことにします。インターフェース用データ抽出処理の特定と理解
売上情報が入力されたテーブルから、未連携のデータのみをどのように抽出するかを理解し、二重送信が防止される仕組みになっていることと、未連携データがもれなく取得される仕組みになっていることを確認します。
また、抽出処理の過程でデータが加工・集計されている場合（例えば合計値にまとめてから連携しているような場合）には、自動計算の要素を識別する必要があるかを検討します。
このとき、インターフェースファイルが作成されるまでのプログラムファイル名を特定し、タイムスタンプの査閲により期中に変更が発生していないことを確認しておきます。
加えて、データ抽出処理をキックするジョブを特定し、ジョブがキックしているプログラムと抽出処理の理解を通じて特定したプログラムが一致していることを確認します。あわせてジョブスケジューラを確認し、外部ツールを利用している場合には評価対象に含めることを検討します。ジョブの変更履歴を確認方法も合わせて確かめておくとよいでしょう。（エラーハンドリングについては次項でまとめて記載するためここでは省略します）データ伝送方法の理解
作成されたインターフェースファイルをどのように下流システムに渡しているかを確認します。FTPで送信している場合もあれば、中継サーバにPOSTして受信システム側がGETしているというケースもあります。あるいは、SAPのiDocのようにパッケージシステム固有の仕組みを持っているかもしれません。
上流システムの送信ジョブ並びに受信ジョブをそれぞれ特定し、ジョブスケジューラを合わせて確認します。また、連携エラーが生じた場合のエラー検知の仕組みを特定し、特定したジョブが監視対象に含まれておりエラーが確かに検出されるよう設定されていること、エラー発生時には適切な連絡先に通知されること、通知を受けた運用チームがリカバリ処理を実施してデータ連携を正常終了させる手続きになっていることを確認するとともに、これら一連のプロセスがIT全統制の障害管理の評価範囲に確かに含まれていることを確認します。
また、ジョブスケジューラ同様、エラー検知ツールについても変更管理の観点から全般統制の評価要否を検討します。
さらに、中継システムを経由している場合には、中継システム上で実行されている処理を理解し、データの加工や集計を実施しているのであればプログラム変更管理などの全般統制の評価を検討します。
勘定科目のマッピングのような処理があるのであれば、コンフィグレーションのITACが識別され、紐づくアクセス権の確認も必要になるかもしれません。一度データをデータベースに取り込んでいるのであれば、3に戻って同じ検討を繰り返します。
データファイルを一時的にストックして後から下流システムがGETしに来るような場合であれば、ストック期間中のデータファイルが改ざんさえるリスクを評価し、必要ならばアクセス権の設定・管理状況を評価します。
このとき、ここまでの検討の過程で識別されたプログラムすべてについてファイル名を特定し、タイムスタンプの査閲により期中に変更が発生していないことを確認しておきます。インターフェースされたデータの取込処理の特定と理解
インターフェースファイルに含まれている売上金額・売上数量・販売日・勘定科目コードのそれぞれが、データベース上のどのテーブルのどのカラムに取り込まれているかを把握します。また、後続の自動仕訳の処理までに取り込み時のテーブルから別のテーブルに連携されるのであれば、最終到着地点まで推移を追跡します。
（プログラムタイムスタンプやエラーハンドリングについては前項に同じためここでは省略します）後続処理の確認
取り込まれた売上金額・売上数量・販売日・勘定科目コードの内容が、最終的に作成される仕訳に正確に反映されていることを確認します。また、連携された勘定科目が下流システムの科目に存在しない場合のエラー処理を理解し、エラーとなった仕訳が通常の仕訳起票プロセスと同水準の統制のもとでシステムに登録されていることを確認します。
特に勘定科目のマッピングが行われているような場合には、マッピングの妥当性についても合わせて確認します。
（プログラムタイムスタンプについては前項に同じためここでは省略します）
これらの観点を抑えることで、システムにデータが入力されるところから仕訳に至るまでの処理を一気通貫で理解することができます。
書いてみると意外と多くないと感じるかもしれませんが、これらの情報を収集するには多方面との調整が必要になりますし、関連する設計書類の読み込みだけでも相当の時間が必要になります。
ここまで整理してようやく整備状況評価が完了です。
もはや詳述は避けますが、次のステップとしては整備評価の理解に基づいて各種設定値やデータ連携処理、中間のデータ加工処理、周辺システムの全般統制並びに付随的に識別されたITAC、エラーハンドリングプロセスの有効性と障害管理におけるリカバリの状況といった内容の運用評価を実施することになります。
インターフェース一本ごとにこうした検討が必要になるため、大規模グループ会社において、各子会社独自のシステムから親会社の会計システムにいたーフェースが集中しているようなシステム構成の場合、すべてのインターフェースに依拠するとなると莫大な工数がかかります。
このため、コストを踏まえるとインターフェースの都度上流と下流のデータの一致を手作業で確かめるマニュアル統制を入れるような対応も現実的な選択肢となり、PCAOB本家本元の米国ではそうした対応も一般的になるのではないかと推測します。
インターフェース以外においても同様に、同様に詳細な処理を含めてプロセス全体を一気通貫で理解し、紐づくリスクと対応する統制の特定をすることが重要になります。PCAOBに限らず重要な観点ではあるのですが、特PCAOBにおいては、その精緻さが群を抜いているというイメージなのではないでしょうか。
PIT監査人のキャリアとスキル
ここまで、内部統制の目的や保障の枠組みを確認するとともに、IT領域に関する監査には多様なものがあることを見てきました。多様な監査があるということを裏返すと、それだけ低減したいリスクの種類が豊富であることを意味します。
また、財務諸表監査を例に具体的な論点を掘り下げて記載し来ましたが、同様の観点は財務諸表監査以外にも十分に応用が利くものであることは想像に難くないと思います。
IT監査人としての専門性を高める上で多様な監査を経験することはもちろん有効ですが、一番重要なのはどれか一つについて十分な深度で理解し、先達と議論を交わしながらその本質に肉薄する努力を重ねることではないかと思います。（私自身まだまだ勉強中のみですから偉そうなことを言える立場にはないのですが……）
ITの基礎的な理解とリスクに対する考え方、リスクと監査手続の対応が身についていれば、あとは必要に応じて技術的な理解を深めたり、監査手続に関連する公知のガイドラインや基準を勉強すれば、相当幅広い領域に対応できるのではないかと思います。
もちろん初めて取り組む領域においては先達から学びながら取り組むのが一番ですが、初めての領域に院チャージやマネージャーとしてアサインされてしまうこともあるかと思います。そうした時こそ自分の軸となる領域に立ち返ってみることで新しい気づきが得られるのではないかと思います。
余談ですが、後輩にどこまでできればIT監査のインチャージとして一人前だと思うか聞かれたことがあります。個人的な感覚としてはリスクベースで手続を自分で作れればよいのではないかと思うのですが、まだそれができない人にどう説明すれば感覚的に理解してもらえるのか悩んだ記憶があります。
なかなか難しい質問だと思うのですが、最近は岩下先生のIT監査ガイドブックを字面を負うだけでなく中身を理解して読破できるくらいのレベルという説明がいいんじゃないかと思っています。ここまでお読みくださった皆さんだったらどう答えるか、ぜひXなどでご意見お聞かせください。
おわりに
冒頭で「ちょっと長い」と書きながらずいぶんと長々と書いてしまいました。本当はもっと図表を挿入するとわかりやすいだろうなと思ったりもしたのですが、時間と気力の限界もあり、特に後半は文字の暴力になってしまったと反省しています。IT全般統制と挿絵を足したら本一冊くらいの分量になってしまっていたかもしれませんね……。
少々長すぎなきらいはあるものの、無料の記事としてはそれなりのものになったのではないかと自負しているのですが、いかがでしたでしょうか。少しでも誰かの参考になる記事となっていることを願います。
noteのコメント機能を有効にしていないので、ぜひX（@NF_SQ_08）にご意見お寄せください。誤りの指摘や補足情報、ディスカッションも大歓迎です！
長文にお付き合いいただきありがとうございました。