PCI DSSとは|クレジットカード業界の情報セキュリティ基準

2026年6月3日

PCI DSS（Payment Card Industry Data Security Standard）はクレジットカードの会員情報を扱う全ての事業者が遵守すべき情報セキュリティ基準で、Visa、Mastercard、American Express、Discover、JCBの5ブランドが2004年12月に共同で策定したことに始まる。2006年にはPCI SSC（Payment Card Industry Security Standards Council）が設立され、現在の最新版は2024年4月に必須化されたPCI DSS v4.0、続いて2025年3月末から完全適用となるv4.0.1である。本稿では成立の経緯、要件構造、適合性評価レベル、関連規格との関係を体系的に整理する。

この記事の目次

PCI DSSの成立と運営体制
12要件と6目標の構造
監査レベルと評価手段
ISO 27001やGDPRとの位置づけ
まとめ

PCI DSSの成立と運営体制

2000年代前半、各カードブランドはVisa CISP、Mastercard SDPなど独自のセキュリティプログラムを持っており、加盟店は重複監査の負担に苦しんでいた。これを統合するために2004年12月15日に共通基準PCI DSS 1.0が公開され、2006年9月7日にPCI SSCが設立されて以降は同団体が基準の策定・改訂と評価機関の認定を担っている。

PCI SSCはVisa、Mastercard、Amex、Discover、JCBの5社が共同で運営する非営利組織で、加盟店規模に応じた監査要件はカードブランドが個別に定める一方、基準そのものは中立的に維持される構造になっている。日本ではJCBとPCI SSC公認の評価機関（QSA）が監査を担当し、近年は経済産業省の「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」がPCI DSS準拠をカード情報保持事業者の必須要件に位置づけている。

12要件と6目標の構造

PCI DSSは6つの目標と12の要件、その下に300以上の具体的なテスト手順を持つ階層構造である。6目標は「安全なネットワークの構築」「カード会員データの保護」「脆弱性管理プログラム」「強固なアクセス制御」「定期的な監視とテスト」「情報セキュリティポリシー」で、12要件はファイアウォール、デフォルト無効化、保存データ暗号化、伝送暗号化、マルウェア対策、セキュアな開発、アクセス権限、認証、物理アクセス、ログ監視、定期テスト、ポリシーへと展開される。

v4.0では「カスタマイズドアプローチ（Customized Approach）」が導入され、リスクベースで代替実装を選択できるようになった。また、要件6.4.3ではWebサイトに読み込まれるすべてのスクリプトを正当性検証する仕組みが追加され、フロントエンドへのスキミング攻撃（Magecart等）への対応が強化された。これらの新規要件は2025年3月31日まで「ベストプラクティス」だったが、それ以降は完全な必須項目として評価される。

監査レベルと評価手段

加盟店はカードブランドが定める年間トランザクション数によりLevel 1〜4に分類される。VisaとMastercardの場合、Level 1（年間600万件超）はQSAによる現地監査と年次RoC（Report on Compliance）提出が必須、Level 2〜4はトランザクション数や事故履歴に応じてSAQ（Self-Assessment Questionnaire）による自己評価が認められる。サービスプロバイダはLevel 1（年間30万件超）とLevel 2に区分され、Level 1ではQSAによる現地監査が義務化される。

SAQはカード情報の取扱形態に応じてA、A-EP、B、B-IP、C、C-VT、D、Pなど複数の様式が用意され、たとえば完全外部委託型はSAQ A、独自決済ページを持つeコマースはSAQ A-EPなどに分かれる。脆弱性スキャンは四半期ごとにASV（Approved Scanning Vendor）が実施し、年次でペネトレーションテストを実施する。ASVリストはPCI SSCの公式サイトに公開されており、依頼先選定の根拠資料となる。

ISO 27001やGDPRとの位置づけ

PCI DSSはカード会員データという特定の資産に対する具体的・技術的要件を提示する規格で、ISO/IEC 27001がマネジメントシステムを問うのとは粒度が異なる。実務的にはISO 27001でガバナンスを整え、その下位プロセスとしてPCI DSSの統制を組み込むのが一般的である。PCI DSSの要件はOWASP Top 10やASVSを具体策として参照しており、開発・運用の現場ではアプリケーションセキュリティの実装基準としても活用される。

GDPRや日本の個人情報保護法はカード番号も個人データとみなすため、PCI DSS適合は法令対応の根拠資料として機能する。クラウド事業者向けにはPCI DSSのCloud Computing Guidelinesが整備され、責任共有モデルに基づき事業者・テナント双方の責務範囲が明確化されている。AWS、Azure、Google Cloudは主要リージョンでPCI DSS認証を取得しており、テナント側はカード情報を扱うコンポーネントに対して残りの統制を実装することになる。