契約書だけでは会社を守れない時代へ

契約・個人情報・クラウド・事故対応を一体で整備する

メタディスクリプションランサムウェア、委託先経由の攻撃、クラウド利用、個人情報漏えい、生成AIリスクが重なる時代、契約書だけでは企業を守り切れません。中小企業が整備すべき「契約・個人情報・クラウド・事故対応」の一体管理を、企業法務とサイバーセキュリティの実務視点から解説します。

1. 「契約書を作ったから安心」は、もう通用しない

かつて企業法務では、「取引基本契約書」「秘密保持契約書」「業務委託契約書」を整えておけば、相当程度のリスクを管理できると考えられていました。しかし、現在の企業活動は、クラウド、SaaS、外部委託、リモートアクセス、生成AI、API連携、海外データセンターなどを前提に動いています。

つまり、リスクは契約書の中ではなく、日々の業務フロー、クラウドの設定、委託先の管理、個人情報の扱い、事故発生時の初動に潜んでいます。

IPAの「情報セキュリティ10大脅威 2026」では、組織向け脅威の1位がランサム攻撃、2位がサプライチェーンや委託先を狙った攻撃、3位がAIの利用をめぐるサイバーリスクとされています。いずれも、単に契約書に「秘密を守る」と書くだけでは防げないリスクです。

また、2025年にはサイバー対処能力強化法及び同整備法が成立・公布され、日本のサイバーセキュリティ体制は官民連携を含めて新しい段階に入りました。直接の義務対象は重要インフラ等が中心ですが、委託先・クラウド事業者・システム開発会社を含めたサプライチェーン管理の重要性は、一般の中小企業にも確実に及んでいます。

2. 会社を守るには「契約・個人情報・クラウド・事故対応」を分けて考えない

実務でよく見る失敗は、次のような「縦割り管理」です。

契約書は総務や法務が保管している。個人情報管理は現場任せ。クラウドの契約内容は情報システム担当しか知らない。事故対応は起きてから考える。委託先管理はチェックシートを一度送っただけで終わっている。

この状態では、いざ事故が起きたときに、誰が判断するのか、どの契約に基づいて委託先へ何を要求できるのか、個人情報保護委員会への報告が必要か、顧客へ通知すべきか、クラウドログを取得できるのか、バックアップから復旧できるのかが分かりません。

NIST Cybersecurity Framework 2.0も、サイバーリスク管理を特定のIT部門だけの問題ではなく、組織全体のガバナンス、リスク管理、契約・調達、サプライチェーン管理と結び付ける考え方を示しています。特にサプライヤーとの契約等にサイバーリスク要求事項を組み込むことが明記されています。

中小企業に必要なのは、分厚い規程集ではありません。必要なのは、契約書、個人情報管理台帳、クラウド/SaaS台帳、委託先管理台帳、事故対応手順を一本の線でつなぐことです。

3. 契約書に入れるべき条項は「秘密保持」だけでは足りない

秘密保持条項は重要です。しかし、現在のサイバーリスクに対しては、それだけでは不十分です。

業務委託契約、システム開発契約、クラウド利用契約、保守契約、BPO契約では、少なくとも次の観点を確認する必要があります。

項目	実務上の確認ポイント
情報の範囲	秘密情報、個人情報、個人データ、営業秘密、認証情報、ログ、バックアップデータを区別しているか
委託先の安全管理	アクセス制御、多要素認証、暗号化、ログ保存、脆弱性対応、バックアップ、再委託管理を求めているか
クラウド利用	データ保存場所、管理者権限、障害時対応、監査証跡、退会時のデータ削除・返還を確認しているか
事故報告	「漏えいのおそれ」「不正アクセスの疑い」の段階で、何時間以内に誰へ報告するかを決めているか
調査協力	ログ提出、原因調査、証拠保全、顧客説明資料、再発防止策への協力義務があるか
生成AI利用	顧客データや個人情報を生成AIに入力してよい範囲、学習利用の可否、出力物確認の責任を定めているか
再委託	再委託の事前承認、再委託先への同等義務、再委託先事故時の責任範囲を定めているか

特に事故報告条項は、「漏えいが確定したら報告」では遅すぎます。実務では、漏えいの有無が確定する前に、調査・封じ込め・顧客対応・行政報告の準備が始まります。したがって、契約条項では「漏えい等が発生した場合」だけでなく、漏えい等のおそれ、不正アクセスの疑い、クラウド設定ミス、認証情報の漏えい、ランサムウェア感染の疑いまで含めて、報告義務を設計する必要があります。

4. 個人情報は「保有しているか」ではなく「どこを流れているか」で管理する

個人情報管理で最も危険なのは、「当社は顧客名簿くらいしか持っていない」という思い込みです。

実際には、問い合わせフォーム、ECサイト、採用応募、給与計算、勤怠管理、メール配信、CRM、チャットツール、会計ソフト、クラウドストレージ、外部コールセンター、配送委託、保守ベンダーなど、個人情報は社内外を流れています。

個人情報保護委員会は、漏えい等報告について、速報は発覚日から3〜5日以内、確報は原則30日以内、不正な目的で行われたおそれがある場合は60日以内と案内しています。

プライバシーマーク付与事業者の場合は、PMK500に基づく事故等の報告、本人通知、公表、調査、注意・勧告、一時停止、取消しの制度的リスクもあります。最新のPMK500は2024年10月17日改定・同月31日施行として公表されています。 

したがって、個人情報管理は「プライバシーポリシーを作る」だけでは足りません。次の台帳を整備する必要があります。

台帳	記載すべき内容
個人情報管理台帳	取得元、利用目的、保存場所、担当部署、保管期間、廃棄方法
委託先管理台帳	委託先名、委託内容、提供する個人データ、契約締結日、再委託の有無
クラウド/SaaS台帳	サービス名、管理者、保存データ、MFA設定、ログ取得可否、データ所在
事故対応台帳	発生日、発見者、影響範囲、初動対応、報告先、再発防止策

この4つがつながっていない会社は、事故発生時に必ず混乱します。

5. クラウドは「便利な保管場所」ではなく「共同責任のリスク領域」

クラウドを使えば安全になる、という考え方は危険です。安全なクラウドサービスを選んでも、利用者側の設定ミス、権限管理の不備、退職者アカウントの残存、共有リンクの公開、ログ未取得、バックアップ未確認があれば、事故は起きます。

個人情報保護委員会は、クラウドサービス提供事業者に個人データの取扱いを委託する場合、サービス機能だけでなくセキュリティ対策を理解・確認した上でサービスを選択し、安全管理措置や役割・責任分担を規約や契約等で客観的に明確化するよう注意喚起しています。

政府情報システム向けにはISMAPがあり、政府が求めるセキュリティ要求を満たすクラウドサービスをあらかじめ評価・登録する制度として運用されています。民間企業でも、クラウド選定時の参考指標として有用です。

また、ISMSでは情報の機密性・完全性・可用性を守るマネジメントシステムとして、技術的対策だけでなく教育・訓練、組織体制の整備を含めて考えます。クラウド固有のリスクについてはISO/IEC 27017に基づくISMSクラウドセキュリティ認証もあります。

なお、プライバシー情報管理については、ISO/IEC 27701:2025の発行に伴い、ISMS-ACが従来のISMS-PIMS認証から、ISMS認証を前提としないPIMS認証へ制度変更することを案内しています。個人情報・プライバシー保護の第三者認証を検討する企業は、最新制度を確認する必要があります。

6. 事故対応は「発生後の広報」ではなく「発生前の設計」で決まる

ランサムウェアや不正アクセスが発生した直後、現場は混乱します。サーバを止めるべきか、ネットワークを遮断すべきか、委託先へ何を求めるか、顧客へいつ説明するか、警察・JPCERT/CC・個人情報保護委員会・認証機関へどの順番で連絡するか。これを事故発生後に初めて考えるのは危険です。

JPCERT/CCは、侵入型ランサムウェア攻撃への初動対応として、被害範囲の把握と最小化、侵入経路の封鎖、攻撃者の要求には応じずバックアップから復旧する方針を示しています。また、社内連絡体制、社外向け窓口、外部組織との連携担当者の確保も重要とされています。

中小企業で最低限決めておくべき事故対応手順は、次の7点です。

1. 誰が事故を受け付けるか

2. 誰がシステム停止・ネットワーク遮断を判断するか

3. 誰が顧客・取引先・行政機関への連絡を判断するか

4. 誰がクラウド事業者・保守会社・委託先へ連絡するか

5. ログ、端末、メール、脅迫文、通信記録をどう保全するか

6. 個人情報漏えい等報告の要否を誰が確認するか

7. 復旧後、再発防止策と契約・規程の見直しをどう行うか

事故対応規程は、紙で存在するだけでは意味がありません。年1回でもよいので、机上訓練を実施し、「休日夜間にランサムウェアが発生した場合」「委託先から漏えいの疑いが通知された場合」「クラウド共有リンクが外部公開されていた場合」など、実際の場面で動けるかを確認することが重要です。

7. 委託先にセキュリティ要求を出すときは、取引適正化にも注意する

サイバーセキュリティ対策では、委託先に対してISMS取得、脆弱性診断、ログ提出、多要素認証、バックアップ、事故報告、再委託制限などを求める場面が増えています。これは必要な管理です。

しかし、発注者側が一方的に高度なセキュリティ要求を追加し、その費用や工数を委託先に押し付けると、取引法務上の問題が生じます。

旧下請法は2026年1月1日から改正され、通称「取適法」として施行されました。改正により、適用対象の拡大、手形払等の禁止、協議に応じない一方的な代金決定の禁止などが追加されています。

公正取引委員会・中小企業庁の下請法ガイドブックでも、親事業者が下請事業者にISO認証取得を要請し、その取得費用を考慮せず一方的に従来どおりの下請代金を据え置く事例は、買いたたきの観点で問題になり得るものとして示されています。

つまり、セキュリティ要求は「厳しくすればよい」のではありません。発注者としては、必要なセキュリティ水準を明確にし、見積条件に反映し、協議記録を残し、契約書・仕様書・発注書に落とし込む必要があります。

8. 中小企業が整備すべき「一体型」文書セット

山崎行政書士事務所が中小企業法務の現場で重視しているのは、単発の契約書ではなく、次の文書を連動させることです。

文書	役割
取引基本契約書・業務委託契約書	権利義務、再委託、事故報告、損害対応、調査協力を定める
秘密保持契約書	取引開始前の情報開示、営業秘密、技術情報、顧客情報を守る
個人情報取扱覚書	委託先監督、安全管理措置、再委託、事故報告、返還・廃棄を定める
クラウド利用基準	SaaS選定、管理者権限、MFA、ログ、バックアップ、退会時処理を定める
情報セキュリティ基本方針	経営者の方針、従業員の行動基準、社外説明の基礎にする
個人情報保護規程	取得、利用、保管、委託、第三者提供、開示請求、漏えい対応を定める
インシデント対応規程	初動、封じ込め、報告、広報、復旧、再発防止を定める
委託先管理チェックシート	契約前・契約中・更新時の確認記録を残す
クラウド/SaaS台帳	どのクラウドに何の情報があるかを見える化する
事故対応チェックリスト	事故時に担当者が迷わず動けるようにする

重要なのは、これらを別々に作るのではなく、契約書の条項と社内規程と現場運用を一致させることです。契約書に「事故発生時は速やかに報告」と書いてあっても、社内に報告窓口がなければ機能しません。規程に「クラウド利用は承認制」と書いてあっても、現場が勝手にSaaSを使っていれば意味がありません。

9. まず90日で取り組むべき実務ステップ

中小企業が最初からISMSやPマークの全項目を完璧に整えるのは現実的ではありません。まずは90日で、次の順番で整備することをお勧めします。

第1段階：見える化契約書、委託先、クラウド、個人情報、重要データ、管理者アカウントを洗い出します。ここで、退職者アカウント、共有リンク、契約書の未締結、再委託の未把握が見つかることが多いです。

第2段階：優先順位付けすべてを同時に直すのではなく、個人データ、顧客情報、決済情報、認証情報、基幹システム、バックアップから優先して対策します。

第3段階：契約と規程の修正委託契約、個人情報取扱覚書、クラウド利用基準、事故報告条項を整備します。特に、事故報告、ログ提出、再委託、データ削除、バックアップ、調査協力は早急に見直すべきです。

第4段階：技術対策の確認多要素認証、最小権限、バックアップ復元テスト、EDR、メールセキュリティ、VPNやリモートアクセスの脆弱性対応、管理者権限の棚卸しを行います。

第5段階：事故対応訓練1時間でよいので、経営者、総務、情報システム、営業、広報、外部保守会社を交えて、事故発生時の連絡・判断・報告の流れを確認します。

経済産業省のサイバーセキュリティ経営ガイドラインも、経営者のリーダーシップの下でサイバーセキュリティ対策を推進し、経営者が認識すべき3原則とCISO等へ指示すべき重要10項目をまとめています。中小企業においても、サイバーセキュリティは情報システム担当者だけの問題ではなく、経営課題です。

10. まとめ：会社を守るのは「契約書」ではなく「動く仕組み」

契約書は、会社を守るための重要な道具です。しかし、契約書だけではランサムウェアを止められません。クラウドの設定ミスも防げません。個人情報保護委員会への報告期限も守れません。委託先の初動対応も動きません。

会社を守るには、契約書を起点にしながら、個人情報管理、クラウド管理、委託先管理、事故対応、技術対策を一体で整備する必要があります。

山崎行政書士事務所では、行政書士として対応できる範囲で、企業の契約書作成、個人情報保護規程、委託先管理文書、クラウド利用基準、事故対応規程、Pマーク・ISMSを見据えた文書整備を支援しています。紛争対応、訴訟、法律上の代理交渉、フォレンジック調査等が必要な場合は、弁護士・IT専門事業者等と連携し、会社を現実に守る体制づくりをお手伝いします。