Compliance Check

Compliance Screening Report

Decision under review: Adopting Stripe for payment card processing in a US-based B2B SaaS product. Cards collected from end customers via the Stripe-hosted checkout (Payment Element), routed through the company's Stripe account, with subscription billing managed by Stripe Billing.

Data types in scope: Cardholder data (PAN, expiration, CVV, name on card) handled exclusively by Stripe; persistent customer identifiers (email, billing address, Stripe customer ID, subscription state) handled by the application; transaction metadata (amounts, timestamps, line items) handled by both.

Jurisdictions in scope: United States (federal + applicable state laws); secondary consideration for international subscribers under GDPR and CCPA/CPRA.

Executive Summary

This does not mean compliance is automatic. Three areas still require the company's attention:

1. Web page integrity — SAQ A v4.0 introduces requirements 6.4.3 and 11.6.1 for scripts loaded on payment pages.
2. Vendor management — Stripe must be added to the third-party risk register, the Stripe Service Agreement must be on file, and the annual Attestation of Compliance must be retrieved and stored.
3. Adjacent data laws — PCI-DSS applies to cardholder data only. Customer email, billing address, and subscription metadata are governed by separate privacy regimes.

Overall risk level: Low to Medium, contingent on the controls below being in place before launch.

PCI-DSS Scope: Self-Hosted vs Stripe Checkout

Applicable Frameworks

Obligations Triggered

PCI-DSS v4.0 (via SAQ A path)

The applicable subset of requirements is short — that is the value of staying in SAQ A scope — but is not zero.

• Requirement 2.2 (default credentials): No applicable, since the merchant operates no payment system; however, the application's hosting infrastructure must meet baseline hardening.
• Requirement 6.4.3 (script integrity on payment pages): New in v4.0. All scripts loaded on the page that hosts the Stripe Payment Element must be authorized, justified, and integrity-verified. Subresource Integrity hashes or a similar mechanism are the practical implementations.
• Requirement 8.3.6 (multi-factor authentication for administrative access): Applies to administrative access into the Stripe Dashboard for any staff with write permissions.
• Requirement 11.6.1 (change detection on payment pages): New in v4.0. Automated detection of unauthorized modifications to payment pages and the HTTP headers received by the consumer browser. A content security monitoring service or in-house equivalent is required.
• Requirement 12.8 (third-party service provider management): Maintain a list of service providers (Stripe, plus any monitoring tooling); retrieve Stripe's Attestation of Compliance annually; document the shared responsibility between merchant and Stripe.
• Requirement 12.9 (responsibility acknowledgement from Stripe): Already satisfied by Stripe's standard Service Agreement and AoC.

State Privacy Laws (illustrative — CCPA/CPRA shown)

• Right to know: Consumers can request a list of categories of personal information collected and processed. Customer email + billing address + transaction history must be enumerable.
• Right to delete: Consumers can request deletion. Transaction records are retained under a deletion exception (CCPA §1798.105(d)(1) — completing the transaction for which the information was collected, including legitimate business purposes like tax, fraud, and warranty obligations), but the contact data must be deletable.
• Service provider agreement: Stripe is a service provider under CCPA §1798.140(ag); the Stripe Service Agreement satisfies the form requirements but must be acknowledged in the vendor file.

Required Controls

Pre-launch checklist organized by where the work sits:

Application / Engineering

• SRI hashes on payment page scripts. All script tags on the checkout page should specify integrity hashes. Document the exempted scripts (Stripe.js itself, since its hash changes with Stripe-managed releases) and the alternative monitoring covering them.
• Content Security Policy header on payment page. A CSP restricting script sources to known origins, including Stripe's documented domains.
• Page-integrity monitoring. Either a third-party tool (Akamai Page Integrity Manager, Imperva, Jscrambler, etc.) or an in-house equivalent that detects DOM modifications and alerts within minutes.
• Webhook signature verification. All Stripe webhooks must verify the Stripe-Signature header before any side effect. Already covered by Stripe's official SDK; reverify implementation.
• No card data fields on any company-controlled form. Audit every form across the application to confirm no card number, CVV, or expiration field exists outside the Stripe iframe.

Vendor / Procurement

• Stripe Service Agreement on file. Executed copy stored in the vendor management system.
• Stripe Attestation of Compliance retrieved. Available from the Stripe Dashboard; refresh annually.
• Shared responsibility matrix documented. A written record of which PCI-DSS requirements Stripe satisfies vs. which fall on the merchant, signed off by the security owner.
• Tax handling decision documented. Stripe Tax or in-house — both have implications for what transaction data is retained and where.

Operations / Security

• MFA on Stripe Dashboard. Enforced for all staff with any Stripe Dashboard access; auditable in Stripe's user roles UI.
• Role-of-least-privilege on Stripe Dashboard. Restrict refund, payout, and API key permissions to specific named roles.
• Quarterly access review. Stripe Dashboard users and their roles reviewed and pruned each quarter.
• Incident response runbook covers Stripe compromise scenarios. Specifically the lost-API-key and unauthorized-refund-spike playbooks.
• PCI-DSS SAQ A completed. The questionnaire itself, signed by an appropriate officer, retained for the merchant's acquiring bank if requested.

Customer-facing

• Privacy policy updated. Discloses Stripe as a payment processor, what data is shared, retention periods, and customer rights.
• Terms of service reference subscription billing. Auto-renewal, refund, and cancellation language must align with Stripe Billing's actual behavior.

Common Pitfalls

Risk Summary

Overall risk level: Low to Medium, conditional on the page-integrity and CSP controls being in place before processing live transactions.

Open Questions for Counsel

1. Are any EU residents subscribing today, or expected to subscribe in the next 12 months? Determines GDPR applicability and the need for a Data Processing Addendum with Stripe.
2. Is the company a "business" under CCPA's $25M revenue / 100K consumer thresholds? Determines whether full CCPA obligations apply or only the service-provider-passthrough subset.
3. Are there enterprise customer contracts that obligate the company to specific PCI-DSS report-on-compliance levels beyond SAQ A?
4. Will refunds be processed by a customer-support tool that has its own data flow, or strictly through the Stripe Dashboard?

Recommended Next Steps

1. Confirm the integration path is the Payment Element (iframe) and not Stripe Elements with custom card fields. SAQ A applies only to the former; custom fields force SAQ A-EP, which is materially more work.
2. Engage counsel on the four open questions above before the controls list is finalized.
3. Select and configure a page-integrity monitoring solution with at least three months of runway before launch — implementation is straightforward but the tooling has a vendor selection cycle of its own.
4. Update the privacy policy and terms of service in the same sprint as the Stripe integration so the customer-facing language goes live with the feature.
5. Complete the SAQ A questionnaire as part of the launch readiness checklist, not after.

This is an operational compliance review, not legal advice. Counsel must review and approve before this analysis informs any regulatory filing, customer-facing representation, or contract negotiation. The analysis is based on publicly available information; ClearPoint Nexus is not affiliated with the companies named.

This sample illustrates the skill's output format. Names, metrics, and operational details are illustrative unless the artifact explicitly analyzes public information.