PCI DSS: levels and compliance

1) What is PCI DSS and who needs it

• accept card payments (directly or through a PSP/gateway),
• process/store/transfer card data (PAN, term, CVV) or their shortened/encrypted forms,
• are a service provider for other merchants (hosting, processing, anti-fraud, payment orchestration, etc.) if you can affect the security of these cards.

Version and timing: the current version is PCI DSS v4. 0. Requirements v3. 2. 1 retired; "future-dated" items v4. 0 are now in effect. New in v4. 0: enhanced MFA, "Customized Approach," targeted risk analysis of procedure frequency, segmentation and encryption refinements.

2) Compliance levels: merchants and service providers

2. 1 Merchants (merchants)

• Level 1:> 6 million transactions/year or was compromised. Requires annual ROC (Report on Compliance) from QSA or internal ISA at reconciliation, + quarterly ASV scans.
• Level 2: ~ 1-6 million/year. Usually - SAQ (self-assessment) + ASV scans; some schemes/acquirers may require ROC.
• Level 3: ~ 20k-1 million e-commerce/year. Usually - SAQ + ASV scans.
• Level 4: Below L3 thresholds. SAQ; requirements may vary by acquiring bank.

2. 2 Service Providers

Usually 2 levels; for Level 1 (large volume/critical role in the chain), a ROC from QSA is required, for Level 2 - SAQ-D SP (sometimes - ROC at the request of counterparties/schemes). In iGaming, many PSPs/gateways/hosting partners are SP Level 1.

3) SAQ vs ROC: How to choose

• SAQ A - redirect/iframe/hosted fields only; there is no processing/transfer/storage of cards with you.
• SAQ A-EP is e-commerce, where your site affects the security of the payment page (for example, hosts scripts), but PAN is introduced in the provider's environment.
• SAQ B/B-IP - terminals/imprinters without electronic storage; B-IP - connected terminals.
• SAQ C-VT/C - virtual terminals/small processing environment, no storage.
• SAQ P2PE is only a PCI-certified P2PE solution.
• SAQ D (Merchant/Service Provider) - "wide" option for any processing/transfer/storage, custom integrations, orchestrators, etc.

Practice for iGaming: the target path is SAQ A/A-EP due to PAN-safe streams, tokenization and hosted fields. If you have your own payment services/walts - usually SAQ D or ROC.

4) Scoping: What goes into CDE and how to narrow it down

CDE (Cardholder Data Environment) - systems where card data is processed/stored/transmitted, and all connected/influential segments.

• Hosted fields/iframe/TSP - Enter PAN outside your domain.
• Tokenization and network tokens: Your services operate on tokens, not PAN.
• P2PE: end-to-end encryption with a certified solution.
• Network segmentation: hard ACLs, CDE isolation from the rest of the environment.
• Mandatory DLP and log masking, banning dumps with PAN/CVV.

In v4. 0 added flexibility of methods for achieving goals, but evidence of effectiveness and targeted risk analysis are mandatory.

5) PCI DSS v4 "12 requirements." 0 (meaning blocks)

1. Network security and segmentation (firewalls, ACL, CDE isolation).
2. Secure host/device configuration (hardening, baselines).
3. Protection of cardholder data (PAN storage - only if necessary, strong cryptography).
4. Data protection during transmission (TLS 1. 2 + and equivalents).
5. Antivirus/anti-malware and integrity control.
6. Secure development and modification (SDLC, SAST/DAST, library control).
7. Access as needed (least privilege, RBAC).
8. Identification and authentication (MFA for admin and remote access, passwords by v4. 0).
9. Physical security (data centers, offices, terminals).
10. Logging and monitoring (centralization of logs, immutability, alerts).
11. Safety testing (ASV scans quarterly, pentests annually and after changes, segmentation test).
12. Policy and risk management (procedures, training, incident-response, risk assessments, "Customized Approach" documents).

6) Mandatory activities and frequency

ASV scans (external) - quarterly and after significant changes.
Vulnerabilities/patching - regular cycles (frequencies are justified by TRA - targeted risk analysis).
Penetration tests (internal/external) - annually and after significant changes; segmentation check is mandatory.
Logs and monitoring - continuously, with retention and protection against modifications.
Personnel training - when hiring and then regularly.
MFA - for all admin and remote access to CDE.
Inventory of systems/data streams - update constantly.

7) SAQ selection matrix (short)

Only iframe/redirect, without PAN you → SAQ A.
E-commerce, your site affects the payment page → SAQ A-EP.
Terminals/imprinters → SAQ B/B-IP.
Virtual Terminal → SAQ C-VT.
Small "card" network without storage → SAQ C.
P2PE solution → SAQ P2PE.
Other/complex/storage/processing → SAQ D (or ROC).

8) Artifacts and evidence for audit

• Network and data flow diagrams, asset register, vendor register, accounting/access register.
• Policies/procedures: secure development, change management, logging, incidents, vulnerabilities, keys/crypto, remote access, backups.
• Reports: ASV, pentests (segmentation inclusive), vulnerability scans, correction results.
• Logs/alerts: centralized system, immutability, incident analysis.
• Crypto management: KMS/HSM procedures, rotations, inventory of keys/certificates.
• "Customized Approach" proofs (if applied): control objectives, method, performance metrics, TRA.
• Contours of responsibility from third parties: AoC partners (PSP, hosting, CDN, anti-fraud), Shared Responsibility matrix.

9) Compliance project (step by step)

1. Copy and Gap Analysis-Define CDE, adjacent segments, current breaks.
2. Quick wins: PAN-safe stream (iframe/hosted fields), tokenization, ban PAN in logs, close "external" crete vulnerabilities.
3. Segmentation and network: isolate CDE, mTLS, firewall-ACL, least-privilege accesses, MFA.
4. Observability: centralized logging, retention/chain of custody, alerts.
5. Vulnerability and code management: SAST/DAST, patches, SBOM, dependency control.
6. Tests: ASV scans, internal/external penetration tests, segmentation check.
7. Documents and training: procedures, IR-playbooks, trainings, training records.
8. Selection of the certification form: SAQ (type) or ROC; to be agreed with the acquirer/brands.
9. Annual cycle: support, evidence, risk/frequency review, repurposing.

10) Integration with iGaming architecture

The payment orchestrator only works with tokens; PAN can't see.
Multi-PSP: health-checks, smart-routing, idempotency, ретраи; AoC from each PSP.
Event-driven bus/DWH: no PAN/CVV; masking the last 4 digits; DLP gates in CI/CD.
3DS/SCA checks: store only the necessary artifacts (transaction IDs), without sensitive data.

11) Frequent errors

PAN/CVV logging and invalid masks.
"Temporary" PAN routing through internal APIs/buses.
Lack of a pentest segmentation test.
Unreasonable frequency of procedures (no TRA by v4. 0).
Dependence on one PSP without AoC and without fallback.
Unaccounted "influential" segments (admin-jump-hosts, monitoring, backups).

12) Fast start checklist (iGaming)

• Go to hosted fields/iframe; remove PAN input from your forms.
• Enable tokenization/network tokens; exclude PAN from events/logs.
• Perform CDE copying and segment isolation (MFA, RBAC, mTLS).
• Set up centralized logs and alerts (immutability, retention).
• Run ASV scans, eliminate critical/high.
• Perform penetration tests (internal/external) + segmentation test.
• Prepare policies/procedures and evidence of implementation.
• Agree the qualification form with the acquirer (SAQ type/ROC).
• Obtain and store AoC of all Crete vendors.
• Integrate PCI controls into the release cycle (SDLC, IaC hardening, DLP in CI/CD).

13) FAQ short

Do I need a QSA? For ROC, yes. Self-certification is often sufficient for SAQ, but many acquirers/brands may require a QSA/ASV partner.
If we don't store PAN? Still fall under PCI DSS if you accept cards. Aim to achieve SAQ A/A-EP.
Does 3DS solve PCI? No, it isn't. 3DS - about authentication; PCI - about data protection.
Is TLS enough? No, it isn't. All relevant v4 requirements are needed. 0, including processes and evidence.

14) Summary

For iGaming, the optimal strategy is to minimize the scope (PAN-safe, tokenization, hosted fields, P2PE where possible), hard segment the CDE, automate logging/vulnerabilities/penetration tests, collect a full package of artifacts and choose the correct form of confirmation (SAQ or ROC) at your level. This reduces risk, speeds integration with the PSP, and maintains stable conversion and monetization while meeting card brand requirements.