監査支援

重要: このスキルは SOX コンプライアンスワークフローをサポートしていますが、監査またはリーガルアドバイスは提供しません。すべてのテストワークペーパーおよび評価は、適格な財務専門家によってレビューされるべきです。「significance」および「materiality」はコンテキスト固有の概念であり、最終的には監査人によって評価されますが、このスキルは専門家が効果的な内部統制を作成・評価し、監査向けドキュメンテーションを準備するのをサポートすることを目的としています。

SOX 404 コントロールテスト方法論、サンプル選択アプローチ、テストドキュメンテーション基準、コントロール欠陥の分類、および一般的なコントロールタイプ。

SOX 404 コントロールテスト方法論

概要

SOX第404項は、経営者に財務報告に関する内部統制(ICFR)の有効性を評価することを要求しています。これには以下が含まれます:

1. スコーピング: 重要な勘定科目および関連する主張を特定する
2. リスク評価: 各重要な勘定科目について、重大な誤表示のリスクを評価する
3. コントロール特定: 各リスクに対応するコントロールを文書化する
4. テスト: 主要なコントロールの設計および運用効果性をテストする
5. 評価: 欠陥が存在するか、その重大性を評価する
6. 報告: 評価および重大な欠陥を文書化する

重要な勘定科目のスコーピング

勘定科目が重要である場合とは、個別にまたは集計で重大である可能性のある誤表示を含む可能性が低くない場合です。

定量的要因:

• 勘定科目残高が materiality 閾値を超過している(通常、主要なベンチマークの3～5%)
• 取引量が多く、エラーのリスクが高い
• 勘定科目が重大な見積もりまたは判断の対象である

定性的要因:

• 勘定科目が複雑な会計を含む(収益認識、デリバティブ、年金)
• 勘定科目が不正に容易である(現金、収益、関連当事者取引)
• 勘定科目に過去の誤表示または監査調整がある
• 勘定科目が経営者の重大な判断または見積もりに関連している
• 新しい勘定科目または大幅に変更されたプロセス

勘定科目タイプ別の関連する主張

勘定科目タイプ	主要な主張
収益	発生、完全性、正確性、期間中の受取
売掛金	存在、評価(引当金)、権利
在庫	存在、評価、完全性
固定資産	存在、評価、完全性、権利
買掛金	完全性、正確性、存在
見積負債	完全性、評価、正確性
資本	完全性、正確性、表示
財務クローズ/報告	表示、正確性、完全性

設計有効性対運用有効性

設計有効性: コントロールは、関連する主張における重大な誤表示を防止または検出するために適切に設計されていますか？

• ウォークスルーを通じて評価する(トランザクションをプロセス全体にわたって終始トレースする)
• コントロールがプロセス内の適切なポイントに配置されていることを確認する
• コントロールが特定されたリスクに対応していることを確認する
• 少なくとも年1回、またはプロセスが変更されたときに実施する

運用有効性: コントロールはテスト期間を通じて実際に設計通りに運用されましたか？

• テスト(検査、観察、再実施、質問)を通じて評価する
• 結論を裏付けるための十分なサンプルサイズが必要である
• 依拠の全期間をカバーする必要がある

サンプル選択アプローチ

ランダム選択

使用時期: 大規模な母集団を持つトランザクションレベルのコントロールのデフォルト方法。

方法:

1. 母集団を定義する(テスト期間中にコントロールの対象となるすべてのトランザクション)
2. 母集団内の各項目に順序番号を付ける
3. 乱数生成器を使用してサンプル項目を選択する
4. 選択にバイアスがないことを確認する(すべての項目が等しい確率を持つ)

利点: 統計的に有効、防御可能、選択バイアスなし 欠点: 高リスク項目を見落とす可能性がある、完全な母集団リストが必要である

ターゲット(判断的)選択

使用時期: リスクベーステスト用のランダム選択の補足。母集団が小さいまたは非常に多様な場合の主要な方法。

方法:

1. 特定のリスク特性を持つ項目を特定する:
   • 高額の項目(定義された閾値を超過)
   • 異常または非標準的なトランザクション
   • 期末トランザクション(期間中の受取リスク)
   • 関連当事者取引
   • 手動またはオーバーライドトランザクション
   • 新しいベンダー/顧客トランザクション
2. リスク基準に合致する項目を選択する
3. 各ターゲット選択の根拠を文書化する

利点: 最高リスク項目に焦点を当てる、テスト努力の効率的利用 欠点: 統計的に代表的ではない、特定のリスクを過度に表現する可能性がある

恣意的選択

使用時期: ランダム選択が実用的でない場合(順序付き母集団リストなし)、かつ母集団が比較的均質である場合。

方法:

1. 特定のパターンまたはバイアスなしに項目を選択する
2. 選択が全母集団期間にわたって分散していることを確認する
3. 無意識のバイアスを回避する(常に上部の項目、丸い数字を選ばない)

利点: シンプル、テクノロジーが不要 欠点: 統計的に有効ではない、無意識のバイアスに容易である

体系的選択

使用時期: 母集団が順序付けられており、期間全体に対して均等なカバレッジを希望する場合。

方法:

1. サンプリング間隔を計算する: 母集団サイズ / サンプルサイズ
2. 最初の間隔内からランダムな開始点を選択する
3. 開始点からすべてのN番目の項目を選択する

例: 1,000の母集団、25のサンプル → 40の間隔。ランダム開始: 項目17。項目17、57、97、137、...を選択する

利点: 母集団全体にわたって均等なカバレッジ、実施が簡単 欠点: 母集団の周期的パターンが結果にバイアスをもたらす可能性がある

サンプルサイズのガイダンス

コントロール頻度	予想される母集団	低リスクサンプル	中程度リスクサンプル	高リスクサンプル
年1回	1	1	1	1
四半期1回	4	2	2	3
月1回	12	2	3	4
週1回	52	5	8	15
日1回	約250	20	30	40
トランザクションごと(小規模母集団)	< 250	20	30	40
トランザクションごと(大規模母集団)	250+	25	40	60

サンプルサイズを増加させる要因:

• 勘定科目/プロセスの固有リスクが高い
• コントロールが重大なリスクに対応する唯一のコントロールである(冗長性なし)
• 前期においてコントロール欠陥が特定されている
• 新しいコントロール(前期でテストされていない)
• 外部監査人が経営者テストに依拠している

テストドキュメンテーション基準

ワークペーパー要件

すべてのコントロールテストは以下により文書化されるべきです:

1. コントロール特定:

   • コントロール番号/ID
   • コントロール説明(何が、誰によって、どのくらいの頻度で行われるか)
   • コントロールタイプ(手動、自動化、IT依存手動)
   • コントロール頻度
   • 対応するリスクおよび主張

2. テスト設計:

   • テスト目的(何を決定しようとしているか)
   • テスト手順(段階的な指示)
   • 予想される証拠(コントロールが有効である場合に予想される内容)
   • サンプル選択方法論および根拠

3. テスト実施:

   • 母集団説明およびサイズ
   • サンプル選択の詳細(方法、選択された項目)
   • 各サンプル項目の結果(合格/不合格、検査した具体的な証拠)
   • 記載される例外とその詳細説明

4. 結論:

   • 全体的な評価(有効/欠陥/重要な欠陥/重大な欠陥)
   • 結論の根拠
   • すべての例外に対する影響評価
   • 代替コントロールの検討(該当する場合)

5. 署名:

   • テスト実施者の名前と日付
   • レビュアー名と日付

証拠基準

十分な証拠には以下が含まれます:

• システムで強制されたコントロールを示すスクリーンショット
• 署名/イニシャルが入った承認文書
• 識別可能な承認者と日付を含むメール承認
• 誰がアクションを実行したか、およびいつ実行したかを示すシステム監査ログ
• 一致した結果で再実施された計算
• 観察メモ(日付、場所、観察者を含む)

不十分な証拠:

• 単独の口頭確認(確証が必要)
• 日付のない文書
• 識別可能な実行者/承認者のない証拠
• 日付/タイムスタンプのない一般的なシステムレポート
• 確証文書のない「[名前]との議論による」

ワークペーパーの整理

テスト文書をコントロール領域別に整理します:

SOX Testing/
├── [Year]/
│   ├── Scoping and Risk Assessment/
│   ├── Revenue Cycle/
│   │   ├── Control Matrix
│   │   ├── Walkthrough Documentation
│   │   ├── Test Workpapers (one per control)
│   │   └── Supporting Evidence
│   ├── Procure to Pay/
│   ├── Payroll/
│   ├── Financial Close/
│   ├── Treasury/
│   ├── Fixed Assets/
│   ├── IT General Controls/
│   ├── Entity Level Controls/
│   └── Summary and Conclusions/
│       ├── Deficiency Evaluation
│       └── Management Assessment

コントロール欠陥の分類

欠陥

内部統制の欠陥は、コントロールの設計または運用により、経営者または従業員が割り当てられた機能を実行する通常の過程において、重大な誤表示を適時に防止または検出することができない場合に存在します。

評価要因:

• コントロール失敗が重大な誤表示をもたらす可能性はどの程度か?
• 潜在的な誤表示の大きさはいくらか?
• 欠陥を緩和する代替コントロールがあるか?

重要な欠陥

重大な欠陥より軽微だが、統治責任者による注意に値するほど十分に重大な欠陥、または複数の欠陥の組み合わせ。

指標:

• 欠陥が、軽微よりは大きいが重大より小さい誤表示をもたらす可能性がある
• 重大な誤表示の可能性が低くない(しかし合理的に可能性が高い以下)である
• コントロールが主要コントロールであり、欠陥が代替コントロールにより完全には緩和されていない
• 個別には軽微な欠陥の組み合わせが、共に重大な懸念を表現している

重大な欠陥

欠陥、または複数の欠陥の組み合わせであり、財務諸表の重大な誤表示が適時に防止または検出されないという合理的な可能性が存在します。

指標:

• 上級経営者による不正の特定(すべての規模)
• 重大なエラーを修正するために以前に発行された財務諸表の再表示
• 監査人による会社のコントロールでは検出されなかったであろう重大な誤表示の特定
• 監査委員会による財務報告の無効なオーバーサイト
• 複数のプロセスに影響を与える普遍的なコントロール(エンティティレベル、IT一般コントロール)の欠陥

欠陥の集計

個別には重大ではない個々の欠陥は、組み合わせでは重大である可能性があります:

1. 同じプロセスまたは同じ主張に影響を与えるすべての欠陥を特定する
2. 組み合わせた影響が重大な誤表示をもたらす可能性があるかを評価する
3. 代替コントロールの欠陥が他の欠陥を悪化させるかどうかを検討する
4. 集計分析および結論を文書化する

是正

特定された各欠陥について:

1. 根本原因分析: なぜコントロールが失敗したのか?(設計ギャップ、実行失敗、人員配置、訓練、システムの問題)
2. 是正計画: コントロールを修正するための具体的なアクション(再設計、追加訓練、システム拡張、追加レビュー)
3. タイムライン: 是正完了の目標日
4. 責任者: 是正の実施責任者
5. 検証: 是正されたコントロールの有効性を確認するために、どのように、いつ再テストするか

一般的なコントロールタイプ

IT一般コントロール(ITGC)

アプリケーションコントロールおよび自動化プロセスの信頼性の高い機能をサポートするIT環境のコントロール。

アクセスコントロール:

• ユーザーアクセスプロビジョニング(新しいアクセスリクエストは承認が必要)
• ユーザーアクセスデプロビジョニング(終了ユーザーは適時に削除)
• 特権アクセス管理(管理者/スーパーユーザーアクセスは制限および監視)
• 定期的なアクセスレビュー(ユーザーアクセスは定義されたスケジュールで再認定)
• パスワードポリシー(複雑性、ローテーション、ロックアウト)
• 職務分離の強制(矛盾するアクセスを防止)

変更管理:

• 実装前に変更リクエストが文書化および承認されている
• 変更は本番環境以外の環境でテストされてから昇格される
• 開発環境と本番環境の分離
• 緊急変更手順(事後承認で文書化、承認)
• 変更レビューおよび事後実装検証

IT運用:

• バッチジョブ監視および例外処理
• バックアップおよびリカバリー手順(定期的なバックアップ、テスト済みリストア)
• システム可用性およびパフォーマンス監視
• インシデント管理およびエスカレーション手順
• 災害復旧計画およびテスト

手動コントロール

判断を使用して人々によって実行されるコントロール、通常はレビューと承認を含みます。

例:

• 財務諸表およびキーメトリクスの経営者レビュー
• 閾値を超えるジャーナルエントリの管理者承認
• 三者間マッチング検証(PO、受取、請求書)
• 勘定科目調整の準備およびレビュー
• 物理的な在庫観察およびカウント
• ベンダーマスターデータ変更承認
• 顧客信用承認

テスト時の主要な属性:

• コントロールが適切な権限を持つ人によって実施されたか?
• 必要な期限内に適時に実施されたか?
• レビューの証拠があるか(署名、イニシャル、メール、システムログ)?
• レビュアーは効果的なレビューを実施するための十分な情報を持っていたか?
• 例外が特定され、適切に対応されたか?

自動化コントロール

人的介入なしにITシステムで強制されるコントロール。

例:

• システムで強制される承認ワークフロー(必要な承認なしに進むことはできない)
• 三者間マッチ自動化(PO/受取/請求書が一致しない場合、システムが支払いをブロック)
• 重複支払検出(システムが重複請求書にフラグを立てるまたはブロック)
• クレジットリミット強制(システムがクレジットリミットを超過する注文を防止)
• 自動計算(減価償却費、償却、金利、税金)
• システムで強制される職務分離(矛盾する役割を防止)
• 入力検証コントロール(必須フィールド、フォーマットチェック、範囲チェック)
• 自動調整マッチング

テストアプローチ:

• テスト設計: システムコンフィグレーションが意図されたとおりにコントロールを強制することを確認する
• 運用効果性テスト: 自動化コントロールの場合、システムコンフィグレーションが変更されていなければ、1つのコントロールテストは通常期間に対して十分です(ITGC変更管理のテストで補足)
• 変更管理ITGCが有効であることを確認する(システムが変更された場合、コントロールを再テスト)

IT依存手動コントロール

システムが生成した情報の完全性と正確性に依存する手動コントロール。

例:

• システムが生成した例外レポートの経営者レビュー
• 引当金評価のためにシステムが生成した加齢レポートの監督者レビュー
• システムが生成した試算表データを使用した調整
• システムが生成したワークフローで特定されたトランザクションの承認

テストアプローチ:

• 手動コントロールをテストする(レビュー、承認、例外のフォローアップ)
• そして、基礎となるレポート/データの完全性と正確性をテストする(IPE — エンティティが生成した情報)
• IPEテストは、レビュアーが依拠したデータが完全かつ正確であったことを確認する

エンティティレベルコントロール

組織レベルで運用し、複数のプロセスに影響を与える幅広いコントロール。

例:

• トーン・アット・ザ・トップ/行動規範
• リスク評価プロセス
• 財務報告の監査委員会オーバーサイト
• 内部監査機能および活動
• 不正リスク評価およびアンチフラウドプログラム
• 内部告発者/倫理ホットライン
• コントロール有効性の経営者監視
• 財務報告の適格性(人員配置、訓練、適格性)
• 期末財務報告プロセス(クローズ手順、GAAP準拠レビュー)

重要性:

• エンティティレベルコントロールは緩和することができますが、通常はプロセスレベルのコントロールに置き換わることはできません
• 無効なエンティティレベルコントロール(特に監査委員会のオーバーサイトおよびトーン・アット・ザ・トップ)は、重大な欠陥の強い指標です
• 効果的なエンティティレベルコントロールは、プロセスレベルコントロールに必要なテストの範囲を削減できます