【上場審査の実績あり】IT関連規程で注意すべきポイント5点とは|IT統制対応

内部統制・IT統制

IT統制構築・整備のご支援をさせていただくと、IT関連規程が厳しすぎる内容になっていたり、逆に本来規程に明記すべき内容が盛り込まれていなかったり、規程間で不整合が起きていることがあります。

IT統制を構築・整備する上で、規程の内容は非常に重要です。
なぜなら、監査は規程の内容を正として、規程の内容どおりに運用が行われているかどうかを確認するものだからです。

しかし、それほど重要な位置付けであるにも関わらず、具体的にどういった内容を規程に記載すべきか、という情報はネットで調べてもほとんど公開されていません。会社によって記載すべき内容が異なりますし、絶対的な正解がないからです。

とは言え、上場を目指してIT統制の構築・整備の対応をされている企業様にとっては知りたい情報だと思いますので、上場監査や監査法人による監査をクリアした経験のある弊社がこれまでに蓄積したノウハウや事例をもとに、できるだけ具体的にIT関連規程を作成する上で注意すべきポイントについて、解説したいと思います。
 
 

IT統制で作成すべき規程とは

 
IT統制で作成すべき規程とは
 
まずはじめに、どういった規程を作成すべきか整理します。
規程の名称は各社によって若干異なりますので、その点はご留意ください。
 

◯ システム開発保守規程


システムの開発・導入と保守について明記します。
開発・導入については、プロジェクトを企画する段階から、プロジェクト計画、開発、テスト、移行といった各工程で遵守すべきルールを明記します。
保守については、アプリケーションだけでなくハードウェアなども含まれますが、ユーザー部門からの変更依頼やシステム不具合によってアプリケーションを改修する際のルールが主な内容となります。保守ではなく「変更管理」という言い方をすることもあるため、「システム開発変更管理規程」という名称にしているケースもあります。

なお、開発と保守や変更管理を別々の規程にすることもあります。同じ規程にしても、別々の規程に分けても、問題はありません。重要なことは内容が網羅されていることだからです。
 

◯ システム運用管理規程


主に情報システム部門による運用業務について明記します。
具体的には、運用管理体制、構成管理(ソフトウェア、ハードウェア、ネットワーク等)、ソフトウェア管理、ハードウェア管理、ネットワーク管理、データ管理、設備管理等の運用ルールを明記します。
 

◯ システム利用規程


全従業員向けに、各システム利用時の注意事項や遵守事項を明記します。
具体的には、Excelやスプレッドシートを使う際の注意事項や、PCの持ち出しは勝手に行わない、といった内容を記載します。
 

◯ 情報セキュリティインシデント管理規程


情報セキュリティを担保するために実施する対策や従業員が遵守する内容などを明記します。
情報セキュリティインシデントや事故発生時の報告および対応についても明記します。
 

◯ 外部委託先管理規程


システム開発や運用保守において、業務の委託など外注するケースが多いので、外部委託先との契約時には機密情報保護の取り扱いや再委託の可否を定める、委託契約後は定期的な監査やモニタリングを行う、といった内容を明記します。

 
 

IT関連規程で注意すべきポイント5点

 
IT関連規程で注意すべきポイント5点
 

(1)責任者や管理者の不整合をなくす

 
前述のとおり、規程は複数存在するため、それぞれの規程で責任者や管理者の定義を行っていると、規程間で不整合を起こすケースがあります。これは規程を横串に確認しないと見つけにくい点です。

例えば、運用管理規程では「セキュリティ運用管理責任者」、セキュリティ管理規程では「セキュリティ管理責任者」と書いてあるようなケースがあります。それぞれ異なる名称になっていますが、実態としてはどちらも同じ役職者の方が担うことになっており、かつやることは同じという場合は、名称を統一させたほうが良いです。名称が異なることによって運用時に混乱が生じるためです。

各規程で明記される役割(〜〜管理者、〜〜責任者など)を一覧化し、役割を全て洗い出して確認することをおすすめいたします。
 

(2)手順書レベルの内容は記載しない


例えば、アクセス権限を付与する際のルールとして、「申請者が〇〇ワークフローを使って申請し、システム管理者がxxxと照合して内容を確認する。問題がなければ承認を行い、システム担当者が□□□システムを使って申請者に対してアクセス権限を付与する。付与した後は、申請者に対してxxx報告書を送付して通知を行う。」という内容まで規程に書いてあるケースがあります。

規程ではここまで具体的な内容まで記載する必要はありません。最低限記載すべき情報は「誰が申請して、誰が承認するのか」という点です。

そのため前述の例でいうと、「申請者が申請し、システム管理者が承認する」という内容だけ規程に記載しておけば問題ありません。

一般的に、規程を制定・改廃する際には取締役会での承認が必要となります。そのため、規程に書く内容を細かくしすぎると、運用手順やルールが変わる度に規程を改定し、取締役会での承認を得なければいけません。そうなると、IT関連規程を管理する情報システム部門や総務部門の負荷が非常に高くなってしまいますので、手順書レベルの内容は規程に記載せず、規程に紐づく手順書や要領という形で文書化しておきましょう。

手順書や要領であれば、管理部門の本部長や部長が承認者となることが多く、規程よりは改定しやすいためです。
 

(3)最低限必要な項目を網羅する


IT統制の対応として明記すべき内容が規程から漏れているというケースもあります。
具体的に記載すべき項目を列挙しますので、これらの項目が記載されているかどうか確認していただくことをおすすめいたします。

なお、以下の項目は最低限記載すべき項目のうち、記載が漏れやすい項目のみを挙げていますので、全体的な網羅性の確認が必要でしたら、弊社までご相談ください。
無料相談はこちらからどうぞ
 
<IT全般統制の観点で漏れやすい項目例>
・アカウント管理
・アクセス管理(権限管理、社内ネットワークへのアクセス等)
・機密情報の定義
・情報の持ち出しや廃棄
・外部委託契約時の注意事項(特に機密情報の取り扱い、再委託の可否について)
・外部委託先の管理やモニタリング
 

(4)全てのシステムを同じレベルで管理しない


内部統制報告対象のシステム(基幹システム、会計システム等)は財務会計へ影響を及ぼすため重要度が高く、管理レベルを高くしなければいけません。しかし、重要なデータを扱っていないシステムに対して、会計システムと同じレベルの管理を行う必要はありません。

システムで扱うデータの重要度や業務の重要度を鑑みて、システム毎に管理レベルを変えるべきです。なぜなら、システムを全て同じレベルで管理しようとすると、管理負荷が高くなってしまうからです。管理負荷が上がるだけでなく、運用が形骸化されてしまうリスクもあり、結果的に重要なシステムの管理がしっかりとされていない、といった事象には繋がりかねません。

具体的には、規程の中でシステムの重要度を定義し、遵守すべきルールをどのシステムへ適用させるのか明記することがよいでしょう。重要度の低いシステムについては、「推奨事項とする」という一文を入れておくと良いでしょう。
 
システムの重要度を定義する際の具体例は以下のとおりです。あくまでも例ですので、参考までにご覧ください。

<重要度の定義例>

◯ 案1:稟議決裁金額に応じて重要度を決める

社内の稟議決裁の金額に準じてシステムの重要度を決めるやり方です。
例えば、最上位の社長承認が必要なシステム導入に関しては全ての工程を実施し、全てのドキュメント(企画書、要件定義書、設計書等)を残すこととし、部長クラスの承認でもよいシステム導入に関しては必要だと判断した工程のみ実施し、最低限必要なドキュメントだけを残す、というやり方です。
 
◯案2:業務への影響度合いに応じて重要度を決める

業務への影響度合いに応じてシステムの重要度を決めるやり方です。
特に財務会計への影響を及ぼす可能性のあるシステムについては、厳格に管理し、業務上の影響がほとんどないシステムについては管理レベルを下げる、というやり方です。
 
◯案3:扱うデータの機密度に応じて重要度を決める

対象のシステムで管理するデータの機密度に応じてシステムの重要度を決めるやり方です。
例えば、財務情報や個人情報を取り扱うようなシステムではセキュリティレベルや管理レベルを最も高くし、財務情報や個人情報といった重要なデータを扱わないシステムでは管理レベルを下げる、というやり方です。
 

(5)クラウドサービスやパッケージシステムを考慮する


最近では、ゼロからシステムをオリジナルで開発するケースは減少し、クラウドサービスやパッケージシステムを導入するケースが多くなりました。しかし、規程はゼロからシステムを開発することを前提とした記載になっていることが多々あります。インターネット上で公開されているような規程は古いことが多く、クラウドサービスやパッケージシステムが考慮されておらず、そのままの規程を流用してしまうためです。

この点が考慮されていないと、たとえカスタマイズが発生しないクラウドサービスやパッケージシステムの導入であっても、要件定義書や設計書、テスト仕様書等のドキュメントを残さなければいけなかったり、単体テストや結合テストまで行うことになってしまいます。規程で明記しているのであれば、遵守しなければならないからです。

カスタマイズが発生しないのであれば設計書まで残す必要はありませんし、クラウドサービスやパッケージシステムでは既に品質が保証されているので、単体テストや結合テストも必要ありません。現場で業務を行う方の負荷だけが上がってしまいますので、クラウドサービスやパッケージシステムを導入することを想定した記載にしておきましょう。

具体的には、「例外事項として、当社独自の開発がなくクラウドサービスやパッケージシステムを導入する場合は、ユーザーテスト、本番移行のみにすることも可能とする。」「クラウドサービスやパッケージシステムを導入する場合、プロジェクト計画の段階で実施すべき工程と成果物を定義し、プロジェクトオーナーが承認する」といった内容を記載しておけば問題ありません。
  
 

まとめ

 
今回ご紹介させていただいた観点で、ぜひ一度貴社のIT関連規程を見直してみてはいかがでしょうか。
IT統制を安全に対応し、かつ運用負荷をできるだけ減らすように規程の内容を見直すことは強くおすすめいたします。上場に向けて進んでいき、上場直前になって規程を改廃するのは難しいので、早めに見直しておいてはいかがでしょうか。
 
なお弊社では、昨年(2021年)上場された企業様のIT統制を対応しておりました

その際にもIT関連規程の見直しを行っておりますので、「規程の内容が上場監査に耐えられる内容かどうか確認して欲しい」「最低限の統制は担保しつつ、できるだけ運用負荷を下げるために規程を見直したい」といったお悩みがございましたら、お気軽にご相談ください。

 

通信事業会社様|IT統制を整備、IPO監査をクリアして上場へ

通信事業会社様|IT統制を整備、IPO監査をクリアして上場へ
 

無料相談する

一覧を見る>

内部統制・IT統制の事例紹介

一覧を見る>

最近の活動・コラム