IPO準備会社におけるIT全般統制（開発・変更管理）の留意点

最近、多くのIPO準備会社のIT全般統制の構築支援を行っています。そこで、主に開発・変更管理の観点から、話題に上がったトピックや必要な統制上の留意点について、これから整備を進めようとする会社の参考になればと思い、筆を取りました。

今回紹介する3点は、（1）開発・変更時の各種段階での承認、（2）職務分掌、（3）データの直接修正時の統制です。なお、以下の意見は、筆者個人の意見であり、当社の正式見解と異なる可能性がありますので、あらかじめご了承ください。

要求元の部門などからの依頼がないシステム開発・変更案件が実施されると、要求仕様や品質基準を満たさなかったり、不正な意図のあるプログラムや誤った内容のプログラムがインストールされたりする懸念が生じ、財務報告の信頼性を損なうおそれがあります。これらを防ぐためには、要求元部門より申請書が起案され、またシステム部門は既存システムへの影響度などを評価のうえ、承認するなどの統制の体制を整備する必要があります。同様の理由により、設計・開発、テスト、本番移行の各段階においても承認に基づいて進められることがポイントになります。

開発者によって本番環境で不正な変更が行われると、システムが意図したとおりに機能せず、その結果、財務情報の信頼性が損なわれるおそれがあります。これを防ぐためには、プログラム開発時や変更時にさまざまな職務分掌が求められますが、とくに開発環境で開発を行う開発担当者と、本番環境にプログラムを移行する運用担当者は明確に分ける必要があります。これにより、プログラムの開発と本番移行は別の担当者により実施され、相互で牽制機能が発揮されます。
ところが、人員が少ないために、開発担当者と運用担当者を分けることができず、同一の担当者によって実施される場合もよくあります。このような状況はなるべく避けたいですが、やむを得ない場合には、プログラムを本番環境に移行する時に、その変更状況をモニタリングする補完的な統制の体制を設けるなどの対応を行う必要があります。

システム障害発生時など、正規の業務システムを介さずにツールなどを利用してデータを直接修正するケースがあります。本来、こうした直接修正が行われること自体望ましくないのですが、意外とこうした実務を行っている会社は少なくありません。
データの直接修正を行う場合には、未承認の不正なデータ修正が行われる懸念や、単純ミスによる修正誤りに気付かない可能性があり、とくに履歴が残らない場合には、誰がどう修正したのかわからないおそれがあります。これを防ぐためには、＜1＞データへのアクセスを、システム部などの職務上許可された担当者に制限したり、＜2＞当該アクセスや変更内容が妥当であるか、管理者に事前承認を受けたり、＜3＞実施時には別の担当者による変更データのダブルチェックやトリプルチェックを行ったり、＜4＞変更ログを残し、事後に適切な修正がなされているかを確認したりする統制の体制を設ける必要があります。