ITACの悩み

むかしSIerに居たならシステム解るでしょ？みたいな先入観でITAC評価の仕事に回されることがある。

PLCのマニュアル統制についての文書化や評価の解説って結構見るけど、自動統制（ITAC）についての話ってあんまないような気がする。
SOX対応で監査法人とかとやりとりしてて正直どうなの？と思ったことをぶっちゃける。
いつか詳しい人に巡り逢えたら聞いてみたい。。

ITACの識別

PLCとITACの対応関係

重要な勘定科目を決定し、勘定科目に至る業務プロセスを文書化し、立証すべきアサーション（勘定科目ごとに異なる）が達成されないリスクを洗い出し、そのリスクを低減しているコントロールを特定・文書化する。ここまでがPLCの識別。
その後、PLCの実施方法を手動／自動に分けて、自動のものをITACと呼ぶ。
ここまでは理解できる。

問題なのは、その後に評価対象の処理を特定するプロセス。
どうやらITACを実装しているプログラムを探し当てなきゃならないらしく、システム設計書を読まなきゃならないし、当然わからないことは情シスに質問してかないといけない。

業務プロセスと比べてシステム処理はだいぶ緻密で複雑なわけで、それを第三者（しかもプログラマですらない）が読み解くのってかなり骨が折れると思うけど（そして設計書がソースコードと完全に整合してる保証もない）、ほんとにプログラムの特定までやる必要あるのだろうか。。

ITAC処理の文書化レベル

PLCの文書化だと、3点セット（RCM、フローチャート、業務記述書）を作成する。
それとは別に、ITACとして更にシステム的に詳細な文書化を行う必要があるらしい。

問題はその詳細度で、システムやプログラムのレベルでフローチャートとか業務記述書とか作成しなきゃいけないんだろうか。

監査法人からの説明はこんな感じだった。
①評価対象プログラムを特定
②評価対象プログラムのアウトプットを特定（帳票／画面表示／DBレコードにおける金額／勘定科目／計上日など）
③アウトプットに繋がるインプットを全て特定（画面への入力、マスタの更新、など）
④インプットからアウトプットに至る中間処理を全て特定（データ変換、ファイル転送、など）
⑤上記を文書化

つまり、ITACを実装するプログラムを特定（①）したら、その重要なアウトプット項目を特定（②）して、その項目のそれぞれがどんなインプットに由来してるかを最初まで遡って（③）、中間処理も全て辿って（④）、文書化（⑤）しろってことらしい。
一体どれだけのリソースを想定してるんだろ。正気なのか。

情シスがメンテしてるシステム設計書とかプログラム設計書の流用ではだめなのか。
システムの非専門家である内部監査部門が独自にシステムの挙動を記述するような文書を作っても正確性が怪しいような気もしなくもないし。
そもそも情シス担当者だって、アウトプット項目の生成に必要なインプット項目が何で、その生成過程がどの設計書に記載されてるかなんて把握してないだろって思うけど。

自動計算はITACなのか

収益とか費用の科目の金額を自動計算する処理があるけど、あれってそもそもコントロールと言えるのだろうか。
マニュアル業務だったら、電卓で計算する行為自体は単なるプロセスで、その後にレビュー承認する行為がコントロールに該当するんだと思う。
自動化することによって、マニュアル業務よりも計算ミスするリスクを低減しているという解釈なのかな。。
だとしたら、対応するアサーションはどれ？

・実在性（本当にあるのか）
・網羅性（すべて記録されているか）
・権利と義務の帰属（会社のものか）
・評価の妥当性（適切な価額か）
・期間配分の適切性（正しい期間に計上されているか）
・表示の妥当性（きちんと開示されているか）

https://jicpa.or.jp/cpainfo/introduction/keyword/post-59.html

ITACの評価

整備状況評価＝設計の検証？　運用状況評価＝実装の検証？

PLCだと、整備状況評価では、業務プロセス上で生成される証拠資料を一通り収集して、規程類と整合しているかどうかを確認する。運用状況評価では、整備状況評価の結果キーコントロールとして扱うことにしたコントロールに対して、証拠資料を収集（統制頻度に応じて25件とかサンプリング）して確認する。これは理解できる。

一方でITACだと、何をやればいいかいまいちよく解ってない。過去の評価調書を見ると、整備状況評価では設計書でコントロールに該当する処理が記載されているか、運用状況評価ではシステムからデータを抽出して設計書通りの処理が実装されてるかどうかか確認してるっぽいけど、PLCと考え方がだいぶ違うような気がする。。

自動化されたコントロールだから、インプットが同じならアウトプットも同じになるので、複数件サンプリングする必要がないってのは分かる。だったら整備状況評価だけで、データ（PLCにおける証拠資料に該当）が設計書（PLCにおける規程類に該当）と整合してるかどうか確認すればいいじゃんと思う。

後は、EUCとか特にそうだと思うけど、処理が設計書に明文化されてるとは限らないと思う。その場合はどう評価するのか。

「正確性」と「網羅性」

ITAC評価時によく出てくるこの言葉。
一見はアサーションのようだけど、違う。
アサーションには「正確性」なんてないし、アサーションの「網羅性」は簿外取引や過小計上がないかどうかだし。

どうやら、
・正確性：出力値が期待値（例えば入力値）と一致すること
・網羅性：出力件数が期待値（例えば入力件数）と一致すること
の意味で使われて気がする。
とても紛らわしいけど、評価はだいたいこの2つの観点でやるのが通例っぽい。

ITACのサンプル評価とシステム開発テストの違い

データ（処理結果）が設計書通りかという確認は、作業的にはシステム開発におけるテストと似てる気がする。
ただ、ITAC評価は本番環境でやらないと意味ないので、テストデータを新たに準備してシステムに投入して処理結果を期待結果と比較検証するってことができない。
なので、既にインプットされたデータとアウトプットされたデータをシステムのDBから引っこ抜いてきて（これがサンプルデータ）、それが設計書通りかを確認することになる。

問題はこのサンプルデータとしてどんなものを使えばいいかということ。
ある処理（＝プログラムの実装）が正しいことを示すためには、システム開発におけるテスト（UT⇒IT⇒ST⇒UAT）みたいに、条件分岐を網羅するために、処理ロジックを読み解いてデータパターンを洗い出す必要があるはずだけど、ITAC評価にそんなリソースはないはず。

PLCと同じ発想で、母集団から何件かランダムにサンプリングして、それだけ確認すればOK（結果的に全ての条件分岐を確認できなくてもOK）とかではだめなのかなあ。
ランダムでいいならロジックを追う必要なくなるのに。

DBからレコードを抜くときの懸念

監査法人は何故かSQL文を欲しがるけど、実際にチェックするべきなのはDBMSのSQL実行ログの方ではないのだろうか。
ログを見ないと、クエリが実行された日付時刻とか載ってないと思うんだけど、何が確認したくて依頼してくるんだろう。

調書の書き方

前期からITAC処理が変更されていないことをどう説明するか

ITACを実装してる該当処理が前期評価時から変更されてないことを示せれば、前期評価時の結果を当期も使いまわしてOKっていうルールがあるらしい。
でも変更されてないことなんてどうやって示せばいいの？（悪魔の証明では？）
設計書の改訂履歴なんてのは更新漏れもあって当てにできないだろうし（そもそもどの処理はどのメソッドで実装するとかまで記載してないだろうし）、バージョン管理ツール上のソースコード更新箇所を全て確認して、ITAC処理に該当してるものがないかいちいち潰していくしかない気が。。

ひとつの処理が始まって終わるまでに、いったい何個の変数が使われ、何個の関数が呼び出されるのか。
ソースコードファイルの更新箇所が「ある処理」に影響を与えないことを検証するなんて、システム開発テストでもやった憶えがない（普通は回帰テストをやり直す）。

変更されてないことを示すより、当期も再評価したほうが労力かからない疑惑まであるんだけど、ほんとにこのルール適用して評価省力化してる現場とかあるのだろうか。

結局のところは

いろいろと納得いかないことは多いけど、それでも経営者としてはITAC評価を有効にしたいわけで（ITを活用すればするほどコントロールは自動化していく）、内部統制評価担当者としては監査法人に「有効である」と納得してもらえるような理屈を捏ねるというのが実務スキルの見せどころなのかもしれない。

自動統制が有効だという立証が厳しかったら、マニュアル統制で補完してリスクを抑えましたって説明を試みるとかね。