compliance-pci
PCI DSS compliance: SAQ A vs SAQ D scope, Stripe Elements for card data isolation, tokenization patterns, cardholder data environment (CDE) scoping, network segmentation, encryption in transit/at rest, audit logging requirements. Never store raw card data. Use when implementing payment systems, reviewing card data handling, PCI scope reduction.
Installation
Suivez les instructions du dépôt pour votre agent. Consultez les fichiers et dépendances avant l’installation.
Voir la source ↗GuidesInstructions
PCI DSS Compliance
When to use
- Implementing payment card processing
- Reducing PCI scope with hosted fields / Elements
- Reviewing what data can/cannot be stored
- Designing network segmentation for CDE
- Choosing SAQ level for annual assessment
Core principles
- Never store raw card data — full PAN, CVV, magnetic stripe data must never touch your servers
- Reduce scope, don't solve scope — use Stripe Elements / Braintree Hosted Fields to push scope to the processor
-
Tokenize, never transmit — use processor tokens (
pm_xxx,tok_xxx); your app never sees raw card numbers - CVV must never be stored — not even transiently in logs; PCI Req 3.3 is absolute
- SAQ A is achievable for most SaaS — if you use hosted card collection, you avoid SAQ D's 300+ controls
References available
-
references/saq-selection.md— SAQ A vs SAQ A-EP vs SAQ D decision tree, control counts, scope criteria -
references/cardholder-data.md— what to store vs what to forbid, tokenization schema, webhook security patterns -
references/network-segmentation.md— CDE boundary design, firewall rules, segmentation testing
Exemples
Consultez les exemples du dépôt source.
Voir la source ↗Historique source
- Date d’indexation
- 2026-03-11
- Mise à jour de l’index
- 2026-03-11
- Branch
- main
Les dates concernent ce répertoire. Consultez le dépôt pour l’historique du code.
GitHub ↗chat Comments (0)
Sign in to join the discussion and leave a comment.
No comments yet. Be the first to share your thoughts!