B2B Supplier Licence
For technology and content suppliers: platform modules, games, RNG, back-office tooling, hosting/security and compliance tooling. This page outlines supplier obligations and the evidence artefacts used to prove control maturity.
What reviewers want
Proof of security controls, change discipline, testing evidence, and traceable logs.
Fast path files
Clear SDLC + change control + pen test evidence + auditability and retention.
Delay triggers
Weak logging, vague hosting responsibility, and missing version control discipline.
Scope (what Supplier covers)
Supplier scope is about building and operating reliable systems with defensible controls.
Platform / modules
Wallet modules, game aggregation, payments modules, back-office tools.
Content / RNG
Games content, RNG logic, fairness testing, configuration controls.
Hosting / security
Infrastructure security, access control, monitoring, incident response.
Boundary rule
If your Operator client uses your platform, you must still provide auditability, version traceability, change control, and evidence of security posture for services under your control.
Supplier compliance workflow (diagram)
Build → test → deploy → monitor → evidence. Repeat with strict change discipline.
Key control domains (Supplier)
Supplier reviews focus on security, auditability, and traceability across the SDLC.
Security controls
Access control, segmentation, monitoring, incident response, vulnerability management.
SDLC discipline
Version control, code review, release gates, change tickets, rollbacks.
Testing packs
Test cases, results, regression evidence, RNG/fairness testing where applicable.
Audit logging
Admin actions, config changes, deployments, access logs, alert logs and retention.
Outsourcing
Cloud providers, subcontractors, SLAs, audit rights, monitoring and exit plans.
Data protection
Data inventory, encryption, backups, access review, retention and deletion controls.
Evidence pack (starter list)
A baseline evidence list for Supplier applications.
| Area | Artefacts | Owner |
|---|---|---|
| Security posture | Security policy set, IAM model, monitoring overview, incident plan, vulnerability process. | Security |
| Pen test / assessments | Penetration test report (recent), remediation plan, status tracking, retest evidence. | Security |
| SDLC & change | Release process, change tickets, approvals, rollback plan, version mapping. | Engineering |
| Testing packs | Test cases, execution results, regression packs, performance tests (if relevant). | QA |
| Audit logging | Log schema, sample logs (redacted), retention settings, access review evidence. | Engineering |
| Outsourcing & vendors | Vendor register, due diligence pack, SLAs, audit rights clauses, exit plan. | Operations |
Packaging standard
Provide a version table mapping releases to controls, plus an evidence index linking every artefact to the relevant domain.
Clarification triggers (avoid these)
Supplier delays usually happen due to missing auditability and weak change discipline.
No log evidence
Claims of logging without sample logs and retention settings.
Vague hosting responsibility
Unclear who owns security controls in shared infrastructure.
Weak change control
No tickets, approvals, or release gates documented.
Old pen test
Assessments outdated or no remediation and retest evidence.
No traceability
No mapping of versions → environments → controls → evidence.
Vendor gaps
No SLAs, audit rights, monitoring or exit plan for vendors.
For overall timing ranges, see Processing Timelines.