pci-audit

Name: pci-audit
Author: briiirussell

107installs36forks

How to install pci-audit?

briiirussell/cybersecurity-skills/pci-audit

$npx -y skills add briiirussell/cybersecurity-skills --skill pci-audit

Installs into the current project.

Summary

Audit applications and infrastructure handling payment card data against PCI DSS v4.0. Heavy emphasis on scope determination (the single most-leveraged variable) plus the engineering-relevant requirements — Req 3 (storage of CHD), Req 4 (transmission), Req 6 (secure SDLC), Req 7-

Files · 1

View on GitHub

SKILL.md

1	# PCI Audit — Payment Card Industry Data Security Standard
2
3	PCI DSS v4.0 (effective March 2025) is the security standard for any environment that stores, processes, or transmits payment card data. Twelve high-level requirements; hundreds of sub-requirements. Most organizations pass or fail on a single decision: scope.
4
5	This skill emphasizes scope determination first, then the engineering-relevant requirements. Final compliance attestation (SAQ self-assessment or QSA audit producing an Attestation of Compliance) is a process this skill prepares for — it is not the attestation itself.
6
7	Cross-references: `crypto-audit` for Req 3 / 4 cryptographic detail; `iam-audit` for Req 7-8; `siem-detection` for Req 10 logging; `dependency-audit` and `owasp-audit` for Req 6 (secure SDLC); `incident-triage` for Req 12.10 (incident response).
8
9	## The scope question (do this first)
10
11	"Scope" in PCI DSS means: the systems that store, process, or transmit cardholder data (CHD), plus systems that can affect the security of those systems (connected-to and security-impacting systems). Everything in scope is subject to all 12 requirements. Everything out of scope is not.
12
13	Most PCI failures are scope failures. A system pulled into scope by accident creates years of compliance debt; a system kept out of scope via good architecture saves substantial cost.
14
15	### Determine scope
16
17	For every system in the environment, classify:
18
19	\| Type \| Definition \| In scope? \|
20	\|---\|---\|---\|
21	\| CDE (Cardholder Data Environment) \| Stores, processes, or transmits PAN, expiration, service code, name when paired with PAN, or sensitive authentication data \| Yes — full PCI DSS \|
22	\| Connected-to \| Has direct connectivity to the CDE without compensating segmentation \| Yes \|
23	\| Security-impacting \| Provides security services to the CDE (auth, logging, monitoring, time sync, DNS) \| Yes \|
24	\| Segmented \| No direct connectivity; segmentation validated annually \| No \|
25	\| Cardholder data flow only as masked / tokenized \| The system handles tokens or masked PANs that cannot be reversed without out-of-band access \| Usually No, but verify the token type — surrogate tokens reversible by the merchant are still in scope \|
26
27	Audit step: trace every payment flow end-to-end. Where does the PAN enter the environment, where does it go, where does it stop. Every system the PAN touches is in scope; every system that touches that system without segmentation is also in scope.
28
29	### Reduce scope (the leveraged engineering work)
30
31	The highest-ROI PCI work is usually scope reduction:
32
33	- Use a hosted payment page — let Stripe / Adyen / Braintree / Worldpay host the input form. The PAN never reaches your servers. The browser communicates directly with the processor. Your scope shrinks to "iframe integration."
34	- Use tokenization — payment processor converts PAN into a token your systems store instead. The token is meaningless without processor-side access. Your systems handle tokens, not PANs.
35	- Use P2PE (Point-to-Point Encryption) — for terminal-present commerce, encrypt at the swipe so plaintext never traverses your network.
36	- Network segmentation — for retained CDE, ensure firewall / VLAN / namespace separation between CDE and the rest. Default-deny at the CDE perimeter.
37
38	A merchant doing 1M transactions/year via Stripe Checkout with no PAN on their servers is radically less in scope than the same merchant taking PANs into their own form and proxying to Stripe. Same merchant; very different audit.
39
40	## Merchant levels and assessment types (compliance posture, not engineering)
41
42	Briefly, because it sets the audit cadence and rigor:
43
44	\| Level \| Volume (Visa) \| Validation requirement \|
45	\|---\|---\|---\|
46	\| 1 \| > 6M transactions/year, or breached merchant of any volume \| Annual on-site QSA assessment → AoC \|
47	\| 2 \| 1M-6M transactions/year \| Annual SAQ (self) or QSA assessment (Visa requires QSA from 2024) \|
48	\| 3 \| 20K-1M e-commerce transactions/year \| Annual SAQ \|
49	\| 4 \| All other \| Annual SAQ \|
50
51	SAQ types (Self-Assessment Questionnaire) match the merchant's CDE shape — SAQ A (fully outsourced e-commerce), SAQ A-EP (e-commerce that does some redirection), SAQ B (terminal only,

briiirussellPublisher · 30 listings

Preview

briiirussell/cybersecurity-skills

# PCI Audit — Payment Card Industry Data Security Standard

PCI DSS v4.0 (effective March 2025) is the security standard for any environment that stores, processes, or transmits payment card data. Twelve high-level requi

This skill emphasizes scope determination first, then the engineering-relevant requirements. Final compliance attestation (SAQ self-assessment or QSA audit prod

Cross-references: `crypto-audit` for Req 3 / 4 cryptographic detail; `iam-audit` for Req 7-8; `siem-detection` for Req 10 logging; `dependency-audit` and `owasp

Repobriiirussell/cybersecurity-skills

LicenseMIT

TypeSkills

CategorySecurity

UpdatedMay 2026

Repo stars320

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

pci-audit

107installs36forks

View on GitHub

How to install pci-audit?

briiirussell/cybersecurity-skills/pci-audit

$npx -y skills add briiirussell/cybersecurity-skills --skill pci-audit

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# PCI Audit — Payment Card Industry Data Security Standard
2
3	PCI DSS v4.0 (effective March 2025) is the security standard for any environment that stores, processes, or transmits payment card data. Twelve high-level requirements; hundreds of sub-requirements. Most organizations pass or fail on a single decision: scope.
4
5	This skill emphasizes scope determination first, then the engineering-relevant requirements. Final compliance attestation (SAQ self-assessment or QSA audit producing an Attestation of Compliance) is a process this skill prepares for — it is not the attestation itself.
6
7	Cross-references: `crypto-audit` for Req 3 / 4 cryptographic detail; `iam-audit` for Req 7-8; `siem-detection` for Req 10 logging; `dependency-audit` and `owasp-audit` for Req 6 (secure SDLC); `incident-triage` for Req 12.10 (incident response).
8
9	## The scope question (do this first)
10
11	"Scope" in PCI DSS means: the systems that store, process, or transmit cardholder data (CHD), plus systems that can affect the security of those systems (connected-to and security-impacting systems). Everything in scope is subject to all 12 requirements. Everything out of scope is not.
12
13	Most PCI failures are scope failures. A system pulled into scope by accident creates years of compliance debt; a system kept out of scope via good architecture saves substantial cost.
14
15	### Determine scope
16
17	For every system in the environment, classify:
18
19	\| Type \| Definition \| In scope? \|
20	\|---\|---\|---\|
21	\| CDE (Cardholder Data Environment) \| Stores, processes, or transmits PAN, expiration, service code, name when paired with PAN, or sensitive authentication data \| Yes — full PCI DSS \|
22	\| Connected-to \| Has direct connectivity to the CDE without compensating segmentation \| Yes \|
23	\| Security-impacting \| Provides security services to the CDE (auth, logging, monitoring, time sync, DNS) \| Yes \|
24	\| Segmented \| No direct connectivity; segmentation validated annually \| No \|
25	\| Cardholder data flow only as masked / tokenized \| The system handles tokens or masked PANs that cannot be reversed without out-of-band access \| Usually No, but verify the token type — surrogate tokens reversible by the merchant are still in scope \|
26
27	Audit step: trace every payment flow end-to-end. Where does the PAN enter the environment, where does it go, where does it stop. Every system the PAN touches is in scope; every system that touches that system without segmentation is also in scope.
28
29	### Reduce scope (the leveraged engineering work)
30
31	The highest-ROI PCI work is usually scope reduction:
32
33	- Use a hosted payment page — let Stripe / Adyen / Braintree / Worldpay host the input form. The PAN never reaches your servers. The browser communicates directly with the processor. Your scope shrinks to "iframe integration."
34	- Use tokenization — payment processor converts PAN into a token your systems store instead. The token is meaningless without processor-side access. Your systems handle tokens, not PANs.
35	- Use P2PE (Point-to-Point Encryption) — for terminal-present commerce, encrypt at the swipe so plaintext never traverses your network.
36	- Network segmentation — for retained CDE, ensure firewall / VLAN / namespace separation between CDE and the rest. Default-deny at the CDE perimeter.
37
38	A merchant doing 1M transactions/year via Stripe Checkout with no PAN on their servers is radically less in scope than the same merchant taking PANs into their own form and proxying to Stripe. Same merchant; very different audit.
39
40	## Merchant levels and assessment types (compliance posture, not engineering)
41
42	Briefly, because it sets the audit cadence and rigor:
43
44	\| Level \| Volume (Visa) \| Validation requirement \|
45	\|---\|---\|---\|
46	\| 1 \| > 6M transactions/year, or breached merchant of any volume \| Annual on-site QSA assessment → AoC \|
47	\| 2 \| 1M-6M transactions/year \| Annual SAQ (self) or QSA assessment (Visa requires QSA from 2024) \|
48	\| 3 \| 20K-1M e-commerce transactions/year \| Annual SAQ \|
49	\| 4 \| All other \| Annual SAQ \|
50
51	SAQ types (Self-Assessment Questionnaire) match the merchant's CDE shape — SAQ A (fully outsourced e-commerce), SAQ A-EP (e-commerce that does some redirection), SAQ B (terminal only,

briiirussellPublisher · 30 listings

Preview

briiirussell/cybersecurity-skills

# PCI Audit — Payment Card Industry Data Security Standard

PCI DSS v4.0 (effective March 2025) is the security standard for any environment that stores, processes, or transmits payment card data. Twelve high-level requi

This skill emphasizes scope determination first, then the engineering-relevant requirements. Final compliance attestation (SAQ self-assessment or QSA audit prod

Cross-references: `crypto-audit` for Req 3 / 4 cryptographic detail; `iam-audit` for Req 7-8; `siem-detection` for Req 10 logging; `dependency-audit` and `owasp

Repobriiirussell/cybersecurity-skills

LicenseMIT

TypeSkills

CategorySecurity

UpdatedMay 2026

Repo stars320

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type