監査の実施

監査調書は、監査の検査、議論、観察に関する重要証拠書類です。監査の監視と透明性が継続して即時利用できるように、調書の管理がリアルタイムで一元化、自動化される必要があります。この記事では、プロジェクトアプリを使用した監査の実行方法について説明します。

この記事では、小規模から中規模の監査職務およびチームに役立つ、作業計画ワークフローを使用した監査の実行方法について説明します。この記事で概説されているワークフローは、単純な監査に適しており、監査チームが実行する一連の手順や手続き、およびそれらの手順の結果のドキュメントから構成されています。これは、1 つのアプローチにすぎませんが、他のプロジェクトの種類を使用して同じまたは類似した目標を達成できます。

監査の実施にはどのような意味があるか?

監査の実施には、次のような様々な活動が関わっています:

リスク評価の実行
手続きの実行
証拠のレビューと分析
観察と問題の文書化
暫定の結論と推奨の草稿
クライアントと他のチームメンバーとの相談

監査を実行した結果、問題の特定と改善が行われます。

どこで監査を実施するか?

プロジェクトアプリを使用して監査を実施します。

全体像

プロジェクトテンプレートは、1 つ以上の監査を構築する出発点として使用され、必要に応じて修正可能です。
プロジェクトは、目標、リスク、および手続きの文書化をはじめ、実地調査の文書化、問題の把握に使用されます。
フレームワークは、複数のプロジェクト間で同じ情報を構成、管理するために使用されます。 1つのフレームワークを使用して、複数のプロジェクト間で、同じ目標、説明文、リスク、統制、およびテスト計画を同期します。

When you make changes to the above elements in a project, you can sync those changes back to the framework the project is associated with, so you can apply those changes to all other projects associated with that framework. This is particularly helpful for audits that happen regularly. For more information, see プロジェクトとフレームワークの同期化.

プロジェクト内で、監査作業の範囲は、さまざまな段階を通じて誘導され、一連のタブに表示されます。

カテゴリは次のとおりです。

プロジェクト計画活動
実地調査の文書化
実行した作業の品質保証レビューの実行
監査結果に関する報告、および推奨事項の経営陣への提供
問題の記録と改善

手順

ツアーに向けて準備完了?

これらの機能を文脈でより詳しく見ていきましょう。

1. プロジェクトを作成する

適切に報告できるようにシステムにデータを設定する最良の方法を理解することが、最初の手順です。プロジェクトを作成して、目標、リスク、および手順を定義し、手続きを実行し、報告目的で情報を収集できます。構造のタグ付けを設定し、目標、リスク、および手続きを関連する文脈のデータポイント (アセット、所有者、エンティティなど) にマッピングでき、これらの次元で報告を有効にすることもできます。

ヒント

プロジェクトアプリは、特定のワークフローに事前作成されたコンテンツを含む、複数のリスクと統制のライブラリ (プロジェクトテンプレート) を提供します。一般的に、さまざまなプロジェクトテンプレートを使用して、監査を活発に行い、再使用可能なテンプレートを作成します。カテゴリは次のとおりです。

内部監査（運用）テンプレート
SOC/SSAE 16/ISAE 3402 監査テンプレート
内部監査（財務 & 内部統制）テンプレート
サーベンスオクスリー法（SOX 法）の監査テンプレート（COSO 2013 フレームワーク）

プロジェクトを設定する

監査が運用可能か、またはさらに包括的かどうかにより (SOX または ICFR レビューなど)、プロジェクトワークフローの 2 つの異なる種類から選択できます。ユーザーがプロジェクトを設定後に、プロジェクトは監査でシンプルなワークフローを実行します。これにより、関連する監査の手続きを特定し、問題を管理できます。

組織的なエンティティ構成のモデルを作る

組織はさまざまな事業単位、部門、場所、地域、および法人組織から構成されています。自分の監査管理プロセスで担当業務と法人構造を具現化できます。これにより、テスト結果と問題について経営陣と監査委員会に報告できます。

監査リスク評価を実行する

組織は一般的に、リスクの体系的な特定と評価に従事します。監査リスク評価は、ビジネスに影響を与える運用リスクを評価し、最初に軽減すべきリスクの優先順位付けをする手段を提供します。運用セグメント、エンティティ、または事業単位にわたり使用可能な共通の評価基準を策定し、定義されたスコアリングフレームワークに基づき、運用リスクのスコアを付けることができます。

ヒント

運用リスクの手動でのスコア付けを回避するには、評価ドライバーを使用し、さまざまなリスク評価を自動化することができます。リザルトアプリで作成されたメトリクスをプロジェクトのリスク評価にリンクさせ、評価を通知し、事前定義されたメトリクスの範囲に基づき、固有のリスクスコアを自動入力します。

例を見る

例

シナリオ

組織は、成熟した再定義された運用リスク評価プロセスを有しており、3 段階で 2 つの次元 (発生可能性と影響度) にわたりリスクを評価します。

1 - 低
2 - 中
3 - 高

ここで、あなたは固有のリスクスコアを評価し、統制または他の軽減要因が実施されない場合に、組織が直面する未熟なリスクを特定する必要があります。

プロセス

ヘルプトピック

Latex Facility Security Review プロジェクト内では次の情報を把握します。

リスク 4-A: 緊急時には、施設セキュリティと活動は中断される可能性があります。

影響度 2 - 中
発生可能性 2 - 中

リスク 4-B: 検査時に安全性要件を満たしていない場合は、罰金か、閉鎖を含むその他の罰則が科される場合があります。

影響度 1 - 低
発生可能性 3 - 高

結果

固有のリスク評価が完了しています。

2. 証拠を収集、評価、および文書化する

証拠の収集、評価、および文書化には、さまざまな活動が含まれています。品質保証のレビューは、プロジェクト作業が完了するときに実施できます。上級監査人は、コーチングメモとレビューコメントを容易に追加し、下級のチームメンバーにその他のタスクを割り当てることができます。プロジェクトアプリは、完了すべきタスクについてチームメンバーに電子メールを自動送信し、通知して、レビュープロセスに彼らを参加させます。

ヒント

iOS または Android 向けの Diligent HighBond を使用し、監査チームは、様々なチームメンバーの物理的な場所に関わらず、中断されることなく調書にリアルタイムにアクセスすることができます。

手続きを実行する

監査人は、実施した手続きの結果を記録できます。手続きを実行する場合、プロジェクトはテスト結果と問題を自動的に集約し、保証をリアルタイムに計算します。

ヒント

プロジェクトアプリとリザルトアプリを使用すると、効率的かつ全母集団のテストのための自動化アナリティクスに調書の証拠を直接リンクさせることができます。組織の実際のデータに基づいた真にアナリティクス主導のリスク評価を行うと、経営陣は、さまざまな報告書や最新情報を収集する必要なく、いつでも組織のリスクの正確な状態を知ることができます。リスク評価は、固有のリスクと軽減努力を自動的に考慮し、残余リスクの定量化予測を提供します。

問題を特定する

監査人は、監査プロセス全体で改善のために警告された問題の把握と割り当てを行うことができます。問題を所有者に権限委譲し、状況と関連する行動計画を更新することができます。容易な追跡、証拠の把握、および解決ができるよう、アクションを関係者に割り当てることもできます。

例を見る

例

シナリオ

手続き 4-03 に失敗したため、あなたは問題をログ記録することで、例外を記録する必要があります。調書内に、問題と、その問題を把握した理由の背景を追加したいと考えています。

プロセス

ヘルプトピック問題の記録

次の問題を文書化します。

タイトル/見出し期限切れの消火器
説明期限切れの消火器が、施設の西玄関の横で見つかりました。
所有者ビルの管理者
問題の種類調査結果
特定された日付日付
重要度低
公開済み公開済み

消火器の監査が終了したら、承認し、上司を次のレビュー担当者に設定して自分の作業を承認してもらいます。

結果

問題が把握されています。後日、監査では、改善計画をレビューし、不備が実際に改善されたかどうかを判断するために再テスト結果を文書化できます。

時間を記録する

部門長は、タイムシートアプリを使用し、稼働率で、個々のリソースのパフォーマンスを測定できます。労働時間数など、特定のプロジェクトに割り当てられたスケジュール済みリソースについて洞察を得ることができます。さらに、特定のプロジェクトの収益性全体および投資利益率（ROI）を測定し、レポートを生成できます。

要求の管理

プロジェクトサイクルのいずれかの時点で、監査人は、プロジェクトアプリ内で直接クライアントの要求を送信、追跡し、整理されるすべてのコミュニケーションのスレッドと要求される項目を保持することができます。自動プロンプトを定期的に送信し、プロジェクトの参加者に未処理の要求をリマインドするようプロジェクトを構成することもできます。

例を見る

例

シナリオ

あなたは次の手続きを実行する準備ができています。

3-02 週末は、施設の主要玄関 (デンバーの南 1 (DV1) とロサンゼルスの南 2 (LA1)) のみがキーカードでの入館が許可されています。

この手順を実行する前に、ビルのキーカードのアクセスログをレビューする必要があります。手続きの実行を進められるように、アクセスログの要求を送信したいと考えています。

プロセス

ヘルプトピック要求の追加

［要求］パネルで次の要求項目を把握します。

要求元氏名
説明分析できるようにアクセスロゴを送ってください。
所有者ビルの管理者
今すぐ送信選択済み
電子メール電子メール
期限 2018 年 7 月 27 日

結果

要求項目が把握され、通知がビルのマネージャーに送信されます。ビルのマネージャーは、要求を閲覧し、要求されたアクセスログをアップロードできます。

3. 問題の改善を管理する

監査の主な結果は、問題の管理、フォローアップ、および改善です。改善フェーズには、問題のライフサイクルの管理と、これらの問題への経営者の回答の入手が必要となります。問題を特定、カタログ化、および評価し、また改善アクションに分類できます。さらに、問題を報告目的でより大きいテーマに要約することもできます。

改善計画を定義する

監査人は多くの場合、経営陣と連携し、問題への回答が適切に記述され、根本原因に対処するよう徹底します。該当する所有者に問題を割り当てることで、問題の所有者は、独自の経営陣の回答またはアクション計画を入力し、責任者、対応策、および完了までの時間枠を記述できます。

例を見る

例

シナリオ

あなたは、改善計画を記録し、防火計画の懸念に取り組み、フォローアップの対策としてアクションを記録する必要があります。

プロセス

ヘルプトピック

［フォローアップと改善］サブタブから、改善の進捗状況を経営陣の対応待ちとして指定します。改善計画の一環として、防災計画をレビューし、すべての要件を確実に満たすために、経営陣に対し方向性を明記します。最後に、問題に対処すべく 2 つのアクションを作成します。

結果

アクションが把握されます。

問題を再テストしてクローズする

監査人は、経営陣に働きかけ、問題を再テストし、継続する調査結果を記録します。問題が実際に改善されたかどうかを明記し、改善活動の進捗状況に関して監査委員会に報告を返します。

例を見る

例

シナリオ

両方のアクションが達成されました。消火器は交換され、経営陣は防災計画をレビューしました。消火器を再検査し、これらが交換されたことが分かりました。経営陣が防災計画をレビューし、コンプライアンスを確保たことが分かりました。

プロセス

ヘルプトピック

再テスト結果を記録し、問題が実際に改善されたことを確認します。

再テスト結果の概要

消火器は検査、交換され、防災計画がレビューされました。

そこで、問題とアクションをクローズします。

結果

再テスト結果は把握され、項目は、クローズされて、報告のための準備が整いました。

次の手順

結果を監視して伝える方法を学習する

リザルトアプリを使用して、例外の特定と管理、データの文脈を述べる回答者からの情報の収集、そして傾向、パターン、または異常値を浮き彫りにするためのデータの可視化を行うことができます。ストーリーボードアプリでは、単一のプレゼンテーションで複数の視覚化とリッチテキストコンテンツを表示できます。

詳細については、結果の監査と連絡を参照してください。

アカデミーのコースを受講する

PROJ 100 学習パスを受講して、引き続きこの記事で紹介したコンセプトに関する知識を確立しましょう。

アカデミーは、Diligent のオンライントレーニングリソースセンターです。 Diligent One サブスクリプションのユーザーは、アカデミーコースを無償で受講できます。詳細については、アカデミーを参照してください。

監査の実施