IT関連規程の作り方と注意点
こんにちは。
上場企業や上場を目指す企業向けに、IT統制をまるっとサポートする「IT統制サポート」というサービスをやっている、株式会社エッグシステム代表の高橋です。
前回は、IT統制とは何か？という基礎的な話しを解説しました。
IT統制は、ITに関するルールを作って運用することだと説明しました。
ルールというのは、会社で言うと「規程」に該当します。つまり、IT統制では規程を作らなければいけませんし、その内容が重要だということです。
今回は具体的に作成すべき規程の対象と規程作成時に注意すべき点について解説します。
作成すべき規程とは
※規程の名称は会社によって若干異なりますので、ご注意ください。
■システム開発保守規程
システムの開発導入時と保守時のルールについて明記します。「開発変更管理規程」という名称で作成するケースもあります。
開発導入時のルールとは、例えばプロジェクトを企画して稟議決裁をとった上で導入を進める、テスト結果は記録として残す、リリース前に責任者の承認を得る、といった内容です。
ポイントは、
◎適切なタイミングで承認を得る
◎記録を残す
の2点です。好き勝手にシステム導入したり、リリース後に問題が起こったりしないようにするためのルールですね。
また保守に関しては、例えば保守依頼をする前に社内で承認を得た上でベンダーへ依頼する、保守作業実施後は確認してからクローズする、といった内容です。
■システム運用管理規程
主に情報システム部門による運用業務に関するルールを明記します。
例えば、運用管理体制として責任者は誰か、ソフトウェアやハードウェアの管理方法や棚卸のルールといった内容です。
「システム開発保守規程」はシステムを導入・開発する人全員が対象となるので、対象は全社員ですが、「システム運用管理規程」はあくまでもシステムの運用業務に携わる人のみが対象です。そのため、システム寄りの内容となるので、システムに詳しくない方にとっては読み慣れない内容になることが多いです。
■情報システム利用規程
システム利用時に守るべきルールについて明記します。
具体的には、PCを使う際はログインパスワードを設定してセキュリティソフトをインストールする、セキュリティソフトは常に最新版へ更新する、PCは社外へ持ち出さない、私物のスマートフォンで会社情報へアクセスしない、メールで送受信する情報は暗号化する、といった内容です。
「システム利用規程」は全社員が対象となる規程で、上述のように、細かいルールを記載することが多いです。最近だと、やはりスマートフォンやタブレットの利用に関してルールを定めることが多くなっています。
大企業であれば、私物のスマートフォンやタブレットは会社で使わない方針にする会社が多いのですが、ベンチャー・中小企業の場合はBYODといって、私物のスマートフォンやタブレットを業務利用するケースが多々あります。
私物のスマートフォンやタブレットを業務利用するときには、例えばデータは保存しない、VPNでアクセスする、といったようなルールが必要ですので、「システム利用規程」に明記しておくと安心です。
■情報セキュリティインシデント管理規程
情報セキュリティインシデント（セキュリティ事故）が発生したときのルールを明記します。
具体的には、セキュリティインシデントが発生したらシステムの管理責任者へ連絡した上で社内周知する、影響が大きいインシデントの場合は経営層へ即時報告する、再発防止策を立案して社内で承認を得る、などです。
「セキュリティインシデント」とは書きましたが、セキュリティに限らず、システム障害全般についてのルールを明記するケースが多いです。
■外部委託先管理規程
システムに関しては、開発や運用などを外部委託するケースが多いので、外部委託するときに守るべきルールについて明記します。
具体的には、委託契約では機密情報保護の内容を盛り込む、委託先の選定基準、委託契約の内容が遵守されているかどうか定期的な確認を行い、証跡を残す、といった内容です。
システムに関して外部委託が多いとは言いましたが、システム以外でも外部委託するケースも当然ありますので、それらをまとめて会社で1つ「外部委託先管理規程」を作成しておく方が効率的です。
IT関連規程を作成する際に気をつけるポイント3選
（１）内容を細かく書きすぎない
規程には大まかなルールを書くことに留め、細かい手順レベルの内容は書かない方がよいです。
なぜかと言うと、規程の作成や変更に際しては、取締役会での承認が必要になり、手順が変わるたびに取締役会で協議しなければいけなくなるからです。
手順レベルの細かい内容は、日々変わる可能性があるので、規程ではなく、「手順書」「内規」といった書類に記載した方がよいですね。
細かい手順レベルの内容
「システムのアクセス権限を付与する際は、利用者が〇〇ワークフローを使って申請し、システム管理者がxxxと照合して内容を確認する。問題がなければ承認を行い、システム担当者が□□□システムを使って申請者に対してアクセス権限を付与する。付与した後は、申請者に対してxxx報告書を送付して通知を行う。」
↓
規程に書くべき内容
「システムのアクセス権限を付与する際は、利用者が申請し、システム管理者が承認する」
（２）クラウドサービスやパッケージシステムを考慮する
ネット上に公開されていて無料でダウンロードできる規程のサンプルは、古いものが多いので、そのまま使うと実態と乖離してしまいます。
乖離するポイントの一つが、クラウドサービスやパッケージシステムについてです。
古い規程では、基本的にゼロからシステム開発することが前提になっています。しかし、最近ではゼロからシステム開発するケースは少なく、クラウドサービスやパッケージシステムを使うことがほとんどです。
ゼロからシステム開発することが前提になっていると、確認や承認などのプロセスが多くなるので、運用負荷が上がります。一方、クラウドサービスであれば、例えばテストはかなり簡略化できるので、確認や承認プロセスが少なくても問題ありません。
具体的には、「クラウドサービスやパッケージシステムを導入する場合は、ユーザーテスト、本番移行のみにすることも可能とする。」「クラウドサービスやパッケージシステムを導入する場合、プロジェクト計画の段階で実施すべき工程と成果物を定義する」といった内容を規程へ盛り込んでおくべきです。
（３）責任者や管理者などの役割の整合性を取る
いろいろな会社でよく見るのが、A規程では「システム管理者」、B規程では「システム責任者」、C規程では「システム管理責任者」と書いてあるケースです。それぞれの役割で名前が違うので、違う役割かつ違う人が担うのか？と思いきや、全てシステム部門の部長が担っている、といったケースです。
上記の例では、規程の読み手が混乱するので、名称は変えない方がよいでしょう。
この点については、どれか一つの規程を読むだけでは、気づきにくいので、規程を作成し終わったら、規程に登場する役割を全て書き出し、内容を確認することをおススメします。
規程（ルール）が分かりにくいということは、実際の運用が行われにくくなる、ということです。そのため、できるだけ分かりやすい規程にするためにも、役割の名称は整合性を取り、極力同じ名称にする方がよいですね。
弊社が持っている規程のサンプルは後日公開しようと思います！
この記事が気に入ったらサポートをしてみませんか？