An online casino can be technically stable and still be exposed if no one can answer a simple question: which outside companies can affect player funds, personal data, game availability, regulatory standing or brand reputation?
That is the job of an iGaming third-party risk register. It turns a scattered vendor list into an operating control. Instead of asking compliance, finance, product and engineering to remember vendor risks from memory, the register gives your team one place to see who you rely on, what they touch, how risky they are, what evidence you have and what still needs action.
For casino operators, this is not just procurement housekeeping. A payment gateway outage can stop deposits. A weak affiliate can create misleading promotions in restricted jurisdictions. A game aggregator misconfiguration can expose games where they are not approved. A KYC vendor issue can slow onboarding or weaken AML controls. The register helps you see those dependencies before they become incidents.
What is an iGaming third-party risk register?
An iGaming third-party risk register is a structured record of external vendors, partners and service providers that support your online casino operation, with a risk assessment attached to each one.
It is more detailed than a vendor inventory. A vendor inventory answers, “Who do we work with?” A risk register answers, “What can go wrong through this relationship, how serious would it be, what controls are in place and who owns the next step?”
For an online casino, the register should cover more than obvious software vendors. It should include payment processors, crypto onramp providers, wallet or custody partners, KYC and AML vendors, fraud tools, game aggregators, studios, affiliate networks, hosting providers, support tools, analytics tools and any third party with access to regulated workflows, player data, funds or production systems.
If you need the broader operating model around onboarding, due diligence, monitoring and contract controls, Spinlab’s casino vendor risk management framework is a useful companion. This guide focuses on the register itself, the artifact your team should maintain week after week.
Why casino operators need a dedicated register
General third-party risk practices are useful, but iGaming has a different risk shape. Vendors do not just support internal operations. They can directly affect player protection, financial flows, jurisdictional compliance, game fairness, bonus abuse, AML monitoring and uptime during peak play.
Regulators also tend to view outsourcing as delegation, not as a transfer of accountability. In Great Britain, the Gambling Commission’s Licence Conditions and Codes of Practice include obligations around responsibility for third parties. In privacy, the EU GDPR’s Article 28 processor requirements require appropriate contractual terms when a processor handles personal data on behalf of a controller. The details vary by market, but the pattern is consistent: operators need to know what vendors do and how they are controlled.
A well-built register helps you:
- Prepare licensing and audit evidence faster
- Spot concentration risk across critical vendors
- Track expiring documents, contracts and certifications
- Prioritize due diligence on vendors that matter most
- Link incidents to affected third parties
- Decide when a vendor needs remediation, exit planning or executive acceptance
It also creates a common language between compliance, technology, payments and commercial teams. Without that language, one team may treat a vendor as low risk because the contract is small, while another team knows the same vendor has production API access or handles sensitive player data.
Define the scope before you open a spreadsheet
The first mistake is starting with columns before deciding what belongs in the register. For iGaming, your scope should be based on operational dependency and regulated impact, not only annual spend.
A small SaaS tool used by your VIP support team may hold personal data. A niche affiliate can create regulatory exposure if it sends traffic through non-compliant advertising. A game studio may have no access to player accounts, but its content availability, certification status and jurisdictional restrictions still matter.
Use these scope questions to decide whether a third party belongs in the register:
- Does it process, store or transmit player personal data?
- Does it touch deposits, withdrawals, chargebacks, crypto assets or settlement data?
- Does it influence KYC, AML, fraud prevention or responsible gambling controls?
- Does it provide games, game aggregation, RNG content, live casino access or bonus logic?
- Does it have API, admin, production, reporting or support access?
- Could its failure interrupt player onboarding, payments, gameplay or withdrawals?
- Could its marketing, content or traffic practices create regulatory exposure?
If the answer to any of these is yes, the vendor should be recorded. Not every vendor needs the same review depth, but leaving them out creates blind spots.
Core fields for an iGaming third-party risk register
A practical register can live in a GRC system, database, backoffice workflow or controlled spreadsheet. The tool matters less than consistency. Every record should be complete enough that a new risk owner can understand the vendor relationship without digging through old email threads.
Use this table as a minimum viable template.
| Register field | What to capture | Why it matters |
|---|---|---|
| Vendor name and legal entity | Trading name, legal name, registration number if available | Avoids confusion between brands, subsidiaries and resellers |
| Service category | PSP, game aggregator, KYC, AML, affiliate, cloud, support, analytics | Helps compare similar vendors and identify concentration risk |
| Business owner | Internal person accountable for the relationship | Prevents orphaned vendors with no clear decision maker |
| Technical owner | Internal person accountable for integration, access and changes | Keeps API, system access and operational issues visible |
| Jurisdictions supported | Markets where the vendor is used or promoted | Essential for licensing, content rules and marketing restrictions |
| Regulated function | Payments, identity verification, AML, game delivery, responsible gambling, marketing | Shows where the vendor touches compliance obligations |
| Data processed | No personal data, basic account data, documents, payment data, behavioral data | Drives privacy, security and contract requirements |
| Funds exposure | None, transaction routing, settlement, custody, refunds, crypto wallet access | Identifies vendors that can affect player money |
| System access | API access, admin access, SSO, production access, reporting access | Links the vendor to security and incident response controls |
| Criticality tier | Low, medium, high or critical | Determines review depth and approval level |
| Inherent risk score | Risk before controls | Helps prioritize due diligence and contract negotiation |
| Key controls | Certifications, SLAs, audit rights, encryption, monitoring, approvals, whitelists | Shows how risk is reduced |
| Evidence location | Links to contracts, certificates, policies, test reports, insurance and assessments | Makes audits and renewals faster |
| Residual risk score | Risk after controls are considered | Supports acceptance, remediation or exit decisions |
| Open actions | Missing evidence, contract clauses, access cleanup, control gaps | Turns the register into a workflow, not a static list |
| Review date | Last review and next review | Keeps monitoring current |
| Trigger events | Renewal, new market, new integration, breach, ownership change, SLA failure | Forces reassessment when the risk profile changes |
| Decision status | Approved, conditionally approved, rejected, suspended, offboarding | Gives teams a clear operating decision |
The register should also record material fourth parties where possible. For example, if your PSP relies on an acquiring bank or your live casino supplier relies on a streaming infrastructure provider, you may not have a direct contract with those companies, but you should still understand the dependency when it is material.
Build a risk scoring method that fits casino operations
A risk register becomes useful when records can be compared. The scoring does not need to be complex, but it must be consistent.
Start with three concepts:
| Score type | Meaning | Simple method |
|---|---|---|
| Inherent risk | Risk before considering controls | Impact multiplied by exposure |
| Control strength | How well current controls reduce risk | Weak, moderate or strong |
| Residual risk | Risk after controls are considered | Inherent risk adjusted by control strength |
Impact should reflect what the vendor could affect if something goes wrong. Exposure should reflect how deeply the vendor is connected to your operation. A KYC provider with document access and onboarding impact usually has higher exposure than a design contractor. A crypto onramp provider may carry payment, AML, custody and reputational dimensions at once.
For more detail on likelihood and impact scoring, Spinlab’s guide to building a risk matrix for online casinos can help you standardize the model.
A simple tiering system is enough for most operators at launch.
| Tier | Typical characteristics | Example vendors | Suggested review cadence |
|---|---|---|---|
| Critical | Can stop core casino operations, affect player funds or create major regulatory exposure | PSP, crypto onramp, custodial wallet provider, game aggregator, KYC and AML provider, primary cloud provider | Quarterly or on material change |
| High | Handles sensitive data, supports regulated workflows or has privileged system access | Fraud tool, affiliate platform, CRM with player data, live casino provider, payment orchestration vendor | Twice per year or on material change |
| Medium | Supports operations with limited data or limited production impact | Email vendor, analytics tool, customer support add-on, localization vendor | Annually or on material change |
| Low | No sensitive access and low operational dependency | Office tools, general marketing design supplier, low-risk content provider | At onboarding and renewal |
The cadence is a governance choice, not a universal rule. A startup operator may review critical vendors monthly during launch, then move to quarterly once controls mature. The key is to make the cadence explicit in the register and follow it.
Add iGaming-specific fields by vendor type
A generic SaaS vendor questionnaire will miss casino-specific exposure. Your register should include custom fields or linked sub-assessments for the vendor categories that carry the most risk.
| Vendor type | Extra fields to add | Risk questions to answer |
|---|---|---|
| Payment gateway or PSP | Supported payment methods, settlement currencies, chargeback process, PCI DSS status, restricted countries, incident contact | Can the vendor interrupt deposits or withdrawals? Are settlement flows transparent and auditable? |
| Crypto onramp or custody partner | Wallet model, custody responsibilities, supported assets, blockchain analytics controls, sanctions screening, withdrawal controls | Who controls funds, keys and screening decisions? What happens during a frozen transaction or wallet incident? |
| KYC, AML or fraud vendor | Data sources, match logic, false positive process, audit logs, data retention, manual review workflow | Can decisions be explained to compliance teams and regulators? Are alerts and overrides traceable? |
| Game aggregator or studio | Jurisdictional game availability, certification evidence, RTP documentation, release process, outage handling, content restrictions | Are games only available where allowed? Can new games be blocked until approved? |
| Affiliate or traffic partner | Traffic sources, sub-affiliates, marketing claims, geo targeting controls, responsible gambling messaging, brand bidding rules | Can the partner create misleading promotions or send restricted traffic? |
| Hosting, CDN or infrastructure | Data residency, uptime commitments, DDoS controls, backup process, incident notification, access management | Can the platform stay available during peak traffic and attacks? |
| Customer support or CRM | Player data access, role permissions, recording retention, escalation workflows, export controls | Can support staff view only what they need and escalate risk signals properly? |
These fields make the register more than a compliance archive. They help product and operations teams make practical decisions, such as whether to enable a new market, add live casino games, launch a bonus campaign or connect a new payment route.
Populate the register step by step
Start with discovery. Pull vendor names from procurement records, contracts, payment configuration, game aggregation settings, affiliate dashboards, cloud accounts, admin panels, API keys, finance ledgers and team interviews. The goal is to catch active dependencies, not just companies with formal master service agreements.
Next, normalize each record. Use the legal entity, service category, internal owner and current status. Mark whether the vendor is live, in onboarding, paused, offboarding or rejected. This makes the register useful for operations, not only compliance.
Then assign criticality before collecting every document. A fast first pass prevents your team from spending equal time on a low-risk design vendor and a payment gateway that handles deposits. Criticality can be revised later, but a first tier helps focus work.
After that, collect evidence based on tier. Critical and high-risk vendors should have stronger due diligence packages. Depending on the vendor type, that may include contracts, data processing agreements, security certifications, penetration test summaries, AML policies, game testing certificates, insurance evidence, SLA terms, incident notification clauses and proof of licensing or authorization where relevant.
Finally, record residual risk and open actions. A vendor with a high inherent risk may be acceptable if controls are strong and evidence is current. A medium-risk vendor may be unacceptable if it refuses basic contract protections or cannot explain how it handles player data.
Set ownership and approval rules
The register should not belong only to compliance. Compliance may maintain the standard, but operational ownership must sit with the team using the vendor.
| Role | Responsibility in the register |
|---|---|
| Business owner | Justifies the vendor need, confirms service scope and owns commercial decisions |
| Compliance or AML lead | Reviews regulated functions, KYC, AML, responsible gambling and jurisdictional risk |
| Security lead | Reviews access, encryption, vulnerability management and incident process |
| Finance or payments lead | Reviews settlement, reconciliation, chargebacks, custody and payment continuity |
| Legal lead | Reviews contract terms, liability, audit rights, termination and data processing terms |
| Operations lead | Reviews SLA performance, escalation paths and continuity impact |
| Executive approver | Accepts high residual risk or approves critical vendor launch |
For critical vendors, avoid silent approvals. If residual risk is high, the register should show who accepted it, why it was accepted, for how long and what remediation is required. Risk acceptance without an expiry date tends to become permanent by accident.
Keep the register alive with review triggers
A third-party risk register fails when it is updated only during annual audits. Casino risk changes whenever the platform, market mix or vendor behavior changes.
Use trigger-based reviews alongside scheduled reviews. Reassess a vendor when you enter a new jurisdiction, add a new payment method, enable crypto payments, expand content through a game aggregator, change API permissions, launch a major affiliate campaign, receive an incident notice, see repeated SLA failures or approach contract renewal.
You should also link the register to incident response. If an outage, data exposure, payment issue or affiliate compliance breach occurs, the incident record should identify the affected vendor and update the register afterward. This creates a learning loop rather than treating every incident as isolated.
The casino licensing checklist is also useful here because the same evidence regulators may ask for during licensing often overlaps with the evidence a strong register should maintain.
Common mistakes to avoid
The most common mistake is treating the register as a procurement spreadsheet. Spend is useful, but it is not the main risk driver in iGaming. A low-cost integration can still have privileged access, hold player data or affect restricted market exposure.
Another mistake is ignoring affiliates and marketing partners. Affiliates may not touch your systems, but they can still create regulatory and reputational risk through misleading claims, poor geo targeting or non-compliant promotions. If a partner can influence acquisition in your name, they belong in the register.
Operators also under-document exit options. For critical vendors, the register should show whether you have an alternative provider, how portable the data is, how long migration could take and what contract terms apply during termination. This matters for PSPs, KYC tools, game aggregation, hosting and crypto onramp providers.
Finally, avoid recording controls with no evidence. “Vendor is secure” is not a control. A current certification, completed access review, signed data processing agreement, tested incident contact or reviewed policy is evidence. The register should distinguish claims from documents your team has actually reviewed.
Sample third-party risk register entries
The following sample is not a complete register, but it shows the level of thinking your team should apply.
| Vendor category | Criticality | Main risk | Evidence to store | Review trigger |
|---|---|---|---|---|
| Payment gateway | Critical | Deposits or withdrawals fail, settlement disputes, chargeback exposure | Contract, SLA, PCI DSS evidence, settlement process, incident contact, restricted country list | New market, new payment method, SLA breach, renewal |
| Game aggregator | Critical | Unapproved game availability, game outage, incorrect content configuration | Game certification evidence, jurisdictional availability matrix, release process, uptime terms | New jurisdiction, new studio, content release, outage |
| KYC provider | High | Weak identity verification, onboarding delays, privacy exposure | Data processing agreement, security evidence, match rules summary, retention terms, audit logs | Rule change, data source change, regulator request, incident |
| Affiliate network | High | Misleading promotion, restricted traffic, sub-affiliate misconduct | Affiliate terms, traffic policy, geo controls, sample monitoring, termination rights | New campaign, complaint, traffic spike, market launch |
| Crypto onramp | Critical | Sanctions exposure, custody confusion, frozen transactions, wallet risk | AML controls, custody model, supported assets, transaction monitoring process, escalation path | New asset, wallet incident, sanctions update, volume spike |
| Support platform | Medium | Excessive player data access, poor escalation, data export risk | Access roles, retention settings, DPA, audit log availability, escalation workflow | New support team, new data field, access review finding |
A register like this helps leadership see risk in business terms. It also helps teams avoid last-minute scrambling when a regulator, bank, auditor or prospective investor asks how third-party risk is managed.
Make the register part of platform operations
The best registers are connected to real workflows. When a new vendor is requested, a draft record should be created. When an API key is issued, system access should be added. When a contract is signed, evidence should be linked. When a vendor is offboarded, access removal and data deletion should be tracked.
For operators building on a modular iGaming platform, the register should map directly to enabled platform components and integrations: payments, KYC and AML, fraud prevention, game aggregation, affiliate tools, analytics, open API connections, crypto onramp flows and backoffice access. That mapping makes it easier to understand which third parties support each player journey.
The goal is not to create paperwork for its own sake. The goal is to make better decisions faster: approve low-risk vendors without friction, apply deeper review to critical providers and escalate residual risk before it becomes a compliance, payment or player trust problem.
Frequently Asked Questions
What is a third-party risk register in iGaming? It is a structured record of casino vendors and partners, including what they do, what systems or data they touch, how risky they are, what controls are in place and who owns follow-up actions.
Which vendors should be included in an iGaming risk register? Include any third party that affects player data, payments, KYC, AML, fraud prevention, responsible gambling, game delivery, affiliate marketing, hosting, support or production systems. Critical vendors should receive deeper due diligence and more frequent review.
How often should an online casino update its third-party risk register? Update it during onboarding, renewal, offboarding and any material change. Critical vendors should also be reviewed on a scheduled cadence, often quarterly or twice per year depending on your governance model.
What is the difference between a vendor inventory and a risk register? A vendor inventory lists who you work with. A risk register adds criticality, risk scores, evidence, controls, residual risk, open actions, review dates and approval decisions.
Should affiliates be part of the third-party risk register? Yes. Affiliates can create regulatory and reputational risk through misleading promotions, poor geo targeting, brand misuse or sub-affiliate activity. They may not access your systems, but they can still expose your license and brand.
What evidence should be stored for high-risk casino vendors? Store contracts, data processing terms, security evidence, licensing or certification documents where relevant, AML or fraud control summaries, SLA terms, incident contacts, audit rights, access records and proof of completed reviews.
Build a cleaner risk foundation with Spinlab
Spinlab helps operators build, launch and scale online casinos with a modular iGaming platform designed for fast onboarding, crypto and fiat payments, game aggregation, compliance workflows, fraud prevention, analytics and customizable backoffice operations.
If you want a Shopify-like platform experience for launching a whitelabel casino while keeping vendor dependencies visible and manageable, explore Spinlab and see how a more organized platform foundation can support cleaner third-party risk management from day one.