外注先選びで必須のセキュリティ確認方法（情報管理チェックリスト）

外注で「一番起きてほしくない事故」は情報漏えい

外注（業務委託・開発委託・BPO）を使うと、スピードや専門性は手に入ります。一方で、取引先に顧客情報・社内資料・ソースコード・アカウント権限などが渡る瞬間から、自社だけでは守れないリスクが発生します。とくに「開発に詳しくない」「情シスが少人数」「何を聞けばよいかわからない」状態だと、価格や納期ばかりを見て、セキュリティ確認が後回しになりがちです。

現場で多いトラブルは、攻撃者によるハッキングだけではありません。たとえば、(1)外注先の個人PCに保存されたファイルが紛失・盗難、(2)共有リンクの誤送信、(3)退職者アカウントの放置、(4)テスト環境に本番データを複製していた、(5)委託先の再委託（孫請け）にまで情報が広がっていた——といった「運用の穴」から起きます。つまり重要なのは、難しい技術の話よりも、情報管理のルールと実行状況を確認することです。

この記事では、外注先選びの段階で最低限おさえるべき「セキュリティ確認方法」を、専門用語を噛み砕いて、チェックリスト形式で整理します。読むだけで、見積比較の前に「まず何を確認するか」「どこまで要求するか」「契約にどう落とすか」がわかるように構成しています。

セキュリティ確認の全体像：3段階で見ると迷わない

外注先のセキュリティ確認は、細かい項目を思いつきで聞くよりも、段階に分けて進めると抜け漏れが減ります。おすすめは次の3段階です。

たとえば「ISMS（ISO27001）を持っていますか？」は入口として有効ですが、それだけでは十分ではありません。認証があっても案件運用が甘いことはありますし、逆に認証がなくても実務の情報管理が堅い会社もあります。そこで、入口で足切りをしつつ、提案時に案件固有の確認（取り扱うデータ種別、アクセス権、開発環境、委託範囲）を深掘りし、契約後に運用で担保する——この流れが現実的です。

また、社内向けに説明する際は「事故が起きたら困るから」だけだと通りにくい場合があります。セキュリティ確認は、コストではなく“損失を避ける投資”です。漏えい時の調査費・報告・顧客対応・停止期間の機会損失は、外注費を簡単に上回ります。確認の手間を最初に払う方が、結果として安く済みます。

選定前に確認すべき「外注先セキュリティ」最低条件（入口チェック）

まずは候補を絞るための最低条件です。ここでのポイントは「聞けばすぐ答えられるか」。答えが曖昧・資料が出ない・責任者が不在の場合、運用も同じように曖昧になりやすいです。

体制と責任の所在

• 情報セキュリティの責任者（役職・氏名・連絡先）が明確か
• 社内ルール（情報管理規程、端末利用規程、持ち出し規程）が整備されているか
• 教育：入社時・年次でのセキュリティ研修、誓約書の取得があるか
• 再委託（下請け・孫請け）の方針：原則禁止か、条件付き許可か

「担当者が気を付けます」だけでは仕組みになっていません。“誰が管理して、どう担保するか”が言語化されているかを見ます。

認証・第三者評価（あると説明が早い）

• ISMS（ISO/IEC 27001）やプライバシーマークの取得状況
• クラウド利用が中心なら、SOC2レポートの有無（取得していれば強い）
• 脆弱性診断やペネトレーションテストの実施方針（年1回等）

認証がない場合でも即NGではありませんが、その分「運用の証拠」を求める必要があります。たとえば、教育記録、端末管理台帳、アクセス権レビューの記録などです。

端末・アカウント管理（事故の多い領域）

• 業務に使うPCは会社支給か（個人PC利用の可否）
• ディスク暗号化、画面ロック、ウイルス対策、OS自動アップデートの強制があるか
• アカウントは個人単位で発行され、共有アカウントを避けているか
• 退職・異動時のアカウント停止が即日で行われるか

外注先が複数人で関わるほど、「共有ID・パスワードの使い回し」が最大の地雷になります。ここは入口で必ず確認します。

提案・見積時に深掘りする「情報管理チェックリスト」（案件別）

次は、実際の委託内容に合わせて確認するパートです。ここが弱いと「会社としては立派だが、この案件は危ない」状態になります。以下のチェックリストを、そのままRFP（提案依頼）やヒアリングシートに貼って使える形でまとめます。

「本番データを渡すか？」は原則No。渡すなら条件を決める

外注でよくあるのが「テストのために本番の顧客データを渡してしまう」ケースです。外注先が悪いというより、発注側が「動作確認に必要だから」と安易に渡してしまうのが原因です。基本方針は、本番データは外に出さない。どうしても必要なら、次の条件をセットにします。

• データを匿名化（氏名・メール・住所を置換）して渡す
• 期間限定（例：2週間）でアクセスを許可し、終了後にアクセス停止
• 保存は禁止し、閲覧のみ・ダウンロード不可にする（可能なら）
• 作業場所と作業者を限定し、ログを残す

認証情報（ID/パスワード、APIキー）をどう扱うか

システム開発委託では、クラウドの管理画面、Git、広告アカウント、メール配信ツールなど、強い権限を外注先に渡す場面があります。このとき「とりあえず管理者権限で渡す」「メールでパスワード送る」は危険です。権限の粒度と渡し方をルール化しましょう。

• アカウントは個別発行（外注先個人のメールで招待）
• 権限は必要最小限（閲覧/編集/管理者を分ける）
• パスワード共有が必要なら、パスワード管理ツール（例：1Password等）を使う
• 鍵・トークンは定期ローテーションし、作業終了時に失効

「開発物の保管場所」と「持ち出し禁止」をセットで決める

ソースコードや設計書が、外注先の個人PC、個人Dropbox、個人Googleドライブに散らばると、回収不能になりがちです。おすすめは、成果物の一次保管場所を発注側が指定することです。例としては、GitHub/GitLab/Bitbucketの組織アカウント、SharePoint/Boxの共有領域など。外注先はそこにコミット・アップロードし、ローカルは作業キャッシュ程度に留める運用にします。

契約に落とす：NDAだけでは足りない条項と実務のポイント

セキュリティ確認で合意した内容は、契約に書いて初めて効力を持ちます。NDA（秘密保持契約）だけ締結して「情報は守ります」で終わらせると、事故時に争点が増えます。ここでは、専門知識がなくても押さえやすい契約ポイントを整理します。

NDAに加えて必要になりやすい取り決め

• 委託契約（業務委託・準委任・請負）側の条項：安全管理措置、再委託、監査、事故時の通知
• 個人情報がある場合：個人情報取扱いに関する覚書（委託先の義務、目的外利用禁止等）
• クラウドを使う場合：利用サービスの範囲（例：生成AIへの投入禁止/条件付き許可）

最低限入れておきたい条項（ひな型の考え方）

法務の専門相談が望ましいですが、発注側のたたき台としては、次の観点が重要です。

• 安全管理措置：端末暗号化、アクセス制御、ログ取得等を「講じる義務」として明記
• 再委託：事前書面承諾制、再委託先にも同等義務、責任の所在
• 事故時の連絡：発覚後○時間以内に一次報告、原因・影響・再発防止の提出
• 監査・報告：年1回の自己点検報告、必要に応じて発注側が確認できる権利
• データの返却・消去：契約終了時の返却、外注先側の消去、消去証明（証跡）

ポイントは、“やること”を具体化し、期限と証跡をセットにすることです。「適切に管理する」だけでは、適切の中身が争点になります。

見積の段階で「セキュリティ対応費」を分けて出してもらう

セキュリティはタダではありません。権限設計、環境分離、ログ設計、脆弱性診断、WAF設定、運用手順書の作成など、工数がかかります。ここを見えないまま契約すると、後から「それは追加費用です」「納期に間に合いません」になりがちです。見積時点で、セキュリティ対応を項目として明細化してもらうと、社内稟議もしやすくなります。

運用で差がつく：開始後にやるべき継続チェックと監査のしかた

外注先のセキュリティは、契約した瞬間がゴールではなくスタートです。とくに半年〜1年の長期委託では、人の入れ替わりや委託範囲の拡大で、最初の前提が崩れます。そこで、運用での継続チェックが重要です。

月次・四半期で見るべきチェック項目

• アカウント棚卸：外注先メンバーの一覧、権限、不要アカウントの削除
• 共有設定の点検：共有リンクの期限切れ、公開範囲（社外公開になっていないか）
• ログの確認：異常アクセス・大量ダウンロード・深夜アクセスなどの兆候
• 脆弱性対応：ミドルウェアやライブラリの更新方針、対応期限
• 作業環境：端末ポリシー遵守、個人PC利用が混ざっていないか

情シスが忙しい場合は、全部を自社でやろうとせず、外注先に月次の自己点検レポートを提出してもらい、重要点だけレビューする形が現実的です。

監査は「抜き打ち」より「確認しやすい仕組み」を作る

監査というと身構えがちですが、目的は「違反を見つけて罰する」ではなく、事故を起こさないための改善です。おすすめは、次のように仕組みで確認可能にすることです。

• 成果物は指定リポジトリに集約（コミット履歴が証跡になる）
• ファイル共有は企業向けストレージに限定（監査ログが残る）
• 権限申請はチケット化（誰がいつ何を要求したかが残る）

人を信用しないのではなく、仕組みで迷わない状態にするのが、良いセキュリティ運用です。

インシデント発生時の「初動」を事前に決めておく

万が一、情報漏えい・不正アクセス・誤送信などが起きた場合、初動が遅れるほど被害が拡大します。契約書の条項に加えて、実務として次を決めておきましょう。

• 外注先→発注側への連絡窓口（24時間連絡可能な手段を含む）
• 一次報告に含める項目（いつ・何が・どの範囲・暫定対応）
• 証拠保全（ログの保存、アカウント停止、鍵のローテーション）
• 顧客・取引先への説明方針（発表前に外注先が独断で連絡しない）

そのまま使える：外注先セキュリティ確認の質問集（コピペOK）

最後に、ヒアリングやメールでそのまま使える質問例をまとめます。ポイントは「Yes/Noで答えられるもの」と「証拠（資料・画面・台帳）を出せるもの」を混ぜることです。回答の速さと具体性は、運用成熟度の指標になります。

なお、生成AIの利用が業務に入り込むケースも増えています。外注先がドキュメントやソースコードを外部AIに貼り付けると、意図せず機密が外部送信される懸念があります。必要に応じて、「生成AIへの投入可否・条件（匿名化、社内限定AIのみ等）」も確認項目に入れてください。

まとめ

外注先選びのセキュリティ確認は、「詳しい人だけができる専門領域」ではなく、情報の流れと権限を整理し、ルールと証跡で固める作業です。入口では体制・端末・アカウント・再委託方針を確認し、提案・見積では案件に合わせてデータ受け渡し、保存、アクセス権、本番データ、ログ、インシデント対応を具体化します。そして契約で義務・期限・証跡を明記し、開始後は棚卸とレポートで運用を継続的に点検する——この3段階が、事故を最も減らします。

「何をどこまで求めるか」は、扱う情報の重要度で変わります。自社だけで判断が難しい場合は、要件定義やRFP作成の段階から、外注設計とセキュリティ要件を一緒に整理すると、過不足のない確認ができます。