VendorLens

    For operators and suppliers

    An iGaming supplier onboarding workflow with incident and subprocessor questions

    A five-stage onboarding workflow, plus ready-to-use incident-notification and subprocessor questionnaire prompts, for bringing a new iGaming software supplier live.

    No signup required. Same template used across the iGaming cluster.

    A typical onboarding workflow

    1. 1

      Initial evidence request

      The operator sends the new supplier a request for company, licensing, security and privacy evidence, typically covering the same areas as a standard due-diligence checklist.

    2. 2

      Evidence review

      The operator’s security, legal and commercial teams review what is supplied, flag gaps, and ask follow-up questions on anything unclear or missing.

    3. 3

      Contract and access terms

      Data processing terms, incident-notification obligations and subprocessor-change notice periods are agreed before integration begins.

    4. 4

      Technical integration

      Architecture, environment separation and access provisioning are confirmed against what was represented during the evidence review.

    5. 5

      Ongoing monitoring

      Evidence is re-checked on a set cadence, and material changes — new subprocessors, incidents, certification renewals — are notified as agreed.

    Incident-notification and subprocessor questions to agree upfront

    These are the prompts worth settling during onboarding, before an incident or a subprocessor change happens under time pressure.

    Subprocessor questionnaire

    • Which subprocessors currently touch player or operator data, and for which purpose?
    • Where is each subprocessor located, and does that affect data-residency commitments?
    • What advance notice is given before adding or replacing a subprocessor?
    • Is there a standing objection or termination right if a new subprocessor is unacceptable?
    • Is the current subprocessor list kept up to date and accessible to customers?

    Incident-notification questionnaire

    • What counts as a notifiable incident under the contract, and who decides?
    • What is the maximum time to first notification after an incident is confirmed?
    • Which contact receives incident notifications, and is it monitored outside business hours?
    • What information is included in an initial notification versus a follow-up report?
    • Is there a documented incident-response policy that can be shared on request?

    Keeping onboarding evidence current afterward

    Onboarding evidence goes stale quickly: certificates expire, subprocessors change, architecture evolves. A supplier that publishes a VendorLens trust center updates the subprocessor list, incident-response contact and certification documents in one place, rather than re-sending an updated pack to every operator by email.

    Restricted documents still require a manually reviewed access request each time an operator needs them; publishing does not open every file to every visitor.

    What VendorLens does not do

    VendorLens helps present, request and control access to evidence that suppliers and operators already maintain. It does not issue licences, certify games, perform security audits, score risk on your behalf, provide legal advice, or replace regulatory submissions or your internal due-diligence process. Document access requests are reviewed and approved manually by the publishing organisation, there is no per-section visitor analytics, and each account publishes one trust page.

    Questions about supplier onboarding