PCI DSS Control and Certification

1) What PCI DSS is and why it matters to iGaming

PCI DSS is the security standard for the payment card industry (Visa/Mastercard/Amex/Discover/JCB). For the iGaming operator, it defines technical and organizational measures to protect cardholder data (CHD), including PAN and sensitive authentication data (SAD). The discrepancy threatens with fines, increased interbank tariffs, recall of the merchant account and reputational damage.

2) Certification roles, levels and type

Roles

Merchant: Accepts cards from players.
Service Provider: processes/hosts/stores CHD for merchants (including hosting, payment platform, tokenization).

Levels (high level)

Merchant levels 1-4: by annual transactions; Level 1 typically requires a ROC (Report on Compliance) from QSA.
Service provider levels 1-2: Level 1 is a mandatory ROC.

Evaluation formats

ROC + AOC: full auditor's report (QSA/ISA).
SAQ: self-assessment by one of the types (see below), plus an external ASV scan.

3) Scope and CDE: How to Narrow and Manage

CDE (Cardholder Data Environment) - any systems/networks/processes that store, process or transmit CHD/SAD.

Minimization strategies

1. Hosted Payment Page (HPP): PSP → SAQ A form.
2. Direct Post/JS + your page (A-EP): your page affects the safety of collecting SAQ A-EP → (wider).
3. Tokenization: PAN exchange for PSP token/your token-walt; PAN is not stored with you.
4. Network segmentation: isolate CDE (VLAN/firewalls/ACL), minimize traffic.
5. "No storage" policy: do not store PAN/SAD; exceptions are strictly justified.

4) SAQ types (summarized)

5) PCI DSS v4. 0: key topics

Customized Approach: allows alternative controls under proven equivalence (plan, TRA, test justification).
Targeted Risk Analysis (TRA): point risk analysis for "flexible" requirements (process frequency, monitoring).
Authentication: MFA for admin and remote access; strong passwords/passphrases; locks/timeouts.
Vulnerabilities and patches: regular scans (internal/external), quarterly ASV, pentests annually and after significant changes.
Encryption: in transit (TLS 1. 2+) и at rest; key management (KMS/HSM), rotations, role separation.
Logs and monitoring: centralized logs, protection against changes (WORM/signature), daily review of security events.
Segmentation/firewalls/WAF: formal rules, review, documented topologies.
SDLC/changes: dev/test/prod separated, SAST/DAST/dependency scans, secret management.
Incidents: formal IRP, drills, roles and contact list, interaction with PSP/acquiring bank.

6) Card data: what can/can not

CHD: PAN (+ optional. name, term, service code).
SAD (forbidden to store after authorization): CVV/CVC, full magnetic tracks, PIN blocks.
Masking: PAN display with mask (usually first 6 and last 4).
Tokenization/storage: if you store PAN → encryption, Need-to-Know access, keys separately, hard logs.

7) Control domains (practical checklist)

1. CDE segmentation - separate subnets, deny-by-default, egress-control.
2. Asset Inventory - all systems in the CDE and related.
3. Hardning - safe configs, default shutdown, basic standards.
4. Vulnerabilities/patches - processes, SLAs, deployment confirmations.
5. Logging - time synchronization, centralized logs, WORM/signatures.
6. Accesses - RBAC/ABAC, MFA, SoD, JIT/PAM, offboarding ≤ 15 minutes.
7. Cryptography - TLS, KMS/HSM, rotation, separate crypto-custodians roles.
8. Development - SAST/DAST/DS/IaC, secret scans, pipeline signatures.
9. Scanning ASV - quarterly and after changes, "Pass" statuses to store.
10. Pentests - external/internal network and †., at least annually.
11. IR-plan - exercises, war-room with PSP/acquirer, timelines.
12. Training - phishing, secure coding, PCI-awareness for roles.
13. Documents/Procedures - PAN Retention/Deletion Policy, Export Log.

8) Interaction with PSP/Vendors

Contracts: Availability/Security SLA, DPIA/TPRM, Audit Right, Incident-Notifications ≤ 72 h.
Technical integration: HP/redirect for TLS, signed webhooks, mTLS/keys in KMS, rotations.
Quarterly monitoring: PSP reports (Attestation, certificates), ASV/pentest excerpts, SDK changes.

9) Compliance documents

ROC (Report on Compliance): full QSA report.
AOC (Attestation of Compliance) - confirmation of compliance (attachment to ROC/SAQ).
SAQ: selected type of self-assessment (A, A-EP, D, etc.).
ASV reports: external scan by a certified provider.
Policies/procedures: versions, owners, change logs.
Evidence: network diagrams, WORM logs, test results, tickets.

10) Roles and RACI

11) Metrics (KPI/KRI)

ASV Pass Rate: 100% quarterly reports - "pass."

Patch SLA High/Critical: ≥ 95% on time.
Pentest Findings Closure: ≥ 95% High closed ≤ 30 days.
MFA Coverage of admins: 100%.
Log Integrity: 100% critical systems with WORM/signatures.
Scope Reduction: the share of payments through redirect/tokenization ≥ 99%.
Incidents: PCI incidents with a deadline of 100%.

12) Roadmap (8-12 weeks before SAQ/ROC)

Weeks 1-2: Payment model selection (HPP/tokenization), CDE mapping, network layout, segmentation plan, SAQ/ROC selection.
Weeks 3-4: hardening, MFA, WORM logs, SDLC scans, keys/KMS, PAN storage policy (default - do not store).
Weeks 5-6: ASV scan # 1, corrections; pentest (web/network/webhooks), IR-learning with PSP, finalization of documentation.
Weeks 7-8: SAQ completion or audit of QSA (Stage-interviews, samples), closure of finds, preparation of AOC/ROC.
Weeks 9-12 (Op.) : "Customized Approach" and TRA, segmentation optimization, KPI/KRI dashboard integration.

13) Checklists

Before the start of card acceptance

• Non-PAN/SAD storage path selected
• Redirect/iframe PSP or tokenization configured
• CDE segmentation, deny-by-default, WAF
• MFA/IGA/JIT/PAM for admins
• Logs (WORM, signatures, NTP) and dashboards
• ASV scan passed, pentest closed
• IR plan and PSP/bank contacts

For annual certification

• Updated CDE schematics and system list
• Passed 4 quarterly ASVs, "pass" saved
• Pentest ≤ 12 months and after changes
• Policies/procedures up to date, versions/owners
• Filled in by SAQ/received by ROC, issued by AOC

14) Frequent mistakes and how to avoid them

Collect PAN on your page without proper protection → SAQ A-EP/D. Use HPP/iframe from PSP.
Logs without protection against changes. Include WORM/signatures and daily overview.
No segmentation - "entire network in CDE." Rigidly isolate the payment loop.
CVV/SAD storage. Prohibited after authorization.
Incomplete ASVs/pentests. Do after changes and keep reports/remediations.

15) Integration with the rest of the wiki sections

Related pages: Password policy and MFA, RBAC/Least Privilege, Log policy, Incidents and leaks, TPRM and SLA, ISO 27001/27701, SOC 2 - for control mapping and a single set of evidence.

TL; DR

PCI DSS v4 success. 0 = minimum scope (HPP/tokenization) + hard segmentation CDE + MFA/WORM logs/encryption/KMS + ASV quarterly, pentest annually and after changes + finished SAQ/ROC/AOC documents. This reduces audit costs, accelerates PSP integrations, and makes the payment loop provably secure.