Lottery Platform Testing, Security, Certification and SLA Checklist
A practical operator checklist for independent testing, security evidence, certification coverage and service levels before signing or launching.
A lottery platform security and uptime checklist should connect each requirement to a test, an accountable owner and evidence for the release you will operate. Start with the intended product, applicable requirements, payment arrangements and contract. Commission independent work early enough to correct findings and retest. Then negotiate measurable service levels for the complete customer journey, not just a server that answers a health check.
RNG reports, penetration tests, certificates and uptime commitments answer different questions. None substitutes for the others. Use the provider evaluation checklist to compare proposals, and download the WhiteLotto Operator Decision Pack (XLSX) to record requirements, evidence gaps and decisions.
Separate testing, certification and operational assurance
Create a requirements matrix: obligation and source, component, version, environment, required standard, eligible assessor, prerequisite, deliverable and acceptance owner. Identify what supplier evidence covers and what remains specific to your deployment. Internal quality assurance supports this work but does not replace required independent assessment.
| Scope | Questions to test | Evidence to request |
|---|---|---|
| Game and RNG | Where randomness is used: generator, mapping, game rules and outcome handling. | Report identifying tested components, versions, methods and exclusions. |
| Platform and integrations | Ticket acceptance, sales cut-off, duplicate requests, settlement, result ingestion and reconciliation. | System test results for the configured integrations and failure cases. |
| Cybersecurity | Authentication, privileged access, APIs, configuration, vulnerabilities and incident handling. | Scoped assessment, findings register and independent retest evidence. |
| Payment security | Card-data flows, systems affecting those flows and divided responsibilities. | Confirmed PCI scope and the applicable validation evidence. |
| Service operation | Availability, recovery, support escalation and transaction integrity. | SLA definitions, monitoring evidence and recovery exercise results. |
The GLI standards catalogue distinguishes gaming and security assessment standards. A catalogue entry is not proof that a particular product has been certified. Confirm the exact standard and evidence accepted for your requirement; do not assume a certificate covers every configuration or use.
Select independent providers before the release window
Check relevant competence, accreditation or recognition where required, independence, conflicts, subcontractors and availability. An introduction to a laboratory does not establish its eligibility or guarantee acceptance of its report. Agree scope, methods, exclusions, input artefacts, confidentiality, permitted reliance, retesting fees and deliverables in writing.
For payments, PCI SSC describes PCI DSS as protecting payment account data, including entities that could affect the cardholder data environment. Do not equate outsourcing checkout with having no responsibilities. Map actual data flows and confirm your applicable scope and validation route with the relevant payment counterparty and qualified assessor.
Keep test results attached to the deployed version
Engineering should maintain a release manifest covering build identifiers or hashes, dependencies, configuration, infrastructure, games and integrations. Record the test environment and explain any production differences. Give assessors time-limited, logged access; minimise data and use approved secure transfer channels.
The evidence register must link each finding to its affected version, severity, owner, corrective action, temporary control, retest and closure decision. Preserve reports and adverse findings securely, including in management summaries. Security owns technical remediation; compliance checks requirement coverage; release management checks that the deployment matches the evidence. Name who may accept residual risk without overriding an external requirement.
A critical finding close to launch
If a penetration test exposes privileged account access, isolate the affected environment, assess exposure and involve security, engineering, compliance and legal owners. Correct the root cause and examine related components. Obtain independent retest evidence; do not downgrade severity to protect the date. Delay or narrow launch scope if the authorised acceptance conditions cannot be met.
Reserve time for scope questions, remediation and retesting, not just the initial assessment. A later authentication-library change can affect sessions, permissions and payment callbacks: assess its impact and ask the relevant specialists whether targeted or broader retesting is needed.
Turn uptime claims into an operational SLA
An SLA is a contract definition, not a certification. Specify covered journeys, measurement periods, monitoring locations, calculation and exclusions. Availability is commonly calculated as eligible time minus counted downtime, divided by eligible time. In an illustrative 30-day period, 99.9% allows 43.2 minutes of counted downtime. That percentage says little about an outage just before a ticket sales cut-off.
| Topic | Ask the provider |
|---|---|
| Covered service | Does availability include login, ticket confirmation, APIs and back-office access? How are partial failures counted? |
| Dependencies and exclusions | How are payment or draw-feed outages classified? What notice and limits apply to maintenance? |
| Incident response | Which severity triggers round-the-clock escalation? Are acknowledgement, updates and restoration separate targets? |
| Recovery | What are the proposed RTO and RPO for each critical service? Which exercise demonstrates them? |
| Evidence and remedies | Who receives measurements and incident reports? How are disputes, credits and repeated breaches handled? |
Recovery time objective (RTO) is the target time to restore service; recovery point objective (RPO) is the target limit on data loss measured in time. A backup schedule alone proves neither. Request observed recovery times, restored data points, prerequisites and exceptions. Numbers here are procurement examples, not WhiteLotto service commitments. Include testing and recovery responsibilities in your software pricing comparison.
Test faults and restoration, not only normal traffic
The ticket confirmation is lost
A customer submits an order but the response times out. Test whether a retry reuses the request identity, checks status and avoids a duplicate ticket or charge. Record the accepted transaction, cut-off decision and reconciliation outcome. A responsive homepage must not conceal a broken purchase journey.
A database restore succeeds but records disagree
Use an authorised isolated exercise to restore records and compare orders, payment references, balances and ticket states. Check missing or duplicated events, integration replay, audit continuity and queued work. Validate keys and dependencies are available without exposing secrets. Agree who reconciles discrepancies before reopening sales; do not create live customer transactions for the exercise.
Assemble the launch evidence pack
- Requirements matrix and assessor eligibility confirmation.
- Versioned architecture, data flows, release manifest and production-equivalence record.
- Test reports, certificates, scope exclusions, validity conditions and reliance permissions.
- Findings, remediation, independent retests and authorised residual-risk decisions.
- SLA definitions, escalation contacts, recovery results and reconciliation procedures.
- Release acceptance owners, ongoing controls and change-triggered reassessment rules.
After launch, track expiry, patching, incidents and changes to libraries, RNG, payments or infrastructure. Assess whether evidence still covers the release, even without a printed expiry date. The NIST Cybersecurity Framework supports ongoing cybersecurity risk management; a certificate is not continuous monitoring. Make responsibility allocation explicit when comparing white-label and turnkey delivery.
Frequently asked questions
Does an RNG report prove platform security?
No. It addresses its stated randomness scope, not every account, integration or operational control. It does not predict future draws.
Can an uptime promise replace recovery testing?
No. Request tested restoration and reconciliation evidence alongside defined RTO and RPO targets.
Does this checklist confirm WhiteLotto certifications?
No. Request current evidence for the proposed scope. This guide claims no WhiteLotto certification or guaranteed uptime, recovery time or data-loss limit.
Discuss the technical fit
Explore the WhiteLotto platform solution, then contact WhiteLotto for a technical fit discussion. Bring your product scope, integration inventory, evidence requirements and proposed service levels so responsibilities and open questions can be documented.
Testing is bounded and cannot guarantee security, approval or future compliance. Evidence acceptance remains with the relevant authority or counterparty; licensing and professional advice are separate workstreams. This is a technical procurement guide, not legal advice.
Adapted by WhiteLotto Team from original technical guidance by Avant-Garde Management B.V. (AGM), with additional operator-focused SLA and recovery guidance.