明確なIT調達ポリシーは、支出をコントロールし、リスクを管理し、すべてのIT購入がセキュリティおよびコンプライアンス要件に確実に適合するようにします。Trupeerを使えば、無料のIT調達ポリシーテンプレートから始めて、ブランドガイドラインでカスタマイズし、ポリシーを従業員やベンダーがすぐに理解できるビデオのウォークスルーに変えることで、ポリシー作成にかかる数時間を節約できます。

IT調達ポリシーとは何か、そして何ではないか

IT調達ポリシーとは、どのようにして会社がテクノロジーベンダーにコミットできるのか、そのコミットが行われる前に何を確認しなければならないのか、そしてその後に関係がどう扱われるのかを決める書面上のルールです。これは購買プロセス、ベンダーリスト、契約ではありません。これらはその下流にあります。

また、「IT」という語が前に付いた一般的な調達ポリシーでもありません。一般的な調達では、購入されるものは一度納品され、どこかに置かれ、減価償却されると想定します。テクノロジーはその前提を4回も裏切ります。自己更新するため、3年のコミットメントは一度だけ署名され、誰も再承認しないまま36回にわたって支払われます。データを保持するため、購入によって顧客または従業員の記録が第三者に渡されますが、その価格は渡したものの価値と無関係です。無料であることもあり、無料ツールはこれまで書かれてきたあらゆる支出の閾値を通過します。そして死にません。ハードウェアは償却される一方で、ソフトウェアは、それを選んだ人が会社を去った後も請求を続けます。

ほとんどのIT調達ポリシーが「お金」を取りこぼす理由

ほぼすべての調達ポリシーテンプレートは同じ形をしています。目的、適用範囲、役割、閾値、承認マトリクス、例外です。承認マトリクスは常に1つの数値に紐づいており、それが「このコストはいくらか」です。この設計は、高額になる瞬間とリスクが高い瞬間が同じ瞬間であることを前提にしています。しかしITでは、ほとんど決してそうではありません。

高額になる瞬間は更新です。更新は自動で行われ、ベンダーが設定する価格で、ベンダーが数えるシート数に対して、何も人が判断しないまま進みます。5年の関係の中では、最初の購入は通常、手続きの中で最も小さな判断であり、誰かがレビューしたのはそれだけであることがほとんどです。

リスクが高い瞬間はデータです。1ユーザーあたり月12ドルのメモ作成ツールで会議の録画を取り込む場合、建物の外に出ない6万ドルのストレージアレイよりも、露出（リスク）が大きくなります。支出の閾値はアレイをCFOへ、メモ作成ツールは誰にも送らないのです。

そこで、このテンプレートは2つの点で異なります。1つではなく、支出とデータ露出の2軸でリクエストを振り分けます。そして更新を会計上の出来事ではなく、あらためて調達判断として扱います。それ以外は標準で、標準であれば問題ありません。重要なのは、ルーティングテーブル、条項9、そして登録（レジスター）です。

Trupeerでこのテンプレートをカスタマイズする方法

ステップ1：Templatesセクションを開く

メインナビゲーションからTemplatesセクションへ移動します。

ステップ2：テンプレートを選択して開く

作業したい任意のテンプレートをクリックして開きます。

ステップ3：テンプレート表示を展開する

必要に応じて、テンプレート表示を展開し、レイアウトと詳細をはっきり確認します。

ステップ4：テンプレートを編集する

編集をクリックして、選択したテンプレートの変更を開始します。

エディター内で、次のことができます：

• 新しいセクションを追加

• 書式ルールを定義または更新

• ロゴを追加し、その位置および関連設定を調整

ステップ5：カスタマイズしたテンプレートを保存する

必要な変更をすべて行ったら、Saveをクリックして更新済みテンプレートを自分のものとして保存します。

ステップ6：プレビューしてテンプレートを微調整する

カスタマイズしたテンプレートがどのように見えるか確認したいときは、Previewを開きます。

プレビュー画面から、必要に応じて直接調整を続けることができ、テンプレートが希望どおりに表示されることを確認できます。

IT調達ポリシーテンプレートを使うと、次のことができます：

• 作成時間を節約：IT調達向けに構成された空白ページをスキップ。

• 支出をコントロール：内蔵の承認閾値により、無許可の購入を防止。

• ブランドに合わせる：Trupeerのブランドキットでロゴ、フォント、色を適用。

• ベンダーのリスクを管理：内蔵のセキュリティおよびコンプライアンス評価基準。

• 監査に備える：SOC 2、ISO 27001などのフレームワークに整合。

• グローバルチームに対応：1クリックで調達ポリシーを65以上の言語に翻訳。

  
  

最安ツールほどリスクが大きい場合の承認ルーティング方法

以下のルーティングテーブルは、単一の列の閾値マトリクスに代わるものです。支出は横方向、データ露出は縦方向として読み、交差するセルにあるルールを適用します。機能させる鍵は、データ露出は承認ティアを引き上げることはあっても、引き下げることはない点です。無料ツールが顧客の個人データに触れる場合はセキュリティレビューへ。しかも「無料だから」という事実は関係ありません。

完全レビューとは、署名やカード入力の前に、セキュリティ、法務、ファイナンス、そしてテクノロジー担当のエグゼクティブが一緒に行うレビューのことです。

通貨とバンドは、あなたが設定するものです。そして列よりもはるかに重要度は低いです。ここを他に何も変えないなら、軸を1つから2つにして閾値を変更してください。なお、「年次のコミット済み支出」とは12か月の合計であり、取引サイズではありません。月額445ドルの請求は、5,340ドルのコミットメントであり、コミットメントではなく取引を読むポリシーが、下の実例が起きた理由です。

IT調達ポリシーテンプレート（パート1）：目的、適用範囲、役割

ここからコピーしてください。角括弧［ ］内の内容はすべて置き換えてください。

1. 目的

このポリシーは、[Company]が情報技術製品およびサービスをどのように評価し、承認し、購入し、更新し、そして退役させるかを定めます。技術への支出が意図されたものであること、第三者に渡すデータが引き渡される前に評価されること、そしてすべてのアクティブなベンダー関係に会社内の指名されたオーナーがいることを確実にするために存在します。

2. 適用範囲

このポリシーは、[Company]のすべての従業員、請負業者、ならびに一時スタッフ、および価値や支払い方法にかかわらずすべてのテクノロジーの取得に適用されます。ソフトウェアのサブスクリプションおよびライセンス、クラウドおよびホスティングサービス、ハードウェアおよびデバイス、プロフェッショナルおよび導入サービス、データおよびコンテンツフィード、ならびに開発者ツールおよびAPIを対象とします。

このポリシーは、これらの製品が[Company]データを処理する場合の無償で提供される製品、および会社カード、個人の経費精算、無料トライアル、またはベンダーのセルフサービスのチェックアウトを通じて取得される製品にも適用されます。

このポリシーは、スタッフの採用、施設の手配、マーケティング媒体の購入、または法務サービスを対象としません。これらは[関連ポリシー]によって管理されます。

3. 定義

年次のコミット済み支出：ライセンス費用、1シートあたりの料金、利用料金、サポート費用、導入コストを含め、いかなる12か月の期間においてもベンダーに支払うべき総額。

データ露出：製品が保存、処理、または送信する[Company]データのうち最も機微なカテゴリ。評価は、申請者がそこに入れたい内容ではなく、製品が受け取ることが可能な内容のレベルで行います。

オーナー：ベンダー関係、そのコスト、その更新の判断、そして最終的な退役について責任を負う指名された個人。

シャドーIT：テクノロジー登録簿に記録されていない、使用中のあらゆるテクノロジー。

4. 役割と責任

申請者は、ビジネス上の必要性、検討した代替案、そして製品が触れるデータを提示します。

オーナー（申請者である場合もあります）は、その関係を存続期間中保持し、更新の判断を確認し、そしてデコミッショニング（廃止）を開始します。

ITは、技術的適合性、統合コスト、すでに保有しているツールとの重複、ならびにサポート負荷を評価します。

セキュリティは、ベンダーの統制、認証、サブプロセッサー、および侵害（ブリーチ）の履歴を評価し、データ処理契約が必要かどうかを判断します。

ファイナンスは、予算を確認し、コミットメントを記録し、支払い方法を管理します。

法務は、責任、補償、解約権、自己更新（オートリニューアル）の文言、および管轄について、契約条件をレビューします。

ポリシーオーナーである[role]は、このポリシーと登録簿を維持し、[quarter]ごとに両方について[committee]へ報告します。

IT調達ポリシーテンプレート（パート2）：申請、レビュー、購入

5. 申請

すべての申請は、いかなるトライアルアカウントも作成する前、いかなる契約も締結する前、そしていかなる支払いも行う前に、[request form or ticket queue]を通じて提出されます。コミットメントがすでに行われた後に提出された申請は、条項12の例外として扱われます。

すべての申請には、求めるビジネス成果、製品が触れるデータカテゴリ、12か月間における想定ユーザー数、年次のコミット済み支出、契約期間、および[Company]がすでに保有している他のツールでその必要性を満たせる可能性があるかどうかを記載します。

6. レビューと承認

申請は、[Appendix A]の承認ルーティングテーブルを用いて振り分けます。承認は、[system]に、承認者、日付、承認済みの年次コミット済み支出とともに記録されます。承認は、明示された期間と明示された支出に対して付与されます。承認は、更新、期間延長、または[15]パーセントを超える支出の増加には引き継がれません。

7. セキュリティおよびデータレビュー

個人データまたは規制対象データを処理することになる製品は、承認前にセキュリティによってレビューされます。レビューには、ベンダーのセキュリティ認証とその範囲、サブプロセッサー、データが保存される国、認証およびアクセス制御、インシデント通知に関するコミットメント、データのエクスポートおよび削除の仕組み、ならびに侵害履歴が含まれます。

個人データが処理される場合、製品がライブデータを受け取る前にデータ処理契約が締結されます。規制対象データが処理される場合、[Company]はさらに[insert the assessment your regulator or framework requires]を行います。

8. 契約と支払い

[Company]を代表して契約に署名する、または利用規約を受け入れることができるのは、[named roles]のみです。クリックして同意する契約の受け入れは、契約への署名に相当します。

法務は、年次のコミット済み支出が[15,000]を超えるすべての合意、および自動更新を含む、個人データの処理を含む、独占または最低ボリュームのコミットメントを含む、または12か月を超える期間の合意をすべてレビューします。

支払いは[購入発注書またはファイナンスが保有するコーポレートカード]によって行います。個人カードおよび経費精算の払い戻しは、いかなる金額であってもテクノロジー購入の承認済みルートではありません。個人に発行されたカードは、継続的なテクノロジー料金の支払いに使用できません。

承認済みのすべての製品は、最初の支払いが解放される前に、テクノロジー登録簿に記録されます。

IT調達ポリシーテンプレート（パート3）：更新、退役、例外

9. 更新

更新は調達判断であり、会計上の出来事ではありません。

更新日の[60]日前よりも前に、非更新の通知が必要となる場合、その合意は締結されません。ただし条項12で承認されている場合を除きます。

各更新日の[Ninety]日前までに、オーナーは、過去90日間におけるライセンスシートに対するアクティブシートの照合、承認済み支出に対する実際の支出、当初のビジネス成果が達成されたかどうか、現在[Company]が保有する他のツールが同じ必要性をカバーしているかどうか、そして製品が扱うデータに変更があるかどうかを含む更新レビューを完了します。

更新レビューは、現在の支出および現在のデータ露出を用いて、当初の購入を承認したのと同じティアによって承認されます。いずれかが製品をより高いティアへ移した場合は、より高いティアが承認します。

更新日の[30]日前までに[role]によるレビューが行われていない更新は、[role]へエスカレーションされます。オーナーが[Company]を離れており後任が指名されていない場合、更新はデフォルトでは承認されず、当該製品はデコミッショニングの候補として扱われます。

10. 所有権とテクノロジー登録簿

[Company]は、すべてのアクティブ製品について、テクノロジー登録簿を維持します。そこには、ベンダー、製品、オーナー、承認権限と日付、年次のコミット済み支出、更新日、通知期間、処理されるデータカテゴリ、データ処理契約が有効かどうか、ライセンスシート、そして管理アカウントの保有者が記録されます。

登録簿は[quarterly]にレビューされます。会社カードまたは銀行明細で、登録簿の記録と照合できない請求は、[30]日以内に調査されます。

従業員が退職する際、[role]はオーナーとして保有している製品について登録簿を確認し、最終出勤日までに所有権を再割り当てします。ベンダーアカウントへの管理アクセスは、指名された個人ではなく、役割ベースのアカウントへ移管されます。

11. デコミッショニング

製品が退役する際、オーナーは[Company]データを利用可能な形式でエクスポートし、ベンダーへ文書化された削除依頼を発行して回答を記録し、すべてのユーザーアカウントを削除し、支払い手段または購入発注書をキャンセルし、登録簿を更新し、依存するシステムがまだ当該製品を呼び出していないことを確認します。

削除の確認が記録されるまで、デコミッショニングは完了しません。

12. 例外および緊急購入

緊急購入は、サービス停止、セキュリティインシデント、または法的義務により遅延が許容できない場合、完全な承認なしで進めることができます。[Role]がこれを承認することができます。完全な承認プロセスは[10]営業日以内に完了し、購入は例外ログに記録されます。

その他すべての例外は、[role]からの書面による承認が必要であり、理由と有効期限日とともに記録されます。例外は更新されません。

13. 非準拠

承認されていないテクノロジー購入は払い戻しできず、承認されていない製品が[Company]データを処理する場合は、発見次第無効化されます。繰り返しの非準拠は[disciplinary policy]に基づいて対応されます。

14. レビュー

このポリシーは[annually]に[role]によってレビューされます。もしくは、重大なインシデント、規制上の義務の変更、または会社組織の変更があった場合は、それより早くレビューします。

ここにコピーしてください。

実例と、その費用

Meridian Freightは、従業員310名で、調達ポリシーに5,000ドルの承認閾値がありました。これは妥当なポリシーでした。ここで、どのように失敗したかを示します。

2024年3月、サポートチームリードがチケット分析ツールを購入しました。シートは5つで、1シートあたり月89ドル、会社カードで月445ドルでした。ポリシーはコミットメントではなく取引を読んでおり、445ドルは5,000ドルに全く届かなかったため、何もトリガーされませんでした。年次のコミットメントは5,340ドルで、閾値を超えていました。

そのツールはチケット本文を丸ごと取り込み、Meridianのチケットには顧客名、配送先住所、電話番号、ならびにコンソーシアムの詳細が含まれています。セキュリティレビューは行われず、データ処理契約も締結されず、ベンダーのサブプロセッサー一覧も一度も読まれませんでした。

リードは2024年11月に退職し、彼女のカードは通常のファイナンスの引き継ぎ手順で後任に再発行されたため、その請求はそのまま引き継がれました。

ツールは2025年3月に更新されました。シート単価は89ドルから119ドルへ移動し、請求は利用ベースだったため、共有キューに人が追加されてシート数が11に増えました。月額コストは約1,300ドルになりました。誰も承認しませんでした。承認すべきものがなかったからです。そこにずっと存在していたカード請求だったのです。

2026年2月のカード監査でそれが見つかりました。11シートのうち3つは、直近90日間にログインしていました。24か月にわたって支払われた総額は約18,200ドルで、そのうち5,340ドルは誰かが下した判断の結果でした。残りの12,852ドルは誰も使っていない支出でした。

重要だったのはお金ではありません。評価されていないベンダーのもとに、顧客の個人データが20か月分存在していました。そして管理アカウントが退職した従業員に属していたため、Meridianはサポートチケットを開いて所有権を証明しない限り、自社のデータをエクスポートまたは削除できませんでした。それには11日かかりました。

ここにある条項のうち、オーバーヘッドに見えるものはすべて、この種の失敗のどれかのバージョンが原因で存在しています。条項8は個人カードを止めます。条項9は2025年3月を判断にします。条項10は一致しない請求を捕捉し、退職時に所有権を再割り当てします。条項11は、削除依頼が誰かが初めて考えるものではないことを意味します。

2週間で書いて展開する

1週目：ルールを書く前に「事実」を確立します。カードと銀行データの12か月分を引き出し、すべての継続的なテクノロジー請求をリスト化し、そのリストに載っていないものを使っているチームリード全員に尋ねます。そうすることで無料ツールが浮かび上がります。各行にオーナーを指名します。誰も名乗らないものは、最初のデコミッショニング候補です。その棚卸しが、登録簿の最初のバージョンになります。

2週目：見つけた分布を使って閾値を設定し、丸い数字にしないことです。上記の条項を調整し、法務とセキュリティに条項7、8、11をレビューしてもらい、それを運用することになる人たちとルーティングテーブルを合意します。登録簿と一緒に公開し、それより前に公開しないでください。登録簿のないポリシーは文書であり、登録簿のあるポリシーは統制です。

展開は「発表」ではなく「行動の変化」として扱ってください。人は不注意だからプロセス外でツールを買うのではありません。締切よりもプロセスの方が遅いから買ってしまうのです。承認ルートが低リスクの申請を2営業日で処理できないなら、ポリシーは迂回されます。承認に関するサービスレベルを設定し、その達成状況を公開してください。これは、私たちの変更管理ガイドでより詳しく説明しています。

入れないでおくべきもの

ベンダー選定基準やスコアリングマトリクスは、ソーシングガイドに入れるべきです。ベンダーのデモに重み付けする方法を指定するポリシーは、1年以内に古くなり、その前に読むには長すぎます。

ベンダーリストは登録簿に入れるべきです。ポリシー内で承認済みベンダーに名前を付けると、ツールを切り替えるたびに変更管理が必要になるためです。

購買システム向けの手順をステップごとに書いた指示は、IT SOPに入れるべきです。ポリシーは購入発注書が必要だと言い、SOPはどのボタンがそれを起こすかを示し、両者を分けておくことで、ポリシーを再度開かずにシステムを変更できます。

このポリシーと並行して作る価値のある関連ドキュメント：購入することになるシステム向けのITドキュメンテーションテンプレート、条項10で説明したテクノロジー登録簿の自然な置き場所となるアプリケーションおよび資格情報の登録簿、条項10の所有権引き継ぎのためのナレッジトランスファーSOP、そして導入が必要になるほど大きなものすべてに対応するITプロジェクト計画テンプレートです。

法務・規制レビューに関する注記

このテンプレートは出発点であり、法的助言ではありません。調達上の義務は、管轄区域と業界によって大きく異なります。公共部門の機関、規制対象の金融機関、医療提供者、そして公共入札のルールが適用される組織は、このテンプレートが再現しようとしない法定要件をすべて負っています。データ処理の条項は、GDPR、UK GDPR、CCPA、そして業界固有のルールと、データ主体やベンダーがどこにいるかに応じて異なる形で相互作用します。

公開する前に、法務顧問およびデータ保護またはコンプライアンスの責任者に条項7、8、11をレビューしてもらい、さらに、取締役会ですでに承認されている権限委任に対して閾値が適切かどうかを確認してもらってください。

ポリシーを、実際に守られるものにする

共有ドライブに置かれたポリシーは、一度だけ読まれます。人が実際に従うのは、その人が何かを買おうとしている「その瞬間」に添付されているバージョンです。

Trupeer AIは、画面録画を文書化されたプロセスに変えるため、条項5の申請ルートが、1つの段落で説明するのではなく、実際の申請フォームのウォークスルーになります。フローを一度記録すれば、同じ録画から、あなたのナレッジベースに、ステップごとのガイド、ビデオ、そしてドキュメントが、あなた自身のブランディングで作成されます。

記録する。ブランド化する。翻訳する。Trupeerする。

ポリシーライブラリを管理するチーム向けに、documentationとSOP creatorがポリシー、登録簿、手順を一緒に保ちます。翻訳によって、グローバルなファイナンスチームは自分たちの言語で承認ルーティングテーブルを読むことができます。セットアップ手順はドキュメントテンプレートのセットアップガイドに記載されています。

よくある質問

このIT調達ポリシーテンプレートのWord版はありますか？

完全なポリシー本文は、このページの「copy」マーカー2つの間にあり、コピー＆ペーストしても耐えられるように書かれています。条項1から条項14までを選択し、WordまたはGoogle Docsに貼り付けると、番号と太字の見出しがそのまま引き継がれます。リクエスト用のWordダウンロードは用意されていないため、あなたと本文の間にメールフォームもありません。

PDF版はありますか？また、配布できるIT調達ポリシーPDFはありますか？

本文をドキュメントエディターに貼り付け、そこからPDFとして書き出してください。固定のPDFよりもこのドキュメントには適しています。なぜなら、調達ポリシーは、意味を持つ前に、あなたの閾値、役割名、通貨が角括弧［ ］内に置き換えられている必要があるからです。条項2にまだ[Company]と書かれているPDFはポリシーではなく、配布することでポリシーが飾りであると教えてしまいます。

このテンプレートを無料でダウンロードできますか？

本文は無料で、制限なく利用できます。使って、編集して、自分の名前で社内に公開してください。ポリシードキュメントでTrupeer AIのクレジット表記をする必要はありません。

COBIT APO10とは何で、このテンプレートはそれを満たしますか？

APO10は、管理されたベンダーを対象とするCOBITの目的で、ベンダー選定、関係管理、契約管理、そしてベンダーライフサイクル全体にわたるパフォーマンス監視を含みます。調達ポリシーはAPO10への入力であり、同じものではありません。

このテンプレートは取得と契約の部分をうまくカバーしており、条項9と10が継続的な関係管理の一部をカバーしています。ただし、ベンダーのパフォーマンススコアカード、サービスレベルのモニタリング、ポートフォリオ全体でのベンダーリスクのティアリングはカバーしていません。これらはAPO10が想定しているものです。COBITのアセスメントに取り組んでいる場合は、これを目的を閉じる統制としてではなく、必要になる複数のドキュメントの1つとして扱ってください。

シンプルな調達ポリシーとは何で、いつそれで十分ですか？

シンプルな調達ポリシーは通常2〜3ページです。目的、適用範囲、支出の閾値テーブル、そして誰が署名するか。おおよそ50人未満の会社で、規制対象データがなく、主流のツールだけを購入している場合は、それで本当に十分です。そして14条項のポリシーは守られません。

短い版が欲しい場合は、条項1、2、4、6、8、9を残して、それ以外を削除してください。条項9は削除しないでください。更新の規律は、どの規模の会社でも自分自身のコストを回収する唯一の統制であり、短いポリシーから最もよく欠ける条項です。

この内容はSaaSやクラウドサービスも対象ですか？それともハードウェアだけですか？

両方です。条項2の適用範囲は、その曖昧さが多くのポリシー漏れの原因になるため、明確にするように書かれています。クラウドとSaaSは難しいケースなので、ルーティングテーブルには「支出ゼロ」の行と「データ露出」の列があります。ハードウェアの購入は、多くの会社では支出だけで綺麗にルーティングできます。

このポリシーのオーナーは誰が持つべきですか？

テクノロジーの支出に責任を持つ人であるべきです。多くの会社ではCIO、ITディレクター、またはHead of ITであり、小規模な会社ではCOOまたはファイナンスディレクターであることが多いです。肩書きよりも重要なのは、オーナーが条項10で説明されているカードおよび銀行データを見通せることです。請求内容が見えないポリシーオーナーは、それを強制できません。

どのくらいの頻度でレビューすべきですか？

条項14では、年1回が妥当なデフォルトです。ベンダーに関するセキュリティインシデントがあった場合、あなたに適用される規制上の義務が変わった場合、買収または買収された場合、または四半期ごとの登録簿レビューで、連続して2四半期にわたり一致しない請求が見つかった場合は、それより早くレビューしてください。最後のケースは、人々にポリシーを思い出させる必要があるという意味ではなく、ルーティングテーブルまたは承認のサービスレベルが機能していないというサインです。