クレジットカード情報を扱う事業者に求められるセキュリティ基準「PCI DSS」が、2022年にバージョン3.2.1から4.0へと大きく改定されました。取引先や決済代行会社から「v4.0への対応が必要」と告げられ、まず何が変わって・いつまでに・自社は何をすべきかを整理したい担当者は少なくありません。
結論から言えば、v4.0では多要素認証（MFA）の適用範囲の拡大や、決済ページのスクリプト管理といった新要件が加わり、その多くが2025年3月31日をもって必須化されています。さらに2024年に公開されたv4.0.1が現在の唯一の有効版で、いま対応するなら合わせる先はv4.0.1です。本記事執筆時点（2026年8月）では、新要件は「これから」ではなくすでに必須です。
この記事では、v3.2.1からv4.0で変わった点を要件番号つきの一覧表で示し、対応期限のタイムラインとv4.0・v4.0.1の関係を整理します。そのうえで、EC事業者にとって影響の大きい決済ページの新要件（6.4.3・11.6.1）を掘り下げ、自社が取るべき最初の一歩まで解説します。
目次
一括ダウンロードする
PCI DSS v4.0のおもな変更点・新要件（要件番号つき一覧表）
まず、v3.2.1からv4.0で加わった主な新要件を、要件番号・変更内容・具体的に何をするかの3列で示します。v4.0では新要件が64件加わりましたが、下表はそのうち多くの事業者に影響が大きい主要なものを抜粋したもので、全件はPCI SSCの公式文書「Summary of Changes（v3.2.1からv4.0）」で確認できます。
既存要件のなかにも強化されたものがあり、パスワードの12文字化（8.3.6）はその代表例です。
| 要件番号 | 8.4.2 | 8.3.6 | 6.4.3 | 11.6.1 | 6.4.2 | 5.4.1 | 3.5.1.2 | 12.3.1 |
|---|---|---|---|---|---|---|---|---|
| 変更内容 | カード会員データ環境（CDE）へのすべてのアクセスに多要素認証（MFA）を導入 | パスワードを最低12文字に（システムが12文字非対応なら最低8文字） | 消費者のブラウザで読み込み・実行されるすべての決済ページスクリプトを管理 | 決済ページの改ざん検知メカニズムを導入 | 公開Webアプリに、攻撃を継続的に検知・防御する自動技術的ソリューション（WAF等）を導入 | 従業員をフィッシング攻撃から検知・防御する仕組みを導入 | ディスク／パーティション暗号化でPANを読取不能にしてよいのはリムーバブル媒体のみ | 実施頻度に柔軟性がある要件についてターゲットリスク分析を実施・文書化 |
| 具体的に何をするか | 従来は管理者アクセス中心だったMFAを、CDEに入る全アクセスへ拡大して適用する | パスワードポリシーを見直し、最低文字数を引き上げる | 決済ページで動くスクリプトを棚卸し・承認し、完全性を確認する仕組みを持つ | 決済ページのHTTPヘッダ・内容の不正な改変を検知しアラートする仕組みを入れる | 手動レビューの選択肢に代えて、WAFなどの自動的な仕組みを常時稼働させる | フィッシング対策の技術的・運用的なメカニズムを整備する | サーバ内蔵ディスク等ではディスク暗号化だけに頼らず、別の方式（3.5.1）でも保護する | 対象要件ごとに、実施頻度の根拠となるリスク分析を文書として残す |
出典・参考資料（1件）
- 出典：Summary of Changes from PCI DSS v3.2.1 to v4.0（Revision 1）｜PCI Security Standards Council（PDF）
個別要件のほかに変わった「2つのアプローチ」
v4.0では個別の新要件に加えて、要件を満たすための考え方そのものが2つに整理されました。従来どおり要件で定められた方法をそのまま実装する定義済みアプローチ（defined approach）と、要件のセキュリティ目標を自社独自の方法で達成するカスタマイズアプローチ（customized approach）です。
カスタマイズアプローチは、環境やリスクに応じて達成手段を柔軟に選べる一方、採用する各要件についてターゲットリスク分析（要件12.3.2）が求められ、これはv4.0の審査を受ける事業者に即時適用されます。
この12.3.2は、変更点表に挙げた12.3.1（実施頻度に柔軟性がある要件向けのターゲットリスク分析）とは別の要件です。自社の実装が要件の文言どおりでない場合に、目標を満たしていることをどう示すかの選択肢が増えた、と捉えると分かりやすいでしょう。
PCI DSS v4.0の対応期限・移行スケジュール
ここからは、v4.0への移行スケジュールと、v4.0とv4.0.1の関係を整理します。
移行タイムライン（v4.0公開から新要件の必須化まで）
- 2022年3月31日：PCI DSS v4.0公開
- 2024年3月31日：v3.2.1が退役。以降はv4.0（v4.0.1）での審査・準拠が必要に
- 2024年6月11日：v4.0.1公開（限定改訂）
- 2024年12月31日：v4.0が退役し、以降はv4.0.1が唯一の有効版に
- 2025年3月31日：将来日付要件（新要件64件のうち51件）が必須化
新要件の多くは、移行期間中は「ベストプラクティス（推奨）」として扱われ、2025年3月31日をもって必須になりました。本記事執筆時点（2026年8月）では、これらの新要件はすでに必須であり、対応は先送りできない段階にあります。
出典・参考資料（2件）
PCI DSS v4.0とv4.0.1の違い（合わせる先はどちらか）
検索されるキーワードは「v4.0」ですが、いま対応するなら合わせる先はv4.0.1です。v4.0.1は2024年6月11日に公開された限定改訂版で、PCI SSCの公式説明によれば、書式・誤字の修正と一部要件・ガイダンスの趣旨の明確化を行ったもので、新要件の追加や削除はありません。
v4.0は2024年12月31日に退役し、以降はv4.0.1が唯一の有効版です。したがって、v4.0とv4.0.1で対応すべき要件の中身は同じで、新要件の必須化日（2025年3月31日）も変わりません。具体的な明確化の例としては、決済ページのスクリプト管理（6.4.3）の適用範囲や、CDEへのMFA（8.4.2）に関する適用注記が加えられています。実務では、最新のv4.0.1を参照すれば足ります。
出典・参考資料（1件）
- 出典：Just Published: PCI DSS v4.0.1｜PCI Security Standards Council Blog（ブログ）
将来日付要件は「もう必須化済み」
v4.0で加わった64の新要件のうち51件が「将来日付要件（future-dated requirements）」とされ、2025年3月31日まではベストプラクティス期間、同日をもって必須化されました。
前掲の変更点一覧表に挙げた新要件（8.4.2・8.3.6・6.4.3・11.6.1・6.4.2・5.4.1・3.5.1.2・12.3.1）はいずれもこの将来日付要件にあたり、2026年8月時点ではすべて必須化済みです。残る13件は、v4.0への移行時点で即時発効していました。
一括ダウンロードする
そもそもPCI DSSとは／自社は準拠対象か
ここで、変更点を掴んだうえで自社が準拠対象かどうかを確認します。PCI DSS（Payment Card Industry Data Security Standard）は、クレジットカード情報を安全に扱うための国際的なセキュリティ基準で、PCI SSC（PCI Security Standards Council）が策定しています。
カード会員データを保存・処理・伝送する事業者や、それらに影響を与えうる事業者が対象です。
PCI DSSの12要件（概観）
PCI DSSは、大きく12の要件で構成されます。v4.0でもこの12区分の枠組みは維持され、各要件の中で前掲の新要件が追加・強化されました。本記事で扱う新要件は、主に要件3（保存データの保護）・6（安全な開発）・8（認証）・11（テスト）・12（方針）に含まれます。
- ネットワークセキュリティコントロールの導入・維持
- すべてのシステムへのセキュアな設定の適用
- 保存されるカード会員データの保護
- 公衆ネットワーク送信時のカード会員データの暗号化
- マルウェアからのシステム・ネットワークの保護
- 安全なシステム・ソフトウェアの開発と維持
- カード会員データへのアクセスを業務上必要な範囲に制限
- 利用者の識別とアクセスの認証
- カード会員データへの物理的アクセスの制限
- システム・データへのアクセスのログ記録と監視
- システム・ネットワークの定期的なテスト
- 情報セキュリティを支える方針とプログラムの整備
準拠対象と加盟店レベル
準拠の求められ方は、事業者の年間カード取引件数などに応じた「加盟店レベル」で変わります。ここで注意したいのは、加盟店レベルはPCI DSS（PCI SSC）が定めるものではなく、Visaやマスターカードなど各カードブランドが個別に定める運用ルールだという点です。ブランドによって区分が異なり、近年は区分の見直しも行われています。
目安として、一般には年間カード取引件数が多い順にレベル1〜4といった区分が知られています。おおまかな傾向として、取引件数の多い大手ほど上位レベルとなり、認定審査員（QSA）によるオンサイト監査など厳格な評価が求められ、件数が少ない事業者は自己問診（SAQ）を中心とした評価になりやすい、と捉えておくと自社の位置の見当がつきます。
ただし正確な自社レベルと必要な評価方法は、取引のある決済代行会社・アクワイアラや各カードブランドに確認するのが確実です。
準拠状況の評価方法（SAQ・ASVスキャン・QSA監査）
準拠状況の確認方法には、主に次の3つがあります。自己問診（SAQ：Self-Assessment Questionnaire）は事業者が自ら準拠状況を確認する方式、ASVスキャンは承認スキャンベンダ（ASV）による脆弱性スキャン、QSA監査は認定審査員によるオンサイト評価です。どのレベルでどの方式が求められるかは、前述のとおりカードブランドの運用ルールに従います。
PCI DSSの12要件やSAQのタイプ、非保持化による準拠範囲の考え方を、v4.0の変更点とは別に基礎からまとめて押さえておきたい場合は、以下の記事で1本に整理しています。
実務で押さえたい主要な新要件
ここからは、変更点一覧表の新要件のうち、システム面の対応が必要になりやすいものを、実際に何をするかまで掘り下げます。フィッシング対策（5.4.1）のように運用・教育が中心の要件は表の記載に留め、ここでは技術対応の見積もりに関わる要件を取り上げます。EC事業者に特に影響の大きい決済ページの要件（6.4.3・11.6.1）は次の章で単独で扱います。
CDEへのMFA拡大（8.4.2）とパスワード強化（8.3.6）
要件8.4.2では、多要素認証（MFA）の対象がカード会員データ環境（CDE）へのすべてのアクセスに拡大されました。従来は管理者アクセスなどが中心でしたが、v4.0ではCDEに入る全アクセスにMFAを適用します。
あわせて要件8.3.6で、パスワードの最低文字数が7文字から12文字に引き上げられました（システムが12文字に対応しない場合は最低8文字）。まずは認証基盤とパスワードポリシーの現状を棚卸しし、CDE境界に入る経路をすべて洗い出すところから着手するのが現実的です。
公開Webアプリへの自動技術的ソリューション（6.4.2）
要件6.4.2では、一般公開しているWebアプリケーションに対し、Webベースの攻撃を継続的に検知・防御する自動技術的ソリューションの導入が求められます。従来の要件6.4.1にあった「手動または自動の脆弱性評価によるレビュー」という選択肢は廃止され、常時稼働する自動的な仕組みが必要になりました。
WAF（Web Application Firewall）はその代表例ですが、要件の文言はWAFに限定していないため、継続的に攻撃を検知・防御できる自動的な仕組みであればよい、と理解します。
保存データの暗号化（3.5.1.2）
要件3.5.1.2では、ディスクレベル／パーティションレベルの暗号化でPAN（カード番号）を読取不能にしてよいのはリムーバブル電子媒体の場合に限ると定められました。
サーバ内蔵ディスクのような非リムーバブル媒体では、ディスク暗号化だけでは不十分で、要件3.5.1を満たす別の仕組みでもPANを保護する必要があります。保存データの暗号化方式が、ディスク暗号化に依存していないかを確認することが対応の起点です。
ターゲットリスク分析の文書化（12.3.1）
要件12.3.1では、実施頻度に柔軟性がある各PCI DSS要件について、頻度の根拠となるターゲットリスク分析を実施し、文書として残すことが求められます。「なぜその頻度で実施するのか」をリスクの観点から説明できる文書を、対象の要件ごとに用意する運用が必要になります。
【EC事業者向け】決済ページのスクリプト管理（6.4.3・11.6.1）
ECサイトを運営する事業者にとって、v4.0で特に影響が大きいのが決済ページに関する2つの新要件です。近年、決済ページに読み込まれるスクリプトを改ざんしてカード情報を盗む攻撃（Webスキミング）が増えたことを背景に、6.4.3と11.6.1がセットで決済ページの保護を求めています。
要件6.4.3は、消費者のブラウザで読み込み・実行されるすべての決済ページスクリプトの管理を求めます。要件11.6.1は、決済ページ（消費者が受け取るHTTPヘッダと内容）の不正な改ざんを検知してアラートする改ざん検知メカニズムの導入を求めます。PCI SSCの公式文書では、それぞれ次のように定義されています。
6.4.3 New requirement for management of all payment page scripts that are loaded and executed in the consumer’s browser.
11.6.1 New requirement to deploy a change-and-tamper-detection mechanism to alert for unauthorized modifications to the HTTP headers and contents of payment pages as received by the consumer browser.
出典：Summary of Changes from PCI DSS v3.2.1 to v4.0（Revision 1）｜PCI Security Standards Council
具体的には、決済ページで動くスクリプトを棚卸しして許可したものだけに絞り、その完全性を確認する仕組み（6.4.3）と、ページが改ざんされたら気づける仕組み（11.6.1）を用意することが求められます。
代表的な手段としては、読み込むスクリプトを制限するCSP（Content Security Policy）、外部スクリプトの完全性を検証するSRI（Subresource Integrity）、決済ページの変化を監視して改ざんを検知するツールなどが挙げられます。どの手段の組み合わせで要件を満たせるかは自社の実装によって変わるため、要件の趣旨に照らして選ぶことになります。
自社でECサイトを構築している場合は影響範囲が広くなりやすい一方、決済ページ自体を決済代行会社の環境に預けている場合は、この負担の多くを事業者側で抱えずに済むケースがあります。どこまでが自社の対応範囲かは、利用中の決済サービスに確認するのが確実です。
決済ページの接続方式（リンク型・API型など）によって、6.4.3・11.6.1で自社が実際にすべき対応は変わります。自社の実装がどの方式にあたり、方式ごとに何をすればよいかを具体的に確認したい場合は、以下の記事で接続方式別に整理しています。
PCI DSS v4.0対応の最初の一歩｜ギャップ洗い出しと準拠範囲の絞り込み
最後に、自社が取るべき最初の一歩を整理します。すべての要件に一度に取り組むのではなく、現状との差分を洗い出し、優先度をつけて進めるのが現実的です。
自社システムとの差分（ギャップ）の洗い出しと優先度づけ
まず、前掲の変更点一覧表を自社のチェックリストとして使い、各新要件を「すでに満たしている／対応が必要／自社の対象外」に仕分けていくと、現状との差分が見えてきます。
対応が必要な項目は、認証基盤（8.4.2・8.3.6）、公開Webアプリ（6.4.2）、決済ページ（6.4.3・11.6.1）のように領域ごとにまとめると、担当と作業量を見積もりやすくなります。判断がつかない要件は、決済代行会社やQSA（認定審査員）・PCI DSS対応支援サービスに相談するのが近道です。
カード情報を自社で保持しない＝準拠範囲を狭める
対応の負担を根本から下げる考え方が、カード情報を自社で保持・処理しない構成にすることです。決済ページやカード情報の取り扱いをPCI DSS準拠済みの決済代行会社に委ねれば、自社のカード会員データ環境（CDE）が縮小し、対応すべき要件の範囲そのものを狭められます。
ただし、範囲を狭めても自社の対応がゼロになるわけではありません。たとえばv4.xでは、最も簡易な自己問診であるSAQ Aで対応するEC加盟店にも、承認スキャンベンダ（ASV）による四半期ごとの脆弱性スキャン（要件11.3.2）が新たに求められるようになりました。どこまでを決済代行に委ね、どこからが自社の対応かを、利用するサービスの準拠範囲とあわせて確認しておくことが大切です。
出典・参考資料（1件）
- 参考資料：Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x（SAQ AとASVスキャン要件11.3.2）｜PCI Security Standards Council Blog（ブログ）
カード情報を自社で保持しない「非保持化」を具体的にどう実現するのか、EC事業者に求められる理由と対応方法は、以下の記事で詳しく解説しています。
PCI DSS準拠の負担を抑えるオンライン決済・決済代行サービス
ここからは、自社の準拠範囲を狭める選択肢になるサービスを紹介します。方向性は2つあり、1つはカード情報の取り扱いをPCI DSS準拠済みの決済代行に委ねてカード決済を導入する方法（サブスクペイ・Paysys）、もう1つはそもそもカード情報を扱わない後払い（掛け払い）で決済する方法（RP掛け払い）です。
前者は自社でカード会員データを保持しない構成を取りやすく、後者はカードを扱わないためPCI DSSの対象外になります。まずは各サービスの特徴を比較したうえで、資料で詳細を確認してみてください。
| サービス名 | サブスクペイ | Paysys（ペイシス） | RP掛け払い |
|---|---|---|---|
| 提供会社 | 株式会社ROBOT PAYMENT | 株式会社ペイメントフォー | 株式会社ROBOT PAYMENT |
| 決済の仕組み・主な決済手段 | クレジットカード・口座振替・ コンビニ・銀行振込 など （継続課金に対応） | クレジットカード5ブランド・ PayPay・コンビニ・ペイジー・ バーチャル口座 など | BtoB掛け払い（請求書ベースの後払い） 与信・請求・回収・債権保証を代行 |
| カード情報の自社保持 | 不要 （取り扱いを同社に委ねられる） | 不要 （決済ページ・処理を預けられる） | 該当なし （カード情報を扱わない後払い） |
| PCI DSS準拠 | PCI DSS 4.0準拠 ISMS認証も取得 | PCI DSS（SAQ Type-D）準拠 | － （カード情報を扱わない 回収方法のため） |
| EMV 3-Dセキュア（本人認証） | ●標準対応（追加料金0円） | ●標準対応（追加料金0円） | － （カード決済ではないため非該当） |
| 料金の目安 | クレジットカード決済手数料 2.5%〜 初期・月額費用は要問い合わせ | BtoB限定プラン 〜1.99%・初期費用0円 （BtoCは個別見積り） | 要問い合わせ （請求書郵送費用は0円） |
| 詳細情報 | 公式資料を見る | 公式資料を見る | オンライン相談を予約 |
1. サブスクペイ（株式会社ROBOT PAYMENT）
サブスクリプションや継続課金ビジネスに強いのが、株式会社ROBOT PAYMENTのサブスクペイです。クレジットカード決済を軸に、口座振替・コンビニ決済・銀行振込など複数の決済手段を一元管理でき、決済に連動した顧客管理・請求・入金管理まで扱えます。カード情報の取り扱いを同社側に委ねられるため、自社でカード会員データを保持しない構成を取りやすいのが特徴です。
セキュリティ面では、クレジットカード業界のセキュリティ基準であるPCI DSS 4.0に準拠し、ISMS（情報セキュリティマネジメントシステム）認証（JIS Q 27001:2023）も取得しています。継続課金の自動リトライやカード有効期限切れ前の更新URL自動送付など、定期課金の失効を抑える機能も備えます。クレジットカード決済手数料は2.5%〜、料金の詳細は個別見積りです（2026年8月時点）。
2. Paysys（ペイシス）（株式会社ペイメントフォー）
システム開発をせずに導入できる点を強みにするのが、株式会社ペイメントフォーのPaysys（ペイシス）です。管理画面から請求用のURLやQRコードを発行し、メール・SMS・SNSなどで案内するだけでクレジットカード決済を完結でき、メールリンク型・フォーム型・API連携型の3方式から選べます。決済ページや決済処理をサービス側に預けられるため、カード情報を自社で保持しない導入がしやすい構成です。
セキュリティ基準であるPCI DSS（SAQ Type-D）に準拠し、本人認証のEMV 3-Dセキュアを追加費用なしで標準対応しています。Visa・Mastercard・JCB・American Express・Dinersの5ブランドに対応し、BtoB向けには手数料〜1.99%・初期費用0円のプランも用意されています（2026年8月時点、料金は個別見積り）。
3. RP掛け払い（株式会社ROBOT PAYMENT）
企業間（BtoB）取引の後払いに特化するのが、株式会社ROBOT PAYMENTのRP掛け払いです。与信審査・請求書の発行と送付・代金回収・入金消込・督促までの請求／債権管理業務を代行し、与信を通過した適格債権には貸し倒れが起きても100%の債権保証が付きます。
掛け払いは請求書ベースの後払いで、クレジットカード情報を扱わない回収方法です。そのため、BtoB取引の決済をカード以外で回す選択肢として、カード情報の取り扱いに伴う負担を避けたい場面で候補になります。請求書郵送費用は0円で、手数料率や初期・月額費用は取引条件により変わるため個別見積りです（2026年8月時点）。
ここで紹介した3サービスのほかにも、カード情報を自社で持たずに導入できるオンライン決済システムは数多くあります。実店舗・EC・サブスクといった導入形態別に主要サービスの機能や選び方を広く比較したい場合は、以下の記事が参考になります。
まとめ
PCI DSS v4.0では、CDEへのMFA拡大（8.4.2）やパスワードの12文字化（8.3.6）、決済ページのスクリプト管理（6.4.3）と改ざん検知（11.6.1）など多くの新要件が加わり、その多くが2025年3月31日をもって必須化されました。いま対応するなら、現行の唯一の有効版であるv4.0.1に合わせれば足ります。
まずは変更点一覧表を使って自社の差分を洗い出し、領域ごとに優先度をつけて進めましょう。カード情報を自社で保持しない構成にすれば、対応すべき準拠範囲そのものを狭められます。自社に合った決済環境を選ぶために、まずは各サービスの資料を取り寄せて比較してみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. PCI DSS v4.0とは何ですか？
A. PCI DSS v4.0は、クレジットカード情報を安全に扱うための国際セキュリティ基準「PCI DSS」の、2022年3月31日に公開された新バージョンです。策定元であるPCI SSC（PCI Security Standards Council）が従来のv3.2.1を大きく改定したもので、多要素認証（MFA）の適用範囲の拡大や決済ページのスクリプト管理といった新要件が加わりました。
現在の唯一の有効版は、2024年6月11日に公開されたv4.0.1です。
Q. PCI DSS v4.0ではv3.2.1から何が変わりましたか？
A. PCI DSS v4.0では、CDE（カード会員データ環境）への全アクセスへのMFA適用（8.4.2）、パスワードの最低12文字化（8.3.6）、決済ページのスクリプト管理（6.4.3）と改ざん検知メカニズム（11.6.1）などの新要件が加わりました。あわせて、要件のセキュリティ目標を独自の方法で達成する「カスタマイズアプローチ」を選べるようになった点も大きな変更です。
全体では64件の新要件が加わりましたが、12要件という枠組み自体は維持されています。
Q. PCI DSS v4.0の新要件はいつから必須になりますか？
A. PCI DSS v4.0の新要件の多くは、2025年3月31日をもってすでに必須化されています。64件の新要件のうち51件が「将来日付要件（future-dated requirements）」とされ、2025年3月31日まではベストプラクティス（推奨）期間、同日以降は必須です。
残る13件はv4.0への移行時点で即時発効していました。本記事執筆時点（2026年8月）ではこれらはすべて必須化済みで、対応は先送りできない段階にあります。
Q. PCI DSS v4.0とv4.0.1はどちらに対応すればよいですか？
A. いま対応するなら、現行の唯一の有効版であるv4.0.1に合わせれば足ります。v4.0.1は2024年6月11日に公開された限定改訂版で、書式・誤字の修正と一部要件・ガイダンスの趣旨の明確化を行ったもので、新要件の追加や削除はありません。v4.0は2024年12月31日に退役しているため、対応すべき要件の中身も、新要件の必須化日（2025年3月31日）も、v4.0と変わりません。
Q. 自社はPCI DSS v4.0の準拠対象ですか？
A. カード会員データを保存・処理・伝送する事業者や、それらに影響を与えうる事業者は、PCI DSS v4.0の準拠対象です。ECサイト運営者や実店舗の加盟店、決済代行を利用する事業者も含まれます。
ただし求められる評価方法（SAQ・ASVスキャン・QSA監査）は、年間カード取引件数などに応じた「加盟店レベル」で変わり、このレベルはPCI DSSではなくVisaやマスターカードなど各カードブランドが個別に定めます。正確な自社レベルと必要な評価方法は、取引のある決済代行会社・アクワイアラや各カードブランドに確認するのが確実です。
Q. 決済代行を使えばPCI DSS v4.0への対応は不要になりますか？
A. 決済代行を使っても対応がゼロになるわけではありませんが、自社の準拠範囲を狭めて負担を大きく下げられます。カード情報の取り扱いや決済ページをPCI DSS準拠済みの決済代行会社に委ねれば、自社のCDE（カード会員データ環境）が縮小し、対応すべき要件の範囲そのものを絞れます。
ただし、最も簡易な自己問診であるSAQ Aで対応するEC加盟店にも、v4.xでは承認スキャンベンダ（ASV）による四半期ごとの脆弱性スキャン（11.3.2）が新たに求められるなど、自社に残る対応はあります。どこまでを委ねられるかは、利用するサービスの準拠範囲とあわせて確認しておくことが大切です。
Q. ECサイトでPCI DSS v4.0対応として特に注意すべき要件は何ですか？
A. ECサイトでは、決済ページのスクリプト管理（6.4.3）と改ざん検知メカニズム（11.6.1）の2つの新要件に特に注意が必要です。決済ページに読み込まれるスクリプトを改ざんしてカード情報を盗むWebスキミング攻撃を背景に、消費者のブラウザで動くすべての決済ページスクリプトの管理（6.4.3）と、決済ページの不正な改変を検知してアラートする仕組み（11.6.1）がセットで求められます。
自社でECサイトを構築している場合は影響範囲が広くなりやすく、決済ページ自体を決済代行の環境に預けている場合はこの負担の多くを抑えられることがあります。
Q. PCI DSS v4.0対応で判断に迷ったらどこに相談すればよいですか？
A. PCI DSS v4.0対応で判断がつかない要件は、取引のある決済代行会社やQSA（認定審査員）・PCI DSS対応支援サービスに相談するのが近道です。まずは変更点の一覧を自社のチェックリストとして使い、各新要件について「すでに満たしている／対応が必要／自社の対象外」を仕分けたうえで、判断が難しい部分を専門家に相談すると進めやすくなります。
あわせて、カード情報を自社で保持しない構成にできないかを、利用中の決済サービスの準拠範囲と照らして検討するのも有効です。
オンライン決済・決済代行サービスの料金・機能を一括チェック
MCB FinTechカタログでは、PCI DSS準拠のオンライン決済・決済代行サービスの最新資料を一括でダウンロードいただけます。各サービスの料金・決済手段・セキュリティ対応の詳細を並べて比較し、自社の準拠範囲を狭める候補の絞り込みにお役立てください。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
