KPI for Compliance and Security: Which Metrics and Evidence to Request from a Vendor

Vendor selection in iGaming is a risk decision as much as a commercial one. Relying on marketing materials and verbal assurances when evaluating technology partners leaves a gap between what is claimed and what can actually be delivered — a gap that tends to surface at the worst possible moment.

An evidence-based approach closes that gap. Instead of accepting general statements about security or compliance maturity, you define the specific KPIs (Key Performance Indicators) you need to see, the artifacts that prove those KPIs are real, and the threshold below which a partner does not qualify. This article walks through the full framework: what to measure, what to request as proof, and how to build a vendor assessment process that holds up under scrutiny.

Why “Trust Me” Is Not a Vendor Assessment Strategy

Security is easy to state and harder to evidence. The useful distinction is between a statement of priority and the data that demonstrates it — between a polished security page and a SOC 2 (Service Organization Control) report, a vulnerability scan export, and documented incident response metrics provided on request.

Evidence-based assurance matters for several reasons. It surfaces gaps that general statements can hide. It gives you a consistent evaluation standard across multiple candidates rather than comparing different levels of marketing polish. And it creates defensible documentation for internal procurement, legal, and risk functions.

The scope of what you are trying to prove covers a few core areas:

• Confidentiality and integrity — is data protected from unauthorized access and modification?
• Availability — can the required uptime and recovery objectives be met for your operation?
• Privacy compliance — is personal data handled lawfully and with proper controls?
• Resilience — does performance hold under real pressure, not just in ideal conditions?

What “fit for purpose” means depends on the specific use case. A partner handling player account data sits at a different evidence standard than one delivering a game feed.

The Evidence Model: From Claims to Proof

Before looking at individual KPI categories, it helps to have a clear model for how claims map to evidence. The independence of the evidence is what determines its weight, and it rises across four levels.

• Self-attestation (low independence) — a security questionnaire or written statement
• Third-party certification (medium independence) — an ISO 27001 certificate or SOC 2 report
• Direct evidence (high independence) — audit logs, scan exports, configuration screenshots
• Live demonstration (high independence) — a back-office walkthrough or access-review output

When evaluating any claim, identify which level of evidence you actually have. A questionnaire answered without supporting third-party validation or direct artifacts sits at the lowest assurance level, however the answers are phrased.

Security Governance: What Sits Behind the Controls

Technical controls work when there is functional governance behind them. Before assessing individual KPIs, look at the structural layer: how security ownership is defined, how risk is managed, and whether there is board-level visibility.

What to ask for:

• Risk register with a documented review cadence
• Exception management process — how deviations from policy are tracked and approved
• Evidence of board or executive reporting on material security risks
• Third-party oversight documentation — how risk from the supply chain is managed

Specific artifacts answer these questions more reliably than general statements, which is why the request is structured to elicit documents rather than assurances.

Access Control and Identity: Preventing Unauthorized Access

Unauthorized access is one of the most common root causes of security incidents. For any partner with access to your systems or player data, IAM (Identity and Access Management) and privileged access management KPIs are essential starting points.

Privileged access management governs who holds elevated system access, under what conditions, with what approval process, and with what monitoring. Where privileged accounts are not tightly controlled and audited, the assurance value of everything built on top of them is reduced.

Key KPIs to request:

• MFA (Multi-Factor Authentication) coverage — what percentage of access points require MFA?
• Privileged access controls — is elevated access managed through a dedicated system with session recording?
• Joiner/mover/leaver SLA (Service Level Agreement) — how quickly are access rights modified or revoked when roles change?
• Access review completion rate — what percentage of scheduled access reviews are completed on time?

Evidence to request: audit logs showing access events, access review reports, and screenshots of privileged-access configuration. Policy documents alone are not sufficient — operational proof shows the controls are active.

Vulnerability and Patch Management: How Fast Risk Is Reduced

How quickly known vulnerabilities are identified and closed is one of the clearest signals of operational discipline. Scan coverage matters, but remediation speed matters more.

Key KPIs to request:

• Scan coverage — what percentage of the environment is scanned regularly?
• Remediation SLAs by severity — target and actual closure times for critical, high, medium, and low findings
• Patch latency — average time between vulnerability publication and patch deployment
• Re-open rate — what percentage of closed findings reappear in subsequent scans?

A high re-open rate can point to findings being closed administratively rather than fully resolved, which is worth probing in conversation.

Evidence to request: scan exports, ticket samples linking findings to remediations, and change records showing patch deployment.

Application Security: Building Security Into the Delivery Pipeline

For a partner that develops and maintains the software you run on, secure development discipline directly shapes the risk profile of the codebase. The core testing disciplines are:

• SAST (Static Application Security Testing) — analyzes source code without running the application, identifying issues like injection flaws, insecure function calls, and input validation errors
• DAST (Dynamic Application Security Testing) — tests the running application for behavioral vulnerabilities including authentication weaknesses, session management issues, and misconfigured security headers
• SCA (Software Composition Analysis) — checks third-party libraries and dependencies against known vulnerability databases, flagging outdated or compromised components

Alongside these, ask about secrets scanning (preventing credentials from being committed to code repositories), mandatory code review before deployment, and release gates that block deployment when security checks fail.

Dependency hygiene deserves its own question — the discipline of keeping third-party packages controlled and safe through regular updates, removal of unused libraries, version locking, CVE (Common Vulnerability and Exposure) monitoring, and fast patching of critical findings. Well-managed dependency hygiene is easy to describe precisely: a tracked inventory, a defined SLA for patching critical CVEs, and supporting evidence.

Evidence to request: pipeline configuration documentation, release gate policies, and tool reports from SAST, DAST, and SCA runs.

Incident Response: Measuring Real Performance Under Pressure

An incident response plan on paper is common; the useful question is whether it works and whether the results can be shown.

Key KPIs to request:

• MTTD (Mean Time to Detect) — average time from when an incident begins to when it is identified and formally acknowledged
• MTTR (Mean Time to Respond) — average time from detection to containment and resolution
• Incident volume by severity — tracked over a recent period
• Post-mortem completion rate — the share of incidents that result in a documented review covering root cause, timeline, contributing factors, and a CAPA (Corrective and Preventive Action) plan with named owners and deadlines

Post-mortem completion rate is particularly informative: a high rate reflects the organizational discipline to learn from failures systematically. Where post-mortems cannot be produced at all, it is worth clarifying whether incidents are simply not occurring or not being formally reviewed.

Evidence to request: the incident response plan itself, redacted incident reports from real events, and exercise minutes from tabletop drills.

‍

Logging, Monitoring, and Observability

Comprehensive logging is what makes other security controls auditable and forensically useful. Without it, controls cannot be verified as operating, and investigation after an event becomes guesswork.

Key KPIs to request:

• Log source coverage — what percentage of the environment feeds into centralized logging?
• Log retention period — how long logs are retained and in what format
• Alert tuning metrics — false-positive rate on security alerts, since high rates mean alerts get ignored
• SIEM usage — is a SIEM (Security Information and Event Management) system in place and actively monitored?

A SIEM collects and correlates log data across the infrastructure in real time, surfacing patterns and anomalies that no single source would reveal. Ask specifically whether it is used for active security monitoring and compliance purposes, or deployed but underutilized.

Evidence to request: logging architecture documentation, retention configuration, and sample alert outputs.

Data Protection and Privacy KPIs

Where personal data is processed, privacy compliance is a distinct KPI category with its own evidence requirements.

Key documentation to request:

• RoPA (Records of Processing Activities) — a register of what personal data is processed, for what purpose, by whom, for how long, and with what protections
• Encryption configurations — for data at rest and in transit, including key management practices
• Signed DPA (Data Processing Agreement) — covering roles, security measures, sub-processor lists, incident notification timelines, and data deletion procedures

Key KPIs to track:

• DSR SLAs (Data Subject Request Service Level Agreements) — how quickly requests from individuals to access, correct, or delete their data are handled
• DPIA completion rate (Data Protection Impact Assessment) — whether privacy risk assessments are run when new features or processing activities are introduced

Business Continuity: Availability You Can Validate

Recovery objectives are only meaningful when they have been tested under realistic conditions.

Key KPIs to request:

• RTO (Recovery Time Objective) — maximum acceptable downtime after a failure event — how quickly must services be restored?
• RPO (Recovery Point Objective) — maximum acceptable data loss by time — how far back can systems roll back before it becomes operationally unacceptable?
• Backup success rate — what percentage of scheduled backups complete successfully?
• Restore test frequency — how often backups are actually restored and verified
• DR (Disaster Recovery) test results — documented outcomes from DR exercises, including the RTO and RPO actually achieved, what failed, and corrective actions taken

Evidence to request: DR test reports, backup logs, and architecture diagrams showing redundancy and failover design.

An RTO target without evidence of a test that validated it describes an intended recovery capability rather than a demonstrated one — a distinction worth making explicit during assessment.

‍

Compliance Assurance: Certifications, Scope, and Exceptions

Third-party certifications are a useful baseline, but the details matter as much as the headline.

When reviewing a SOC 2 report, look at scope carefully — which systems and services are covered, and which are carved out. A report that excludes the infrastructure most relevant to your use case provides limited assurance. Look as well for management exceptions and auditor observations: these mark the places where controls did not fully meet the standard being tested.

For any finding, ask for the associated CAPA plan (Corrective and Preventive Action plan) — a document specifying what was identified, the steps being taken to address it, who is responsible, and by when. Mature compliance programs treat CAPA plans as living documents, not one-time filings.

Vendor Supply Chain: Fourth-Party Visibility

The risk introduced by a partner's own vendors — fourth-party risk — is frequently underassessed. Strong internal controls can still leave exposure if oversight of sub-processors is weak.

What to request:

• Complete sub-processor inventory
• Evidence of due diligence conducted on critical sub-processors
• Contractual flow-downs — whether your security requirements extend to sub-processors via contract
• Concentration risk assessment — if a sub-processor fails, what the operational impact is and what mitigation is planned

Contractual Evidence: Making KPIs Enforceable

KPIs without contractual backing are performance aspirations, not commitments. The contract structure should include:

• MSA (Master Service Agreement) — with explicit security clauses, defined breach notification timelines, and the right to audit
• DPA exhibits — covering technical and organizational security measures, sub-processor lists, and cross-border data transfer mechanisms
• SLA schedules — formal annexes defining specific metrics, how they are measured, target thresholds, and consequences for non-performance such as service credits or escalation triggers

When reviewing SLA schedules, check measurement methodology carefully. Uptime measured on a rolling window looks different from uptime measured per calendar month — the calculation method affects what the numbers actually mean.

‍

Ongoing Assurance: Keeping the Assessment Current

Vendor assurance does not end at contract signing. Security posture changes over time, and an assessment that passed in a prior cycle can age as the platform, sub-processors, or organization change.

Build continuous assurance into the relationship:

• Quarterly KPI reviews against agreed metrics
• Annual full reassessment or third-party audit review
• Automated security rating monitoring between formal reviews
• Defined trigger events for reassessment: a significant security incident, a material change in sub-processors, a major platform architecture change, or a change in ownership or key personnel

Building a Repeatable Vendor Scorecard

A scorecard that weights KPIs by the risk they address, defines minimum gates for high-sensitivity controls, and documents compensating controls where gaps exist gives a consistent and defensible evaluation framework.

Scoring approach:

• Weight by risk level — access control and incident response carry more weight than general governance for most iGaming use cases
• Minimum gates — certain controls are pass/fail regardless of overall score — MFA coverage, active DR testing, a signed DPA
• Compensating controls — where a specific control cannot be met, document what alternative measure reduces the risk and whether it is acceptable

The output is not just a procurement decision — it is documentation that the evaluation was structured, evidence-based, and proportionate. That matters to internal audit, to partners, and to any external review of third-party risk management.

Conclusion: Turning Assurance Into a Repeatable Discipline

An evidence-based assessment turns vendor selection from a matter of trust into a matter of record. The framework is consistent across categories: define the KPI, request the artifact that proves it, set the threshold that qualifies a partner, and keep the assessment live through the relationship rather than treating it as a one-time gate.

This kind of structured, evidence-led evaluation is exactly the standard operators are held to in competitive iGaming markets — and the standard worth applying to any technology partner. Soft2Bet builds for operators who run their iGaming business to that level of rigor, with platform infrastructure designed around the availability, security, and compliance demands that serious operations require.

‍