Skill Being Reviewed
Skill name: pci-dss-review
Skill path: skills/compliance/pci-dss-review/
False Positive Analysis
Benign code/configuration that triggers a false positive:
scope_reduction:
method: outsourced_payment_page
validation_type: SAQ-A
provider: ExamplePay
provider_aoc:
version: PCI DSS v4.0
status: current
covered_services:
- hosted_payment_page
- token_vault
- payment_gateway
merchant_responsibilities:
- iframe integration integrity monitoring
- vendor due diligence
- annual AOC review
- incident notification contact testingWhy this is a false positive:
The skill may over-expand scope when it sees payment integration code or outsourcing references. A fully outsourced hosted payment page with current AOC, covered services matching the integration, written responsibility matrix, and no PAN touching merchant systems can qualify for reduced scope. The review should not treat all payment-page integrations as SAQ A-EP or SAQ D without checking the provider evidence and data-flow boundary.
Coverage Gaps
Missed variant 1:
Provider AOC: current, but covers "Gateway API"
Merchant uses: hosted fields + token vault + dispute webhook with masked PAN
Responsibility matrix: generic PDF, no mapping to Req 6.4.3, 11.6.1, 12.8.5
Result: merchant assumes provider owns all payment-page script controls
Why it should be caught:
The skill lists TPSP inventory and responsibility documentation, but the output only asks for "Third-party service providers in scope: list." It should require per-provider, per-service evidence that the AOC actually covers the consumed service and that responsibilities are mapped to specific PCI DSS requirements. A provider can be compliant for one service while the merchant's used integration remains partially merchant-owned.
Missed variant 2:
Last annual AOC review: 2026-01-02
Provider changed hosted checkout JavaScript domain: 2026-04-18
Provider added new analytics script to payment page: 2026-05-03
Merchant scope review triggered: no
Why it should be caught:
The skill covers annual TPSP monitoring and significant-change scope review separately, but not provider-side change drift. For outsourced payment flows, provider service changes can alter merchant obligations, script inventory, incident contacts, and SAQ eligibility before the next annual AOC review.
Edge Cases
Scope reduction depends on the exact service consumed, not only the provider's compliance status. A merchant using a provider's hosted checkout may have very different obligations from a merchant using the same provider's direct post API, hosted fields, mobile SDK, webhook, or token vault.
Another edge case is shared responsibility ambiguity. A generic agreement that says "provider is PCI compliant" does not prove who owns Req 6.4.3 payment-page script authorization, Req 11.6.1 tamper detection, incident notification, log retention, or vulnerability remediation for integration code.
Remediation Quality
Suggested additions:
TPSP evidence: provider, service consumed, current AOC date/version, covered service names, responsibilities by PCI requirement, customer-owned controls, review date.
Provider drift: service change notice, script/domain change, API/webhook change, AOC scope change, SAQ eligibility impact, owner and deadline.
SAQ decision: data-flow proof that merchant systems do or do not store/process/transmit PAN/SAD.
Comparison to Other Tools
| Tool |
Catches this? |
Notes |
| QSA ROC/SAQ workflow |
Yes |
A QSA normally asks for TPSP AOC scope and responsibility matrix evidence, not just provider name. |
| GRC vendor inventory |
Partial |
Tracks vendors and renewals but often misses service-level PCI scope and requirement ownership. |
| CSP shared-responsibility docs |
Partial |
Useful pattern, but payment providers need service-specific AOC and PCI responsibility mapping. |
Overall Assessment
Strengths: Good coverage of PCI DSS v4.0 scope, SAQ/ROC types, targeted risk analysis, segmentation, PAN protection, and new 2025-due controls.
Needs improvement: Treat third-party service provider evidence as a requirement-level matrix, not a flat provider list, and connect provider-side changes back to scope and SAQ eligibility.
Priority recommendations:
- Add a TPSP responsibility matrix table keyed by provider, service, AOC coverage, and PCI DSS requirement.
- Require evidence that provider AOC covered services match the exact integration in use.
- Add provider-side change drift checks that trigger scope/SAQ reassessment.
Bounty Info
Skill Being Reviewed
Skill name: pci-dss-review
Skill path:
skills/compliance/pci-dss-review/False Positive Analysis
Benign code/configuration that triggers a false positive:
Why this is a false positive:
The skill may over-expand scope when it sees payment integration code or outsourcing references. A fully outsourced hosted payment page with current AOC, covered services matching the integration, written responsibility matrix, and no PAN touching merchant systems can qualify for reduced scope. The review should not treat all payment-page integrations as SAQ A-EP or SAQ D without checking the provider evidence and data-flow boundary.
Coverage Gaps
Missed variant 1:
Why it should be caught:
The skill lists TPSP inventory and responsibility documentation, but the output only asks for "Third-party service providers in scope: list." It should require per-provider, per-service evidence that the AOC actually covers the consumed service and that responsibilities are mapped to specific PCI DSS requirements. A provider can be compliant for one service while the merchant's used integration remains partially merchant-owned.
Missed variant 2:
Why it should be caught:
The skill covers annual TPSP monitoring and significant-change scope review separately, but not provider-side change drift. For outsourced payment flows, provider service changes can alter merchant obligations, script inventory, incident contacts, and SAQ eligibility before the next annual AOC review.
Edge Cases
Scope reduction depends on the exact service consumed, not only the provider's compliance status. A merchant using a provider's hosted checkout may have very different obligations from a merchant using the same provider's direct post API, hosted fields, mobile SDK, webhook, or token vault.
Another edge case is shared responsibility ambiguity. A generic agreement that says "provider is PCI compliant" does not prove who owns Req 6.4.3 payment-page script authorization, Req 11.6.1 tamper detection, incident notification, log retention, or vulnerability remediation for integration code.
Remediation Quality
Suggested additions:
Comparison to Other Tools
Overall Assessment
Strengths: Good coverage of PCI DSS v4.0 scope, SAQ/ROC types, targeted risk analysis, segmentation, PAN protection, and new 2025-due controls.
Needs improvement: Treat third-party service provider evidence as a requirement-level matrix, not a flat provider list, and connect provider-side changes back to scope and SAQ eligibility.
Priority recommendations:
Bounty Info