委託先のセキュリティ対策チェック項目｜開発・保守の段階別リスト

委託先のセキュリティ対策は、取引開始前にチェックシートの回答をもらうだけでは確かめきれません。確認すべき項目は、選定時よりも、契約で決めること、運用中に確かめ続けること、契約終了時に片付けることに多くあります。HVLはシステム開発・保守を受託する立場から、委託先のセキュリティで本当に差が出るのはこれらの場面だと考えています。

この記事では、業務システムやWebサイトの開発・保守を外部に委託する中小企業の経営者・総務・情報システム担当者向けに、発注の段階（選定・契約・開発中・運用保守・契約終了）ごとの確認項目を整理します。

扱うのは、契約・アカウント・データ・再委託・更新の担当・事故時の連絡といった委託先の管理です。作られたプログラムのコードに含まれる脆弱性は別のテーマなので、AI開発の脆弱性の混入経路と確認項目をまとめた記事をご覧ください。IPAの公開情報は、2026年10月30日に確認した内容をもとにしています。

結論：確認項目は選定時より契約と運用中のほうが多い

委託先のセキュリティチェックで確認する項目は、選定時よりも契約時と運用保守の段階に多く集まります。段階ごとの要点は次のとおりです。

• 選定時：委託先の基本方針と体制、事故の経験と対応を確認する。
• 契約時：責任の範囲、再委託、事故時の連絡、データの扱い、契約終了時の処理を文書にする。
• 開発中：ソースコード・テストデータ・開発環境の権限を確認する。
• 運用保守：更新の範囲、アカウントの棚卸し、バックアップと復元の確認を定期的に行う。
• 契約終了時：データの返却・消去と、アカウント・権限の削除を確認する。

チェックシートの回答が示すのは、回答した時点の状態です。担当者や預けるデータは契約後に変わっていくため、HVLは回答の内容と同じくらい、契約と運用の中に確認の仕組みがあるかを重視すべきだと考えています。

委託先のセキュリティ対策とは：委託元が決めて確かめること

委託先のセキュリティ対策とは、業務を外部に委託するときに、預ける情報や発行する権限を守るために委託先が行う対策と、それを委託元が契約と確認で管理する取り組みを指します。

委託先の社内でどのような対策を行っているかは、委託元からは見えにくいものです。そのため委託元の実務は、何を求めるかを決めて文書にし、その実施状況を確かめることが中心になります。

この記事で使う言葉は、次の意味で統一します。

• 委託元：業務システムやWebサイトの開発・保守を外部に発注する企業。
• 委託先：開発・保守を受託する企業。
• 再委託：委託先が、受けた業務の一部を下請けやフリーランスへ再発注すること。
• アカウントの棚卸し：発行済みのアカウントと権限の一覧を実態と照らし合わせ、不要なものを止める作業。

なぜ委託先の確認が必要か

委託先の不備で起きた事故でも委託元が管理責任を問われることになるため、委託先の確認は委託元自身の課題です。IPAの公開資料は、この点を次のように示しています。

• IPA「情報セキュリティ10大脅威 2026」（2026年1月29日公開）の組織編で、2位は「サプライチェーンや委託先を狙った攻撃」で、8年連続8回目の選出です。
• IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版（2026年3月27日公開）は、経営者が認識すべき3原則の2つ目に「委託先の情報セキュリティ対策まで考慮する」を挙げています。委託先に提供した情報が漏えい・改ざんされたとき、委託先の不備であっても、事故の影響を受ける者から委託元としての管理責任を問われることになると説明しています。
• 同じガイドラインの重要7項目の取組6は「委託や外部サービス利用の際にはセキュリティに関する責任を明確にする」です。委託先でも少なくとも自社と同等の対策が行われるようにし、委託先の責任や実施すべき対策を契約書に明記し、合意する必要があるとしています。
• 同じガイドラインの「5分でできる！情報セキュリティ自社診断」の25項目には、「重要情報の授受を伴う取引先との契約書には、秘密保持条項を規定していますか？」「クラウドサービスやウェブサイトの運用などで利用する外部サービスは、安全・信頼性を把握して選定していますか？」という設問があります。

IPAのSCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）のページは、制度の背景となる課題を委託元と委託先の両面から挙げています。委託元は委託先の対策が可視化しづらく、チェックリスト等の要求事項の適正性の担保も難しいという課題です。委託先は様々な委託元から様々な要求事項を求められ、過度な負担につながっているという課題です。

そのうえでSCS評価制度は、2社間の取引契約等において、委託元が委託先に適切な段階（★）を提示し、示された対策を促すとともに実施状況を確認することを想定しています。SCS評価制度の詳細情報によると、2026年10月28日時点のIPAの公開情報では、★3は計26件、★4は計43件の要求項目です。★3・★4は2027年3月の受付開始に向けて整備中です。

段階別チェックリスト：選定から契約終了まで

委託先へ確認する項目は、発注の段階ごとに分けると、誰がいつ確かめるのかがはっきりします。すでに委託が始まっている場合は、選定時の項目を読み飛ばし、契約時と運用保守の項目から確認してください。

選定時

選定時は、細かい対策の有無よりも、委託先が方針と体制を説明できるかを確認します。

• 情報セキュリティ基本方針を定めて公開しているか、または提示できるか。
• セキュリティの責任者が決まっているか。
• 過去の事故や障害のとき、どのように連絡し、どう対応したかを説明できるか。
• 再委託（下請け・フリーランスへの再発注）を行うことがあるか、その場合の管理方法はどうなっているか。
• SECURITY ACTIONの宣言やSCS評価制度への対応状況はどうか。宣言や登録があれば、どの範囲が対象か。

事故や障害については、経験がないという回答より、起きたときの連絡と対応を具体的に説明できるかを見るほうが、判断の材料になるとHVLは考えています。また、SECURITY ACTIONは、中小企業自らがガイドラインに示した対策に取り組むことを自己宣言する制度です。宣言の有無だけで判断せず、他の項目と合わせて確認します。

契約時

契約時は、事故が起きてから揉めやすい役割分担を、文書で決めておきます。

• 責任の範囲：開発・保守の対象（アプリケーション、サーバー、OS、ミドルウェア、ネットワーク機器、クラウドの設定）のうち、どこまでを委託先が担当するか。
• 更新の担当：OS・ミドルウェア・ライブラリ・機器の更新を誰が判断し、誰が適用し、費用をどう扱うか。
• 再委託：再委託の可否、事前承諾の要否、再委託先にも同じ義務を課すか。
• 事故時の連絡：事故や事故の疑いを知ったとき、誰に、どの手段で、いつまでに連絡するか。
• データの扱い：預けるデータの範囲、目的外利用の禁止、保管場所、持ち出しの制限、秘密保持。
• 契約終了時の処理：データの返却・消去の方法と、その報告。
• 監査・報告：対策の実施状況を報告してもらう頻度と方法。

HVLが契約時に特に重視したいと考えているのは、責任の範囲と更新の担当です。委託元は任せたつもりで、委託先は依頼されていないつもりという食い違いが、この部分で起きやすいためです。契約書の具体的な文言は、自社の法務担当や専門家と確認してください。

開発中

開発中は、ソースコードとテストデータに誰が触れられるのかを確認します。

• ソースコードの保管場所と、アクセスできる人の範囲。
• テストに本番データを使うかどうか。使う場合は、範囲と加工の方法、テスト後の消去。
• 開発環境・検証環境に誰がアクセスできるか。共有アカウントを使っていないか。
• 発注側から委託先に発行したアカウント（クラウド、業務システム、メール等）の一覧と権限。

発行したアカウントの一覧は、この段階で作っておくと、運用保守の棚卸しと契約終了時の削除にそのまま使えます。共有アカウントがあると、誰が操作したのかを後から追いにくくなるため、見つけた時点で扱いを話し合います。

運用保守

運用保守では、契約で決めたとおりに実施されているかを定期的に確かめます。

• 更新の範囲どおりに更新が行われているか、報告を受けているか。
• 委託先の担当者の交代・退職があったとき、アカウントを止めているか。アカウントの棚卸しを定期的に行っているか。
• バックアップを誰が取得し、復元できることを誰が確かめているか。
• リモートで保守する場合、接続の方法（VPN等）と、その機器の更新を誰が担当しているか。
• 事故時の連絡先が最新か。

バックアップは、取得しているという報告だけでは足りません。復元できることを確かめる担当まで決まっているかを確認します。接続に使う機器の更新は、委託元と委託先のどちらの担当か曖昧になりやすいので、契約時の責任の範囲と照らし合わせます。

契約終了時

契約終了時は、預けたものを回収し、渡した権限を消します。

• 預けたデータが返却または消去され、その報告を受けたか。
• 委託先に発行したアカウント・権限・鍵・接続設定を削除したか。
• ソースコード、設計書、構成の資料、管理者パスワードなど、引き継ぎに必要なものを受け取ったか。

委託先を替える場合は、新しい委託先への引き継ぎが終わる時期に合わせて、アカウントや接続設定を削除する順番を決めておきます。受け取った管理者パスワードは、引き継ぎ後に変更するかどうかも確認します。

段階ごとの確認項目と根拠資料の一覧

各段階で確認することと、確認の根拠になる資料を並べると、回答だけで済ませない項目を選びやすくなります。資料の名称は例なので、自社と委託先で使っているものに読み替えてください。

委託先の確認を進める手順

確認は、すべての項目を一度に送るのではなく、委託の現状を把握してから、決まっていない項目を埋める順で進めることをHVLは勧めます。

1. 委託の現状を洗い出す：委託先ごとに、対象のシステム、預けているデータ、発行しているアカウントを一覧にします。
2. 段階を分ける：委託先ごとに、選定・契約・開発中・運用保守・契約終了のどの段階にあるかを分けます。
3. 契約書と照らし合わせる：契約時の項目のうち、現在の契約書で決まっていないものを書き出します。
4. 委託先と話し合う：決まっていない項目について役割分担を話し合い、合意した内容を文書にします。作業や費用が増える項目は、その扱いも一緒に決めます。
5. 確かめ直す時期と担当を決める：年に1回など定期的に確認する時期と、自社の担当者を決めます。
6. 変化があったときに見直す：委託先の担当者の交代、委託範囲の変更、再委託先の変更があれば、定期の確認を待たずに一覧と文書を更新します。

委託先が多く、すべてを同時に進められない場合は、次に当てはまる委託先から着手するとよいとHVLは考えています。

• 重要な情報や個人情報を預けている。
• 本番環境やクラウドの管理者権限を渡している。
• 再委託があるのか、自社で把握できていない。
• 契約書に責任の範囲や更新の担当が書かれていない。

よくある抜けとつまずきやすい点

つまずきやすいのは、対策の難しさよりも、誰の担当かが決まっていない部分だとHVLは考えています。システム開発・保守を受託する立場から見て、抜けやすい点と対処を挙げます。

• 契約書に「保守」とだけ書かれている：OSや機器の更新が範囲に入るのかどうかが決まっていない状態です。対象ごとに担当を一覧にして、委託先と合意します。
• 古いアカウントが残っている：担当者が交代した委託先のアカウントや、過去の委託先のアカウントが残っている状態です。棚卸しの時期を決め、交代の連絡を受ける流れを契約時に決めておきます。
• 本番データのコピーがテスト環境に残っている：テスト後の消去を誰が確かめるのかを決め、消去の報告を受けます。
• 再委託先の存在を事故が起きてから知る：再委託の可否と事前承諾を契約で決め、再委託先の一覧を提示してもらいます。
• 資料がなく委託先を替えられない：仕様書や構成の資料がなく、委託先を替えようとしても引き継げない状態です。契約時に引き継ぎに必要な資料を決めておきます。すでに資料がない場合は、仕様書がないシステムの保守・引き継ぎと解析の進め方が参考になります。

チェックシートを使うときの注意

チェックシートは、項目を増やすより、根拠を確かめる項目を絞り、回答後に確かめ直すことで役に立つとHVLは考えています。

• 委託先の負担を考える：取引先ごとに違うチェックシートを送ると、委託先の回答の負担が大きくなります。SCS評価制度も、この負担を背景の課題として挙げています。
• 根拠を示してもらう項目を絞る：「はい／いいえ」の回答だけでなく、基本方針、規程、アカウント一覧、更新の記録などの文書を示してもらう項目を絞って設けると、確認の質が上がるとHVLは考えています。
• 受け取って終わりにしない：運用保守の段階で、年に1回など定期的に確かめ直します。

根拠を求める項目は、この記事の一覧表のうち、自社への影響が大きいものから選びます。アカウント一覧や更新の記録のように、すでに運用の中で作られている資料を指定すると、委託先が新たに作る手間も抑えられます。回答に「いいえ」があった場合は、それだけで取引をやめるのではなく、対応の時期や代わりの方法を話し合う材料にします。

自社が委託先として回答するときの準備

取引先からチェックシートが届く立場の会社は、次の資料をそろえておくと回答が早くなります。

• 情報セキュリティ基本方針
• 端末・アカウント・取り扱うデータの一覧
• 更新・バックアップ・アカウント停止の記録
• 再委託先の一覧と、再委託先との取り決め
• 事故時の連絡体制

IPAのガイドラインは、受託している場合には委託元の要求に応じる必要があるとしています。また、取引先からのセキュリティ対策の要請に対して、企業間でパートナーシップを構築し、必要な対策の実施とともに価格交渉を行い、円満に合意することが肝要だとしています。

対策に費用や作業が伴う要請を受けたときは、できることと追加の対応が必要なことを分けて伝えると、話し合いを進めやすくなります。自社の対策をこれから整える場合は、中小企業のセキュリティ対策を何から始めるかを整理した記事もあわせてご覧ください。

委託先が★を持っている場合・持っていない場合

SCS評価制度の★の有無にかかわらず、契約で決める事項と運用中の確認は委託元が行う必要があります。★の違いや準備の手順は、SCS評価制度の★3・★4の違いと中小企業の準備手順で詳しく扱っています。

• ★を登録している場合：どの取得単位・適用範囲で登録したかを確認します。自社の案件を扱う部門やシステムが範囲に入っているとは限りません。
• ★を持っていない場合：それだけで判断せず、この記事のチェックリストで契約と運用の項目を確認します。2026年10月30日時点では★3・★4の受付は始まっていません。
• どちらの場合も：再委託、事故時の連絡、契約終了時の処理は契約で決める必要があります。

SCS評価制度の詳細情報によると、★3は登録希望組織が自己評価を行い、SCSセキュリティ専門家の確認を受ける方式です。★4は評価機関による審査と技術検証を受ける第三者評価です。評価は、各登録希望組織で決定した適用範囲の中から対象をサンプリングして行うことが想定されています。

適用範囲を組織側で決める仕組みだからこそ、自社の案件が範囲に入るかを確認することが大切だとHVLは考えています。受付開始までの間は、委託先に今後の対応の予定を聞いておくと、取引の見直しの時期に役立ちます。

よくある質問

委託先のセキュリティチェックでは何を確認すればよいですか？

選定時の基本方針と体制に加え、契約での責任範囲・再委託・事故時の連絡・データの扱いを確認します。さらに、運用中のアカウント棚卸しとバックアップ、契約終了時の返却・消去も確認します。

委託先が再委託している場合はどうすればよいですか？

契約で再委託の可否と事前承諾を決め、再委託先にも同じ義務を課すかを確認します。

チェックシートは毎年送り直すべきですか？

運用中に体制や担当者が変わるため、年に1回など定期的に確かめ直すことをHVLは勧めます。

委託先がSCS評価制度の★を持っていれば確認は不要ですか？

不要にはなりません。★の取得単位と適用範囲を確認し、契約で決める事項は別に確認します。

契約終了時に忘れやすいことは何ですか？

委託先に発行したアカウントや接続設定の削除と、預けたデータの返却・消去の報告です。

まとめ

委託先のセキュリティチェックは、選定時の回答で終わりではありません。契約で責任の範囲と再委託・事故時の連絡を決め、運用中にアカウントとバックアップを確かめ、契約終了時に返却・消去と権限の削除を確認します。IPAのガイドラインが示す「委託先の情報セキュリティ対策まで考慮する」を、発注の段階ごとの作業にしておくことが大切だとHVLは考えます。

業務システムやWebサイトの開発・保守を委託する際の役割分担や、契約で決めておく範囲を整理したい場合は、HVLのシステム開発・保守（システムインテグレーション）にご相談ください。開発・保守の進め方をまとめた資料の請求や、お問い合わせも受け付けています。