Card data security requirements apply to any organisation that stores, processes or transmits cardholder data. The obligation is not proportional to size, and the cost of meeting it is determined almost entirely by one variable.
That variable is scope — how much of your environment touches card data at all.
The scope principle
Systems that never see cardholder data fall outside the assessment. Systems that do fall inside it, along with anything connected to them that could affect their security.
This produces the central strategy: rather than securing a large environment to a demanding standard, arrange your architecture so that card data touches as little of it as possible.
The difference in effort between the two approaches is substantial. An operator whose card data flows through their own servers is looking at a materially different assessment from one whose systems never receive it.
How scope reduction actually works
Two mechanisms do most of the work.
Hosted payment fields. The card entry form is served by the payment provider and embedded into your page, so card details go directly from the player’s browser to the provider. Your servers never receive them. The player experiences a single page; the data path bypasses you entirely.
Tokenisation. The provider returns a token representing the stored card. Your systems store and use the token for subsequent transactions. The token is useless to anyone who obtains it, and the actual card number lives with the provider.
Together these allow recurring deposits, saved payment methods and refunds without the operator ever holding card data.
The trade-off is dependence. Tokens are provider-specific, which means changing provider or adding a second one requires either re-collecting card details from players or arranging a token migration — a real project that vendors are not always keen to facilitate.
Where scope expands accidentally
This is where operators who did the architecture correctly still end up in trouble.
Support tooling. An agent asks a player to send a photograph of their card to resolve a query. That image is now in the ticketing system, which is now in scope.
Call recordings. Where telephone support exists and card numbers are read aloud, recordings contain cardholder data. This is a well-known problem with well-known solutions, and it catches operators who never considered their call system part of the payment environment.
Log files. Debug logging that captures full request payloads during an integration problem, written to a log aggregation system with broad access. Temporary logging that nobody removed is a recurring finding.
Analytics and CRM. Card details pasted into a note field by a support agent trying to be helpful.
None of these are architectural decisions. They are operational drift, and they are why scope needs periodic re-examination rather than being established once.
Segmentation
Where systems do handle card data, network segmentation limits how far scope extends.
An environment isolated by properly configured controls keeps adjacent systems out of assessment. Segmentation that exists on a diagram but not in enforced configuration does not, and the difference is tested rather than assumed.
Your provider’s compliance is not yours
A common and expensive misunderstanding.
Using a compliant payment provider does not make an operator compliant. It reduces scope, which reduces the obligation — but the operator retains responsibility for their own environment, for how the integration is implemented, and for the operational practices around it.
Providers publish responsibility matrices setting out which controls they cover and which remain with the merchant. Reading that document is worth the half hour, because the assumption that the provider handles everything is exactly the assumption that produces gaps.
When evaluating PWP.BET casino solutions or comparable integrated platforms, the specific question is where card data enters the system, whether the platform ever receives it, and what the responsibility split is between platform, payment provider and operator. Integrated stacks vary considerably on this, and a platform that never touches card data is a meaningfully different proposition from one that stores tokens or worse.
Continuous, not annual
Validation happens periodically. The requirements apply continuously.
An environment assessed as compliant drifts — new systems added, access granted and not revoked, a temporary integration that became permanent. Operators treating this as an annual exercise are compliant on one day a year and describing themselves as compliant on the other three hundred and sixty-four.
Where a breach occurs, the question asked is whether controls were operating at the time, not whether a certificate was current.
Compliance is a floor
The honest closing point: meeting the standard is not the same as being secure.
The requirements are a baseline covering known risk categories. They do not address every attack path, and organisations have been breached while holding valid attestations.
Treating the assessment as the security programme rather than as its minimum is the mistake. It is a floor to clear, not a target to reach.
