Security & Compliance · pre-launch readiness
Read the security posture.
For a CFO, security reviewer, or legal reviewer doing a compliance-readiness read — and for the engineering team receiving this handoff. Most items below are pre-launch and not yet signed off; that's not a gap this page hides. Each row states plainly what's attested, what's still pending, and who or what it's waiting on.
9
total attestations tracked
0
signed off (status: passed)
7
GA-blocking, not yet signed off
2
marketplace-blocking, not yet signed off
9
never signed off — no attestation date on record
0 of 9 signed off· 7 GA-blocking outstanding · 2 marketplace-blocking outstanding
How to read this
Pending is the handoff signal, not a defect. Each pending or in-review row below names exactly what a security or legal reviewer still needs to check, decide, or sign — that's more useful to a receiving team than a page that only shows green. "STRIDE analysis complete, awaiting sign-off" is not the same claim as "signed off," and this page never conflates the two: a passed badge only appears when status === 'passed'in the attestation record.
The attestation pack
- marketplace-blockingpendingphase: pre-launch
BC marketplace technical review
never signed off
A second marketplace-review tracker (annual-review trigger, 365-day expiry) covering the same BC App Review gate — both remain open.
Related: #1269
- marketplace-blockingpendingphase: launch
BC marketplace technical review — submission + approval
never signed off
BigCommerce's partner-team technical review of OAuth scopes, webhooks, and app-extension compliance — required before the app can list in the marketplace. BC controls the timeline; no internal work bypasses it.
Related: #1269
- ga-blockingpendingphase: pre-launch
DSAR erasure — financial-record retention vs deletion (legal + payments decision)
never signed off
A BRD-vs-ratified-ADR conflict with a legal dimension: DSAR erasure currently soft-deletes charges, but GDPR Art-17(3)(b) plus tax law require retaining de-identified financial records. Needs operator + legal + payments sign-off.
Related: #1636
- ga-blockingpendingphase: pre-launch
GDPR compliance review — data subject rights + processor agreements
never signed off
Legal and technical review of data-subject rights, processor agreements (Cloudflare / Stripe / BigCommerce), and code-enforced retention before selling to EU merchants.
Related: #1269 · #1279 · #1309 · #1319 · #1320 · #1321 · #1323 · #1324
- ga-blockingpendingphase: pre-launch
PCI scope verification — no raw card data in our systems
never signed off
Confirms the app stays in PCI SAQ-A scope — no raw card data ever transits our API, database, or logs; the canonical charge rail is BigCommerce's stored-instruments vault (ADR-0037).
- ga-blockingpendingphase: ongoing
Secret scanning audit — gitleaks + environment secret hygiene
never signed off
Gitleaks plus environment secret-hygiene audit; an ongoing obligation re-triggered whenever a new secret is added.
- ga-blockingpendingphase: pre-launch
Third-party penetration test — full app surface
never signed off
Third-party (CREST-equivalent) penetration test of the full attack surface — the only gate that validates the security posture under adversarial conditions.
- ga-blockingin-reviewphase: pre-launch
STRIDE threat model — payment authorization and capture flows
never signed off
STRIDE threat model of tokenization, authorization, capture, dunning retry, and refund. The analysis is complete (five of six acceptance items checked); it is awaiting human-owner sign-off and an evidence link.
Related: #1269 · #1279 · #1308 · #1332 · #1333 · #1334 · #1336 · #1338
- ga-blockingin-reviewphase: pre-launch
STRIDE threat model — subscription lifecycle operations
never signed off
STRIDE threat model of the lifecycle state machine (create through cancel and reinstate); tenant-isolation and authorization controls verified. Analysis complete; awaiting sign-off.
Related: #1269 · #1279 · #1307 · #1327 · #1328 · #1329 · #1330 · #1331
Glossary
- STRIDE
- A standard security threat-modeling framework developed at Microsoft. Acronym for six attack categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
- PCI scope / SAQ-A
- PCI DSS (Payment Card Industry Data Security Standard) regulates how systems handle credit card data. SAQ-A is the lightest PCI self-assessment tier — it applies when a merchant never touches raw card data because the flow is fully outsourced to a compliant third party (here, BigCommerce's stored-instruments vault). Staying in SAQ-A scope is the goal; touching raw card data anywhere would push the app into a much heavier compliance tier.
- DPA (Data Processing Agreement)
- A contract required under GDPR between a data controller (the merchant) and a data processor (us, or a subprocessor like Cloudflare/Stripe) that governs how personal data is handled on the controller's behalf.
- DSAR (Data Subject Access Request)
- A GDPR-granted right letting an individual request a copy of, or the deletion of, the personal data an organization holds about them. Erasure requests are the source of the financial-retention conflict tracked below.
- MIT (merchant-initiated transaction)
- A card-network classification for a charge the merchant initiates without the cardholder present at that moment — the category recurring subscription billing falls under, distinct from a customer-initiated checkout.
- ga-blocking
- An attestation gating tier: the item must reach
passedbefore General Availability launch. Most rows on this page carry this gate. - marketplace-blocking
- A stricter gating tier: the item must pass before the app can list on the BigCommerce App Marketplace at all — a harder gate than ga-blocking because it's controlled entirely by BigCommerce's own review timeline.
Where to go next
Open items carries the full actionable list across every category, not just security. For the engineering-director architecture read this pack supports, see Engineering. The underlying STRIDE and PCI packs — the source documents behind every caption on this page — live under docs/attestations/security-compliance/in the repository.