PCI DSS — Payment Card Industry Data Security Standard
Status: SAQ-A scope · first self-assessment scheduled for billing launch · 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 reviewed against the published list at /legal/sub-processors. |
| 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) will be completed annually by Glassbreak's compliance owner and signed off by leadership, beginning with the first cycle after paid billing goes live (billing is currently in early access).
- 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.