Kody Nexov
Published 
Original research - checked 2026-07-25
Research question
Which architecture claims can be converted into a versioned artifact, test, metric, log, or recovery exercise before platform approval?
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
| Control area | Primary anchor | Public support | Buyer evidence | Acceptance exercise | Boundary | Primary source |
|---|---|---|---|---|---|---|
| System and trust boundaries | NIST CSF 2.0 | Partial | Component, data-flow, owner, and system-of-record map | Trace one player and money flow | Architecture remains product-specific | NIST Cybersecurity Framework 2.0 |
| API and application security | OWASP ASVS 5.0 | Yes | Versioned requirements, threat model, test results, and remediation | Test auth, input, access, and error controls | Choose a risk-appropriate ASVS level | OWASP |
| Secure development | NIST SSDF 1.1 | Yes | SDLC policy, provenance, vulnerability, release, and supplier records | Trace one release from requirement to remediation | Implementation is supplier-specific | NIST SP 800-218 |
| Reliability and recovery | AWS Reliability Pillar | Yes | SLOs, dependency budgets, capacity tests, RTO/RPO, and drills | Fail a critical dependency and recover | Guidance is not a contractual SLA | AWS Well-Architected |
| Payment-data boundary | PCI DSS | Yes | Card-data flow, scope decision, segmentation, responsibility, and assessment | Trace card data and validate scope | Applicability depends on the payment design | PCI Security Standards Council |
| Gambling software controls | UKGC RTS | Yes | Market-specific control map, configuration, logs, and test evidence | Run applicable player and game control cases | Great Britain is one jurisdictional anchor | UK Gambling Commission |
| Release assurance | UKGC testing strategy | Yes | Change classification, test plan, independence, approval, and evidence retention | Rehearse one material release and rollback | Local licence obligations still apply | UK Gambling Commission |
| Cybersecurity governance | NIST CSF 2.0 | Yes | Governance, risk, protect, detect, respond, and recover ownership | Run an incident evidence exercise | Framework outcomes require local implementation | NIST Cybersecurity Framework 2.0 |
Findings
1. Architecture diagrams are only the start
Every important boundary needs a named owner, data contract, failure behavior, evidence output, and recovery route.
2. Security can be specified contractually
OWASP ASVS and NIST SSDF provide versioned verification and development language that buyers can put into requirements.
3. Reliability claims need measurement rules
Availability, scale, and resilience are not comparable without a metric source, dependency boundary, test, and remedy.
4. Jurisdiction changes the control map
The UKGC sources provide one current regulated-market anchor; they are not a universal licence checklist.
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
The crosswalk is a procurement framework, not a reference architecture or certification. It does not prove that any named platform implements a control, and it does not replace local regulatory, security, payment, or data-protection analysis.
Primary sources
- 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.
- PCI Security Standards Council - PCI DSS - Payment-account data security requirements for relevant merchants, processors, service providers, and connected systems.
- 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 Platform Architecture Research
- Use dated primary-source crosswalks and downloadable evidence matrices to turn software claims into buyer-owned verification tasks.
- iGaming Platform System Map
- Assign platform boundaries, systems of record, interface owners, acceptance evidence, and degraded-mode questions.
- iGaming platform
- Compare platform architecture, integration depth, module ownership, and operational constraints before selecting a core stack.
- affiliate platforms
- Affiliate platforms are a critical growth component for iGaming operators, acting as the technical bridge between traffic acquisition partners and backend financial systems.
- PAM iGaming platform
- Player Account Management (PAM) systems form the operational core of any iGaming platform.
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.
- 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.
- PCI Security Standards Council — PCI DSS Industry standards body. Payment account data security requirements for merchants, processors, service providers, and systems that can affect the cardholder data environment.
- 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.
