要点まとめ。 NIS2 Article 21(2)(d) はサプライチェーンリスクを調達部門の注釈ではなく、経営レベルの問題に格上げします。指令はセルフホスティングを義務付けているわけではありません。しかし、データパスに何があるのか、そのベンダーが最悪の一日を迎えたときに自社はどうなるかを問います。セルフホスト型インフラは、大半の SaaS データパスが持つ 4 層のうち 3 層を取り除きます。4 層すべてを取り除くわけではなく、そう主張するのは CISO を監査担当者の前で窮地に立たせるマーケティング上の誇張です。
- 指令本文と ENISA のガイダンスを平易な言葉で解説します。
- 多くのチームが見落とす 4 層構造の SaaS データパスを説明します。
- Rediacc の 2 ツールモデルがベンダー登録簿から何を除去し、何を残すかを示します。
- 「NIS2 対応済み」を主張するベンダーへの 6 つの調達チェックリストを提供します。
2020年7月、Blackbaud は身代金を支払い、その事実を後から公表しました。事後に1万3,000を超える顧客組織へ通知し、7つの司法管轄で集団訴訟に対応し、最終的には州検事総長との和解金4,950万ドルと、SEC による誤解を招く開示への制裁金300万ドルを支払うことになりました。その1万3,000の組織のすべてが Blackbaud とデータ処理契約 (DPA) を締結していました。大半は Blackbaud の SOC 2 レポートを確認していました。多くが Blackbaud をベンダーリスク登録簿に載せ、ティア評価、更新日、担当者名を記載していました。
それでも連鎖は止まりませんでした。データは Blackbaud の境界内にありました。バックアップ環境が侵害されると、すべての顧客組織が同時に被害を受けました。
NIS2 Article 21(2)(d) は「ベンダーを監査したか」よりも厳しい問いを立てます。データパスに何があり、そのベンダーが最悪の一日を迎えたときに自社はどうなるか、という問いです。大半のチームにとって答えは「自社とベンダーは一体であり、それに気づいていなかった」です。
この記事は、2026年に DPA を再交渉する CISO と調達責任者に向けたものです。Article 21(2)(d) のデータパスからの読み解きであり、認証からの読み解きではありません。また、セルフホスト型インフラが解決しないことについても正直に述べます。監査担当者が必ず問うのはそのギャップ部分ですが、マーケティングパンフレットは飛ばすからです。
Article 21(2)(d) が実際に義務付けること
指令の英語原文は次のとおりです（EUの公式文書に邦訳は存在しないため、権威ある英文のまま掲載します）。
“Member States shall ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use […] and shall include at least the following: […] (d) supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”
購入者にとってこのテキストで重要な点が 2 つあります。
第一に、義務を負うのはあなた自身であり、ベンダーではありません。ベンダーの認証、ベンダーの SOC 2、ベンダーの ISO 27001 は、あなたのリスク評価への入力情報です。それらはリスク評価の代替にはなりません。ベンダーのコンプライアンス態勢が完璧でも侵害が起きた場合、規制当局が問うのはあなたのサプライヤーリスク管理であり、ベンダーのそれではありません。
第二に、義務は契約の範囲を超えます。ENISA の 2024年実施ガイダンス、欧州委員会実施規則 (EU) 2024/2690 の附属書 IV は、期待される実務を示しています。ICT サプライヤーの登録簿を維持し、重要度に応じて分類し、業務やデータ処理に対するリスクをそれぞれ評価し、定められた周期で評価を更新することです。附属書 IV は「サプライヤーのサプライヤー」を明示的にスコープ内と定めており、ほとんどのチームはここで、自社のベンダー登録簿が本当の意味での登録簿ではなく、ラベルを貼った契約リストに過ぎないことを発見します。
調達側からの実務的な解釈は次のとおりです。本番データへの論理的アクセスを持つすべてのベンダーを列挙し、スコアリングし、監視し、交代可能にしなければなりません。「交代可能」という部分が、既存のほとんどの取り決めを破綻させます。
多くのチームが描き忘れる 4 層構造の SaaS データパス
調達責任者と座って、バックアップベンダーの製品が 1 件のレコードを書き込む際に何が起きるかを追ってみます。正直なデータパスは次のとおりです（上から下へ）。
- ベンダーアプリケーション。 データを取り込み、ルーティングを決定し、ビジネスロジックを適用するコードです。ベンダーのインフラ上で動作し、ベンダーが保守・パッチ・監視します。
- ベンダークラウド。 アプリケーションが動作するハイパースケーラーのリージョンまたはベンダー自身のデータセンターです。ストレージボリューム、ネットワーク、IAM が含まれます。多くの場合、ベンダーが副処理者契約を結んでいるハイパースケーラーです。
- ベンダーの鍵管理。 ベンダークラウド上の保存データを保護する暗号化鍵です。大半の SaaS 契約ではベンダーが保有します。「カスタマー管理鍵」は上位ティアのオプションとして提供されることもありますが、その場合でも鍵はベンダーの IAM が呼び出せるハイパースケーラーの KMS 上にあります。
- ベンダーの副処理者。 ベンダーが利用するサードパーティサービス（CDN、オブザーバビリティ、請求、カスタマーサポートツールなど）で、データやそこから派生するメタデータを経由・保存する可能性があります。
これら 4 層のそれぞれが、Article 21(2)(d) のサプライヤー登録簿の 1 エントリになります。それぞれに固有のインシデント履歴、侵害の影響範囲、契約交渉の対象があります。SaaS ベンダーと更新するたびに、暗黙的に 4 層すべてを更新します。SaaS ベンダーとの契約が、あなたが交渉できる唯一のものだからです。
Blackbaud インシデントはレイヤー 2 の侵害（ベンダークラウド）であり、レイヤー 1（ベンダーアプリケーション）を通じて伝播し、レイヤー 3（ベンダーの鍵管理。このケースでは侵害されたデータベースでテナント分離なしのサーバーサイドキー）のために全顧客に可視化されました。Blackbaud の副処理者は侵害の経路ではありませんでしたが、顧客はそれまで列挙していなかった副処理者が 3 社あることをこの機に知りました。
Blackbaud、Druva 型の鍵管理、連鎖パターン
Blackbaud の SEC 提出書類から、NIS2 の観点で重要な 3 つの詳細があります。
第一に、Blackbaud は顧客データの暗号化鍵を保有しており、侵害対象となったバックアップ環境も同様でした。カスタマー管理鍵は提供されていませんでした。事後の SEC 訴訟では、Blackbaud の契約がそれを認めていたため、コントロールのギャップとして特徴付けられましたが、規約違反とはされませんでした。同じ取り決めに対する Article 21(2)(d) の観点はより厳しく、顧客は可視性を持たないコントロールのリスクを意味ある形で評価できないからです。
第二に、侵害はライブデータベースより古いバックアップデータに及びました。Blackbaud のプライマリシステムからライブデータが削除されていた顧客組織も、バックアップ環境を通じてデータを露出しました。これが連鎖パターンです。ベンダーの侵害が、顧客がすでにスコープ外と考えていた履歴データにまで到達します。
第三に、1万3,000を超える顧客組織が侵害通知を受けました。その多くは対応する運用能力を持たない小規模な非営利団体や学校であり、DR 手順書も、フェイルオーバー先の第二バックアップベンダーも持っていませんでした。その意味でベンダーのインシデントが、そのまま彼ら自身のインシデントになりました。
Druva 型の現代的な SaaS バックアップでは、アーキテクチャは一部で改善されています（テナント単位の鍵分離はより一般的になり、上位ティアでは BYOK が提供されています）。しかし、4 層構造のデータパスは同じです。ベンダーアプリケーション、ベンダークラウド（通常は AWS）、鍵管理（ベンダー保有、カスタマー KMS での BYOK、またはハイブリッド）、副処理者。どのレイヤーで侵害が起きても全顧客に同時に到達します。すべての顧客データが境界の同じ側にあるからです。
これが構造的な論拠です。Druva への批判ではありません。Druva は Blackbaud よりも厳格に運営しています。論拠は、SaaS 設計のバックアップ製品の構造が、レイヤー 2 およびレイヤー 3 の侵害を Article 21(2)(d) の義務として生じさせており、顧客がそれを意味ある形で果たせないという点にあります。
セルフホスティングが 4 層のうち 3 層を取り除く
Rediacc は異なる設計です。完全なアーキテクチャはアーキテクチャページに文書化されていますが、サプライチェーンに関連する形状は SSH 越しに通信する 2 つのバイナリです。
rdcはオペレーターのワークステーションで動作します。~/.config/rediacc/以下のフラットな JSON 設定ファイルを読み込み、オペレーター自身のマシンに SSH で接続してコマンドを発行します。renetはオペレーター自身のサーバー上で root 権限で動作し、LUKS2 暗号化ディスクイメージ、分離された Docker デーモン、リバースプロキシを管理します。
オペレーターはバックアップ、リストア、フォークを実行するために Rediacc という会社のインフラにログインすることは一切ありません。データパスに Rediacc のクラウドは存在しません。リポジトリの LUKS2 認証情報はオペレーターのローカル設定ファイル（モード 0600）に保存され、サーバーには置かれず、Rediacc に送信されることもありません。データパスは次のとおりです。
- オペレーターのワークステーション。
rdcを実行し、LUKS2 認証情報を保持します。 - オペレーター自身のサーバー。
renetを実行し、LUKS2 暗号化リポジトリを保持します。 - オペレーター自身のバックアップ先。 rclone 互換の任意のストレージ（S3、B2、OneDrive、オンプレミスの MinIO など）。暗号化ボリュームを受け取ります。
レイヤー 4 は存在しません。実験的なクラウドアダプターにオプトインしていないオペレーターに対して、Rediacc という会社は副処理者ではありません。セルフホスト型オペレーターにとって、Rediacc との関係はソフトウェアライセンスであり、データ処理契約ではありません。
これがデータパスの論拠であり、サプライヤー登録簿の議論で最初に提示すべき論拠です。SaaS 競合はカスタマー管理鍵を提供できます（現代的な製品の大半はそうしています）。しかし SaaS 競合は「当社は副処理者ではない」とは言えません。
データパスの論拠が伝わった後の第二の論点は鍵管理です。Rediacc では、LUKS2 認証情報はオペレーターの設定ファイルの中にあります。それだけです。鍵エスクローも、オペレーターが認証情報を紛失した際に Rediacc が運営できるリカバリーサービスもありません。これはゼロ知識設定ストアの推奨アーキテクチャでもあり、暗号化鍵はパスキー PRF 拡張からクライアントサイドで導出され、サーバーは不透明なブロブを保存するだけです。サーバーは SSH 鍵、LUKS2 認証情報、IP アドレス、平文の設定を読み取ることができません。アクセストークンを更新しても、サーバーに遡及的な読み取り権限は生じません。
Article 21(2)(h)（暗号化）においてこれは重要です。Article 21(2)(d)（サプライチェーン）においてはさらに重要です。Rediacc という会社からオペレーターのデータへの最後の論理的アクセス経路を除去するからです。
セルフホスティングが取り除かないもの
セルフホスティングはサプライヤーリストを変化させますが、削除はしません。監査担当者がなお問い続けることが 3 つあります。
1. サプライヤーは依然として存在します。ただし異なるサプライヤーです。 ハードウェアベンダー（Hetzner、Hostinger、OVH、コロケーション施設、自社ベアメタル）。ハイパーバイザー（KVM、VMware）。OS（Debian、Ubuntu、RHEL）。コンテナレジストリ（Docker Hub、GHCR、プライベートレジストリ）。サービスが取得するベースイメージ。それぞれが Article 21(2)(d) のエントリです。セルフホスティングはサプライヤーリストを変化させますが、削除はしません。
2. Rediacc は ISO 27001、SOC 2、BSI C5 をまだ取得していません。 これらはロードマップにありますが、現時点では取得済みではありません。認証をゲーティング条件として使う調達チームにとって、これは実際の摩擦になります。防御可能な反論は、この記事が一貫して主張してきたものです。データパスの論拠は、それらの認証が証明する内容（ベンダークラウドのセキュリティコントロール、ベンダー人員のアクセス管理、ベンダーの副処理者管理）の大半がスコープ外であることを意味します。Rediacc という会社がデータパスに存在しないからです。その論拠は、認証が必要な購入者に認証の代替として提示するのではなく、慎重かつ防御可能な形で示す必要があります。
3. GRC レイヤーは依然としてあなたのものです。 Rediacc はオペレーターに 70 件以上のイベントからなるハッシュチェーン型監査ログを提供します（rdc audit verify がチェーンをエンドツーエンドで検証します）。ただし、サプライヤー登録簿、コントロールフレームワーク、エビデンス収集ワークフローは提供しません。それらは引き続き Drata、Vanta、OneTrust、またはヨーロッパの参入企業から調達することになります。その補完関係のコスト構造については、関連記事実際のコストで詳しく説明しています。
交渉不要になる DPA
具体的にするために、匿名化した実際の調達会話から「導入前後」の登録簿行を示します。買い手は附属書 II の「重要エンティティ」に分類された従業員 280 名のドイツ製造業企業です。バックアップに関する元のサプライヤー登録簿エントリは次のとおりでした。
| 項目 | 導入前 |
|---|---|
| ベンダー | Acme Backup SaaS |
| ティア | クリティカル |
| 処理データ | 本番データベース、顧客 PII、財務記録 |
| 副処理者 | AWS (eu-central-1)、Datadog、Stripe、Zendesk |
| 契約状況 | 2023年 DPA 署名済み、SCC 添付、措置スケジュールの最終確認 2025年1月 |
| 鍵管理 | ベンダー管理（現在のティアでは BYOK オプションなし） |
| 終了計画 | 「ベンダーは解約後 30 日以内に CSV 形式でデータをエクスポートすることに同意する」 |
| 最終評価 | 2025-Q1、鍵管理のギャップを指摘、更新時まで繰り延べ |
Hetzner 上の Rediacc に移行後：
| 項目 | 導入後 |
|---|---|
| ベンダー | (1) Rediacc OÜ、ソフトウェアライセンス；(2) Hetzner、IaaS |
| ティア | (1) 非クリティカル（データプレーンなし）；(2) クリティカル（データプレーンあり、ただし顧客管理） |
| 処理データ | (1) なし；(2) 暗号化ボリューム、顧客が鍵を保有 |
| 副処理者 | (1) セルフホスト型ではなし；(2) Hetzner 内部のみ、同社 DPA に記載 |
| 契約状況 | (1) ソフトウェアライセンス、DPA 不要；(2) Hetzner DPA + SCC 既存 |
| 鍵管理 | 顧客管理（LUKS2 認証情報はオペレーター設定ファイル、サーバー上にはなし） |
| 終了計画 | 「rclone 互換の任意のターゲットから rdc repo backup pull。ボリュームは LUKS2 暗号化済み、オペレーターが認証情報を保有。」 |
| 最終評価 | (2) 既存の IaaS レビューで対応済み |
1 エントリではなく 2 エントリになりました。クリティカルティアのエントリは IaaS プロバイダーのもので、買い手はすでに DPA と検証済みの終了計画を持っていました。IaaS は大半のチームが管理方法を知っている関係だからです。Rediacc のエントリは非クリティカルです。データ処理者ではなく、ソフトウェアライセンスだからです。
CISO がデータプレーンの SaaS 依存を減らしたいと考えるのは、調達コストがスプレッドシート上で似て見えても、登録簿エントリの形が異なるからです。これが構造的な理由です。
調達チェックリスト
2026年の営業サイクルで「NIS2 対応済み」を主張するベンダーへの 6 つの質問：
1. 保存データの暗号化鍵はどこにありますか? 「当社の HSM」または「IAM 経由で呼び出せる顧客の KMS」という答えなら、そのベンダーはあなたの鍵管理チェーンに入っています。「あなたのローカル設定ファイルにあり、当社のインフラには存在しない」であれば、そうではありません。
2. 法的条件を無視した場合、貴社の誰がデータを技術的に読み取れますか? 「誰が権限を持つか」ではなく「誰が望めば読み取れるか、監査ログがオフだったとして」です。その答えがゼロでなければ、それがインサイダーリスク評価の対象母数です。
3. リストアは実際の本番クローンでテストされていますか、それとも合成テストデータに対してですか? Article 21(2)(c) と (e) を合わせて読むと、バックアップが実際にリストアできることが求められます。合成データのみで検証するベンダーはリカバリーを検証しているのではなく、バックアップファイルの整合性を検証しているだけです。（詳しくは関連記事継続的な有効性評価を参照してください。）
4. 監査証跡は各アクションの実行者が人間かエージェントかを記録していますか? AI エージェントのアクティビティは監査ログカテゴリの中で最も急速に成長しています。人間とエージェントを区別しない 2026年の監査ログは、2027年にはギャップとして見られることになります。
5. メタデータを含め、データへの論理的アクセスを持つすべての副処理者を列挙してください。 「論理的アクセス」が適切なフレーズです。「メタデータを含む論理的アクセス」がより良いフレーズです。請求、オブザーバビリティ、カスタマーサポートの副処理者が通常持つのはメタデータのみのアクセスであり、ペイロードが暗号化されていても機密構造を漏洩するには十分だからです。
6. 2027年に EU 域外の買い手に買収された場合、終了計画はどうなりますか? GDPR の十分性フレームワーク、クラウド法、FISA 702 はいずれも動き続けています。今日のベンダーのデータ所在地の主張は、3年後の保証ではありません。買い手が問うべきは、ベンダーの所有権が変わった場合にデータパスはどうなるかです。
6 問すべてに明確に答えるベンダーはまれです。6 問中 4 問に答えつつ残りの 2 問を率直に認めるベンダーは、6 問すべてに自信を持って答えるベンダーより信頼できます。信頼性のシグナルは、解決されていないことを名指しできる意欲です。
次の更新サイクルへの示唆
今後 12 ヶ月以内にバックアップまたは DR の更新を控えており、Article 21(2)(d) が調達スコアカードに含まれているなら、3 つの具体的な行動があります。
- 現在のベンダーの 4 層データパスをホワイトボードに描いてください。3 番目の副処理者の名前を言えなければ、NIS2 以前から存在する登録簿の完全性問題があります。更新がそれを修正する適切な機会です。
- 上記 6 つの質問リストを現在のベンダーに対して実施してください。その回答を DPO と監査担当者に送り、ギャップが受容されているかどうかを確認してください。ギャップにレイヤー 3（鍵管理）またはレイヤー 4（列挙されていない副処理者）が含まれる場合、それが切り込みどころです。
- セルフホスト型コントロールプレーンを持つ代替サプライヤー登録簿がどのような形になるかを検討してください。ライセンスコストではなく、登録簿エントリを比較してください。ライセンスコストは 2 倍以内で似た水準ですが、登録簿エントリの形は異なります。（NIS2 スタックの構造的コストの関連記事で、何が縮小し何が残るかを詳しく説明しています。）
私たちがショートリストの候補であれば、提案は具体的です。ベンダー質問票をお送りください。実際にデプロイされたインスタンスに対して、ギャップも含めてあなたの質問への実際の回答を記入して返答します。書類を送る前にアーキテクチャを確認したい場合は、創業者との 30 分のアーキテクチャレビューを設定します。防御可能な登録簿エントリへの道は光沢のあるパンフレットではありません。答えそのもの、居心地の悪いものも含めた答えです。
Rediacc の機能と NIS2 各条項のパブリックマッピングについては、NIS2 および DORA を参照してください。より広いコンプライアンスフレームについては、コンプライアンス概要、データ主権、オンプレミス を参照してください。