Kody Nexov
Published 
Original research - checked 2026-07-25
Research question
Which supplier assurances should become evidence schedules, tests, metrics, rights, remedies, and exit deliverables?
Methodology
- Scope: the named product sample or control areas in the evidence matrix below.
- Sources: current official supplier pages, regulators, government standards, open standards, and testing guidance.
- Classification: Yes is explicit support; Partial is incomplete support; Not found is no evidence in the reviewed public source; Unknown is not evaluated.
- Checked: 2026-07-25. This is a point-in-time public-evidence record.
- No inference: a general standard does not prove a supplier implementation, and a missing public disclosure does not prove a missing capability.
Evidence matrix
| Procurement field | Primary anchor | Public support | Evidence or clause | Verification | Boundary | Primary source |
|---|---|---|---|---|---|---|
| Service and responsibility scope | UKGC RTS and testing strategy | Partial | Versioned service, product, market, RACI, dependency, evidence, and change schedules | Trace each regulated workflow to one owner | Contract must fix supplier-specific scope | UK Gambling Commission |
| Controller and processor roles | ICO contract guidance | Yes | Processing details, instructions, confidentiality, security, assistance, audit, and end-of-contract terms | Map each dataset and processing purpose | Other privacy regimes may apply | UK ICO |
| Subprocessors | ICO contract guidance | Yes | Current list, locations, functions, authorization, flow-down, notice, and objection process | Add or replace a representative subprocessor | Commercial leverage affects remedies | UK ICO |
| Application security | OWASP ASVS | Yes | Versioned control baseline, test scope, results, remediation, exceptions, and re-test | Verify the production release candidate | Buyer chooses risk-appropriate level | OWASP |
| Secure development and provenance | NIST SSDF | Yes | SDLC, environment, source, dependency, build, release, vulnerability, and provenance records | Trace a release and a disclosed vulnerability | Framework does not certify the supplier | NIST SP 800-218 |
| Testing and release assurance | UKGC testing strategy | Yes | Change classification, independent testing, approval, rollback, and retained evidence | Rehearse one material release failure | Applicable market rules still govern | UK Gambling Commission |
| SLA and recovery | AWS Reliability Pillar | Partial | SLIs, SLOs, measurement, exclusions, dependencies, credits, incidents, RTO/RPO, and drills | Calculate one breach and execute recovery | Guidance is not a contractual promise | AWS Well-Architected |
| Data export and portability | ICO portability guidance | Partial | Schemas, formats, history, identifiers, frequency, integrity, assistance, and cost | Import a full export into a replacement environment | Legal portability and commercial exit differ | UK ICO |
| Termination and deletion | ICO contract guidance | Yes | Return, transition, deletion, backups, evidence, access revocation, and survival terms | Execute a termination tabletop and evidence request | Replacement support is negotiated | UK ICO |
| Source-code escrow | NIST SSDF | Partial | Deposit scope, dependencies, build instructions, update events, verification, release events, and licence | Independent party rebuilds a deposited release | Escrow is a contract mechanism, not a standard mandate | NIST SP 800-218 |
Findings
1. Assurance statements need evidence schedules
Security, compliance, availability, support, data, and exit promises should identify artifacts, owners, frequency, rights, tests, and remedies.
2. Data ownership is too vague on its own
Roles, purpose, access, schemas, derived data, logs, portability, retention, deletion, and assistance need separate treatment.
3. An SLA needs a measurement model
A percentage without metric source, window, exclusions, dependency boundary, incident duties, service credits, and recovery targets is not comparable.
4. Escrow works only if it is usable
Scope, dependencies, build instructions, update events, verification, release conditions, rights, and operational capability determine whether a deposit helps.
How to use the evidence
- Remove fields that are not applicable to the target entity, market, product, and operating model; document why.
- Assign one accountable owner and one evidence artifact or test to every retained field.
- Keep Yes, Partial, Not found, and Unknown separate through RFP, demo, test, reference, and contract review.
- Convert supplier-specific gaps into versioned proposal, implementation, SLA, data, security, and exit schedules.
- Re-check source versions and effective dates before a procurement or launch decision.
Limitations
This crosswalk is not legal advice or a model contract. Regulatory, privacy, intellectual-property, insolvency, employment, tax, and commercial positions vary by jurisdiction, entity, service, leverage, and governing law.
Primary sources
- UK ICO - Contracts and liabilities between controllers and processors - Controller-processor contract fields, instructions, confidentiality, security, sub-processors, assistance, audit, and end-of-contract provisions.
- UK ICO - Right to data portability - Structured, commonly used, machine-readable personal-data export principles within the right's defined scope.
- OWASP - Application Security Verification Standard - Versioned and testable web-application security requirements that can be used in procurement and verification.
- NIST SP 800-218 - Secure Software Development Framework 1.1 - Secure-development practices and a common vocabulary for software producers, purchasers, and supplier-management activities.
- NIST Cybersecurity Framework 2.0 - Cybersecurity governance, identification, protection, detection, response, and recovery outcomes.
- AWS Well-Architected - Reliability Pillar - Reliability design, failure recovery, change management, capacity, testing, and dependency-management questions.
- UK Gambling Commission - Remote gambling and software technical standards - Great Britain remote gambling software controls and current technical-standard verification questions.
- UK Gambling Commission - Testing strategy for remote gambling software - Testing, release, audit, change-control, and independent-assurance expectations for relevant Great Britain licensees.
Frequently asked questions
Does a Yes classification prove that a supplier complies?
No. Yes means the cited primary source explicitly supports the control or disclosure field. Supplier implementation still requires current product evidence and buyer verification.
Does Not found mean a capability is absent?
No. It means the reviewed public sources did not expose the evidence. Authenticated documentation, tests, proposals, or contracts may change the classification.
Can the CSV be used as an RFP starting point?
Yes, after adapting applicability, ownership, evidence, tests, and legal requirements to the target entity, jurisdiction, product, and operating model.
Concept map
Related concepts and decision guides
- iGaming Software Procurement Research
- Use dated primary-source crosswalks and downloadable evidence matrices to turn software claims into buyer-owned verification tasks.
- iGaming Vendor Due Diligence Library comparison
- Work through security, certification, payments, data, lock-in, escrow, and exit evidence before contract approval.
- How to Choose an iGaming Software Provider
- Create a repeatable provider-selection process based on evidence and operator fit.
- ISO 27001 and iGaming Provider Security control guide
- Use certification as one input while testing actual security controls and scope.
- iGaming Data Ownership guide
- Define access, permitted use, export, retention, deletion, and transition rights.
Evidence layer
Primary references and verification limits
Sources were checked on . They support the standards and verification questions used in this guide. They do not prove a supplier-specific price, market eligibility, implementation result, or private product claim; buyers should request current, versioned evidence for those points.
- UK ICO - Contracts and liabilities between controllers and processors Data-protection regulator. Controller-processor contract fields, instructions, confidentiality, security, sub-processors, assistance, audit, and end-of-contract provisions.
- UK ICO - Right to data portability Data-protection regulator. Structured, commonly used, machine-readable personal-data export principles within the right's defined scope.
- OWASP - Application Security Verification Standard Open application-security standard. Versioned and testable web-application security requirements that can be used in procurement and verification.
- NIST SP 800-218 - Secure Software Development Framework 1.1 Government standards body. Secure-development practices and a common vocabulary for software producers, purchasers, and supplier-management activities.
- NIST Cybersecurity Framework 2.0 Government standards body. Cybersecurity governance, identification, protection, detection, response, and recovery outcomes.
- AWS Well-Architected — Reliability Pillar Cloud architecture guidance. Availability targets, resilience testing, incident learning, recovery objectives, capacity, and dependency management.
- UK Gambling Commission — Remote gambling and software technical standards Regulator. Remote gambling software controls, security requirements, player-facing technical controls, and jurisdiction-specific verification questions.
- UK Gambling Commission — Testing strategy for remote gambling software Regulator. Testing, release control, audit evidence, change management, independent review, and production assurance questions.
- OWASP Application Security Verification Standard Open application-security standard. Testable web-application security requirements and procurement-ready verification criteria.
- NIST Cybersecurity Framework 2.0 Government standards body. Cybersecurity governance, risk management, protection, detection, response, and recovery outcomes.
