What makes a vulnerability assessment for an online lottery different from one for a casino?

The asset list. A lottery adds retailer or agent terminals, partner and aggregator APIs, draw-management tooling, result-publication systems and a winner or payout back office. Many of these are not on the public website, so an assessment scoped only to the main domain misses most of what an attacker could reach.

Should the draw system itself be scanned?

Only if the owner of the draw agrees in writing, with named windows, rate limits and a stop contact. Draw tooling is high consequence and often fragile. Many operators scan a staging copy, or scan the management network from a defined position, and leave certified random number components out of scope entirely.

How often should a lottery run a vulnerability assessment?

Tie it to change and to the calendar rather than to a fixed month. Re-assess after a platform release, a new retailer or partner integration, a change of cloud or edge provider, and before large jackpot periods. Run it far from a real draw window, not close to one.

Who should receive the findings?

Give each finding an owner by asset class: web and API, retailer channel, payments, draw operations and infrastructure. A single list sent to one team stalls, because the fix for a retailer terminal is not the fix for a result page, and the draw owner must approve anything that touches the draw environment.

Vulnerability Assessment for an Online Lottery: Scope

The short answer

A vulnerability assessment for an online lottery should start from an asset inventory, not from the website's domain. The exposure that matters includes retailer or agent terminals, partner APIs, draw-management tooling, result pages and the payout back office. Scope each group with its own owner, rate limits and scan window, and keep random number and draw certification out of scope.

Who this is for

This is for a CTO, head of security or compliance lead at an online lottery operator, or at an iGaming company that runs lottery products, who is buying or commissioning a vulnerability assessment. It does not repeat general casino guidance; for that read scoping an external vulnerability assessment for a casino. The same inventory-first idea for a live-session product is in Vulnerability Assessment for an Online Poker Room. The exploitation-side view of the same draw cycle is in online lottery penetration testing.

Why the website is the smallest part of the scope

A vulnerability assessment finds known weaknesses, exposed services and misconfigurations across a defined list of assets. That makes the list the product. If the list is only the consumer website, the report will be accurate and almost useless, because a lottery runs on systems that the website barely touches.

A lottery typically has four groups of assets that an ordinary online business does not:

Retailer and agent channels. Terminals, retailer portals and batch submission endpoints that sell or validate tickets on the operator's behalf. They are numerous, often managed by third parties and rarely in the operator's own asset register.
Partner and aggregator integrations. Other platforms that resell tickets, supply results or deliver payments, each exposing an API or callback endpoint.
Draw and result tooling. The systems that close sales, run or record a draw, and publish a result. They have few users and very high consequence.
Winner and payout operations. The back office where winners are identified, verified and paid, which holds personal and financial data.

Each group has a different owner, a different tolerance for scanning and a different fix path. A scope that treats them as one list produces one report that nobody can act on.

A dark counter with a row of tagged lottery retailer terminals in front of a draw console and a ball machine, with one terminal showing a green status light — An assessment can only find weaknesses on devices someone has listed: every terminal needs a tag, an owner and a place in the scope before the first scan.

Build the inventory first

Most surprises in a first assessment are assets the operator did not know were reachable. Before scanning anything, build the list from several directions and reconcile them:

From the business. Ask product, retail operations and partner management which channels sell tickets and which providers integrate. This finds the retailer and aggregator endpoints that engineering may not own.
From the network. Domains, subdomains, IP ranges, certificates and cloud accounts that belong to the operator or to its providers. Retired campaign sites and old result microsites are common leftovers.
From the vendors. The list of third parties that host, run or integrate any lottery function, and what each exposes to the internet.
From the draw calendar. Which systems are active before a cutoff, during a draw and after a result, since "unused" assets are often only unused for most of the week.

Differences between these lists are the first findings of the assessment, and they cost almost nothing to produce.

The scope matrix

Use this as a structure to fill in with your own architecture and providers. It contains no thresholds, scan rates or performance claims; those must come from your own environment and your provider's terms.

Asset group	What to include	Scan approach	Needs approval from	Findings go to
Public site and result pages	Domains, TLS, web server and framework versions, exposed admin paths	Unauthenticated and authenticated, off-peak	Web or edge team	Web engineering
Player accounts and APIs	Login, registration, ticket purchase and history endpoints, API gateways	Authenticated with test accounts, low rate	Product and security	API team
Retailer and agent channels	Portals, batch endpoints, terminal management interfaces	Only the operator's side, with agreed windows	Retail or channel manager, plus the third party where they run it	Channel owner
Partner and payment callbacks	Aggregator APIs, provider webhooks, signature handling	Configuration and exposure review, no load	Payments engineering and each partner	Payments engineering
Draw and result tooling	Management interfaces, administration hosts, publication pipeline	Staging copy or restricted network position, written window and stop contact	Draw-operations owner	Draw operations with infrastructure
Winner and payout back office	Admin panels, case tools, document storage	Authenticated, off-peak	Compliance and finance	Back-office owner
Cloud accounts and hosts	Public storage, open ports, patch level, exposed management services	Configuration review and non-intrusive scan	Infrastructure	Infrastructure

The most valuable column is "Needs approval from". A scanner pointed at a draw management interface without the draw owner's agreement is a risk to the draw, not a security control.

Treat the draw environment with care

Draw tooling is the one place where an assessment can do harm. Scans can slow, lock or crash fragile software, and a draw has a published time that cannot move because a test went badly. Three rules keep this safe:

Never scan near a real draw window. Agree calendar exclusions in writing, covering the hours before a cutoff, the draw and the result release.
Prefer a staging copy or a restricted position. Where a faithful non-production copy exists, assess it. Where it does not, scan the management network from a defined internal position at low intensity, with the draw owner watching.
Name a stop contact. One person who can halt the scan immediately, reachable throughout the window, with the authority to say stop.

If any of these cannot be agreed, put that asset in a "reviewed by configuration only" row of the scope and record why. An honest limitation is better than a risky scan.

What stays out of scope

Be explicit about exclusions so nobody assumes more assurance than the work provides:

Random number generation and draw certification. These are tested by specialist certification processes. A vulnerability assessment says nothing about whether a draw is fair.
Exploitation. A vulnerability assessment identifies and rates weaknesses. Proving that a weakness is exploitable, and chaining several, is penetration testing, and the difference is set out in vulnerability assessment vs penetration testing for iGaming.
Systems you do not control. A retailer's own network or a partner's platform needs that party's written authorisation. Without it, record the interface you can see and leave the rest.
Denial-of-service testing. Load against production or against a provider's shared network is not a scan. If you want to exercise availability, that is a separate, authorised DDoS stress test.

Turn findings into decisions

A lottery has more owners than most operators expect, so prioritisation must show who acts, not just how severe something is. For each finding record the asset group, the owner, whether it touches the draw or the cashier path, and whether the fix needs a change window around the draw calendar.

Two ordering rules help:

Exposure on the revenue and draw paths first. A weakness on a ticket purchase endpoint or a draw management interface outranks the same weakness on a marketing page, even if the scanner scores them equally.
Known-exploited issues first. Public catalogues of vulnerabilities that are being exploited, such as the CISA Known Exploited Vulnerabilities list, are a good tie-breaker when many findings compete for the same fix window.

Some fixes cannot wait for the next release, such as an exposed administration interface. Others, such as a retailer terminal firmware update, may need weeks and a third party. The report should say which is which, and what compensating control, such as a network allow-list, applies in the meantime.

Keep it current

A lottery changes its attack surface when it adds a retailer network, switches a payment provider, launches a new draw product or moves hosting. Treat these events as triggers for a targeted re-assessment of the affected asset groups, not as items for the annual calendar. Between full assessments, keep the inventory live: a new subdomain or a new partner callback should enter the register the day it is created, with an owner. The monitoring side of the same cycle is in Managed SOC for an online lottery, and the hardening that follows from a finding is described under security hardening.

Limitations

This article is not legal or regulatory advice and does not state what any licensing authority requires for lottery security testing, vendor oversight or draw systems. It uses no external statistics or incident case studies. The matrix is a design hypothesis to adapt to your own platform, retailer model and providers. A vulnerability assessment is a point-in-time view of known weaknesses on listed assets; it does not find unknown flaws, does not prove exploitability and does not certify a draw.

Decision and next step

If you can name every asset group, its owner, its approval step and its scan window, you are ready to ask for a quote. If you cannot, the inventory and the draw-environment rules are the first things to write down. Request an asset-scope quote from AnySec and we will map your retailer, partner and draw assets to a scope with owners, windows and exclusions.

Sources and review

The structure follows public guidance: NIST SP 800-115 Technical Guide to Information Security Testing and Assessment and the CISA Known Exploited Vulnerabilities Catalog, read 2026-11-12; check the current versions. AnySec prepared the lottery-specific matrix from the public structure of lottery operations; no AnySec-original statistics are used. Author: AnySec Engineering. Published 2026-11-12; reviewed by the AnySec security team.

Frequently asked questions

What makes a vulnerability assessment for an online lottery different from one for a casino?: The asset list. A lottery adds retailer or agent terminals, partner and aggregator APIs, draw-management tooling, result-publication systems and a winner or payout back office. Many of these are not on the public website, so an assessment scoped only to the main domain misses most of what an attacker could reach.
Should the draw system itself be scanned?: Only if the owner of the draw agrees in writing, with named windows, rate limits and a stop contact. Draw tooling is high consequence and often fragile. Many operators scan a staging copy, or scan the management network from a defined position, and leave certified random number components out of scope entirely.
Does a vulnerability assessment cover random number generation or draw certification?: No. Those are assessed by separate certification processes. A vulnerability assessment looks for known weaknesses, exposed services and misconfigurations on the systems around the draw, and it neither proves nor changes the fairness of a result.
How often should a lottery run a vulnerability assessment?: Tie it to change and to the calendar rather than to a fixed month. Re-assess after a platform release, a new retailer or partner integration, a change of cloud or edge provider, and before large jackpot periods. Run it far from a real draw window, not close to one.
Who should receive the findings?: Give each finding an owner by asset class: web and API, retailer channel, payments, draw operations and infrastructure. A single list sent to one team stalls, because the fix for a retailer terminal is not the fix for a result page, and the draw owner must approve anything that touches the draw environment.