システムリプレイスに伴うJ-SOX対応～事例に基づく進め方のポイント～

近年、業務効率化やデジタル化を背景に、システムリプレイスを行うケースが増えています。その背景ばかりに焦点があたり、J-SOXへの影響が見過ごされることがあります。システム間のデータ自動連携・業務の自動化等、従来手動で対応していた業務が自動化され、リスク・コントロールの設定やコントロールに関連する証憑の見直しが必要となります。リプレイス後に影響を検討したのでは、統制に必要となる機能が設計されていないために不備が発生したり、手動で対応せざるを得ない事態も起きかねません。構想策定から導入まで2年以上かけシステムリプレイスのプロジェクトを進めるケースもあり、新システムの構想段階から情報システム部門および現場部門を巻き込み、システムリプレイスの対応と並行して、J-SOXへの影響を検討することが大切です。今回の記事では、システムリプレイスに伴う内部統制対応のスケジュールや構築・評価を進めるうえでのポイントを説明します。

システムリプレイスの内部統制への影響
システムリプレイスに伴うJ-SOX対応事例～スケジュール作成のポイント～
システムリプレイスに伴うJ-SOX対応事例～構築のポイント～
システムリプレイスに伴うJ-SOX対応事例～評価のポイント～
システムリプレイスに伴うJ-SOX対応の留意事項
まとめ

システムリプレイスの内部統制への影響

まずはシステムリプレイスにより内部統制にどのような影響があるのかご説明します。リプレイスするシステムによりその影響は様々ですが、特に基幹システムの場合、幅広い業務に大きな影響があり、内部統制の構築や評価の見直しが必要となります。

■IT全般統制の構築・評価に与える影響（例）
・システム管理ルールの見直し
・申請書類の見直し
・IT全般統制評価調書の更新
・システム開発・導入に係る評価

■業務プロセス統制・IT業務処理統制の構築・評価に与える影響（例）
・業務の流れ・使用する証憑の変更
・リスク・コントロールの見直し
・ITに依拠する統制の把握
・母集団データの変更
・評価手続の策定

基幹システムに限らず、在庫管理システム等、財務報告に関連するシステムのリプレイスにおいても、J-SOX対応に影響を与えます。その影響は限定的になることもありますが、リプレイスの目的や業務フローを照らし合わせ、財務報告に関するリスク・コントロールの見直しが必要です。

<在庫管理システムの場合の対応事例>
リプレイスの目的：入出庫の記録を手入力で行っており、工数や入力ミス等が問題となっていた。
リプレイスによる効果：ハンディターミナルとバーコードを活用することで、入出庫の登録が簡素化され作業工数が削減された。
リスクとコントロールの検討：従来は担当者による入出庫の入力ミスがリスクとなっていたが、システムリプレイスによりシステムへの反映が簡素化され、リスクの重要性は低下した。一方、システムに依存した業務となるため、マニュアル統制ではなくIT業務処理統制を設定した。

リプレイスするシステム毎でJ-SOX対応への影響は異なります。精度の高い内部統制の構築・評価のスケジュールを策定するためには、事前にリプレイスの内容を把握し、内部統制への影響を検討することが大切です。

システムリプレイスに伴うJ-SOX対応事例～スケジュール作成のポイント～

システムリプレイスへの対応にあたり、システム概要・要件定義からリプレイスの目的や効果を確認し、業務の変更点を把握するためのスケジュールが重要です。スケジュールを作成する際に検討すべきポイントをリプレイスの段階に分けてご紹介いたします。

＜構想段階・設計・開発段階・テスト段階＞
ポイント①評価対象システムの確認（IT全般統制）
システムリプレイスによりデータの流れが変わることで、財務報告におけるシステムの重要性が変わることがあります。例えば、今まで単なる金額集計のため使用していたシステムが、基幹システムへ自動連携されるシステムに変更になった場合、マニュアルでの作業を介在せず、計上までデータが流れるため、システムの重要性が高くなることがあります。まずは評価対象システムの見直しから着手することが大切です。
ポイント②管理ルールの確認
例えば、自社開発システムから外部のパッケージソフトにリプレイスする場合、外部ベンダーを利用することになるため、委託管理や変更管理等IT管理ルールが必要になります。既存の規程類を確認し、IT全般統制の評価項目と照らし合わせ、規程の見直しが必要かを確認するべきです。
ポイント③3点セット・評価調書の更新
リリース前に担当者へヒアリングを実施し、３点セット・評価調書のドラフト版を作成することもポイントです。特に期中でリプレイスする場合、評価期間がタイトになるため、変更点を把握し評価方法まで検討しておくことで、評価の際に必要となる証憑が明確になります。

＜運用開始後＞
ポイント④リリース後の変更点の把握
リリース後、想定していたオペレーションが運用できず、業務フローが変更になることや、統制内容・証憑も変わることがあります。そのような変更が発生することを前提に、3点セット・評価調書の更新もスケジュールに含めておく必要があります。場合によっては、評価作業と並行して、3点セット・評価調書の更新を行うこともあります。その場合、関連部門の負荷が高くなるため、リソース面を考慮することも大切です。

リプレイス後にJ-SOX対応への影響を検討したのでは、不備事項が発生し改善対応を迫られることにもなりかねません。上記ポイントを含め、構想段階から内部統制対応に着手するスケジュールを組むことがポイントです。

システムリプレイスに伴うJ-SOX対応事例～構築のポイント～

システムリプレイスに伴う具体的な対応ポイントを紹介します。IT全般統制の場合はシステム概要の確認、業務プロセス統制・IT業務処理統制の場合は業務に影響があるポイントを確認することが必要です。把握した内容を基にシステム管理ルールを見直し、システム管理方法の検討や財務報告に関するリスクとコントロールの設定・見直しを行います。

■IT全般統制
事例①：自社開発システムから外部のパッケージソフト（クラウド）への移行
構築ポイント：外部ベンダーがシステム管理を行うことになった場合、システム管理ルールの変更に伴い、申請書類（プログラム変更やアカウント発行の申請依頼書等）の見直しが必要です。また、外部委託先の選定・契約の維持に関する手続、委託業務に関する検収手続等、システム管理ルールと照らし合わせ、統制内容を見直すことになります。バックアップの実施や不正アクセス対策等、ベンダーが対応している事項は、SOCレポート等の委託先の内部統制状況が確認できる文書を入手し、その管理状況を確認する必要があります。

■業務プロセス統制・IT業務処理統制
事例②：業務の自動化を目的としたシステムリプレイス
構築ポイント：システムリプレイス後の業務の流れを確認し、自動起票・自動連携・電子承認等、変更点を把握します。自動化によりリスクの内容も変わり、リスクに対応するコントロールの確認が必要です。各々の業務で自動化を進めた結果、確認や承認がないまま計上まで進んでしまう事態になることもあります。例えば、受注において、金額基準を下回る案件は自動承認としている場合、案件の網羅性や実在性等のリスクに対応する発見的統制の設定が必要です。リプレイス前に文書化に着手することで、そういった不備の発見にも繋がります。

リプレイス前は確定していない業務が多く、仮で文書化を進めることになります。リリース後に確認漏れがないよう、確認事項を一覧化し、対応状況を管理することも大切です。

システムリプレイスに伴うJ-SOX対応事例～評価のポイント～

次に評価ポイントのご説明です。システムリプレイスにより、評価が例年よりタイトなスケジュールになることがあります。また、証憑が用意できないケースや、想定と異なる業務処理となったため、システム管理方法や統制内容の見直しが必要となるケースもあります。

■IT全般統制
事例①：自社開発システムから外部のパッケージソフト（クラウド）への移行
評価ポイント：システムリプレイスにあたり外部ベンダーの選定に関する評価が必要となります。ベンダーの選定資料や導入決定の決裁資料等を確認し、システム管理ルールに沿っていることを確認します。開発・導入に関しては、システム設計書や要件定義書、テスト記録等を確認します。また、SOCレポートが入手可能な場合は、委託先の内部統制を直接検証することが不要となります。SOCレポートを参照することで評価手続が簡素化できます。

■業務プロセス統制・IT業務処理統制
事例②：業務の自動化を目的としたシステムリプレイス
評価ポイント：システムリプレイスにより母集団データ変わり、網羅性を検証することが必要となります。また、システムから出力される評価証憑の構成も変更になることがあるため、事前にどのような内容を含んでいるかを確認したうえで、評価手続を策定していきます。

業務が自動化されることにより、システムから出力できる情報も多くなります、案件情報の他、ログに承認履歴が含まれていれば、複数案件を一つのデータで確認ができ、証憑収集や評価作業の効率化が図れます。

システムリプレイスに伴うJ-SOX対応の留意事項

システムリプレイスは、J-SOX対応において、現場部門を含め内部統制担当者の負担が大きくなります。手戻りなく確実に進めるためには、対応事項を洗い出し、実効性のあるスケジュールを作成することが重要です。また、下記に該当する事例の場合、柔軟な対応が必要となり、より事前の計画が必要です。

事例①期中におけるシステムリプレイス
期中のリプレイスの場合、リプレイス前の統制状況の評価が必要となるケースがあります。その場合、リプレイス対応期間中に評価を実施することになるため、負担が大きくなります。また、リプレイス前のシステムから証憑を取得することになるため、システム担当者への確認が必要です。仮に期末に近い時期にリプレイスを行う場合、文書更新はリプレイス前から着手し、フローを早い時期に把握し、リスクとコントロールの検討を行うことが大切です。

事例②システムリプレイスの延期対応
想定していたリリース時期が延期になった場合は、その原因を把握するべきです。特に延期の原因がシステム間の連携や、内部統制に関連する機能開発にある場合、リプレイス後、早々に稼働状況を確認する必要があります。もしシステムが上手く稼働しない場合は、一時的にマニュアル統制で対応することもあり、その場合は評価方法の見直しが必要です。期中におけるリプレイスの留意事項を踏まえ、監査法人と評価期間、評価方法について協議を行うことが大切です。