What's the minimum vulnerability assessment cadence for an online casino?

Quarterly is the baseline for most operators — it's also the floor PCI DSS 11.3.2 sets for the external scan component if you process cards. Monthly is the right cadence if you ship platform changes fast or sit in a regulated sector like casinos, fintech, or crypto, where the estate moves faster than a calendar can track.

Does PCI DSS require a fixed scan frequency?

Requirement 11.3.2 requires a quarterly external vulnerability scan, run by a PCI SSC-listed Approved Scanning Vendor (ASV) if the deliverable has to satisfy that specific attestation. That's a compliance floor for the external surface, not a full answer to internal-surface or risk-based cadence — see the external-scope breakdown linked below for what that quarterly requirement does and doesn't cover.

What events should trigger an off-cycle vulnerability assessment, regardless of the calendar?

Five: a new feature or platform launch that adds attack surface before it's battle-tested, an infrastructure or vendor change (new host, new payment processor, new third-party integration), an M&A event or expansion into a new licensing jurisdiction, remediation verification after an incident, and a newly disclosed CVE landing in a component you run — the same logic that made an unpatched Metabase instance a live risk before it hit a KEV listing.

Does recurring vulnerability assessment replace the annual penetration test requirement?

No. Most licensing and compliance frameworks that require an annual penetration test still expect it on top of recurring VA, not instead of it — VA is breadth-first and catches drift between cycles, a pentest is depth-first and proves exploitability against your highest-value flows. Recurring VA plus one annual pentest is the pattern AnySec recommends for high-risk platforms.

Do any gaming regulators mandate a specific scan cadence?

Yes — cadence requirements vary by licensing jurisdiction, so check yours directly rather than assuming PCI DSS is the only clock running. Pennsylvania's Interactive Gaming Platform Requirements (58 Pa. Code § 809a.6) is a concrete example: it requires internal and external network vulnerability scans at least quarterly, or after any change or modification to the interactive gaming system that requires Board approval — a scan cadence rule that has a change-triggered clause built in, not just a calendar one.

How often should an online casino run a vulnerability assessment?

The short answer

Quarterly is the realistic floor for an online casino's vulnerability assessment cadence — it's the minimum PCI DSS 11.3.2 sets for external scanning if you process cards, and the baseline AnySec recommends for any regulated, internet-facing platform. Faster-moving operators, or platforms in a licensing jurisdiction with an explicit scan mandate, should run monthly. But calendar cadence only answers half the question: a new feature launch, an infrastructure or vendor change, an M&A event, or a security incident should each trigger an assessment on its own, independent of where you are in the quarterly cycle.

Who this decision is for

This is written for the person who has already decided to run a Vulnerability Assessment — not choosing between VA and a pentest, which is a separate decision covered in vulnerability assessment vs penetration testing for iGaming — and now has to set or defend a recurring cadence. That's usually a CISO or Head of Security setting a scan schedule for the first time, defending an existing schedule to a board or auditor, or deciding whether a one-off engagement should become a recurring one.

It's not for you if you're still defining what an assessment covers. Scoping an external vulnerability assessment for a casino covers what gets scanned and where an external-only scope's evidence runs out; this post assumes that scope question is settled and answers a different one — how often to run it.

The calendar floor: what regulators and standards actually require

Two concrete, checkable minimums, plus the AnySec baseline:

Requirement	Cadence	What it covers
PCI DSS 11.3.2	Quarterly	External-facing scan, if you process card payments — must be performed by a PCI SSC-listed ASV if the deliverable needs to satisfy that specific requirement
Pennsylvania 58 Pa. Code § 809a.6 (Interactive Gaming Platform Requirements)	Quarterly, plus after any Board-approved change or modification	Internal and external network vulnerability scans, with quarterly verification submitted to the Board
AnySec recommended baseline	Quarterly minimum, monthly for fast-changing or regulated platforms	Full external-plus-internal estate, manually validated

The Pennsylvania rule is worth calling out specifically because it does something PCI DSS 11.3.2 doesn't: it builds a change-triggered clause directly into the regulatory cadence, not just a calendar one. That's the same logic a risk-based cadence should follow even where the letter of the law only asks for quarterly.

Licensing requirements are not uniform across jurisdictions — treat any specific number here as one concrete data point, not a substitute for checking what your own regulator requires.

Beyond the calendar: five risk-based triggers

A calendar cadence catches drift over time. It doesn't catch the moment your risk actually changed. Five events should move a scan off-cycle regardless of where you are in the quarter:

A new feature or platform launch. New attack surface — a new cashier flow, a new API, a new affiliate integration — is riskiest in the window before it's been battle-tested, not three months later when the next scheduled scan happens to reach it.
An infrastructure or vendor change. A new hosting provider, a new payment processor, a new third-party analytics or BI tool — each one is a new set of assumptions about what's exposed, and the kind of internet-facing internal tool CVE-2026-72898 in Metabase showed can carry production database credentials without anyone flagging it as in-scope.
M&A, or expansion into a new licensing jurisdiction. Acquired platforms and newly-licensed markets both mean estate you haven't assessed yet, on someone else's patch cadence.
Post-incident remediation verification. A scan that only confirms the specific finding was fixed misses whatever else changed during incident response; a full re-scan verifies the fix actually held.
A CVE lands in a component you run. Not every disclosure warrants an unscheduled scan, but one in a component you can confirm is deployed — especially one heading toward a KEV listing — is exactly the kind of event a purely calendar-based cadence structurally can't react to in time.

What a mature cadence looks like over time

Cadence isn't static — it should track how the platform matures:

Starting cold: a single external VA to establish a baseline before committing to a recurring schedule.
Established, standard risk: quarterly, matching the PCI DSS floor and giving four checkpoints a year to catch drift.
Fast-changing or regulated (casinos, fintech, crypto): monthly, because the estate moves faster than a quarterly cycle can track.
High-risk platforms generally: recurring VA on whichever of the above cadences fits, plus one annual penetration test — VA catches breadth and drift, the pentest proves exploitability against the flows that actually matter.

What you get each cycle

A Vulnerability Assessment engagement runs 3–5 business days per cycle, with a quarterly or monthly recurring option, and produces a prioritized, de-duplicated findings list ranked by real exposure rather than raw CVSS, concrete remediation guidance per finding, and an audit-ready summary formatted for a regulator, payment partner, or internal audit trail. Every automated hit is manually verified before it reaches the report — findings volume doesn't compound just because the cadence does.

Limitations

This is a cadence framework, not a scoping decision. It doesn't tell you whether to run VA or a pentest — that's already covered — or what an external assessment specifically checks — also already covered.
Regulatory minimums are jurisdiction-specific. The two cited here (PCI DSS, Pennsylvania) are concrete examples, not a survey of every licensing regime; confirm your own regulator's requirement directly.
More frequent scanning without remediation capacity doesn't add security — it adds backlog. A monthly cadence only helps if findings get triaged and fixed between cycles; otherwise it just produces more unread reports faster.
Cadence doesn't substitute for depth. No scan frequency, however tight, replaces the goal-driven testing a penetration test does against your cashier, wallet, or auth flows specifically.

Decision framework and next step

Quarterly is the floor. Move to monthly if you ship fast or sit in a regulated sector. Layer the five risk-based triggers on top of whichever calendar cadence you land on, regardless of when the next scheduled scan falls. Add one annual penetration test if the platform is high-risk. If you're not sure which of those applies to your platform, tell us your estate and current schedule and we'll help you set — or defend — the right cadence.

Sources and review

Pennsylvania's quarterly-plus-change-triggered scan requirement is cited to 58 Pa. Code § 809a.6, System requirements, the Commonwealth's own published code. The PCI DSS 11.3.2 quarterly external-scan requirement is cited to the PCI Security Standards Council's own Approved Scanning Vendor program page, the same source used in the external-scope post linked above. Author: AnySec Engineering. Published 2026-08-19.