Scoping a penetration test for an online casino

The short answer

Scoping a penetration test for an online casino means fixing five things before an engineer touches your stack: which of external, internal, and application layers are in scope, a signed Rules of Engagement (RoE) naming targets and stop conditions, which casino-specific assets — cashier, KYC/back office, bonus engine — are named individually rather than lumped into "the platform," which tier of depth and duration you're buying, and what the report and retest actually include. Get those five answers and the quote you receive will match the test you actually need, not a generic web-app engagement with a casino logo on the cover page.

Who this is for

This is written for whoever signs the statement of work — a Head of Security, a CISO, or a platform owner at an online casino or sportsbook who has been told by a licensing regulator, a payment provider, or their own risk committee to "get a penetration test done" and now has to turn that into a scoped, priced engagement.

It is not for you if what you actually need is broad, recurring coverage across a wide or fast-changing estate — that's the job of a vulnerability assessment, not a pen test, and we cover when each applies in vulnerability assessment vs penetration testing for iGaming. It's also not a substitute for day-to-day monitoring: a pen test proves what an attacker can do on the day it runs; a managed SOC is what watches for that same attacker every other day of the year.

What's actually in scope

"Penetration test our casino" is not a scope — it's a wish, and vague scopes are how operators end up paying for a generic external-network test that never touches the systems that actually carry financial risk. A properly scoped engagement names each layer and, within it, each casino-specific asset:

External network — perimeter, web servers, firewalls, and public API endpoints. This is table stakes and every vendor covers it; it's rarely where the real risk lives.
Internal network — lateral movement paths, Active Directory attack chains, and privilege escalation from a foothold to a domain-level compromise. For an operator running back-office, KYC, and reporting systems on an internal domain, this is where a single foothold turns into full account-data exposure.
Application layer — the web and mobile clients (iOS / Android), tested against the OWASP Mobile Application Security Verification Standard (MASVS) where mobile is in scope, plus the server-side logic behind them.

Within those layers, the assets that decide whether a casino pentest actually earned its price tag are the ones a generic scope statement tends to omit by naming only "the platform":

Asset	Why it belongs in scope by name
Cashier / wallet API (deposit, withdrawal)	Where an authenticated session turning into an unauthorized fund movement does the most damage — see credential stuffing against casino cashiers for how attackers already target this endpoint with valid-looking requests
Bonus / promotions engine	Business-logic abuse here (replay, negative-value exploitation) produces losses a vulnerability scanner will never flag, because every individual request looks well-formed
KYC / AML back-office panel	Often the least-tested surface because it's internal-facing, and the one that decides whether a compromised account can complete a withdrawal at all
Affiliate portal	Frequently forgotten as "not really part of the platform," and frequently internet-facing with weaker authentication than the player-facing site
Player auth and session handling	Decides whether a stolen or replayed session survives to a funded action — the chain why we still do pure-manual penetration testing covers in more depth

Naming these individually in the RoE — rather than trusting "full platform coverage" in a sales deck — is what turns the scope into something a tester can actually be held to.

The Rules of Engagement question every operator asks

Before signing, every operator asks some version of: "how do we know this won't take down production during a live betting window?" The answer lives in the RoE, not in a verbal assurance:

A named target list, not "the whole platform" — so testing effort goes to the assets above instead of spreading thin across low-risk surface.
A defined testing window, agreed in advance, so a chained-exploitation test against the cashier doesn't collide with a real settlement run.
A named contact on both sides with the authority to pause testing immediately if something unexpected happens — a phone number, not a ticket queue.
Explicit authorization boundaries — what's in scope for exploitation versus what's flagged and left untouched (production financial transactions are typically tested against a segregated account, not live player balances).

Licensing regimes for online casinos and sportsbooks commonly require evidence of a recent, independent penetration test as a condition of maintaining the license — which is why the RoE and the final report both need to hold up to regulator and auditor scrutiny, not just internal sign-off.

How the engagement runs

Once the RoE is signed, the sequence is what separates an authorized penetration test from testing activity that happens to be invoiced:

Step	What happens
1. RoE and scope definition	Targets, timing, authorization boundaries, and stop conditions signed before any exploitation begins
2. Reconnaissance and attack-surface mapping	External, internal, and application surfaces enumerated against the named scope — including the cashier, bonus, and back-office assets called out above
3. Manual exploitation with chained vulnerabilities	Senior engineers test by hand, deliberately looking for the multi-step chains — a session bug plus a bonus-replay bug plus a missing step-up check — that automated scanners test in isolation and miss
4. Post-exploitation impact analysis	Every successful exploitation path is traced to a business outcome: account takeover, unauthorized withdrawal, or data exposure, not just "endpoint vulnerable"
5. Report drafting	Executive summary plus a developer-actionable technical report with reproduction steps, written for both your board and your engineers
6. Retest	Fixes are validated against the same technique that found them, by the same engineer

This is 100% manual delivery by design — the same reasoning covered in why we still do pure-manual penetration testing: automated tooling scales reconnaissance, but the chained business-logic findings that matter for a casino only surface when a senior engineer reads the application and decides what to test next.

What drives the cost

Penetration testing pricing varies with scope depth and duration, not with a flat day rate, which is why "how much does a casino pentest cost" only has an honest answer once scope is fixed. Three tiers cover most operators:

Tier	Price	Duration	Scope
Focused	€2,499 per engagement	Up to 5 days	One target — a single web or mobile app, or one external/internal network
Standard	€5,999 per engagement	Up to 10 days	Full-stack — external + internal + one application + one mobile app, plus a purple-team debrief with your blue team
Continuous	€12,000 per quarter	Ongoing	Quarterly full-stack cycle with out-of-band micro-engagements between cycles — fits fast-moving platforms that ship weekly

The variable that moves an operator between tiers is rarely the size of the network — it's whether the cashier, bonus engine, and back-office panel need to be tested as named, chained targets (Standard) or whether a single high-priority asset needs deep coverage on a tighter budget (Focused). Platforms that ship new features on a weekly cadence tend to outgrow a once-a-year engagement regardless of tier, which is where the Continuous cycle earns its price over three separate Focused engagements booked reactively.

What you walk away with

A properly scoped penetration test for an online casino produces:

An executive summary naming business risk in plain language for stakeholders who won't read a CVSS table — what a real report should contain is covered in what a real pentest report looks like.
A technical report with reproduction steps a developer can follow without messaging the tester.
Per-finding remediation guidance, at the code or configuration level, not "adopt secure coding practices."
A retest, confirming the fix closes the exact technique that found it — not just a rerun of the same automated scan.

None of these is "we tested it and nothing broke." A clean initial pass with no critical findings is still evidence — but only if the scope and RoE that produced it are documented well enough for a regulator or payment partner to trust the negative result.

Limitations — what this doesn't replace

A penetration test proves what an attacker can do against the named scope, on the day it runs, at the depth the tier bought. It is not a substitute for a vulnerability assessment if what you actually need is wide, recurring coverage across a large or changing estate — that's a different engagement with a different cadence, covered in vulnerability assessment vs penetration testing for iGaming. It is also not continuous monitoring: a clean report on Monday says nothing about the code shipped on Friday, which is what a managed SOC exists to catch between engagements. And a pen test that skips the casino-specific assets above in favor of "full platform coverage" on paper will produce a report that satisfies a compliance checkbox without ever testing the systems that carry real financial risk.

How to decide you're ready to scope one

Bring three things to the scoping call: which assets actually carry your financial and licensing risk (rarely just "the homepage"), which tier matches your release cadence and budget, and any regulator or payment-partner requirement that names specific test types or timing. If you can't answer all three yet, that gap is the actual starting point, not a reason to wait. Tell us your platform and scope and we'll turn it into a signed RoE, a tier recommendation, and a cost estimate before any testing begins.

Sources and review

This guide reflects AnySec's Penetration Testing engagement methodology and standard industry scoping practice as codified in the Penetration Testing Execution Standard and the OWASP Web Security Testing Guide. Author: AnySec Engineering. Published 2026-08-05; last reviewed 2026-08-05.