Contents
なぜ「委託先のセキュリティ確認」が必須なのか
外注・委託でシステム開発や運用を進めると、社内では触れない領域(ソースコード、クラウド設定、顧客データ、ログなど)を委託先が扱う場面が増えます。ここで問題になるのが「自社は対策しているのに、委託先が穴になって事故が起きる」ケースです。近年はサプライチェーン(取引先)経由の事故が現実的なリスクで、特に情シスや管理部門が「どこまで確認すべきか」を持ち回りで悩みやすい領域でもあります。
ただ、専門用語を並べた監査資料を要求しても、双方が疲弊し、肝心のリスクが減らないこともあります。重要なのは「自社が守りたいもの(顧客情報、機密、事業継続)と、委託範囲(誰が何にアクセスできるか)を結びつけて、必要十分なセキュリティのチェック項目に落とす」ことです。
この記事では、開発に詳しくない担当者でも使えるように、委託先のセキュリティをチェックリストで評価する進め方を、実務の流れ(準備→評価→契約→運用)で整理します。ISOやSOC2などの規格に詳しくなくても、事故を減らすための「確認の型」を持てるようになります。
よくある誤解
- 「PマークやISMSがあるから大丈夫」:一定の安心材料ですが、あなたの委託範囲で必要な対策が実装されているかは別問題です。
- 「NDAを結べば安心」:秘密保持は大事ですが、情報漏えいは“悪意”ではなく“ミスや設定不備”でも起きます。
- 「技術が分からないから評価できない」:技術そのものより、運用や管理(誰が、いつ、どう管理するか)を聞く方が効果的です。
3分でできる! 開発費用のカンタン概算見積もりはこちら
チェックリストの前に決めるべき「範囲」と「守る対象」
いきなりチェックリストを送ると、相手から「何を想定した質問ですか?」となりがちです。まずは評価の前提をそろえます。ポイントは、委託先が触れる“資産”と“権限”を言語化することです。守る対象(データ・システム・業務)と、委託先の作業範囲の対応表を作ると、確認すべき項目が自然に絞れます。
例えば「Webサイト制作」のつもりでも、実際はCMSの管理者権限や、クラウド(AWS/GCP/Azure)の設定権限を渡していることがあります。権限が強いほど、委託先のセキュリティ対策は“推奨”ではなく“必須”になります。
- 委託先が扱う情報:顧客情報(氏名・メール等)、決済情報、従業員情報、機密文書、ソースコード、設計資料、ログ
- 委託先が使う環境:自社のクラウド上で作業/委託先の環境で作業/両方
- アクセス権限:閲覧のみ/更新可/管理者権限/本番環境アクセス/DB直接接続
- 委託形態:スポット制作/運用保守/常駐/再委託あり
この整理ができると、「最低限、委託先に確認すべきセキュリティ項目」と「できれば実施してほしい項目」が分けられます。結果として、チェックリストが“詰問”ではなく、リスクに沿った合理的な確認になります。
簡単な分類の目安
- 低リスク:公開情報のみ、権限なし、納品物が静的(画像・原稿など)
- 中リスク:社内限定情報、テスト環境アクセス、CMS編集権限
- 高リスク:個人情報・機密、管理者権限、本番DB、運用保守(24/365含む)
委託先評価のチェックリスト(実務で使える項目例)
ここでは、委託先のセキュリティをチェックリストで評価するための主要項目を、非エンジニアでも確認しやすい質問形式に落とします。すべてを一度に要求する必要はありません。先ほどのリスク分類に応じて、必須・任意を決めると運用が回ります。「はい/いいえ」だけでなく、運用証跡(手順書・画面・ログ)の有無まで聞くと実効性が上がります。
組織・ルール(ガバナンス)
- 情報セキュリティ方針:社内規程(ポリシー)があり、従業員に周知していますか。
- 教育:年1回以上のセキュリティ教育(標的型メール、パスワード、持ち出し等)を実施していますか。
- 委託先内の権限管理:担当者が退職・異動した際、当日中に権限を削除する運用ですか。
- 再委託:再委託の可能性はありますか。ある場合、再委託先にも同等のセキュリティ条件を課しますか。
アクセス管理(アカウント・権限)
- 個人アカウント:共有IDではなく、個人ごとのアカウント運用ですか。
- 多要素認証(MFA):管理者・クラウド・Git・VPN等でMFAを必須にしていますか。
- 最小権限:必要な期間・必要な範囲だけ権限を付与し、作業後に削除しますか。
- ログ:誰がいつ何をしたか(監査ログ)を残し、一定期間保管しますか。
端末・作業環境(PC/スマホ/ネットワーク)
- 端末管理:業務端末にパスコード、ディスク暗号化、画面ロック、ウイルス対策を適用していますか。
- BYOD:私物端末での作業を許可していますか。許可する場合、MDM等で管理していますか。
- リモートワーク:公共Wi-Fi利用時のルール、VPN、データ持ち出し制限はありますか。
- データ保管:成果物や顧客データを個人PCや個人クラウドに保存しない運用ですか。
開発・運用(システムの作り方/守り方)
- 脆弱性対応:OSやライブラリのアップデート方針、重大な脆弱性が出た時の対応期限はありますか。
- レビュー:コードレビューや設定レビューを実施しますか(最低でも重要箇所は複数人確認)。
- 秘密情報の管理:APIキーやパスワードをソースコードに直書きせず、Vaultや環境変数で管理しますか。
- バックアップ:バックアップの頻度、復元テスト(戻せるかの確認)を実施していますか。
- 本番反映:本番作業の手順、承認、ロールバック(戻し手順)がありますか。
インシデント対応(事故が起きた時の動き)
- 連絡体制:インシデント時の一次連絡(窓口・電話・時間帯)を定めていますか。
- 初動:影響範囲の切り分け、ログ保全、暫定対策(アクセス遮断等)の手順がありますか。
- 報告:原因・再発防止策の報告書テンプレート、報告期限の目安はありますか。
法令・第三者認証(あれば加点、ただし過信しない)
- 個人情報の取り扱い:個人情報保護法や委託契約に基づく管理(目的外利用禁止等)を理解していますか。
- 認証:ISMS(ISO27001)やSOC2等の取得状況、適用範囲(どの拠点・部門か)を提示できますか。
チェックリスト運用のコツ
- Yes回答でも「どうやって担保していますか(手順・画面・ログ)?」を1つだけ追加すると形骸化しにくい
- 委託先の負担を下げるため、最初は10〜20問程度の必須項目に絞る
- 「できていない=即NG」ではなく、代替策や改善計画で判断できるようにする
3分でできる! 開発費用のカンタン概算見積もりはこちら
チェックリストを点数化して比較する(合否ではなくリスクで判断)
複数社を比較する場合、チェックリストを「合否」だけで見てしまうと、現場に必要な委託先を落としてしまったり、逆に書類が整っているだけの会社を選んでしまったりします。おすすめは、重要度(重み)をつけたスコアリングです。リスクが高い委託ほど、MFA・権限・ログ・インシデント対応の配点を上げます。
例として、各設問を「0=未実施/1=一部実施/2=実施/3=実施+証跡あり」で評価し、カテゴリごとに重みを設定します。
例:高リスク委託(本番・個人情報あり)の重み
アクセス管理 30%
開発・運用 30%
インシデント 20%
端末・環境 15%
組織・ルール 5%
この形にすると、「教育はこれから整備予定だが、MFAとログと権限は強いので許容」「バックアップの復元テストがないので要改善」など、意思決定が具体的になります。さらに、スコアだけでなく“赤信号項目”を作るのも重要です。点数が高くても、致命的な穴が1つあれば事故につながるからです。
- 赤信号の例:共有アカウント運用、MFAなしで管理者権限、本番DBに常時接続、ログが取れない/保管しない、秘密情報を平文保存
点数化は「委託先を落とすため」ではなく、「どこを契約条件・運用条件で補うべきか」を見える化するための道具です。予算がある企業ほど、スコアリングで“必要な投資”が説明しやすくなります(監査対応、取締役会説明、顧客への説明にも使えます)。
契約・運用に落とし込む:チェック結果を「守れる形」にする
チェックリストで評価しても、契約や運用に反映されなければ効果は薄れます。実際の事故は「決めていなかった」「連絡が遅れた」「権限が残っていた」で起きがちです。チェック項目のうち重要なものは、契約条項・運用手順・権限設計に埋め込むのがポイントです。
具体的には、次の3点セットで固めます。
- 契約(委託契約・基本契約):秘密保持、再委託条件、事故時の連絡期限、損害・責任分界、監査協力
- SLA/運用合意:障害・インシデントの一次応答時間、復旧目標、定例会、変更管理
- 技術的な境界(権限・環境):本番アクセス方法、踏み台/VPN、操作ログ、権限付与・削除フロー
例えば「インシデントは速やかに連絡」では曖昧です。最低限、「疑いを含めて何時間以内に、誰に、どの手段で」まで決めます。さらに、委託先だけに責任を押し付けず、自社側の窓口(情シス・法務・広報・CS)も明確にします。
契約・運用に入れておくと揉めにくい項目例
- 再委託は事前承諾制(承諾なく再委託しない)
- アカウントは個人単位、退職・異動時は当日中に無効化
- MFA必須(対象サービスを列挙)
- 本番作業は事前申請・承認、作業ログを提出
- インシデントは「発覚から◯時間以内」に一次報告、◯営業日以内に報告書
- 年1回の棚卸し(権限・委託範囲・データ保管場所)
また、委託先が「全部対応は難しい」と言う場合、技術的にリスクを下げる選択肢もあります。たとえば、委託先に本番DBを触らせない設計にする、個人情報をマスキングした検証データを使う、権限を期限付きにする、操作を録画・監査ログ化するなどです。セキュリティは“人の善意”ではなく“仕組み”で担保する方が強いです。
3分でできる! 開発費用のカンタン概算見積もりはこちら
現場で回る運用例:初回評価→改善→定期見直し
チェックリストは一度作って終わりではなく、運用で育てるものです。特に中小企業や、情シスが少人数の組織では「完璧な監査」を目指すと止まります。現実的には、初回は重要項目に絞って開始し、半年〜1年で改善サイクルを回すのが成功しやすいです。
- 初回(契約前/更新前):必須10〜20問+赤信号項目で評価。追加で“証跡が出せるか”を確認。
- ギャップ整理:未対応項目を「すぐ対応」「次回まで」「代替策」で分類。対応期限を合意。
- 導入(権限・運用整備):MFA、個人アカウント、ログ、連絡体制、作業申請を整える。
- 定例(運用中):月次/四半期で、変更・障害・ヒヤリハット共有。権限棚卸し。
- 年次見直し:委託範囲が拡大していないか(本番作業増、個人情報追加など)を再評価。
運用でよくある落とし穴は、「委託先が増え、チェックリストが形骸化する」ことです。これを避けるには、社内でテンプレート化し、案件ごとの例外を少なくするのが効果的です。具体的には、委託形態ごとに3段階(低・中・高)のチェックリストを用意し、案件登録時に選ぶだけにします。
もう一つの落とし穴は、「委託先に丸投げして自社のセキュリティが止まる」ことです。委託先が強くても、アカウント発行が雑、退職者の権限削除漏れ、社内共有のパスワード、という自社側の運用不備で事故になります。委託先評価は、自社の運用を整えるきっかけにもなります。
明日からできる最小セット(高コスパ)
- 委託先の管理者権限にMFAを必須化
- 共有アカウント禁止(個人アカウント+権限期限)
- 本番作業は申請・承認・ログ提出
- インシデント連絡(窓口・手段・期限)を明文化
- 四半期に1回、権限棚卸し
まとめ
外注・委託先のセキュリティをチェックリストで評価する目的は、「相手を疑う」ことではなく、事故が起きやすいポイントを事前に潰し、責任分界と運用を明確にすることです。まずは委託範囲(誰が何にアクセスするか)と守る対象(個人情報・機密・事業継続)を整理し、リスクに応じてチェック項目を絞り込みましょう。
評価は合否だけでなく、重み付けした点数化と赤信号項目で判断すると、現場でも経営判断でも説明がしやすくなります。最後に、チェック結果を契約条項・運用ルール・権限設計に落とし込み、定期的に見直すことで、チェックリストが“書類”から“実際に守れる仕組み”に変わります。
株式会社ソフィエイトのサービス内容
- システム開発(System Development):スマートフォンアプリ・Webシステム・AIソリューションの受託開発と運用対応
- コンサルティング(Consulting):業務・ITコンサルからプロンプト設計、導入フロー構築を伴走支援
- UI/UX・デザイン:アプリ・Webのユーザー体験設計、UI改善により操作性・業務効率を向上
- 大学発ベンチャーの強み:筑波大学との共同研究実績やAI活用による業務改善プロジェクトに強い
コメント