EUの顧客から「NIS2準拠を証明してほしい」という質問票が届いたとき、返答を情報システム部だけへ渡すと詰まります。質問はアクセス制御だけで終わらず、経営責任、事業継続、脆弱性開示、直接供給者、事故連絡、契約終了後のデータまで広がるからです。一方、依頼された日本企業がNIS2の直接対象とは限りません。
結論は、日本企業が「NIS2認証」を探す前に、EU顧客との商流、提供サービス、EU域内の拠点・規模、顧客が自社を直接供給者としてどう評価するかを分けることです。直接義務主体でなくても、証跡提出と事故連絡は契約要件になり得ます。
根拠にしたのは、2026年9月1日時点のNIS2指令、欧州委員会、ENISAの一次情報です。日本の供給者が受ける実務質問へ翻訳しますが、各加盟国の国内法、監督当局、契約、提供地域で結論は変わります。法的適用はEU法と現地法に詳しい専門家へ確認してください。
最初の30分で「誰の義務か」を分ける
直接適用と顧客契約を混ぜると、過剰対応と見落としが同時に起きます。
NIS2指令は、附属書I・IIに掲げる分野のうち、原則として中規模以上でEU域内にサービスを提供・活動する一定の事業体を対象にします。規模にかかわらず対象となる例外や、EU域外事業者の代表者に関する規定もあります。日本に本社があるという一事だけでも、EU顧客へ納品しているという一事だけでも判定できません。
判定表には、契約主体、サービス提供国、EU拠点、従業員・売上規模、提供分野、顧客名ではなくサービスの種類、重要インフラとの関係を書きます。顧客自身がessential entityまたはimportant entityである場合と、自社自身も対象となる場合を別の行にします。
「当社はEU法人ではないので関係ない」と「EUへ売っているので当社も直接対象だ」は、どちらも判定を一段飛ばしています。直接適用と、顧客の供給網管理を通じた契約上の要求は別です。
欧州委員会のFAQは、NIS2が従来より対象分野を広げ、経営層の責任、より正確な報告要件、制裁の調和を含むと説明しています。顧客の法務部門が適用主体を確認し、調達部門が供給者要件へ落とすため、日本側は法令質問と商取引質問へ窓口を分けます。
顧客が見たいのは、規程の枚数ではなくリスクとのつながり
サービス、資産、対策、証拠、例外を一つの索引で追えるようにします。
NIS2第21条は、リスク分析、インシデント処理、事業継続、危機管理、サプライチェーン、取得・開発・保守、脆弱性処理、対策有効性、暗号、人・アクセス・資産、必要に応じた多要素認証などを含む技術的・運用的・組織的対策を挙げます。直接供給者やサービス提供者との関係では、その供給者固有の脆弱性と製品・開発慣行の品質を考慮します。
質問票へ「規程あり」とだけ書いても、顧客は自社リスクへ接続できません。提供サービス名、処理データ、接続、重要な下請、資産台帳、認証方式、バックアップ、復旧目標、脆弱性受付、通知窓口、直近の演習と改善を同じ索引で渡します。
良い証跡は「対策を実施している」という現在形ではなく、対象、責任者、実施日、結果、例外、是正期限まで追えます。ISO認証や監査報告は有力な証拠ですが、顧客へ提供するサービス範囲が認証範囲外なら、その差分を補う必要があります。
方針書、資産、テスト結果、例外、改善をサービス単位で索引化すると、顧客が自社リスクへ結び付けられます。
供給者台帳は社名一覧で終わらせない
自社が顧客の直接供給者であると同時に、クラウド、ソフトウェア部品、保守会社、データセンターへ依存している場合、質問は一段下へ続きます。台帳には、供給者名だけでなく、何を依存し、停止すると何時間で顧客へ影響し、代替があり、事故情報を何時間で受け取れるかを書きます。
SBOM導入の進め方はソフトウェア部品の把握に使えます。ただしSBOMだけでは、運用委託先の特権ID、データ復旧、通信障害、要員不足を説明できません。サプライヤーサイバーリスク管理と組み合わせ、製品部品とサービス依存を分けます。
ENISAの供給網ガイダンスは、供給者選定・契約基準、セキュア開発、脆弱性処理、品質を扱います。最安値と納期だけで選定していた委託先へ、後から無制限の監査や短時間通知を要求しても実行できません。次回更新まで待てない重要契約から、追加合意と代替策を決めます。
事故連絡は72時間という一つの数字で設計しない
顧客が自社の当局報告を判断する時間を、供給者側の連絡設計へ戻します。
NIS2第23条は、重大な影響を持つインシデントについて、早期警告、通知、必要に応じた中間報告、最終報告という段階を置きます。24時間や72時間は対象事業体が当局へ行う段階報告の重要な基準ですが、日本の供給者が顧客へ72時間後に初めて知らせれば間に合う、という意味ではありません。
顧客は影響範囲を判断し、自社の当局報告を準備する時間が必要です。契約では、確証を得た時刻ではなく「影響の可能性を認識した時刻」を起点にするか、初報に必要な最小情報、更新間隔、休日連絡、誤報時の扱いを決めます。
供給者から顧客への初報期限は、顧客から当局への法定期限より短く置かなければ、顧客側の調査時間が消えます。一律の2時間通知を全事故へ課すと雑音が増えるため、対象サービス、機密性・完全性・可用性、利用者、越境、継続時間で重大度を分けます。
誰が最初に気付き、何を顧客へ伝え、次の更新をいつ出すかは、連絡網ではなく実際の時系列で試します。
初報へ入れる六つの事実
初報は原因究明報告書ではありません。発見時刻、影響するサービス、観測した事象、現時点の影響範囲、実施した封じ込め、次回更新時刻を入れます。攻撃者や原因を断定できない段階では、事実と仮説を分けます。個人データ、製品安全、サービス停止が絡む場合は、それぞれの法令・契約の報告も並行して確認します。
ログを90日で削除しているのに、契約で一年分の原因分析を約束する、海外時刻を日本時間だけで記録する、再委託先の連絡が営業担当で止まるといった矛盾は机上演習で見つかります。SOCとMDRの違いを使う場合も、検知会社が顧客通知の法的判断まで担うとは限らないため、責任分界を残します。
契約へ入れるのは「NIS2を守ること」ではなく実行条件
抽象的な遵守条項を、日々実行できる期限・成果物・責任へ変えます。
「NIS2その他の法令を遵守する」という一行は、対象範囲も期限も成果物も決めません。別紙へ、対象サービス、最低対策、証跡、監査方法、重大度、連絡期限、脆弱性対応、再委託、データ所在、事業継続、終了時返却・削除を置きます。
監査権は、無制限の現地立入りだけが正解ではありません。第三者報告、質問票、リモート説明、特定条件での現地監査を段階化します。複数顧客から毎週異なる監査を受ければ現場が止まるため、共通証跡室を作り、顧客固有差分だけを追加します。証跡に機密情報が含まれる場合は、閲覧者、複製、保存期間も決めます。
契約で約束する対策は、営業が受注時に書ける最大値ではなく、運用部門が毎日実行し、監査で再現できる値です。実行できない24時間修正や全下請への同一条件を約束するより、重大度別期限、補完策、例外承認、改善計画を明示します。
欧州委員会の2026年提案は、現行義務と混ぜない
欧州委員会は2026年1月、サイバーセキュリティ・パッケージの一部としてNIS2の改正案を公表しました。これは手続を経る提案であり、現行指令と各国法を自動で置き換えた確定法ではありません。社内資料では「現行法」「各国実装」「提案」「顧客独自要件」を別欄にし、提案を既に必須であるかのように説明しません。
各国の移行状況や監督運用には差があります。EU全体のFAQだけで契約を決めず、顧客所在国とサービス提供国の当局ページ、国内法、ガイダンスを確認します。複数国へ同じサービスを出す場合は、共通の高い基準と国別差分を分けます。
60日で作る供給者向け証跡パッケージ
質問票が来るたびに探す状態から、サービス単位で更新できる状態へ移します。
最初の10日で、上位10顧客と提供サービス、契約主体、EU関連、顧客の業種を並べます。次の10日で、サービスごとのデータ、接続、資産、再委託、停止影響を一枚にします。21日目から、アクセス、バックアップ、脆弱性、事故、継続、教育の証跡を集めます。
31日目には、足りない証拠を対策不足と記録不足へ分けます。対策がないものは実装し、実施しているが証拠が残らないものはチケット、承認、テスト結果を保存します。45日目までに顧客向け回答と機密度を決め、60日目に営業、法務、セキュリティ、運用、経営で事故演習を行います。
完成条件は質問票を埋めたことではなく、質問の根拠となる資産・担当・証拠を更新でき、事故時に同じ情報から顧客へ初報できることです。質問票だけを複製すると、翌年の回答が実態から離れます。
200問の質問票を三種類の回答へ分解する
受け取った質問を、そのまま200人へ割り振りません。第一は事実で答えられる質問です。暗号方式、バックアップ頻度、脆弱性窓口、再委託先などを証跡台帳から引用します。第二は顧客との責任分界で答える質問です。顧客側設定、利用者ID管理、データ投入、障害連絡などを共同責任表へつなぎます。第三は現時点で満たさない質問です。無理にYesへせず、リスク、補完策、改善期限、責任者を書きます。
回答の根拠を「社内規程第5条」だけにしないでください。規程が求める月次レビューについて、直近の実施記録、未完了項目、承認者まで提示できるようにします。顧客から証拠の原本を求められた場合は、他顧客名、社員情報、ネットワーク詳細を伏せ、閲覧だけを許す資料と提出できる資料を分けます。
質問票ごとに新しい表現を作ると、同じ事実へ矛盾した回答が生まれます。共通回答には所有者と確認日を付け、顧客固有の上乗せは差分として残します。営業が過去回答をコピーするのではなく、証跡の所有部門が変更を承認します。
顧客から「重大脆弱性は24時間以内に修正」と求められたら、全資産へ一律に同意せず、悪用状況、外部公開、サービス重要度、更新試験、停止影響を基に段階期限を提案します。期限内に修正できない場合の分離、機能停止、監視、顧客通知まで約束すると、YesかNoだけの回答より実行可能になります。
取引終了時も供給網リスクは残る
契約終了日にアカウントを消しても、バックアップ、ログ、顧客データの複製、保守端末、下請の保存物が残る場合があります。返却・削除の対象、証明方法、法定保存との優先、暗号鍵の破棄、問い合わせ窓口を終了計画へ入れます。
顧客側に残る自社エージェントや証明書、許可IPも削除対象です。双方の台帳を突き合わせ、再接続が拒否されるところまで試します。取引終了後に発見した、契約期間中へ遡る事故を何日以内に通知するかも決めます。
顧客から要求が来ていない会社でも、ゼロトラスト導入ロードマップの前に重要サービスとIDを棚卸しし、製造業のサプライチェーン可視化で停止影響を整理すると、NIS2以外の取引先監査にも使える基盤になります。
まとめ
日本の供給者に必要なのは、NIS2という名称を規程へ追加することではありません。直接適用の有無を法的に判定しつつ、顧客が自社の供給網リスクを管理するために必要な証拠を、サービス単位で渡せる状態を作ります。
適用判定、証跡、契約、事故連絡を一つのサービス台帳へ結び、顧客の報告期限より前に事実を更新できる会社は、NIS2対応を監査イベントではなく取引継続能力へ変えられます。
参考情報
以下は2026年9月1日に確認した一次情報です。
よくある質問
気になる質問を開くと、本文の重要点を短く確認できます。
Q日本企業もNIS2の直接対象ですか？
A日本本社という理由だけでも、EU顧客へ供給するという理由だけでも決まりません。EU域内での提供、拠点・代表者、分野、規模、例外、各国法を確認します。直接対象でなくても顧客の供給網管理を通じて契約要件を受ける場合があります。
QNIS2の認証を取得すれば回答できますか？
ANIS2そのものを一つの認証で満たす仕組みではありません。第三者認証は証拠の一部になりますが、対象サービス、事故連絡、再委託、各国法、顧客固有条件との差分を補う必要があります。
Q顧客への事故連絡は72時間以内でよいですか？
A一律に72時間後でよいとは言えません。顧客自身が当局報告を判断する時間が必要です。契約で初報の起点、対象、最小情報、更新間隔を決め、顧客の期限より前に知らせます。
QSBOMを渡せば供給網対策は十分ですか？
A十分ではありません。SBOMはソフトウェア部品の証跡ですが、クラウド、運用委託、特権ID、復旧、人員、通信などのサービス依存は別に管理します。
Qすべての顧客へ同じ証跡を渡してよいですか？
A共通証跡は再利用できますが、提供サービス、データ、国、契約、顧客の重要度で差分があります。機密情報の閲覧者と保存期間も顧客別に決めます。
Q欧州委員会の2026年改正案は既に守る必要がありますか？
A提案と現行法を分けてください。提案は手続を経て内容や施行時期が変わり得ます。現時点の指令、各国法、監督当局ガイダンス、契約要件を優先します。
