TPRM（Vendor Risk Management）の運用設計（体制、役割、運用思想）
TPRMを導入したものの、7つのロールを誰に配り、日々の運用サイクルをどう回せばよいか分からない。そう感じる担当者は多いはずです。ServiceNowのTPRMは vendor_risk_admin から external_assessment_responder まで7ロールを持っています。直接ACLの数も、権限の重なり方も一様ではありません。Australia PDIでベンダー登録からアセスメント1件をDraftからClosedまで完走させ、7ロールの権限構造と運用サイクルの型を実機で確認しました。担当者本人でログインしたときの見え方（4ロールの自動付与・自社データだけが表示される画面）は、本記事だけの実測です。
検証環境：Australia PDI / OOTB / 2026-08-22 確認
TPRMシリーズ（全9本） — 導入から設計・運用・トラブルまで通しで書いています。
誰がどう回すかの運用設計書（この記事）
1. はじめに
1.1 「作り」の記事と「回し方」の記事を分ける
テーブルやスクリプトの作りを追った開発設計書は、TPRMがどう組み立てられているかを扱いました。この記事が扱うのは別の問いです。どのロールを誰に配り、日々のサイクルをどう回すか、という体制の側になります。読む人も使う場面も違うため、分けて作るほうが機能する構成です。この型の運用設計書は、Continual Improvement Managementの運用設計書やProject Portfolio Managementの運用設計書でも使っています。
1.2 対象範囲
対象は2つ。TPRM本体（sn_vdr_risk_asmt）が持つ7ロールと、third party・engagement・assessment・issueという4つの主要テーブルが回る運用サイクルです。導入手順や初期設定の詳しい手順はすでに別記事で扱ったため、この記事では扱いません。Now Assist for Third-Party Risk Management（sn_tprm_genai）はPDIには入れられない設計のため、検証の範囲外です。
1.3 前提となる実機の事実
運用設計に効く実測を先に並べます。数字はすべて実機の値です。7ロールはadmin・manager・reviewer/assessorという3段の継承構造を持ち、admin一人が他アプリのロールまで束ねています。承認専用のapproverロールは、直接ひもづくACLが0件でした。導入すると3つのグループが自動作成されますが、いずれもメンバーは0人で、admin用のグループそのものが存在しません。誰をどのグループに入れるかは、運用側が自分で設計する領域だと分かります。
1.4 用語
vendor_risk_admin / manager / assessor / reviewer / approver：TPRM本体（sn_vdr_risk_asmt）の5ロール
internal_assessment_responder / external_assessment_responder：質問票に回答する側の2ロール
vm_vdr_contact：外部の回答者を表すテーブル。globalスコープでsys_userを継承する旧Vendor Managementの遺構
registration_status：vm_vdr_contactが持つ招待状態。not_sentからsentのように遷移する
Tiering：third partyの重要度を先に決める工程。def_tier_scaleという5段階の尺度を使う
repeating assessment schedule：定期的にアセスメントを再発行するdailyのジョブ
2. 誰が何をするか：7ロールの権限構造
ロールの作り（継承の実装）は開発設計の記事で扱いました。この章では同じ7ロールを「誰に配るか」という運用の視点で扱います。
2.1 admin・manager・reviewer/assessorという3段の継承
vendor_risk_adminの公式説明はこうです。
Vendor Risk Administrator role has full control over all Vendor Risk Management data. Also have full control over Assessment Metric Types.
（訳: Vendor Risk Administratorロールは、Vendor Risk Managementの全データに対して完全な制御権を持つ。Assessment Metric Typesに対しても完全な制御権を持つ）
adminはさらに、他アプリのロールまで束ねています。内訳は次の5件です。
assessment_admin / connection_admin
sn_smart_asmt.assessment_admin
sn_grc_workspace.task_admin
sn_smart_imp_auto.automation_creator
TPRM単体の管理者に見えて、実際にはGRCワークスペースとSmart Assessment基盤の両方に権限が及ぶ設計になっています。
vendor_risk_managerの公式説明はこうです。
Manages third parties, third-party contacts, third-party assessment templates, questionnaire templates, documentation request templates, and scheduled assessments.
（訳: third party・その連絡先・アセスメントテンプレート・質問票テンプレート・書類請求テンプレート・スケジュール済みアセスメントを管理する）
テンプレートとスケジュールという、運用の前提を整える役割だと分かります。
reviewerとassessorは、同じ現場の運用層でも役割が分かれています。vendor_assessment_reviewerの公式説明は「Allows user to edit assessments」（訳: assessmentの編集を許可する）で、編集専用です。vendor_assessorの公式説明はこうです。
Manages third parties, third-party contacts, Third-party Risk Assessments, and issues, and completes third-party risk assessment requests
（訳: third party・その連絡先・Third-party Risk Assessments・issueを管理し、third-party risk assessmentの依頼を完了させる）
reviewerが編集に限られるのに対し、assessorは登録から完了までを実際に動かす側になります。
2.2 approverは直接ACLが0件の承認専用ロール
approverの公式説明はこうです。
Users with this role can approve in the third-party risk management process.
（訳: このロールを持つユーザーは、third-party risk managementプロセスで承認できる）
説明はこの1文だけ。実測では、approverに直接ひもづくACLは0件でした。manager93件、admin10件と比べると際立った少なさです。承認できる権限を持ちながら、承認以外のデータへは直接触れない設計だと読み取れます。
ロールを付けたのに画面が見えないという疑問が出たときの切り分け方は、ロールを付けたのに見えない理由：ACL（sys_security_acl）で扱いました。承認だけを切り出すロール設計の考え方は、承認（Approval）運用設計書とも共通します。
2.3 内部と外部の回答者は、GRCワークスペースに入るかどうかだけで分かれる
internal_assessment_responderとexternal_assessment_responderは、継承元がほぼ同じです。外部側はsn_smart_asmt.actorだけを継承し、内部側はそれに加えてsn_grc_workspace.user・sn_grc_workspace.task_readerを継承します。差は1点だけ。GRCワークスペースへ入れるかどうかです。
直接ACLの内訳はinternal_responder3件、external_responder1件でした。外部からのアクセスを実際に支えているのは、継承元のsn_smart_asmt.actorにひもづく106件のACLです。権限がどの層で決まるかを7層まで広げて整理する考え方は、ServiceNowで権限はどこで決まる？で扱いました。
2.4 自動作成される3グループには、まだ誰も入っていない
導入すると3グループが自動で作られます。メンバーは全員0人でした。
Third-party risk managers（manager＋approver）
Third-party risk reviewers（reviewer）
TPRM compliance managers（approver）
admin用のグループは用意されていません。担当者への割当設計は、この3グループに沿って組みつつ、adminをどこへ入れるかも含めて自社で決める作業になります。
3. 外部の回答者をどう管理するか
3.1 vm_vdr_contactは旧Vendor Managementの遺構
外部の回答者はvm_vdr_contactというテーブルで管理されます。globalスコープでsys_userを継承しており、TPRM本体（sn_vdr_risk_asmt）が持つテーブルではありません。旧Vendor Management時代からの連絡先管理を、新しいTPRMがそのまま流用している構造です。
3.2 プライマリコンタクトが無いと発行できず、回答URLは本人専用
vm_vdr_contactはregistration_statusという招待状態を持ち、not_sentからsentへ遷移します。今回の完走では、担当者を作成した時点でregistration_statusが自動でsentへ進みました。PDIはSMTPが無効なため、実際にメールが飛んだわけではありません。取引先にPrimary contactが1人もいない状態では、アセスメントの発行そのものがエラーになります。登録時点でPrimary contactを必ず1人つけておく運用が要ります。
回答用のURL（/assessment_take2.do）も、割り当てられた本人以外は開けない作りでした。
管理者アカウントでも、割り当てられていない限りは回答画面に入れません。代理入力を運用でカバーする場合は、この制約を踏まえた手順にする必要があります。
では、正しくは誰が開くのか。この画面を本来開くのは、社内の管理者ではなく取引先の担当者（vm_vdr_contact）です。担当者レコードを作成すると、snc_external・sn_smart_asmt.actor・vendor_contact・sn_vdr_risk_asmt.external_assessment_responderの4ロールが自動で付与されます（実測）。この組み合わせが「外部の回答者」の正体です。担当者本人でログインすると、同じURLで質問票が開き、ポータルにも自社の情報だけが表示されます。
運用設計としては、「管理者で確認できないもの」を確認する手段として、テスト用の担当者アカウントを1件用意しておく手順を組み込みます。担当を誰に割り当てるかという設計の基本的な考え方は、担当割り当て運用設計書でも扱いました。
3.3 外部からのアクセスはポータルとワークスペースの2系統に分かれる
外部の第三者がTPRMへ触れる経路は2つあります。ひとつはService Portalの「Third Party Portal - Scoped」（url_suffix=svdp）です。もうひとつはUXワークスペース「GRC: Third Party External Workspace」（landing_path=smart-asmt）で、社内メニューからのリンクは持ちません。
管理者アカウントで/svdpを開くと、third partyのみが使えるページだと拒否されます。担当者本人でログインした場合は、Assessments・Issues・Tasks・Documents・FAQのタブを持つポータルが表示され、見えるのは自社のエンゲージメントと自分のアセスメントだけです。
社内の担当者が代理でポータル側を確認したいときは、この画面には入れない前提で、テスト用の担当者アカウントを使う手順を組む必要があります。
4. 運用サイクルをどう回すか
state遷移の実装（UI ActionとBusiness Ruleの分担）は開発設計の記事の範囲です。1件を流す操作手順は運用手順の記事で扱っています。この章では「どの周期で・誰が回すか」に絞ります。
4.1 Tieringが評価の順番を最初に決める工程になる
third partyの重要度は、Tieringという工程で先に決めます。def_tier_scaleという5段階の尺度が既定で入っており、80〜100が1-Very High、0〜19が5-Very Lowという配点でした。
スコアをどのデータから作るかは既定では決まっておらず、運用側が設計する領域です。有料エリアの運用設計書テンプレートで、決めるべき項目として扱います。
4.2 テンプレート0件から質問票をひもづけて動かす
導入直後、テンプレートは0件。third-party assessment templateを組むところが最初の作業になります。素材となる質問票（asmt_metric_type）はESG・Fourth-party registration・Privacy・Sample・Basicの5件がactiveで用意されています。ただしテンプレートを組むまでは、アセスメントを1件も流せません。初期設定の詳しい手順は導入直後の設定を扱った記事にまとめています。
4.3 発行から完了まで、1件を実際に完走させて確認した
「Standard third-party assessment」というテンプレートに質問票「Basic」（11問）をひもづけました。third party「Meridian Data Services」向けにアセスメントを1件発行し、Closedまで完走させています。
Draft作成の時点で質問票はBusiness Ruleが自動でコピーし、手作業でのひもづけは要りませんでした。Submit実行後もBusiness Ruleがtake_link（回答用URL）を生成し、質問票のインスタンスを自動で組み立てています。回答が完了すると親のstateが「Responses received」へ自動で進み、Finalizeを経てClosedに到達しました。
4.4 観察生成は既定で0件のまま先へ進むことがある
Closedへ向かう途中、canGenerateObservationsForAssessment()という判定を経て「Generating observations」の状態に入ります。今回の完走では、回答内容が良好側だったため、生成された観察（issue）は0件でした。図の点線にある「issueを起票して差し戻す」経路は今回は通らなかった分岐で、判定関数の実装から読み取れる想定にとどまります。観察が0件のまま完了した案件を、回答が本当に良好だったのか判定条件を満たさなかっただけなのか、運用側で見分ける手順を用意しておく必要があります。
4.5 スコアは初期状態で単一指標に事実上絞られている
risk_areaの重み設定は、Third-party Risk Assessmentsだけが100でした。Engagements・Subsidiaries・Risk intelligence ratingは、いずれも0です。risk_area_definitionは12件登録されていますが、有効化されているのはDefault（weight=100）の1件だけです。導入直後の総合スコアは、外部アセスメントの結果だけで決まる単一指標の構成になっています。複数の観点を重ねた評価にするかどうかは、運用を始めてから決める設計判断です。
5. 期限をどう追うか
5.1 18件の通知はすべて有効な状態から始まる
TPRM単独の通知（sysevent_email_action）は18件あり、すべてactiveでした。名前もVendor Risk Issue Assigned (Internal)／(External)のように、内部と外部を分けて用意されています。
5.2 スケジュールジョブ4件のうち、日次で動くのは2本
TPRM固有のスケジュールジョブは4件でした。periodicallyで動くのはRecalculate risk rating upon valid to overdue or criteria changeです。dailyで動くのはClean third-party security scoresとVendor risk repeating assessment scheduleの2件です。残るMigrate industry column（名前にDO NOT RUN THIS MANUALLYと付く移行用ジョブ）はonceでした。
スケジュールジョブは有効になっていても、実際に走っているとは限りません。run_countと次回実行時刻から実行実態を見分ける方法は、ServiceNowのスケジュールジョブは本当に動いている？にまとめています。
5.3 期限が近い案件だけを絞るメニューが用意されている
見る画面も用意済みです。TPRMのメニューには、期限が近いアセスメントだけを絞り込むDue This Week系のビューがあります。通知とスケジュールジョブに加えて、担当者が自分から確認しに行く画面もセットで用意されている構成です。
6. リスク判定にどう気づき、どう対処するか
リスク管理は評価を付けたら終わり、ではありません。判定が出た後に誰が気づき、どの画面で根拠を確かめ、どう是正へつなぐかまで決めて、はじめて運用として成立します。この章のために検証環境へ評価データを投入し、判定が出た後の見え方を実機で確かめました。
6.1 気づく場所は3つに決める：分布チャート・取引先の詳細・通知
リスクの発見経路が人によってバラバラだと、見落としの原因調査ができません。気づく場所を次の3つに固定する設計とします。
日常の監視：Vendor Management Workspaceのホーム。Risk rating by third-party tiersで「重要度が高い列に評価の悪い棒が立っていないか」を見る。Top risk areasで問題の分野の偏りを見る
個別の確認：取引先の詳細画面。ヘッダーのバッジ・Risk areasカード・Issues件数で1社の状態を確かめる
受動的な気づき：通知。18種すべて有効な初期状態を活かし、アセスメント完了・イシュー割当は担当者へメールで届く前提の設計とする
6.2 高リスクと判定された取引先はこう見える
検証で高リスク（rating 2-High）に設定した取引先の詳細画面です。
ヘッダーのバッジで評価と重要度、Risk areasカードでリスクの分野、左ナビのIssuesで是正の有無が読み取れます。分野が分かるため、是正依頼の宛先（セキュリティ担当か、事業継続担当か）までこの画面で決まります。
6.3 対処は「Issueで受けて、期限を切って、再評価で閉じる」を型にする
高リスク判定が出たときの対処を、次の5段階の型として設計します。
判定の確認：取引先詳細のExternal assessmentsから、評価の根拠になった回答を確かめる
是正の起票：Issueを起票し、社内の担当（vendor_risk_manager）と取引先側の窓口を決める。イシューは外部ポータル経由で取引先本人と共有できる
期限の管理：5章の日次ジョブと通知の仕組みに載せ、個人のメモで追わない
再評価：是正完了の報告を受けたら再アセスメントを発行し、評価を更新してから閉じる
継続監視：tierに応じた周期の定期評価へ戻す
評価が良好だった取引先には、「何もしない」ことを決めるのも対処です。次の画面のように重要度が高くても評価が良好（tier 2-High×rating 4-Low）であれば、是正は起こさず周期評価だけ回す設計とします。
6.4 評価は手で全部埋めない。エンゲージメント単位の評価が自動で集計される
検証でエンゲージメント29件に評価を入れたところ、Business Rule「Calculate engagement component rating」がコンポーネント別の評価を作成しました。続けて「Calculate total third-party rating」が取引先（会社）へ集計します。会社側の評価を1社ずつ手で更新する運用にはしません。エンゲージメント単位で評価を付け、上位への反映は自動集計に任せる設計とします。
実機で気づいたこと
ティア（重要度）とレーティング（安全度）は同じ5バンドで、高得点の意味が逆
def_tier_scaleは80〜100が1-Very High（最重要）でした。ところがdef_rating_scaleは、0〜19が1-Very High（高リスク）、80〜100が5-Very Low（低リスク）という逆向きの配点です。
同じ5段階・同じ数値範囲の構造なので、一見すると同じ尺度に見えます。Tieringは「スコアが高いほど重要」、レーティングは「スコアが高いほど安全」という逆の意味を持つ点は、実機で並べて初めて気づきました。運用設計の資料に両方の尺度を載せるときは、高得点の意味が逆であることを明記しておく必要があります。
「送信済み」は担当者が動く前から始まっている
registration_statusは、担当者レコードを作成した瞬間にsentへ進みました。実際にメールが届いたかどうかとは無関係に、レコード上は送信済みという扱いになります。PDIはSMTPが無効なので気づけましたが、本番相当の環境で同じ挙動だとすれば、registration_status=sentを相手に届いた証拠として扱うのは早計です。
Closedになっても、risk_ratingは最後まで空だった
1件を完走させた後も、risk_ratingとcomputed_risk_ratingは空のままでした。質問票「Basic」側のRisk scoreとRisk ratingの列も空欄です。def_rating_scaleに紐づく行はESG・Fourth-party・汎用向けの15件で、Basic用の行が見当たりません。質問票テンプレート側にスコアリングの設定が無いために計算されなかった、という推測にとどまります。運用を始める前に、使う質問票とdef_rating_scaleの対応関係を必ず確認したほうがよさそうです。
直接ACLが0件のapproverに、承認の実権がある
2.2で見たとおり、approverに直接ひもづくACLは0件でした。最初は権限が薄いロールなのかと思いましたが、これは見え方が違うだけでした。承認できるかどうかはACLではなく、承認という行為そのものを許可するロールの有無で決まる設計です。直接ACLの件数だけでロールの重みを判断すると、承認ロールのような統制系のロールを見誤ります。
ここまでで、7ロールの権限構造と運用サイクルの実測を確認しました。ここから先は、7ロール×12プロセスのRACI表と、割当設計・階層化基準・アセスメント頻度・エスカレーション基準など7項目を決める運用設計書テンプレート、監視・レビュー周期の叩き台をまとめています。自社の運用ルールを決めるときの叩き台としてそのまま使える分量です。
💰 ここから先は有料エリア
