日本の親会社が上場している場合、タイ子会社も内部統制報告制度の評価対象に入ります。そこで求められるIT統制への対応は、システムの権限設定を直すことだけでは終わりません。本記事では、内部統制のIT統制対応として何をどこまで整えるべきかを、IT全般統制(ITGC)の領域ごとに分解し、タイ子会社の現実的な体制で回すための手順と工数の見立て方まで整理します。
内部統制報告制度の改訂で、IT統制対応の前提が変わった
タイ子会社のIT担当者や現地の日本人管理者から「今年から本社の要求が急に細かくなった」という相談を受けることが増えています。その背景には、制度そのものの改訂があります。まずここを押さえないと、本社からの依頼が「担当者の思いつき」に見えてしまい、現地の協力が得られません。
改訂の公表時期と適用時期
内部統制報告制度の基準・実施基準の改訂は、企業会計審議会から2023年4月7日に公表されました。適用は2024年4月1日以後に開始する事業年度からで、3月決算の会社であれば2025年3月期が最初の対象になります。決算期によって初回適用のタイミングがずれるため、自社がすでに適用済みなのか、これからなのかを最初に確認してください。
つまり多くの日系企業にとって、2026年時点では改訂後の運用が2期目から3期目に入っている段階です。初年度は監査法人も様子見だったが、2期目から具体的な指摘が来始めた、という声はここに由来します。
目的が「財務報告の信頼性」から「報告の信頼性」へ変更された
改訂の考え方として整理されているのが、内部統制の基本的枠組みが掲げる目的を「財務報告の信頼性」から「報告の信頼性」へと変更した点です。財務諸表以外の開示情報も視野に入れる方向づけであり、あわせて不正リスクの評価が明記されました。
ただし、ここには重要な限定があります。金融商品取引法自体は改正されていないため、内部統制報告書が対象とする内部統制は従前どおり「財務報告に係る内部統制」です。つまり、評価・報告の対象範囲が非財務情報にまで一気に広がったわけではありません。
それでも現地の実務にとって意味があるのは、むしろ不正リスクの側です。海外拠点における不正リスクを評価対象として意識せざるを得なくなり、その結果として、財務数値の源になっている業務システムの統制状況を説明する場面が増えます。会計システムだけを見ていれば足りるという整理は、もともと成り立ちません。
数値基準の機械的な適用が否定された
実務上いちばん影響が大きいのがここです。従来は評価範囲を決めるとき、「売上高等のおおむね3分の2」「売上・売掛金・棚卸資産の3勘定」という数値基準が事実上のルールとして使われてきました。改訂では、この数値基準を機械的に適用すべきではないことが明確化され、質的な重要性を勘案してリスクベースで範囲を決める方向へ転換しています。
ここで注意したいのは、これが「範囲が狭くなる」という話ではないことです。売上規模が小さい拠点でも、不正リスクが高い、業務が特殊である、過去に不備があったといった質的な理由があれば評価対象になり得ます。売上構成比が数パーセントしかないタイ子会社が新たに評価対象に入ってきたケースは、この転換の帰結として説明できます。
IT関連でも同じ考え方が適用されました。IT業務処理統制について「3年に1回」といったローテーション評価を年数で機械的に決めるべきではないとされ、クラウド移行やシステム刷新が頻発している環境では毎年評価が必要になり得る、その妥当性は監査人と協議すべき、と整理されています。「去年評価したから今年は飛ばせる」という前提が崩れたということです。
報告書に書く内容が増えた
内部統制報告書の記載事項も追加されました。評価範囲を決定した際の判断事由、用いた指標とその割合の根拠、そして前年度に重要な不備があった場合はその是正状況を、付記事項として記載する義務が加わっています。
これは現地の担当者にとって、作業が1つ増えることを意味します。従来は「範囲に入りました」「入りませんでした」という結論を伝えれば済んでいたところに、なぜその範囲になったのかを本社が文章で説明できるだけの材料を出すことまで求められるようになったからです。現地側が数字と根拠を出せないと、本社の内部統制担当が書けません。
対象企業の規模と、違反した場合の重さ
制度の対象は上場企業およそ3,900社と、その連結子会社です。タイ子会社が連結の範囲に入っているなら、制度の外にいるわけではありません。そして内部統制報告書に虚偽記載があった場合、個人には5年以下の拘禁刑または500万円以下の罰金、もしくはその併科という罰則が定められています。
現地の担当者にこの話をすると空気が変わることがあります。ITGCの整備は「監査法人が細かいことを言ってくる面倒な作業」ではなく、虚偽記載のある報告書を提出した者が刑事罰の対象になり得る制度の一部だという位置づけを共有しておくと、現地の協力体制は作りやすくなります。
IT全般統制(ITGC)の領域|アクセス管理・変更管理・運用管理と外部委託
IT統制対応の中核がIT全般統制、いわゆるITGCです。ここでは領域ごとに、タイ子会社の現場で実際に何を求められるのかを具体化します。

ITGCとIT業務処理統制の関係
まず全体の構造を押さえます。IT統制は大きく、IT全社的統制、IT全般統制(ITGC)、IT業務処理統制の3層で語られます。IT業務処理統制は個別の業務処理が正しく行われることを担保する統制で、たとえば入力値のチェックや自動計算の正確性がこれにあたります。
ITGCはその土台です。ITGCが崩れていると、その上で動く業務処理統制も信頼できなくなる、という関係にあります。どれだけ精緻な自動計算を組んでも、誰でも本番環境のプログラムを書き換えられる状態であれば、その計算結果は信用できません。監査法人がITGCを重視するのはこの理由からです。
用語の整理|ITGCの領域と「3点セット」は別物
現場で混乱しやすい点を先に潰しておきます。内部統制の文脈で「3点セット」と言った場合、通常は業務記述書、フローチャート、リスクコントロールマトリクス(RCM)という3つの文書を指します。一方でITGCの構成要素を語るときの区分は、アクセス管理、変更管理、運用管理といった領域の分け方を指します。解説によっては、これに外部委託の管理を加えて4領域とすることもあります。
この2つは指しているものが違います。本社から「3点セットを出してください」と言われたときに、アクセス管理の資料を送って話が噛み合わない、という事故は実際に起きます。依頼を受けたら、文書のことなのか領域のことなのかを最初に確認してください。
アクセス管理
ITGCの領域のうち、監査法人からの指摘が集中しやすいのがアクセス管理です。求められるのは、誰がどのシステムに何の権限でアクセスできるのかが管理されており、その状態が意図したとおりであることを証跡で示せることです。
具体的には次のような統制が対象になります。
- ユーザーIDの登録・変更・削除が、申請と承認を経て行われていること。
- 権限が業務上必要な最小限に絞られていること。
- 特権IDが限定され、その使用が記録されていること。
- 定期的にID棚卸しを実施し、退職者や異動者のIDが残っていないことを確認していること。
このうち特権IDは、設定やデータを広範に変更できる高い権限を持つアカウントであり、権限の棚卸しとあわせて重点的に見られます。確認の対象になるのは業務システムの中だけではありません。クラウドサービス側の管理者権限、ネットワーク機器へのアクセス、そしてサーバールームの入退室記録という物理アクセスまで含めて確認される点は、現地で見落とされがちです。
単一システムの中で役割をどう分け、承認フローをどう組むかという設計レベルの話は、生産管理システムの権限管理|監査で指摘されない役割設計と承認フローで詳しく扱っています。本記事はその一段上、複数システムを横断して制度対応としてどう束ねるかという視点です。
変更管理
変更管理は、システムへの変更が正規の手続きを経て行われていることを担保する領域です。開発・保守の管理と呼ばれることもあります。
押さえるべき要素は、変更の申請と承認、テストの実施と記録、そして開発環境と本番環境の分離です。この3つのうちタイ子会社でつまずきやすいのは環境分離です。拠点の規模が小さく、サーバーが1台しかない、現地ベンダーが本番環境で直接修正しているといった状態は珍しくありません。
ここで安易に「小規模だから例外扱いにしてほしい」と主張しても、まず通りません。評価範囲に入った以上、拠点の規模の小ささはそれ自体では統制を省略する理由にならず、代わりに何をしているのかを説明する責任が残るからです。分離が難しいのであれば、本番環境での作業を事前申請と事後の作業記録で補うといった代替的な統制を設計し、その妥当性を説明できる形にするほうが現実的です。
運用管理
運用管理は、システムが安定して稼働し続けるための統制です。バックアップの取得、ジョブの監視、障害発生時の対応手順が主な要素になります。
ここで問われるのは「バックアップを取っているか」ではなく「取れていることを確認しているか」です。バックアップジョブが3か月前から失敗し続けていたが誰も見ていなかった、という状態は統制が機能していないと判断されます。取得結果の確認記録が残っているか、復旧テストを実施しているかまでが評価の対象です。
バックアップを実際に復旧まで通せる体制にする考え方は、業務システムのバックアップ体制2026|守れるのはコピーではなく復旧で整理しています。監査対応としても事業継続としても、確認すべき論点は重なります。
4つ目の領域|外部委託の管理
ITGCを4領域で整理する場合、アクセス管理・変更管理・運用管理に加えて外部委託の契約管理が入ります。委託先の選定基準、SLAの明確化、委託先の評価が要素です。
そしてこの領域は、タイ子会社でこそ効いてきます。現地拠点はIT担当が1名から2名という体制が一般的で、サーバー保守、ネットワーク、業務システムの改修を現地ベンダーに委託しているケースがほとんどだからです。委託先が実質的にシステムを触っているのであれば、その委託先の管理状況まで含めて統制を説明する必要があります。
ITGCの領域を整理すると、次のようになります。
| 領域 | 何を担保するか | 現地で求められる主な証跡 |
|---|---|---|
| アクセス管理 | 誰が何にアクセスできるかが意図どおりである | ID申請・承認記録、権限一覧、棚卸し結果、特権ID使用記録 |
| 変更管理 | システム変更が正規の手続きを経ている | 変更申請書、承認記録、テスト結果、リリース記録 |
| 運用管理 | 稼働と復旧が管理されている | バックアップ取得結果の確認記録、障害対応記録、ジョブ監視記録 |
| 外部委託の管理 | 委託先経由のリスクが管理されている | 委託契約書、SLA、作業報告書、委託先の定期評価記録 |
証跡という言葉が繰り返し出てくることに気づいたでしょうか。ITGC整備の実務は、統制を設計する作業と同じくらい、統制が機能したことを後から示せる形で残す作業だと考えてください。
タイ子会社でITGC整備が難航する5つの理由
本社の内部統制担当が作った手順書をそのまま現地に渡しても、うまく回らないことがあります。日本国内の拠点には存在しない制約があるためです。
現地固有の制約を先に洗い出す
海外子会社の内部統制評価に関する実務解説でも、時差や言語の違いによってコミュニケーションに時間がかかること、翻訳作業を事前にスケジュールへ組み込む必要があることが指摘されています。加えて、海外拠点では棚卸資産の現物管理が適切に行われていないことにより、日本と比較して横領などの不正が起こりやすい傾向があるとも整理されています。
タイ子会社に固有の論点を整理すると、次のようになります。
| 制約 | 具体的に起きること | 現実的な対処 |
|---|---|---|
| 言語 | 規程・手順書が日本語のみで、現地スタッフが読めない | 統制文書はタイ語または英語を正本とし、日本語は参照訳に回す |
| 人員規模 | IT担当が1名で、申請者と承認者が同一人物になる | 承認者を業務部門長や日本人管理者に置き、職務分離を人ではなく役割で作る |
| 委託依存 | 実作業を現地ベンダーが行い、社内に記録が残らない | 作業報告書の提出を契約に組み込み、受領確認を社内の証跡にする |
| 離職率 | 担当交代のたびに運用が途切れ、証跡が欠落する | 手順を個人のやり方ではなく様式に固定し、引き継ぎ範囲を文書で定義する |
| 時差と距離 | 本社の依頼が繁忙期に重なり、期限に間に合わない | 評価スケジュールを年度初めに合意し、現地の生産カレンダーと突き合わせる |
この表の中で最も軽視されやすいのが人員規模の行です。IT担当が1名の拠点で「申請者と承認者を分けてください」と言われると、現場は物理的に不可能だと感じます。しかし統制で求められているのは人数ではなく職務の分離なので、承認の役割を業務部門やマネジメント層に渡せば成立します。この読み替えができるかどうかで、現地の負担感は大きく変わります。
具体的には、申請を出す席、内容を承認する席、記録を保管する席を別々に置く形にします。人数が足りないから統制が作れないのではなく、席の役割を分けていないから作れていないだけ、というケースは少なくありません。

親会社の評価にどこまで依拠できるか
もう1つ、費用と工数を左右する論点があります。海外子会社が親会社のシステムを利用している場合、その部分については親会社の評価に依拠できるとされています。タイ拠点が本社の会計システムに接続して使っているのであれば、そのシステムのITGCを現地でゼロから評価し直す必要はありません。
逆に言えば、現地で独自に導入した生産管理システムや現地の会計パッケージは、現地で評価するしかありません。整備を始める前に、対象システムを「本社共通」と「現地固有」に仕分けしてください。この仕分けだけで、現地が負う作業量の見通しが立ちます。
ITGC整備の進め方|5つのステップ
ITGCの整備は、評価対象の範囲を決めるところから始まり、統制を設計して文書化し、整備状況評価と運用状況評価を経て、見つかった不備を是正するという流れで進みます。この順序を守らずに、いきなり手順書を書き始めるプロジェクトが失敗しやすいのは、対象が確定していないまま作業量だけが膨らむからです。
各ステップで何をするか
段階ごとの作業を整理します。
| ステップ | 主な作業 | 主に動く担当 |
|---|---|---|
| 1. 範囲決定と現状把握 | 評価対象システムの洗い出し、本社共通と現地固有の仕分け、リスクの高さの評価 | 本社の内部統制担当と現地IT |
| 2. 統制の設計と文書化 | リスクと統制の洗い出し、規程・手順書・証跡様式の整備 | 現地IT、業務部門長 |
| 3. 整備状況評価 | 統制が設計され文書化されているかを確認 | 現地IT、内部監査 |
| 4. 運用状況評価 | 設計どおりに運用された証跡をサンプルで検証 | 現地IT、内部監査 |
| 5. 不備の是正と記録 | 不備の原因分析と対応、再発防止の仕組み化、評価結果と根拠の記録 | 現地IT、委託先、本社の内部統制担当 |
ステップ3とステップ4の違いは意識しておく価値があります。整備状況評価は「ルールが定められ、業務に適用される形になっているか」を見る作業、運用状況評価は「そのルールが一定期間にわたって実際に守られたか」を証跡のサンプルで見る作業です。手順書を完璧に作っても、その手順に沿った記録が1件も残っていなければ運用状況評価では不備になります。
現実的な着手順
限られた人員で進める場合、着手の順序に工夫の余地があります。おすすめは、証跡の様式を先に作ってしまうことです。ID申請書、変更申請書、バックアップ確認表といった記録の雛形を先に配布し、運用を回し始めてから規程の文言を整えていきます。この順序にすると、規程が完成した時点で数か月分の証跡がすでに溜まっている状態を作れます。
逆に規程の文言から作り始めると、規程が承認されるまで証跡がゼロのまま時間が過ぎ、初年度の運用状況評価でサンプルが取れないという事態になりがちです。制度対応の締切は決算期という動かせない日付なので、証跡が溜まる時間を先に確保するほうが安全です。
内部監査の体制をどう補うか
現地に内部監査の機能がない、あるいは兼任で手が回らないという拠点は多いはずです。この点について、内部監査のアウトソーシングとコソーシングを提供する専門ファームの案内では、企業の海外展開が進み海外拠点のリスクが年々増していることを背景に、海外子会社を含む監査で現地の専門家と共同で対応する体制が示されています。業務の一部だけを外部の専門家と分担するコソーシングという形があることを知っておくと、選択肢が広がります。
すべてを社内で抱えるか、すべてを外に出すかの二択ではなく、どこまでを社内で持ち、どこから先を外部と分担するかという線引きの問題として捉えると、現実的な設計がしやすくなります。この考え方は情報システム部門の機能全般にも当てはまるもので、情シスアウトソーシング タイ2026|丸投げではなく線引きの設計で扱っている切り分けの考え方が、そのまま統制の役割分担にも使えます。
ITGC整備の費用と工数をどう見積もるか
ここが最も知りたい情報でありながら、最も慎重に扱うべき部分です。事実として言えることと、前提を置いた推定を明確に分けて整理します。
公開されている相場|ただし対象範囲に注意
ITガバナンス構築の費用相場を整理した解説では、段階別に次の水準が示されています。
| 段階 | 費用の目安 | 期間の目安 |
|---|---|---|
| アセスメント(現状評価) | 200万〜500万円 | 1.5〜3か月 |
| 構築・導入 | 500万〜1,500万円 | 6〜18か月 |
| 定着支援 | 100万〜300万円 | 3〜6か月 |
この数値を読むときに注意が必要なのは、対象がITGCそのものではなくITガバナンス構築全体である点です。同解説では、J-SOXのIT全般統制はITガバナンスの一部であり、ガバナンス構築を行うとITGCの基盤も同時に整う、という関係で説明されています。したがって上の金額をそのままITGC整備の見積もりとして使うと過大になります。
費用が変動する要因としては、対象プロセス数、拠点数、発注先のランク、成果物の深さの4点が挙げられています。発注先については、大手監査法人系は500万円以上が起点、中堅のコンサルティング会社は200万〜300万円から、独立系や実装まで伴走する形はさらに幅が出る、という差も示されています。同じ解説では従業員300名でIT部門10名規模、COBITの15プロセスに絞った場合のモデルとして約1,300万円、期間約12か月という試算が紹介されていますが、これは想定試算であって実案件の数値ではないと明記されています。
なお、タイ現地でITGC整備支援を委託した場合の費用相場については、信頼できる公開統計を確認できませんでした。現地の人件費水準は日本と異なるため、上記の日本国内の数字をそのまま当てはめることはできません。実額を知りたい場合は、対象システム数と既存文書の有無を整理したうえで複数社から見積もりを取るのが確実です。
社内工数のモデルケース|前提を置いた仮の試算
金額の相場が示せない代わりに、社内でどれだけの手が必要になるかを工数で見立てる方法を示します。以下は公開統計ではなく、次の前提を置いた仮の試算です。実際の工数は既存文書の有無や委託先の協力度で大きく変動します。
前提として置いたのは次の条件です。
- タイ子会社1拠点、従業員100名から300名規模。
- 評価対象システムは現地固有のものが3つ程度。本社共通システムは親会社評価に依拠できるものとする。
- 現地IT担当2名、日本人管理者1名が関与できる。
- 規程類は本社に日本語の雛形が存在するが、現地版はゼロから作る。
この前提での初年度と2年目以降の工数目安は次のとおりです。
| 作業 | 初年度の目安 | 2年目以降の目安 |
|---|---|---|
| 範囲決定と現状把握 | 10〜15人日 | 3〜5人日 |
| 規程・手順書の整備と現地語化 | 15〜25人日 | 3〜5人日 |
| 証跡様式の作成と運用開始 | 10〜15人日 | 2〜3人日 |
| ID棚卸しの実施 | 5〜10人日 | 5〜10人日 |
| 変更・運用記録の整備と蓄積 | 10〜20人日 | 10〜15人日 |
| 監査法人および本社対応 | 10〜15人日 | 8〜12人日 |
合計すると初年度でおおむね60人日から100人日、2年目以降で30人日から50人日という水準になります。IT担当2名の拠点であれば、初年度は年間の稼働の1割から2割を制度対応に取られる計算になります。日常の運用と障害対応を抱えたまま上乗せする作業としては、決して軽くありません。
この試算から読み取ってほしいのは、絶対値そのものではありません。重要なのは、初年度と2年目以降で必要な工数の性質が変わるという点です。初年度は文書を作る一時的な作業が中心ですが、2年目以降に残るのはID棚卸しや記録の蓄積といった継続作業です。この継続分を誰が担うかを決めないまま初年度を乗り切ると、翌年に証跡が途切れて振り出しに戻ります。
そして費用対効果については、過大な期待を持たないほうが健全です。ITGC整備は投資回収を狙う施策ではなく、上場企業グループとして必要な前提条件を満たす作業です。副次的に権限の整理やバックアップ体制の改善といった実務的な効果は出ますが、それを主目的にして稟議を組み立てると、範囲の判断を誤ります。
監査法人対応で指摘されやすいポイント
整備を一通り終えた拠点でも、監査の場で指摘を受けることはあります。頻出するパターンを知っておくと、事前に潰せます。

指摘の典型パターン
現場で繰り返し見かける指摘は、次のようなものです。
- 退職者のIDが有効なまま残っている。人事の退職手続きとIT側のID削除が連動していないケースが典型です。
- 特権IDが共有アカウントになっており、誰が操作したか特定できない。
- 変更の承認記録がメールのやり取りしか残っておらず、承認者と承認時点が特定しにくい。
- バックアップは取得しているが、成功したことを確認した記録がない。
- 現地ベンダーの作業内容が口頭合意で進み、作業報告書が残っていない。
- 規程は整備されているが、実際の運用が規程と異なっており、どちらが正しいのか説明できない。
最後の項目は特に厄介です。規程を理想的に書きすぎると、現実の運用が規程に追いつかず、規程違反という形の不備になります。守れない立派な規程より、守れる範囲で書かれた規程のほうが統制としては強い、という原則を覚えておいてください。
説明できる状態を作る
監査法人の評価でおおむね問われるのは、管理対象に対して必要なルールが定められているか、そして運用がそのルールに従っているかの2点です。そして確認の手段は、記録と証跡が残っているか、権限のある者の承認が得られているかに集約されます。
したがって準備すべきは完璧な統制ではなく、説明できる状態です。不備があること自体は致命傷ではありません。不備が発見されたときに、原因が分析され、是正の計画があり、その進捗が記録されている状態を作れているかどうかが問われます。改訂で前年度の重要な不備の是正状況を報告書に記載する義務が加わったのも、この考え方の延長線上にあります。
現地と本社で用語を揃える
意外に多いのが、言葉の行き違いによる混乱です。本社は日本語の内部統制用語で話し、現地スタッフは英語やタイ語の一般的なIT用語で理解しています。「統制」「不備」「整備状況」「運用状況」といった言葉は、直訳しても意味が伝わりません。
対策として有効なのは、評価開始前に用語対照表を1枚作っておくことです。日本語、英語、タイ語の3列で、この制度対応で使う20語程度を並べるだけで、その後のやり取りの手戻りが目に見えて減ります。翻訳作業をスケジュールに事前に組み込むべきという指摘は、この点にも当てはまります。
よくある質問
ITGC整備の費用はいくらかかりますか
日本国内のITガバナンス構築の相場としては、アセスメントで200万〜500万円、構築・導入で500万〜1,500万円、定着支援で100万〜300万円という水準が示されています。ただしこれはITGCに限定した金額ではなくITガバナンス全体の構築費用であり、ITGCはその一部という関係です。そのまま当てはめると過大になります。
またタイ現地での支援費用については、信頼できる公開統計を確認できていません。見積もりを取る際は、評価対象システムの数、既存の規程・手順書の有無、現地語化が必要な範囲の3点を先に整理してから依頼すると、比較可能な金額が返ってきます。
タイ子会社は親会社のIT統制評価にどこまで依拠できますか
親会社のシステムを利用している部分については、親会社の評価に依拠できるとされています。本社の会計システムに現地から接続して使っているような構成であれば、そのシステムのITGCを現地で重複して評価する必要はありません。
一方で、現地で独自に導入した業務システムや、現地ベンダーが保守しているサーバー・ネットワークは現地で評価する必要があります。整備の初期段階で対象システムを本社共通と現地固有に仕分けることが、無駄な作業を減らす最も効果的な一手です。
IT全般統制の評価は毎年必要ですか
評価範囲に入っている限り、IT全般統制は毎期の評価対象になります。頻度を減らせる余地があるとされてきたのは、IT全般統制が有効であることを前提にしたIT業務処理統制のローテーション評価のほうです。まずこの2つを混同しないでください。
そのローテーション評価についても、制度改訂により「3年に1回」といった年数で機械的に頻度を決めるべきではないことが明示されました。クラウド移行やシステム刷新が頻発する環境では毎年の評価が必要になる可能性があり、その妥当性は監査人と協議すべきとされています。「昨年評価したから今年は不要」という判断を自社だけで下すのは避け、システム構成に変更があった年は特に、評価頻度の考え方を監査法人と事前にすり合わせておくほうが安全です。
まとめ
内部統制のIT統制対応について、タイ子会社の実務で押さえるべき点を整理します。
- 制度改訂は2023年4月7日に公表され、2024年4月1日以後開始事業年度から適用。3月決算会社は2025年3月期が最初の対象。
- 内部統制の基本的枠組みが掲げる目的が「財務報告の信頼性」から「報告の信頼性」へ変更され、不正リスクの評価が明記された。ただし内部統制報告書が対象とする内部統制は従前どおり財務報告に係る内部統制。
- 評価範囲の数値基準の機械適用が否定され、質的重要性によるリスクベースの判断に転換した。売上構成比の小さい拠点も対象になり得る。
- IT業務処理統制のローテーション評価も年数で機械的に決めるべきではないとされ、頻度は監査人と協議する前提になった。
- ITGCの領域はアクセス管理、変更管理、運用管理の3つに、外部委託の管理を加えた4区分で捉える。委託依存の高いタイ拠点では4つ目が重要になる。
- 進め方は範囲決定、統制の設計と文書化、整備状況評価、運用状況評価、不備の是正という順。証跡の様式を先に配って運用を回し始めると初年度が楽になる。
- 費用の公開相場はITガバナンス構築全体のものであり、ITGC単体に当てはめると過大になる。タイ現地の相場は公開統計が確認できないため、複数社の見積もりで確かめる。
制度対応は締切が動かせない一方で、現地の体制は急には増えません。だからこそ、どこまでを社内で持ち、どこから外部と分担するかの線引きを早い段階で決めることが効いてきます。TOMAS TECHはバンコクを拠点に、日系製造業向けの生産管理システムやエネルギー管理システムの構築・運用を手がけており、現地のIT体制づくりや権限管理・バックアップ運用の見直しにも関わっています。自社のシステムがどこまで評価対象になりそうか、現地の人員で回せる形にどう落とすか、といった検討段階のご相談も承っていますので、お問い合わせフォームからお気軽にお声がけください。