pci-audit

PCI 監査 — Payment Card Industry Data Security Standard

PCI DSS v4.0.1 は、決済カードデータを保存、処理、または送信するあらゆる環境に適用されるセキュリティ標準です。上位要件は 12 項目、下位要件は数百項目あります。ほとんどの組織が合否を分けるのは、たった 1 つの判断、すなわちスコープです。

バージョンに関する注意：v4.0.1（2024 年 6 月）が唯一の有効なバージョンです。v4.0 は 2024 年 12 月 31 日に廃止され、v4.0 で「将来適用」とされていた要件は 2025 年 3 月 31 日に必須となりました。すべての要件を対象に評価してください。ベストプラクティスにすぎないものとして扱わないでください。

このスキルでは、まずスコープの決定を重視し、その後、エンジニアリングに関係する要件を取り上げます。最終的なコンプライアンス証明（SAQ による自己評価、または Attestation of Compliance を作成する QSA 監査）は、このスキルが準備を支援するプロセスであり、このスキル自体が証明を行うものではありません。

相互参照：Req 3／4 の暗号化に関する詳細は crypto-audit、Req 7〜8 は iam-audit、Req 10 のログ記録は siem-detection、Req 6（セキュアな SDLC）は dependency-audit および owasp-audit、Req 12.10（インシデント対応）は incident-triage を参照してください。

認可

ユーザーの組織が所有する環境、またはレビューを委託された環境のみを監査してください。実際のカードデータ（PAN、CVV、トラックデータ）は読み取ったり、記録したり、トランスクリプトに貼り付けたりしないでください。テスト用カード番号を使い、カード会員データがどのように流れる可能性があるかを追跡してください。本来あるべきでない場所に実際の PAN が見つかった場合は、番号ではなく場所を記録し、インシデントの可能性として扱ってください（incident-triage）。これは準備状況のレビューであり、QSA による評価ではありません。

スコープに関する問い（最初に実施）

PCI DSS における「スコープ」とは、カード会員データ（CHD）を保存、処理、または送信するシステムに加えて、そうしたシステムのセキュリティに影響を及ぼし得るシステム（接続システムおよびセキュリティに影響するシステム）を指します。スコープ内のすべての対象に、12 の要件すべてが適用されます。スコープ外の対象には適用されません。

PCI の不適合のほとんどは、スコープの判断ミスが原因です。 誤ってスコープに含められたシステムは、何年にもわたるコンプライアンス上の負債を生みます。適切なアーキテクチャによってスコープ外に維持されたシステムは、大幅なコスト削減につながります。

スコープを決定する

環境内のすべてのシステムについて、次の表に従って分類してください。

種類	定義	スコープ内か
CDE（カード会員データ環境）	PAN、有効期限、サービスコード、PAN と組み合わせた氏名、または機密認証データを保存、処理、または送信する	はい — PCI DSS 全要件
接続システム	補完的なセグメンテーションがない状態で、CDE に直接接続できる	はい
セキュリティに影響するシステム	CDE にセキュリティサービス（認証、ログ記録、監視、時刻同期、DNS）を提供する	はい
セグメント化済み	直接接続がなく、セグメンテーションが毎年検証されている	いいえ
カード会員データがマスク済み／トークン化済みの状態でのみ流れる	帯域外アクセスなしでは元に戻せないトークンまたはマスク済み PAN をシステムが扱う	通常はいいえですが、トークンの種類を確認してください。加盟店が元に戻せる代替トークンは、引き続きスコープ内です

監査手順： すべての決済フローを端から端まで追跡してください。PAN が環境に入る場所、流れていく先、止まる場所を確認してください。PAN が触れるすべてのシステムはスコープ内です。また、セグメンテーションなしでそのシステムに接続するすべてのシステムもスコープ内です。

スコープを縮小する（効果の高いエンジニアリング作業）

PCI 対応で最も投資対効果が高いのは、通常、スコープの縮小です。

• ホスト型の決済ページを使用する — Stripe / Adyen / Braintree / Worldpay に入力フォームをホストしてもらいます。PAN はサーバーに届きません。ブラウザーは決済処理業者と直接通信します。対象範囲は「iframe の統合」まで縮小されます。
• トークン化を使用する — 決済処理業者が PAN を、システムで代わりに保存するトークンに変換します。処理業者側のアクセスがなければ、トークンには意味がありません。システムで扱うのは PAN ではなくトークンです。
• P2PE（ポイント・ツー・ポイント暗号化）を使用する — 端末を利用する決済では、スワイプ時に暗号化し、平文がネットワークを通過しないようにします。
• ネットワークをセグメント化する — CDE を保持する場合は、CDE とその他の領域をファイアウォール / VLAN / 名前空間で確実に分離します。CDE の境界ではデフォルト拒否を適用します。

年間 100 万件の取引を Stripe Checkout 経由で処理し、サーバーに PAN を一切保持しない加盟店は、同じ PAN を独自のフォームで受け取り、Stripe にプロキシする加盟店と比べて、対象範囲が大幅に小さくなります。同じ加盟店でも、監査の内容は大きく異なります。

加盟店レベルと評価の種類（コンプライアンス体制であり、エンジニアリングではありません）

監査の頻度と厳格さを決めるため、簡単に説明します。

レベル	取引量（Visa）	検証要件
1	年間 600 万件超、または取引量を問わず侵害を受けた加盟店	年次のオンサイト QSA 評価 → AoC
2	年間 100 万～600 万件	年次 SAQ（自己評価）または QSA 評価（Visa は 2024 年から QSA を必須としています）
3	年間 2 万～100 万件の e コマース取引	年次 SAQ
4	その他すべて	年次 SAQ

SAQ の種類（自己評価質問票）は、加盟店の CDE の形態に対応します。SAQ A（完全に外部委託された e コマース）、SAQ A-EP（一部でリダイレクトを行う e コマース）、SAQ B（端末のみ。電子的な保存を行わないダイヤル回線 / IP）、SAQ C-VT（ウェブベースの仮想端末）、SAQ D（その他すべて。最も項目が多い）があります。適切な SAQ は、その要件がすべて自社の環境に当てはまるものです。

エンジニアリングに関連する要件（このスキルが監査する範囲）

要件 3 — 保存されたカード会員データの保護

**原則として、PAN は保存しないでください。**保存が必要な場合は、保存時に暗号化し、保持するデータを最小限にしてください。

• 保存時の PAN は読み取れない状態にする必要があります。強力な暗号方式（AES-256）、要件 3.6 に沿った鍵管理（crypto-audit を参照）、鍵のローテーション、鍵の保管に関する職務分掌を適用します。
• 機密認証データ（CVV / CVV2、磁気ストライプ全体、PIN / PIN ブロック）は、認証後は暗号化の有無にかかわらず、絶対に保存してはなりません。
• PAN はデフォルトでマスキングして表示します。通常は先頭 6 桁と末尾 4 桁を表示します。
• バックアップ、ログ、デバッグ出力など、その他の形式でも PAN を読み取れない状態にします。

監査時の grep パターン：

• データベーススキーマ：pan、card_number、cc_number、cardnum、account_number という名前のカラム
• カードデータを書き込むコードパス：pan、cardNumber、正規表現 ^4[0-9]{12,15}$（Visa）、^5[1-5][0-9]{14}$（Mastercard）、^3[47][0-9]{13}$（Amex）、^6(?:011|5[0-9]{2})[0-9]{12}$（Discover）
• ログ：console\.log.*cardNumber、logger\..*\.pan、log\..*card
• エラー報告：Sentry / Datadog / Bugsnag のスクラブ規則でカード番号のパターン（Luhn アルゴリズムで有効な 13～19 桁の数字列）が確実に削除されることを確認します。
• バックアップ：バックアップの保持対象に、暗号化されていない CHD が含まれないことを確認します。

Luhn アルゴリズムで有効な PAN が、ソースコード、ロックファイル、ログのいずれかに存在する場合、公開済みのテストカード番号（4242 4242 4242 4242、4111 1111 1111 1111、および決済処理業者が公開しているその他のテスト PAN）を除き、意図にかかわらず指摘事項となります。

要件 4 — オープンネットワーク経由の伝送を保護する

• TLS 1.2 以上を使用し、最新の暗号スイートのみを使用します（設定の詳細は crypto-audit を参照）。
• エンドユーザー向けメッセージング技術（メール、SMS、チャット）を介して PAN を送信してはなりません。また、そのような送信を行うフローは拒否します。
• PAN を送信する内部専用ネットワークでも暗号化が必要です（多層防御です。要件 4.2.1 が強力な暗号方式を義務付けているのは、オープンなパブリックネットワークを介する場合のみです）。

Req 6 — セキュアなシステムとソフトウェアを開発・維持する

ここでは、セキュリティ監査の各分野が PCI と交わります。この要件の大部分は、既存のスキルを実行することで満たせます。

• 6.2 セキュアなカスタムソフトウェアの開発 — owasp-audit、api-audit を参照
• 6.3 脆弱性の特定と対処 — vuln-research、dependency-audit、finding-triage を参照
• 6.4 外部公開 Web アプリケーションの攻撃からの保護 — WAF、または年次コードレビュー＋リリース後の手動レビュー
• 6.5 すべてのシステムコンポーネントへの変更をセキュアに管理 — 変更管理、開発環境と本番環境の職務分離、下位環境で使用する前に本番前データをサニタイズ

監査用 grep パターン：

• 実際の PAN を含む下位環境の設定（よくある不備：カードデータを含む本番データベースのダンプからステージング環境を作成）
• セキュアな SDLC を迂回するコードパス（本番環境への直接的なホットフィックスのパターン、本番環境に影響するブランチへのコミットでの --no-verify）

Req 7 — 業務上知る必要のある範囲にカード会員データへのアクセスを制限する

• ロールベースのアクセス — 職務上 CHD が必要な担当者のみアクセスできます
• デフォルト拒否 — アクセスは明示的に付与し、継承させません
• 特権ユーザー ID を文書化し、レビューします

ID とアクセス管理の詳細については、iam-audit を参照してください。

Req 8 — ユーザーを識別し、アクセスを認証する

• すべてのユーザーに一意の ID（共有アカウントは不可）を付与します。サービスアカウントも対象です
• 強力な認証 — 現行の PCI の複雑さ要件を満たすパスワード、コンソール以外からの管理アクセス、すべてのリモートネットワークアクセス、および（Req 8.4.2、2025 年 3 月 31 日から必須）CDE へのすべてのアクセスに対する MFA
• 最も機密性の高いアクセス経路では、MFA にフィッシング耐性が必要です（v4.0.1 では推奨事項であり、必須ではありません）
• 現行の PCI パラメーターに従ったアカウントロックアウト、セッションタイムアウト、パスワードローテーション（v4.0 では一部の従来要件が緩和されています。現行の文面を確認してください）

実装パターンと ID プロバイダーとの統合については、iam-audit を参照してください。

Req 10 — ネットワークリソースおよびカード会員データへのすべてのアクセスを記録し、監視する

• CHD へのすべてのアクセスを記録 — 誰が、いつ、何を、どこから行ったか
• ログを一元管理し、時刻を同期（Req 10.6 — NTP）し、少なくとも 12 か月間保持（3 か月分は即座に利用可能な状態）
• ログを毎日レビュー — 手動または自動で実施します。異常があれば調査を開始します
• ログの完全性を保護 — 分離されたシステム、書き込み専用、イミュータブルストレージ

エンジニアリングの実装については siem-detection を、レビューの頻度については soc-operations を参照してください。

Req 11 — システムとネットワークのセキュリティを定期的にテストする

• 脆弱性スキャン — 内部および外部のスキャンを四半期ごとに実施します。外部スキャンは ASV（Approved Scanning Vendor）が実施する必要があります
• ペネトレーションテスト — 少なくとも年次、および重大な変更の後に実施します。内部と外部の両方が対象です。ネットワーク層とアプリケーション層をテストします。適格な社内担当者または第三者が実施します
• セグメンテーションテスト（スコープ縮小のためにセグメンテーションに依存する環境の場合）— セグメンテーションを検証するためのペネトレーションテストを年次で実施します
• 重要なファイルや設定に対するファイル完全性監視

dependency-audit（脆弱性スキャン）、web-pentest（年次のアプリケーションペネトレーションテスト）、red-team-engagement（より高い成熟度を目指す年次の攻撃的セキュリティ評価）を参照してください。

Req 12 — 情報セキュリティポリシーを維持する

プログラムレベルの層です。エンジニアリングからのインプット：

• 12.10 インシデント対応計画 — incident-triage を参照。少なくとも年次でテストします
• 12.5 サードパーティ／サービスプロバイダーの管理 — DPA に類する証明、プロバイダーのコンプライアンスの年次レビュー（処理事業者から AoC が送付されるため、保管する必要があります）
• 12.6 CHD を扱う担当者向けのセキュリティ意識向上トレーニング

一般的な監査所見（実際の環境で最初に確認する仮説）

• ログ内の PAN — カードデータを含むエラー／デバッグ／アクセスログが Sentry／Datadog／Bugsnag に収集され、承認された期間を超えて保持されている
• 機密性の高い認証データの永続化 — 「再請求を簡便にするため」に CVV が保存されている（禁止されています）、または完全なトラックデータが誤って記録されている
• 本番環境のデータを使った下位環境の構築 — サニタイズされていない本番データのダンプから実際の PAN が取り込まれ、ステージングデータベースに含まれている
• トークン化の範囲に関する誤解 — プロセッサーアカウントで元に戻せる代替トークンが自社の DB に保存されている場合も対象範囲内です。範囲を縮小できるのは一方向トークンだけです
• iframe とプロキシの違い — 「ホスト型決済ページ」が、転送前にサーバーが一時的に PAN を扱うプロキシとして実装されている（対象範囲内）か、サーバーが PAN を一切受け取らない真の iframe として実装されている（対象範囲外）か
• アーキテクチャではなくファイアウォールルールによるセグメンテーション — 特定のトラフィックのみを「許可」するファイアウォールルールがあっても、システムが同じ VLAN を共有している場合があります。有効なセグメンテーションにはアーキテクチャ上の分離が必要です
• MFA の不備 — v4.0 では MFA 要件が拡大されました（2025 年 3 月 31 日から必須）。v3.2.1 に準拠していた古い環境には、不備がある可能性があります

検証してから記録する

references/findings-format.md で定義されている判定を 1 つ付けて候補をすべてクローズし、確定する前に references/verification.md の反証チェックを実施してください。

PCI DSS 要件との不一致は所見です。 要件は、意図された統制です。監査への影響ではなく、カード会員データに対して生じるリスクに基づいて重大度を評価してください。references/severity-calibration.md を参照してください。到達可能なテーブルに CVV が書き込まれている場合は High または Critical です。一方、四半期ごとの ASV スキャンレポートがないこと自体は、リスクではありません。リスクを伴わない不備（ポリシー文書の欠落、期限切れの研修記録、未実施の年次レビュー）は文書上の不備です。重大度を付けず、レポート内の専用セクションに記載し、findings.json には記録しないでください。別のレイヤーによってすでにリスクが抑止されている多層防御上の不備は、強化に関する注記です。

各判定の例を以下に示します。

• confirmed：コードまたはエクスポートされた設定から、カード会員データが要件で禁止されている場所に到達していること、または CDE への経路で必須の制御が欠けていることが確認できる場合です。
  • フォームから cardNumber をサーバーに送信するチェックアウトハンドラー内の logger.info("charge", req.body)：PAN がアプリケーションログに平文で記録されています（Req 3.5.1）。フォームフィールドからロガー呼び出しまでのトレースを示します。
  • CDE 管理コンソールの IdP ポリシーのエクスポートで、パスワードのみのサインインが許可されています（Req 8.4.2）。場所は証拠ファイルと行番号です（下記参照）。
  • LOG_REQUEST_BODIES=true が上書きされない限り有効になる、といった安全でない出荷時のデフォルトは、system_configuration 条件（「LOG_REQUEST_BODIES=false を設定していないデプロイメント」）と信頼度 medium を付けて confirmed とします。確認できないデプロイメントの事実によって信頼度は下がりますが、判定や重大度は変わりません。
• needs_validation：コードは主張を裏付けていますが、ある事実はコードの外部にあります。その事実を明記し、確認担当者に確認方法を示します。
  • Sentry は決済ルートからリクエストボディを受信しますが、データのスクラビング設定はリポジトリではなく Sentry プロジェクトにあります。未確認事項：プロジェクトのサーバー側スクラビングルールがクレジットカード番号を対象としているかどうか。確認方法：Sentry で Project Settings > Security & Privacy を開き、データスクラバーが有効で、$creditcard を対象とする高度なルールがあることを確認します。設定のエクスポートを証拠フォルダーに保存します。
  • ステージング環境は、サニタイザーを呼び出す scripts/seed-from-prod.sh によってシードされます。未確認事項：実際に実行するパイプラインが --sanitize を渡しているかどうか。確認方法：ステージングの payments テーブルにある Luhn チェックに合格する 13～19 桁の値を（出力せずに）数えます。
• rejected：特定の場所にある制御によって、すべての経路で該当しないことが確認できる場合です。
  • 「チェックアウトが PAN を処理する」：カードフィールドは Stripe Elements の iframe であり、サーバーハンドラーが読み取るのは paymentMethodId のみです。ruled_out_by.location はリクエストボディを読み取るハンドラーの行を指し、control は iframe 統合を示します。
  • test/fixtures/cards.json 内の Luhn チェックに合格する 16 桁の数値は、Stripe が公開しているテスト用 PAN です。ruled_out_by はフィクスチャの行を指し、公開済みテストカードであることを示します。
  • 代替制御でカバーされるギャップを rejected とするのは、代替制御のワークシートが存在し、制御が実行されていることを証拠で確認できる場合に限ります。ruled_out_by.location はワークシートを指します。有効性を示す証拠がないワークシートの場合は needs_validation です。
  • 依存関係内の制御（独自のログで PAN をマスクする決済 SDK など）によって候補を却下できます。ruled_out_by.location はバージョンを固定するロックファイルまたはマニフェストの行を指し、control はライブラリ関数とバージョンを示します。
  • 「到達不能」であることを根拠とする却下では、ruled_out_by.location にその証拠を指定します。唯一のインポート箇所または呼び出し箇所、あるいは何も使用していない場合は依存関係の宣言を指します。

デプロイ済みリソースの証拠。 PCI に関する指摘事項の多くは、ファイルではないもの（IdP と MFA のポリシー、ファイアウォールルールとセキュリティグループ、ログの保持設定、プロセッサーの AoC、文書化されたポリシーなど）に関するものです。読み取り専用コマンドの出力またはエクスポートを、機密情報を伏せたうえで <audit dir>/evidence/<name>.json または .txt（例：audit/pci/evidence/okta-cde-policies.json、audit/pci/evidence/sg-cde-ingress.txt）に保存し、location と evidence[] で該当ファイルと関連する行を指定します。プロセスやポリシーに関する証拠（インシデント対応計画、代替制御のワークシート、アクセスレビュー記録）も同じフォルダーに保存します。PAN、CVV、トラックデータ、PIN ブロック、認証情報の値は、証拠、findings.json、レポートに決して保存しないでください。値がある場所と、最大でも下 4 桁のみを記録します。ライブチェックは、許可を得ている場合に限り、読み取り専用で行います。説明されているものの実行されていないチェックは needs_validation です。 フィンガープリントは pci-audit/<class>/<file or resource>/<symbol or name> の形式で、スラッシュで区切り、行番号は含めません。バリデーターは :<digits> のセグメントを拒否するため、ARN と host:port はスラッシュを使って記述してください。pan-at-rest、sad-stored、pan-in-logs、pan-unmasked、pan-in-lower-env、weak-transmission、pan-in-messaging、shared-account、mfa-gap、access-not-restricted、audit-log-gap、segmentation-gap、scope-misclassified など、短いクラス名を使います。

pci-audit/pan-in-logs/src/routes/checkout.ts/createCharge
pci-audit/sad-stored/db/schema.sql/payments.cvv
pci-audit/mfa-gap/okta/acme/cde-admin-console
pci-audit/segmentation-gap/aws/123456789012/us-east-1/sg-0abc/ingress-0.0.0.0-0

デプロイ済みリソースの場合、フィンガープリントは証拠ファイル名ではなく、リソース（プロバイダー、アカウントまたはテナント、名前）を基に作成します。そうすることで、証拠を再取得しても同じ値を維持できます。

ext フィールド（任意のレコードに追加できる任意のオブジェクト。cwe や location など、すでにフィールドがある内容は重複させないでください）：

キー	値	例
requirement	ギャップが該当する PCI DSS v4.0.1 の要件	"8.4.2"、"3.3.1"
scope	影響を受けるシステムのスコープカテゴリ	"cde"、"connected-to"、"security-impacting"
data_element	該当する場合、公開されたカード会員データ要素	"PAN"、"SAD-CVV"、"SAD-track"、"PIN-block"

次に、以下を行います。

1. findings.json を fingerprint でソートし、skill: "pci-audit" を設定して作成します。検証し、すべてのエラーを修正します：node references/validate-findings.mjs findings.json（references/validate-findings.mjs）。
2. 必要に応じて、SARIF をエクスポートします：node references/to-sarif.mjs findings.json -o findings.sarif（references/to-sarif.mjs）。
3. ドキュメントの不足や強化に関するメモは、JSON の横に短いリストとしてまとめます（例：notes.md）。これらはレコードではありません。

処置区分（通常は後から finding-triage が設定します）：Fixed / Deferred / Accepted Risk / Mitigated (platform/config) / Requires major migration。PCI でリスクを受容することは強く推奨されません。「受容したリスク」の多くは、効果を示す文書化された証拠を伴う補完的統制であるべきです。誤検知は処置区分ではなく、rejected レコードにします。

出力形式

まず findings.json を作成します。レポートはそれを基に生成します。説明文によって、JSON に記載されていない判定、重大度、またはブロッカーが変わることはありません。

# PCI DSS v4.0.1 Readiness Review
## Merchant: [name]   ## Merchant level: [1/2/3/4]   ## SAQ type: [A / A-EP / B / C-VT / D / n/a, Level 1 QSA]
## Date: [date]   ## Reviewer: [name]   ## Scope: [full | partial, what was left out]
## findings.json: [path], validated: [yes]   ## Evidence folder: [path]

### Summary
- Confirmed: [N] (Critical [n] | High [n] | Medium [n] | Low [n])   Needs validation: [N]   Rejected: [N]
- Documentation gaps: [N]   Hardening notes: [N]

### Confirmed findings
#### [SEVERITY] [Title]  `fingerprint`
**Requirement:** [ext.requirement]   **Scope:** [ext.scope]   **Data element:** [ext.data_element]
**Location:** `path:line` (source or evidence file)   **Confidence:** [medium | high (reproduced)]
**What and why it matters:** [the trace or the config evidence, in a few lines; the exposure to CHD]
**Fix:** [concrete change]
**Verify the fix:** [the check that proves it]

### Needs validation
| Finding | Requirement | Blocker | Check for the owner to run |
|---|---|---|---|

### Hardening notes (not findings)
- [gap] — [why it isn't a finding] — [effort]

### Documentation gaps (not findings)
| Requirement | What's missing | Owner | Evidence expected |
|---|---|---|---|

### Rejected (do not re-raise)
| Fingerprint | Ruled out by | Location |
|---|---|---|

### Scope determination
- [ ] Payment data flow diagrammed end-to-end
- [ ] CDE explicitly bounded
- [ ] Connected-to systems enumerated
- [ ] Segmentation evidence documented
- [ ] Scope-reduction opportunities identified

| System | Scope category | Why | Evidence |
|---|---|---|---|

### Per-requirement status
| Req | Confirmed | Needs validation | Documentation gaps |
|-----|-----------|------------------|--------------------|
| 3 — Stored CHD | | | |
| 4 — Transmission | | | |
| 6 — Secure SDLC | | | |
| 7 — Access restriction | | | |
| 8 — Authentication | | | |
| 10 — Logging | | | |
| 11 — Testing | | | |
| 12 — Program | | | |

### Recommended scope reductions (if applicable)
[Hosted payment page, tokenization, network segmentation improvements with effort estimates]

### Compensating controls (if used)
[Each compensating control: control description, what it compensates for, evidence of effectiveness, review cadence, worksheet path]

### Prioritized remediation plan
1. [highest first: SAD storage, PAN in clear, missing CDE MFA]

要件ごとの表は、findings.json のレコード（ext.requirement 別）と、ドキュメント不足リストの項目を集計します。これは独立した判定ではありません。

範囲

• このスキルはエンジニアリング側の監査と準備を担います。最終的なコンプライアンス証明（自己評価を行う加盟店が署名する SAQ、または上位階層の加盟店向けに QSA が作成する AoC）は別のプロセスです。
• QSA 主導のレベル 1 評価では、このスキルは QSA に入力情報を提供します。QSA による独立した評価に代わるものではありません。
• PCI DSS に違反するフローの構築を支援することは拒否してください。CVV の保存、PAN のメール送信、トークン化を回避した生のカード情報の取得が該当します。
• 監査で進行中の侵害（PAN がすでに公開されている、侵害が疑われるなど）が判明した場合は、incident-triage に切り替えてください。PCI の侵害対応には、固有の期限と通知要件があります（アクワイアラーへの通知は通常 24 時間以内です）。
• ブランド固有の規則（Visa、Mastercard、Amex、Discover、JCB）は PCI DSS に追加で適用されます。ブランド固有の義務（Visa の Cardholder Information Security Program など）がある加盟店は、各カードブランドのプログラム文書を確認してください。

参考資料

• PCI DSS v4.0.1 — pcisecuritystandards.org/document_library
• PCI DSS v4.x クイックリファレンスガイド — 実務担当者向けの概要
• SAQ の手順とガイドライン — 自己評価を行う加盟店向け
• PCI SSC FAQ データベース — 公式の解釈ガイダンス
• QIR / QSA / PFI / ASV 登録簿 — 承認済みの評価者／ベンダーの選定用
• Visa Cardholder Information Security Program (CISP) — Visa 固有の多層要件
• Mastercard Site Data Protection (SDP) Program — Mastercard の要件
• Open Web Application Security Project (OWASP) — 要件 6 の主要な内容
• NIST SP 800-53 — 多くの PCI 要件に明確に対応する管理策カタログ
• 「PCI Compliance」 — Branden Williams、Anton Chuvakin 著。v4.0 まで更新された実務担当者向け書籍
• 共通の参考資料（ビルド時に references/ にコピーされます）：references/findings-format.md、references/verification.md、references/severity-calibration.md、references/findings.schema.json