ソフトウェアベンダーとして必要なコンプライアンスのレベルは？
私のビジネスがPCIに準拠するために必要なレベルを評価するのに少し苦労しています。
私のビジネスは、クライアントがホストするeコマースWebサイトを開発しています。ウェブサイトのチェックアウトにはiFrameがあり、支払い情報を受け取って処理する支払いゲートウェイアプリケーションにリンクしています。この支払いゲートウェイアプリケーションも私のビジネスによって開発され、私のビジネスがアクセスできないPCI準拠サーバーでそれをホストしているクライアントに引き渡されます。
私のビジネスはソフトウェア開発サービスのみを提供しているため、PCIに準拠する必要はないという印象を常に受けていました。しかし、私のクライアントは私がSAQ Dに該当すると信じています。
私はSAQ Dを通過しましたが、私のビジネスはどのアプリケーションのホスティングも担当していないため、アンケートに記入するのに苦労しています。
私のビジネスにはPCIコンプライアンスが必要ですか？はいの場合、正しいアンケートは何ですか？
どんな助けでもありがたいです！
ボブソンとして 引用 だが、明らかに強調されていないが、読まなかった：
PA-DSSは、承認の一部としてカード会員データおよび/または機密認証データを保存、処理、または送信する支払いアプリケーションを開発するソフトウェアベンダーや他の人向けですまたはこれらのアプリケーションが第三者に販売、配布、またはライセンス供与されている場合ほとんどのカードブランドは、PCI SSCによってテストおよび承認された支払いアプリケーションの使用を販売者に奨励しています
PA-DSSはPayment ApplicationData Security Standardで、 PCISSC Webサイト -で利用できる完全に別のドキュメントです。フィルターボックスでPA-DSSを選択します。 （昔のWeb1.0の日にはハイパーリンクを付けることができましたが、勇敢な新しい世界では、ユーザーを「収益化」していないほんの一部のWebサイトであっても、すべてに対して手動の操作が必要です。）
PA-DSSのほぼすべての実質的な要件は、通常のDSSの要件に基づいており、マーチャントおよびサービスプロバイダーに適用されますカード所有者のデータとトランザクションを実際に処理する（そして現在は発行者）が、ソフトウェア開発プロセスを反映するように調整されています。たとえば、DSSでは、商人などがビジネスニーズに基づいてさまざまなユーザーのアクセス権限を設定する必要があります（マスクされていないPANの表示など）、PA-DSSはアプリケーションベンダーにサポートそのような特権と、ソフトウェアをインストールした後に販売者がそれらを割り当てる方法に関するガイダンスを提供します。ここでDSSは、販売者/ SPがログを監視して問題に対応することを要求します、PA -DSSでは、アプリケーションが監視する適切なログを提供する必要があります。など。ネットワークの実際の運用（四半期ごとの外部スキャンを含む）と物理環境に関する要件はまったく適用されません。PA-DSSに固有の唯一の実質的な要件は、実装ガイドと、販売者など、または該当する場合は販売代理店/インテグレーター（該当しない場合のように聞こえる）が、システムの使用を確認および文書化する際に使用できる関連ドキュメントを作成して提供する必要があります。 ソフトウェアは全体としてDSSを満たしています。
悪いニュースは、PA-DSSアプリケーションベンダー向けの自己評価トラックがないことです。 PA-QSAまたはPayment Application Assessorと呼ばれるPA-DSS専用のQSAによる監査が必要です。これは、[Assessors＆Solutions]タブの下の個別の項目であり、 this list につながることに注意してください。 。
考えられる代替策は、販売者の指示の下で十分に契約している場合、彼らはあなたを社内で、つまり自社の開発チームの一部として、彼らのために「単独で」開発しているものとして扱うことができるということです。しかし、その場合それらは、オンデマンドですべてのyour設計ドキュメント、コーディング標準、コードの変更を示すログを確認できる必要があります。 2人目、トレーニング資格、および場合によってはすべてのスタッフのバックグラウンド調査など。これは非常に煩わしくなります。
DSSとPA-DSSの関係の詳細については、DSSの9ページを参照してください。特に最後の段落で、次のように強調が追加されています。
PCI DSSはペイメントアプリケーションベンダーに適用される場合がありますifベンダーがカード会員データを保存、処理、または送信するか、アクセス権を持っている顧客のカード会員データに（たとえば、サービスプロバイダーの役割で）。
編集：これは実際には正しくない可能性があります。代わりに、PA-DSSについて dave_thompson_085の回答 を参照してください。
元の答え：
残念ながら、SAQ-DサービスプロバイダーとしてdoはPCIに準拠している必要があります。
ここ は、公式のPCIクイックリファレンスガイドへのリンクです。いくつかの引用：
この規格は、カード所有者データを保存、処理、または送信するすべてのエンティティに適用されます。これらのトランザクションで使用されるアプリケーションおよびデバイスのソフトウェア開発者およびメーカーの要件も含まれます。 [6ページ]
PA-DSSは、承認または決済の一部としてカード会員データや機密認証データを保存、処理、または送信する決済アプリケーションを開発、販売、配布、または第三者にライセンス供与するソフトウェアベンダーやその他の人向けです。ほとんどのカードブランドは、PCI SSCによってテストおよび承認された支払いアプリケーションを使用することを加盟店に奨励しています。 [7ページ]
このように考えてください：yourネットワークが侵害されても、誰もカード会員データを取得しません。しかし、知らないうちにアプリケーションに脆弱性が挿入され、それがすべてのクライアントに配布される可能性があります。 （これは サプライチェーン攻撃 として知られています。）
このページ 明示的に呼び出します：
ただし、すべての組織がサービスプロバイダーとしての役割を認識しているわけではありません。この認識の欠如により、ビジネス（および顧客のビジネス）が危険にさらされます。サービスプロバイダー定義の最後の部分（「カード会員データのセキュリティを制御する、またはそれに影響を与える可能性のあるサービスを提供する企業も含まれる」）が混乱を招くことがよくあります。たとえば、企業がマネージドネットワークファイアウォールを提供していて、顧客がそのファイアウォールを使用して、カードデータ環境を構成するPOSシステムとバックオフィスコンピューターを保護している場合、カードデータのセキュリティに絶対に影響を与える可能性があります。
サービスプロバイダーであることを知らないことが多いサービスプロバイダーの例としては、ホスティング、請求先アカウント管理、バックオフィスサービス、コロケーションプロバイダーなどがあります。
私は SAQ-D SP を自分で記入する必要はありませんでしたが、その大きなスワスをN/Aとマークできるはずです（付録Cの補足説明を参照）。例えば：
アプリケーション開発と安全なコーディングに固有の質問（要件6.3および6.5）は、組織が独自のカスタムアプリケーションを開発している場合にのみ回答する必要があります。 ソフトウェアを開発しているので、これらのセクションに入力する必要があります。
要件9.1.1および9.3の質問に答える必要があるのは、ここで定義されている「機密性の高いエリア」を備えた施設のみです。カード会員データ。 自分でデータに触れていないので、このセクションは該当しません。
いつものように、私はQSAではありません。インターネット上の無作為な人に頼るのではなく、おそらく何を評価する必要があるかを確認または支援するために相談する必要があります。ただし、これで開始できます。
@Bobsonによると、要件6.3および6.5が対象です。 6.3および6.5以外では、すべてを適用できません。
クライアントにリリースする前に、要件6.6を含めて、アプリケーションに対してアプリケーションセキュリティテストを実行することができます。クライアントはこれを行うことができますが、修正を実装する必要があるため、そもそもより安全なアプリケーションを提供することが望ましい場合があります。クライアントはWAFを使用することでこの要件を満たすこともできます。
支払い組織は、要件6.3および6.5をN/Aまたはインプレースとして、要件である第三者である要件が満たされていることを明記することができます。要件を満たすために、支払い組織にコンプライアンスを報告する必要があります12.8-サービスプロバイダーのコンプライアンスの監視。