小売・EC × SCS評価制度 ― 個人情報とECサイトを抱える事業者の対応ポイント
SCS評価制度の全体像については SCS評価制度 対策ガイド もあわせてご覧ください。
小売・EC事業者は、SCS評価制度の文脈で見落とされがちです。「うちは部品を作っているわけではないので、サプライチェーンの話は関係ない」と考えている経営者は少なくありません。
しかし実際には、小売・ECはセキュリティ上のリスク量が大きい業種です。理由は3つあります。
- 大量の個人情報を保有している（会員情報、購入履歴、配送先）
- インターネットに公開されたサーバ（ECサイト）を自ら運用している
- 委託先が多い（決済代行、物流、コールセンター、モール、Web制作）
そしてこの3つは、いずれもSCS評価制度の要求事項に直結します。この記事では、小売・EC事業者が押さえるべき論点を整理します。
小売・ECにとってのSCS評価制度の意味
小売・EC事業者は、「求められる側」と「求める側」の両方になります。
- 求められる側：メーカー・卸から取引先として、あるいはモール運営者・決済事業者から出店・契約の条件として、セキュリティ水準の提示を求められる
- 求める側：自社が委託している物流、コールセンター、Web制作、システム保守の各社に対して、セキュリティ水準を確認する立場
後者は★の取引先管理の要求事項そのものです。★3では機密情報を共有する取引先との取り決めが、★4では重要な取引先の年1回以上の確認が求められます。委託先が多い小売・ECにとって、ここが最も工数のかかる領域になります。
目標★の選び方
| 事業形態 | 想定される目標 | 理由 |
|---|---|---|
| 自社ECを大規模運営（会員数万人以上） | ★4 | 公開サーバ＋大量の個人情報。セグメンテーションとログ要件が実質必要 |
| クレジットカード情報を自社で保持 | ★4＋PCI DSS | カード情報の保持は別枠の要求水準 |
| モール出店中心・自社EC小規模 | ★3 | 決済・基盤はモール側。自社は会員情報と業務端末の保護が中心 |
| 実店舗中心の小売 | ★3 | POS・店舗Wi-Fi・従業員端末の統制から |
| メーカー・卸への納入も行う小売 | ★3〜★4 | 取引先からの要求次第 |
カード情報を自社で保持しない設計（決済代行への非通過型）にしているかどうかが、実務負荷を大きく左右します。保持していないなら、その事実を明確に説明できるようにしておくことが最初の武器になります。
小売・EC特有の6つの論点
1. 公開Webサーバ（ECサイト）の分離
インターネットに公開しているサーバは、攻撃を受ける前提で設計する必要があります。★4では「社外公開サーバ・重要サーバの分離」を含むネットワークセグメンテーションが要求事項です。
自社サーバでECを運用している場合、社内の業務ネットワークと同じセグメントに置かれていないかを必ず確認してください。クラウド（AWS・Azure・GCP）やSaaS型ECに載せている場合は、その構成自体が分離の説明材料になります。
CMSやプラグインの脆弱性を突かれる事例が絶えないため、サポート切れのCMS・プラグインの排除（★4要件）と、脆弱性管理のプロセス化（★4要件）が現実的な優先課題です（脆弱性管理体制の作り方）。
2. 個人情報の量とリスク
小売・ECが漏えい事故を起こしたときの影響は、取引先だけでなく消費者に直接及びます。2026年に提出された個人情報保護法改正案では課徴金制度の導入が議論されており、経済的な影響も無視できません（個人情報保護法改正の影響）。
★の観点では、機密区分に応じた情報の管理ルール（★3）と、保管データの暗号化ルール（★4）が該当します。まず「どこに何件の個人情報があるか」を棚卸ししてください。ECの管理画面、CRM、メール配信ツール、Excelの顧客リスト、退職者のPC——分散していること自体がリスクです。
3. 店舗のPOS・店舗Wi-Fi
実店舗を持つ場合、POS端末と店舗Wi-Fiが論点になります。
- POS端末：資産台帳の対象。OSのサポート期限とパッチ適用状況を把握しているか
- 店舗Wi-Fi：来客用と業務用が分離されているか。同一ネットワークなら実質的に外部に開いた状態
- バックヤードPC：共有アカウントで運用されていないか
来客用Wi-Fiと業務系の分離は、★3の段階でも「ネットワーク境界の防御」の説明として問われやすい部分です（VLANとネットワークセグメンテーション）。
4. パート・アルバイトのアカウント運用
小売業は入退社の頻度が高く、アカウントの棚卸しが最も破綻しやすい業種です。★3の「退職者アカウントの速やかな削除・無効化」を成立させるには、人事プロセスとの連動が欠かせません。
- 退職連絡の経路を一本化する
- 月次でアカウント一覧と在籍者名簿を突合し、記録を残す
- 店舗共有アカウントは、利用範囲を限定したうえで管理方法を文書化する
この突合記録は、自己宣言の証跡としてそのまま使えます。
5. 委託先が多いことへの対応
決済代行、物流、コールセンター、Web制作・保守、広告代理店、モール運営者。それぞれに顧客情報や管理画面のアクセス権を渡しています。
まず委託先一覧を作り、重要度でランク分けしてください。判断基準は「個人情報を渡しているか」「システムの管理権限を渡しているか」の2つで十分です。上位に来た委託先から、NDA・セキュリティ要件・終了時のデータ返還/廃棄の取り決めを整備します（委託先管理の実装ガイド）。
Web制作会社に管理者アカウントを渡したまま契約が終わっている——といったケースは珍しくありません。契約終了時のアクセス権回収は★4の要求事項ですが、★3の段階でもリスクとして先に潰しておく価値があります。
6. 繁忙期とインシデント対応
セール期・年末年始・決算期にシステムが止まると、損失が直撃します。★3では事業継続上重要なシステムの目標復旧レベルを定め、必要な対策を整備することが要求事項です。
ECサイトが止まったときに「受注を止める判断を誰がするか」「顧客への告知を誰が出すか」を決めておくだけでも、要求事項への適合と実務の両方が前進します。インシデント時の対応手順はインシデント発生時のSCS評価への影響も参考にしてください。
進め方（★3・6か月モデル）
| 時期 | やること |
|---|---|
| 1か月目 | セルフチェックと評価範囲（本部・店舗・EC基盤）の決定 |
| 2〜3か月目 | 個人情報の所在棚卸し、アカウント棚卸しと人事連動、MFAの全社適用 |
| 3〜4か月目 | 店舗ネットワークの分離確認、POS・端末の台帳化とパッチ運用、ECサイトの脆弱性対応 |
| 4〜5か月目 | 委託先一覧の作成と重要度ランク付け、契約条項とデータ返還ルールの整備 |
| 5〜6か月目 | 規程・手順書の文書化、教育・訓練の実施と記録、バックアップと復旧手順の整備 |
情シス365による支援
情シス365では、本部・店舗・EC基盤にまたがるIT環境の整理からSCS対応まで支援しています。
- 個人情報の所在可視化： どこに何が保管されているかを棚卸しし、集約と保護のルールを設計
- 店舗ネットワークの整理： 来客用Wi-Fiと業務系の分離、POS・端末の統合管理
- アカウント運用： 入退社の多い現場に耐える棚卸しの仕組み化
- 委託先管理： 一覧化・ランク付け・契約条項・年次確認の運用設計
まとめ
- 小売・ECは大量の個人情報・公開Webサーバ・多数の委託先を抱える、リスク量の大きい業種
- 制度上は**「求められる側」と「求める側」の両方**。委託先管理の工数が最大の負荷になる
- 目標は★3が基本。大規模EC・カード情報保持なら★4（＋PCI DSS）を検討する
- 特有の論点は、公開サーバの分離／個人情報の所在／店舗POS・Wi-Fi／パート従業員のアカウント／委託先／繁忙期の停止対応
- 個人情報の所在棚卸しとアカウントの人事連動が、最も早く効く2つの一手
参考リンク：