実際の決済境界を描く
商品ページから確認画面までの購入者経路をマップ化してください。カード入力箇所、リダイレクト、フレーム、スクリプト、API、プラグイン、タグマネージャ、CDN、ならびにそれに影響を与え得る管理者アカウントをマークします。関連するログ、サポートツール、分析も含めてください。これはプロバイダや査定者向けの出発点となる記録であって、単独のコンプライアンス決定ではありません。
決済ページ要素を配信しているドメインを記録してください。PCI SSCはSAQ Aの適格性要件として、すべての決済ページ要素がPCI DSS準拠のサービスプロバイダからのみ提供され、かつ商人サイト（merchant site）由来の要素がないことを挙げています。SAQ A-EPでは各要素は商人またはそのようなプロバイダ由来であってよいが、他の出所から来てはいけません。その他すべての基準は引き続き適用されます。
リポジトリだけではタグマネージャの注入やプラットフォーム設定を見落とすことがあります。通常のチェックアウトブラウザセッションでスクリプト、フレーム、ドメイン、ヘッダを確認してください。
ログ、分析、サポートワークフローで決済フィールドをレビューしてください。実際のカードデータをテストチケットや共有証拠に使わないでください。
説明可能な決済モデルで露出を減らす
可能な場合は、カードデータをあなたのアプリケーションが受け取ったり保存したりするのではなく、PCI DSS準拠のプロバイダが収集する統合を選んでください。完全なプロバイダホスト型リダイレクトはカスタムフォームよりも単純なことが多いですが、埋め込みフィールドやiframeでもあなたのサイトが決済に影響を与え得ます。『ホスト型』というラベルに頼らず、実際の統合を文書化してください。
一次口座番号（PAN）、セキュリティコード、チェックアウトエラーのスクリーンショット、コピーした決済詳細などを、承認された設計が要求していない限り保持しないでください。暗号化はデータ保護に役立ちますが、PCI SSCは暗号化だけでは一般に環境をスコープ外にするものではないと注意しています。トークン、鍵、Webhook、返金、責任分担の取り扱いをプロバイダおよび適格なレビュー担当者と確認してください。
統合ガイド、責任分担情報、関連するコンプライアンス書類、変更通知プロセスをアーキテクチャ記録に保管してください。
マーケティング実験、リプレイトール、チャットウィジェット、不要なライブラリは、明確な所有者とアクセスレビューなしに追加しないでください。
スクリプト、タグ、ヘッダを制御する
サードパーティのブラウザコードは管理されない変更、任意コード実行、他者への情報開示をもたらす可能性があります。各スクリプトのドメイン、目的、所有者、承認、読み込み箇所を含むチェックアウト目録を維持してください。ソースツリーのファイルだけでなく、タグマネージャのルールやベンダーが読み込むコードも含めます。
PCI SSCは許可されたスクリプト、整合性、改ざん監視、およびセキュリティに影響を与えるHTTPヘッダに注目しています。ベースラインを承認し、変更を制限し、差分を検出して調査してください。Content Security Policy（CSP）はリソースの出所を制限できます。適用前にreport-onlyモードでテストすることを検討してください。CSPは多層防御の一部であり、安全なコーディングやレビューの代替ではありません。
Subresource Integrityは外部スクリプトの変更を拒否できますが、クロスオリジン構成と互換性が必要で、ベンダー更新で壊れる可能性があります。
公開権限を制限し、強力な認証を要求し、カスタムコード機能をレビューし、監査証跡を残してください。
アクセスを制限しチェックアウト変更を復旧可能にする
日常的なコンテンツ公開とチェックアウトコード、決済プロバイダ管理、ホスティング、DNS、タグ管理を分離してください。名前付きアカウント、最小権限、サポートされる場合は多要素認証を使用します。役割変更後にアクセスを見直し、元従業員、ベンダー、代理店のアクセスを削除してください。正確なPCI DSS適用範囲は環境によって異なりますが、共有や常設権限を減らすことはリスク低減につながります。
チェックアウトにはリリースプロセスを使ってください：名前付きオーナー、レビュー、可能な限りのテスト、ロールバック手順、リリース後のブラウザ確認。成功パスと失敗パス、リダイレクト、モバイル挙動をテストしてください。Status Is UPはリリース前の準備、パフォーマンス最適化、ロールバック計画を支援しますが、PCI DSSの適合性を決定するものではありません。
資格情報、バックアップコード、ロールバック手順は承認されたアクセス制御されたシステムに保管し、チケット、スクリーンショット、公開リポジトリには置かないでください。
リリース後にブラウザで表示されるスクリプト、ドメイン、ヘッダを承認済み目録と比較してください。
スタックを更新し結果を検証する
コマースプラットフォーム、プラグイン、テーマ、サーバーコンポーネント、ライブラリ、決済SDK、タグテンプレート、チェックアウトに影響を与えるサービスのインベントリを維持してください。重要なベンダー通知を購読してください。NISTはパッチ管理を、更新の特定、優先度付け、取得、インストール、検証として説明しています。変更を記録し、支払い経路をテストし、デプロイ済み内容を確認してください。
高リスクの問題には緊急対応経路を設け、定期変更にはメンテナンスウィンドウを設定してください。露出したチェックアウトコンポーネントを優先しますが、本番を無闇にパッチ適用して支払いを壊さないでください。テスト済みのロールバック手順とプロバイダのリリース指針を使用してください。所有者不明の古いコンポーネントは解決すべきリスクです。
アドバイザリ、リスク判断、テスト結果、デプロイ記録、最終検証を一緒に保持してください。
証拠を保ち、適格な支援を利用する
図、プロバイダの責任情報、SAQ適格性理由、スクリプトとヘッダの目録、アクセスレビュー、承認、テスト結果、変更、ベンダー連絡先を管理された場所に保管してください。アーキテクチャ、所有、スクリプト、プロバイダが変更されたときには更新してください。証拠は認可されたレビュー担当者を助けるものであり、カードデータ、秘密情報、顧客記録を露出してはいけません。
あなたのアクワイアラ（acquirer）や決済ブランドが適用される検証期待を設定します。PCI SSCはQualified Security Assessors（QSA）をPCI DSSアセスメントを行う資格ある独立組織として、Approved Scanning Vendors（ASV）を適用要件の下で外部スキャンを行う資格ベンダとして識別しています。カスタムチェックアウト、スコープ不明、侵害疑い、またはSAQ選択の際には適格な支援を検討してください。
チェックアウトモデル、技術オーナー、エスカレーション連絡先、最終レビュー日、証拠リンクを一緒に保管してください。