PCI DSS — Payment Card Industry Data Security Standard
Status: SAQ-A scope · annual self-assessment · last updated 27 May 2026
Glassbreak is a PCI DSS merchant under the SAQ-A (Self-Assessment Questionnaire A) scope. Cardholder data (CHD) and sensitive authentication data (SAD) never touch Glassbreak infrastructure. Payment processing is fully outsourced to Stripe, a PCI DSS Level 1 Service Provider audited annually by an independent QSA.
Why SAQ-A applies
SAQ-A is the smallest of the PCI self-assessment scopes. It applies to e-commerce merchants who:
- Accept card-not-present transactions only.
- Have fully outsourced ALL cardholder data functions (storage, processing, transmission) to a PCI DSS-validated third-party service provider.
- Do not electronically store, process, or transmit any cardholder data on their own systems or premises — and rely solely on the third party to do so.
- Confirm the third party is responsible for the security of any outsourced cardholder data.
Glassbreak satisfies every condition. The card form is hosted by Stripe Checkout (redirect) or rendered inside a cross-origin iframe via Stripe Elements; neither the input fields nor the encrypted card token ever cross a Glassbreak domain or sit in a Glassbreak HTTP request.
What we store
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| PAN (primary account number) | Full or truncated card number | N/A | Never received, never stored. Stripe holds it in their PCI-DSS-audited cardholder data environment. |
| CVV / CVC | Card verification value | N/A | Never received. Forbidden post-authorisation under PCI DSS Requirement 3.2.1; Stripe enforces this. |
| Expiry date | Card expiry month / year | N/A | Never received. |
| Cardholder name | Name as printed on the card | N/A | Never received as a card-data element. |
| Stripe customer ID | Reference token returned by Stripe | Met | Stored in our `organizations.stripe_customer_id` column. NOT card data — this is an opaque Stripe-internal handle, useless for any purpose other than calling Stripe with our API key. |
| Stripe payment_method ID | Reference token for a saved payment method | Met | Stored opaque token only. Useless without the Stripe secret key. |
| Stripe subscription ID | Subscription reference | Met | Stored opaque token only. |
| Last 4 digits of PAN | Display purposes ("ends in 1234") | Met | Stored in the audit-safe `subscriptions.last4` column for invoice display. PCI DSS Requirement 3.4 explicitly permits storage of the last four digits. |
| Brand (Visa / MC / Amex) | Card brand for display | Met | Stored for invoice display. Not card data under PCI DSS. |
Controls that still apply to us as a merchant
SAQ-A excludes most of the technical requirements (which apply to Stripe), but a small subset apply to the Glassbreak merchant entity directly. These map cleanly to controls we already operate for SOC 2 / ISO 27001.
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| Req 2.1 | Change vendor defaults (passwords, parameters) before deployment | Met | No payment-handling infrastructure under our control to harden; CI-only deployment with no default credentials anywhere in the platform. |
| Req 8 | Identify and authenticate access to system components | Met | MFA required for Stripe Dashboard access (TOTP on every billing-admin account). Argon2id password hashing, EdDSA JWTs, refresh-token rotation across Glassbreak. See /technology/encryption. |
| Req 9 | Restrict physical access to cardholder data | N/A | No physical CHD; no Glassbreak data centre. |
| Req 12.3 | Maintain an information security policy | Met | Published Information Security Policy at /policies/information-security; reviewed annually. PCI-scoped extract in the annual self-assessment. |
| Req 12.8 | Maintain agreements with service providers; monitor compliance status | Met | Written agreement with Stripe (their Services Agreement + DPA). Stripe Attestation of Compliance (AOC) reviewed annually and stored under /policies/sub-processor-compliance. |
| Req 12.10 | Incident response plan | Met | Incident-response procedure at /policies/incident-response covers card-data-related events even though we hold none — sub-processor breach (Stripe) triggers customer notification within 72 hours per the DPA. |
| Stripe Webhook signature verification | Authenticate webhooks from the PSP | Met | Webhook handler verifies the Stripe-Signature header against the per-environment STRIPE_WEBHOOK_SECRET using HMAC-SHA256 in constant time. Unsigned or mis-signed payloads return 400. See api/common/src/api/public/stripe-webhook.ts. |
| TLS in transit (client ↔ Stripe iframe / redirect) | Strong cryptography on public networks | Met | TLS 1.2+ enforced at the edge; HSTS preloaded; the Stripe iframe loads over Stripe-controlled HTTPS. See /technology/encryption. |
Annual attestation
- SAQ-A and the Attestation of Compliance (AOC) are completed annually by Glassbreak's compliance owner and signed off by leadership.
- Stripe's current PCI DSS AOC is on file (refreshed each year by Stripe's QSA cycle); a copy is available under NDA on request.
- If the customer's acquirer requires a Glassbreak SAQ-A or AOC for their merchant pipeline, write to compliance@glassbreak.io.
What would change our scope
We would move out of SAQ-A and into a higher SAQ tier (B, B-IP, C, D) only if we:
- Began rendering card-input fields on a Glassbreak-controlled page outside the Stripe iframe (would move us to SAQ-A-EP), or
- Started accepting card data via API integration that routed CHD through our infrastructure, or
- Started storing any CHD element other than the last 4 digits + brand.
None of these are on the roadmap. The product is structured around Stripe Checkout and Stripe Customer Portal precisely to keep PCI scope minimal.
If PCI DSS scope is a procurement question and you need our latest AOC or SAQ-A under NDA, write to compliance@glassbreak.io.