それは、私たちが認めたくないほど多くのリスクとコンプライアンス・プログラムを脱線させる質問である。
"これは誰のものか？"
発見事項が何ヶ月も解決されないままだと、会議で話題になる。監査準備では、重要な管理が見直されていないことが表面化する。そしてそれは、回避可能な何かが抜け落ちた直後の事後調査にも現れる。
誰もが問題には気づいているが、それを解決するのが誰の仕事なのかは誰も知らない。
GRCの綻びはオーナーシップにある
GRCの失敗のほとんどは過失に起因するものではない。誰も明確な説明責任を果たさなかったために起こるのだ。リスクは記録されるが、そのまま放置される。発見事項は把握され、ラベル付けされ、追跡されるが...実際にはクローズアウトされない。コントロールが失敗しても誰もフォローアップしない。第三者から指摘を受けたが、エスカレーションされない。
人々が自分の仕事をしていないからではなく、システムが彼らの仕事だと言わなかったからだ。
タスクが一般的な役割に割り当てられたり、受信トレイが共有されたりすることがあまりにも多い。期限は設定されるが、フォローアップされることはほとんどない。改善ステップはメールやミーティングで非公式に行われ、プラットフォームに戻されることはない。レポーティングは表面上はきれいに見えるが、深く掘り下げてみると、誰が（いつ）何をしたのか、なぜそうしたのかの痕跡がない。
コラボレーションが盛んなこの世界で、GRCはあいまいさに苦しんでいる。そして曖昧さはフォロースルーを殺す。
文書だけでは不十分。説明責任が必要
リスクの把握や問題の記録は、仕事の半分でしかありません。次に何が起こり、どのように追跡され、どのように解決されるかは、ほとんどのシステムが破綻するところである。
健全なGRCプログラムは、情報を保存するだけではありません。責任を可視化するのだ。罰則的な方法ではなく、「何が期待されているかを全員が知っている」という実践的な方法である。
それは、部門ではなく個人にアイテムを割り当てることから始まる。全員がそれを所有するなら、誰もそれを所有しない。特定の担当者が、行動するためのツールと、次に何が起こるかを知るための明確さをもって、フックになる必要がある。
それはまた、所有権をシステム全体で可視化することでもあり、細かい文字に埋もれることでもない。ダッシュボードやレポートには、誰が責任者なのか、何が期限を過ぎているのか、状況はどうなっているのかを示すべきである。期限が過ぎたら、誰かがフォローアップすることを忘れてはならない。遅れを自動的に把握し、適切な担当者を促し、必要な場合にはエスカレーションを行うべきである。
そして最も重要なことは、アカウンタビリティは検出の段階で終わるべきではないということだ。コントロールが機能しなかったり、リスクが移動したりした場合、プラットフォームは特定から解決までのライフサイクル全体をサポートすべきである。つまり、ワークフローに改善ステップを組み込むということであり、ユーザが切断されたシステム間でアップデートを追いかけることを期待するものではない。
説明責任は設計上の問題であり、性格上の欠陥ではない
物事がうまくいかないとき、人のせいにするのは簡単だ。しかし、本当の問題は構造的なものであることが多い。
もしシステムが、誰が何を所有しているのかを把握することを困難にし、フォロースルーの方法が組み込まれておらず、レポートが現実を反映していなければ、もちろん物事は失敗に終わるだろう。説明責任は手作業で維持するものではありえない。アーキテクチャーに組み込まれる必要がある。
なぜなら最終的に、組織で最も危険なリスクは、あなたが文書化したものではないからだ。誰も見ていないリスクなのだ。
最後に思うことGRCは誰かが所有して初めて機能する
優れたGRCとは、完璧な文書化のことではない。それは、所有権が明確で、行動が期待され、誰も何をすべきか迷うことのないシステムを構築することである。
そのような明確さをプラットフォームに組み込めば、"これは誰のものか？"という疑問はなくなり、"これを前進させる最善の方法は何か？"という疑問に変わる。
GRCプログラムを設計して、抜け漏れをなくしたいですか？話し合いましょう。
