BtoB受注サイトの情報漏えいはどこで起きる？自社構築・ASP別に見る対策と報告義務の基準

◆監修・編集責任者　小園 将隆　2026年9月19日

B2B EC-COLUMN

BtoB受注サイトの情報漏えいはどこで起きるのか

BtoB受注サイトの情報漏えいは、大きく分けると「サーバやアプリケーションの脆弱性を突かれる不正アクセス」と「管理画面の権限・パスワードの管理不備」の二か所から起きます。どちらが自社の責任範囲に入るかは、サイトを自社構築・ASP・パッケージのどの方式で動かしているかで変わります。まず契約書で方式を一つに確定し、自社が管理する範囲とベンダーが管理する範囲を線で分ける。取引先のチェックシートへの回答も社内への報告も、その線引きをそのまま事実として書けば足ります。加えて、漏えいが起きた場合は本人の数が1,000人を超える事態が報告義務の対象となり¹、速報は概ね3〜5日以内に求められます¹。この期限から逆算すると、平時に決めておくべきことも自然に決まります。

起点はサーバの脆弱性を突かれた不正アクセス

BtoBは取引先が限られるため、漏えいが起きても規模は小さいと考えられがちです。しかし実際の事案はそうなっていません。2016年に公表された卸売のBtoBサイトの事案では、サイトへの不正アクセスにより会員情報が最大13万1,464件流出した可能性があると報告されています³。このうちクレジットカード情報は7,386件に上るとされました³。

会員数が数百社であっても、担当者アカウントが社数の何倍にもなり、過去の退会分まで含めれば件数は積み上がります。「うちは取引先が少ないから」という感覚は、確認の出発点にはなりません。数えるべきは取引先の社数ではなく、受注サイトの中に今いくつのアカウントと受注データが残っているかです。

BtoBでは個人情報と取引条件が同じ画面に並ぶ

BtoB受注サイトの受注データには、取引先の担当者の氏名・メールアドレス・電話番号といった個人情報と、取引先ごとの掛け率や与信枠といった取引条件が同じ画面に載ります。個人情報保護法の報告義務がかかるのは前者ですが、後者が外に出れば商売の条件そのものが崩れます。

つまりBtoBの受注サイトでは、法律上の義務と商売上の損失が別々の基準で発生します。確認するときも「個人情報が何件あるか」と「誰がその画面を見られるか」を分けて見る必要があります。前者は報告義務の判断に、後者は取引先への回答に使います。

二つ目の入口は管理画面の権限とパスワード

脆弱性と並んで多いのが、管理画面のアカウント管理の緩みです。退職した社員のアカウントが残っている、複数人で一つのIDを共有している、取引先に渡した初期パスワードが変更されないまま使われている。いずれも特別な攻撃技術を必要とせず、入口として成立してしまいます。

そしてここは、構築方式が何であっても自社の責任範囲から外れません。サーバの保守をベンダーに任せていても、誰にどの権限を与えるかを決めているのは自社だからです。専任のセキュリティ担当がいない会社でも、この部分だけは自力で確認し、自力で直せます。

では、法律の側は漏えいが起きたときに何を求めているのか。ここを先に知っておくと、平時に何を準備すべきかが逆算できます。

漏えいが起きたとき、何をいつまでに報告するのか

本人の数が1,000人を超える事態は報告義務の対象

個人情報保護委員会は、1,000人を超える漏えい等が発生した事態を報告義務の対象として示しています¹。人数の要件のほかにも対象となる事態が定められているため、「1,000人以下なら何もしなくてよい」という読み方はできません。判断の順序としては、まず対象に当たるかを確かめ、当たらない場合でも取引先への説明責任は別に残る、と考えます。

BtoBだから1,000人には届かない、と即断しないほうが安全です。取引先1社あたりの登録担当者が複数いること、休眠・退会分のデータが残っていることを合わせると、社数の印象と実際の人数はかなり離れます。この人数を平時に把握しているかどうかが、有事の初動の速さを決めます。

速報は概ね3〜5日以内

報告の期限も示されています。速報については、速やかに、概ね3〜5日以内に個人情報保護委員会へ報告を行うこととされています¹。この時点で被害の全容が分かっている必要はなく、その時点で把握している範囲を報告する形になります。

現実的な問題は、この数日のあいだに「誰が判断し、誰が報告するか」が決まっていない会社が多いことです。兼任の担当者が一人で抱えたまま社内の承認を待ち、期限を過ぎてしまう。技術的な対策以前に、連絡経路の一本化が効きます。

期限から逆算すると、平時に決めることが決まる

概ね3〜5日以内に速報を出す¹という前提に立つと、平時に用意しておくものは絞られます。受注サイトに登録されている本人の数をすぐ数えられるか、ログが残っていて何が持ち出されたかを追えるか、取引先への連絡先一覧が最新か、そして第一報を上げる相手が社内で決まっているか。この四つです。

逆に言えば、これらが揃っていない状態では、どれだけ対策機能を入れても有事に期限を守れません。対策の導入とあわせて、運用の段取りを文書にしておく必要があります。

自社の受注サイトがどの方式で動いているかを確かめる

方式は契約書と請求の名目で分かる

ここまでの内容を自社に当てはめるには、最初に構築方式を一つに特定します。判断材料は契約書と毎月の請求の名目です。開発会社と請負契約を結び、サーバ費用を自社で払っていれば自社構築。月額の利用料としてサービス名で請求されていればASP。ソフトウェアのライセンスや保守費として請求されていればパッケージ、という見方が目安になります。

「ASPだと思っていたが、実際は自社サーバ上のパッケージだった」という取り違えは珍しくありません。取引先のチェックシートに誤った方式を書けば、回答全体の信頼が崩れます。担当者の記憶ではなく、書面で確認してください。

方式が決まれば自社が触れる範囲も決まる

方式が確定すると、自社が管理する範囲とベンダーが管理する範囲が自動的に決まります。サーバの更新を自社が行うのか、通信の暗号化がどの層で行われているのか、権限をどこまで細かく分けられるのか。これらは自社の努力の問題ではなく、方式と契約の問題です。

この線引きができていれば、取引先への回答は「自社では何をしており、ベンダー側では何が担保されている」という二段構えの事実として書けます。分からない項目を空欄で出すより、責任の所在を明示したほうが評価されます。

まずは、方式に関わらず自社だけで確認できる項目から手を付けるのが早道です。

BtoB受注サイトの漏えいは、脆弱性を突かれた不正アクセスと、管理画面の権限・パスワードの管理不備という二か所から起きます。どこまでが自社の責任かは構築方式で決まるため、契約書で方式を一つに確定することが出発点です。そのうえで、1,000人を超える漏えい等が報告義務の対象であること¹と、速報が概ね3〜5日以内に求められること¹から逆算し、平時の段取りを決めておきます。

構築方式ごとの責任範囲は、契約書の文面だけでは読み取れない部分が残ります。暗号化がどの層で行われているか、権限をどこまで細かく分けられるかは、その基盤や製品を提供している側でなければ事実として答えられないためです。

自社の受注サイトが現在どの構成で動き、どこまでが提供側で担保されているかを、取引先のチェックシートにそのまま書ける形で整理できます。無料相談で要件を整理する

専任担当がいなくても、今日のうちに確認できる項目

取引先のセキュリティチェックシートで問われやすく、かつベンダーに問い合わせずに自社だけで事実を確かめられる度合いを条件に並べています。

• 受注サイトの構築方式が自社構築・ASP・パッケージのどれに当たるか、契約書で確認する

• 管理画面にログインできるアカウントの一覧を出し、退職者・異動者のIDが残っていないか照合する

• 複数人で共有しているIDがないか、パスワードの桁数と変更の決まりが定められているかを確認する

• サーバ・ミドルウェア・アプリケーションの更新を誰が行う契約になっているかを確認する

• 受注サイトに登録されている担当者の人数を数え、報告義務の判断に使える状態にしておく

• 漏えいが疑われたときの第一報を誰に上げるか、社内の連絡先を一行で決めておく

これらは方式に関わらず共通ですが、ここから先は方式によって自社が答えられる範囲が変わります。次から、構築方式ごとに自社とベンダーの責任範囲を分けて見ていきます。

構築方式別に見る、自社とベンダーの責任範囲

構築方式	自社が管理する主な範囲	ベンダーが管理する主な範囲
自社構築	サーバ・ミドルウェア・アプリケーション・アカウント運用のすべて	保守契約で明示的に委託した範囲のみ
ASP	アカウントと権限、取引先へ渡すID、選べる設定項目	サーバ、通信の暗号化、アプリケーションの更新
パッケージ	アカウント運用と、稼働環境が自社側なら環境の保守	機能として備わる対策と、更新プログラムの提供

自社構築：入口から出口まで自社の責任範囲

更新を止めた瞬間に入口ができる

自社構築では、サーバのOSからミドルウェア、アプリケーションまで自社の責任範囲に入ります。開発を外部に委託していても、それは構築の委託であって、公開後の更新まで含まれているとは限りません。「開発会社に任せているので大丈夫」と考えていた期間が、そのまま更新の止まった期間になっている例があります。

不正アクセスの起点として脆弱性が使われる以上³、誰がいつ更新を適用するかを保守契約の文面で確認することが最優先です。契約に入っていなければ、追加で結ぶか、自社で担当を決めるかの二択になります。

取引先への回答は運用の担当者から書く

自社構築の場合、チェックシートの多くの項目に「自社で実施」と書くことになります。このとき、実施している内容だけでなく、誰が担当しているかまで書けると回答の質が上がります。担当者名の記載までは不要でも、部署や役割として定まっていることが伝わる形にします。

裏返せば、担当が決まっていない項目は正直に「未整備」と書き、いつまでに整えるかを添えるほうが安全です。実施していないことを実施していると書けば、事案が起きたときに責任の性質が変わります。

確認する箇所	自社で決めること
サーバ・OS・ミドルウェア	更新を誰がいつ適用するか、保守契約に含まれているか
アプリケーション	改修時の検査と、公開前の確認手順
アカウントと権限	発行と削除の手順、共有アカウントの扱い
通信の暗号化	証明書の有効期限を誰が管理しているか
ログ	何をどれだけの期間残すか

ASP：基盤はベンダー、権限と運用は自社

守られている範囲を、自社の実施項目と混ぜない

ASPでは、サーバの保守や通信の暗号化、アプリケーションの更新はベンダー側で行われます。自社が直接触れない代わりに、その内容を自社で説明できる状態にしておく必要があります。ベンダーが公開しているセキュリティ対策の資料や、提供される報告書が回答の根拠になります。

チェックシートでよくある取り違えが、ベンダーが実施している対策を自社の実施項目として書いてしまうことです。「サービス提供者が実施」と明記し、根拠資料を示す形にすれば、後から食い違いが出ません。

自社に残るのは権限とIDの運用

ASPを使っていても、誰にどの権限を与えるか、取引先の担当者にどうIDを渡すかは自社の判断です。ここが漏えいの二つ目の入口になる以上、ASPだから安心という結論にはなりません。

確認したいのは、権限をどこまで細かく分けられるか、パスワードの桁数や変更の決まりを自社で設定できるか、ログイン履歴を自社で確認できるかです。設定できる範囲はサービスによって異なるため、機能の有無そのものをベンダーに確かめます。

確認する箇所	自社が決めること	ベンダーに確かめること
サーバ・基盤の保守	ベンダーが担う	更新の頻度と、障害時の連絡経路
通信の暗号化	ベンダーが担う	どの区間が暗号化されているか
アカウントと権限	誰にどの権限を与えるか	権限をどこまで細かく分けられるか
取引先へ渡すID	初期パスワードの渡し方と変更の決まり	桁数や変更の設定をどこまで指定できるか
ログイン履歴	定期的に誰が確認するか	自社の画面から確認できるか

パッケージ：機能はベンダー、稼働環境は契約次第

備わっている対策を項目として数える

パッケージでは、セキュリティ対策の一部が製品の機能としてあらかじめ備わっています。たとえばBtoB EC向けのパッケージであるEC-Rider B2B Ⅱは、セキュリティ対策を5つの項目として整理し、機能紹介として公開しています²。こうした公開資料がある場合、取引先への回答でそのまま根拠として示せます。

自社で行うのは、備わっている機能のうちどれを有効にするかの判断と、その設定内容の記録です。機能があることと、有効になっていることは別です。導入時の設定のまま数年が経っている場合は、現在の設定値を一度書き出してください。

稼働環境がどちら側にあるかで責任が変わる

パッケージで注意が必要なのは、稼働する環境が自社のサーバなのか、ベンダーが用意した環境なのかで責任範囲が変わる点です。自社環境であれば、OSやミドルウェアの更新は自社構築と同じく自社の責任範囲に入ります。

この点は契約書に書かれているはずですが、読み落とされやすい箇所でもあります。方式としてはパッケージでも、実態は自社構築に近い責任分担になっている場合がある、と考えて確認してください。

確認する箇所	自社が決めること	ベンダー側に備わるもの
セキュリティ機能	どの機能を有効にし、どう設定するか	機能として備わる対策の項目
稼働環境	自社環境なら保守の担当を決める	ベンダー環境なら環境側の保守
改修・更新	更新をいつ適用するか	更新プログラムの提供
アカウントと権限	発行と削除の運用	権限を分ける仕組み

要点の整理

軸	基準
構築方式の確定	自社構築・ASP・パッケージのどれかを、担当者の記憶ではなく契約書で一つに特定する
責任の線引き	サーバ、アプリケーション、アカウント運用の三つを、自社とベンダーのどちらが持つかで分ける
報告義務の人数	本人の数が1,000人を超える漏えい等は報告義務の対象
速報の期限	速やかに、概ね3〜5日以内に個人情報保護委員会へ報告する
取引先への回答	自社の実施範囲とベンダーの実施範囲を分けて書き、根拠資料を添える
先に直す箇所	退職者アカウントの削除と、共有アカウントの廃止

確認の過程で不足が見つかったとき、自社の運用だけで埋められるのか、方式そのものを見直す必要があるのかは判断の分かれ目になります。ここを取り違えると、手を動かしても入口が残ります。 今の運用のどこまでが機能として備わっていて、どこからが自社で決める設定なのかを項目ごとに突き合わせ、先に直すべき箇所を絞り込めます。

よくある質問

取引先のチェックシートに「ASPを利用している」と書くだけで足りますか。

足りません。ASPではサーバや通信の暗号化がベンダー側で担保される一方、アカウントと権限の運用は自社に残ります。回答は「サービス提供者が実施している範囲」と「自社が実施している範囲」を分けて書き、それぞれの根拠を示す形にしてください。空欄にするより、責任の所在を明示したほうが評価されます。

漏えいかどうか確定していない段階でも報告は必要ですか。

速報については、速やかに、概ね3〜5日以内に個人情報保護委員会へ報告することとされています¹。この時点で全容が判明している必要はなく、把握している範囲での報告になります。確定を待って期限を過ぎるより、分かっている事実を先に上げる前提で社内の連絡経路を決めておいてください。

BtoBなので登録されているのは担当者名だけです。それでも1,000人を超えることはありますか。

あります。取引先1社あたりに複数の担当者アカウントがあること、休眠や退会分のデータが残っていることを合わせると、社数の印象と実際の人数は離れます。1,000人を超える漏えい等は報告義務の対象です¹。自社の受注サイトに登録されている人数を、平時に一度数えておいてください。

クレジットカード情報を自社で保持していなければ安心ですか。

カード情報を持たないことは漏えい時の影響を小さくしますが、入口がなくなるわけではありません。2016年の卸売BtoBサイトの事案では、会員情報が最大13万1,464件³、クレジットカード情報が7,386件³流出した可能性があると報告されています。会員情報だけでも報告義務の判断対象になり、取引条件が含まれれば商売上の損失も生じます。

専任のセキュリティ担当を置けません。どこから手を付ければよいですか。

構築方式の確定と、管理画面のアカウント整理からです。方式は契約書で確認でき、アカウント一覧の出力と退職者IDの削除はベンダーへの問い合わせなしに自社だけで進められます。この二つを終えてから、方式に応じてベンダーへ確認すべき項目を絞り込んでください。

1. 1　出典：個人情報保護委員会「漏えい等報告・本人への通知の義務化について」（2022年）　経路
2. 2　出典：株式会社フライトソリューションズ「5つの強力なセキュリティ対策（EC-Rider B2B Ⅱ 機能紹介）」（2026年）　経路
3. 3　出典：Security NEXT「オークファン子会社のB2B卸サイトに不正アクセス－会員情報最大13万件が流出した可能性」（2016年）　経路