# IGS Control Compliance Standard – Annex A: Technical Compliance & Access Control --- ## Document Control |Field|Value| |---|---| |Document ID|IGS-STD-ANNEX-A| |Version|2.1| |Status|Approved| |Effective Date|[Insert effective date — governs audits commencing on/after this date]| |Supersedes|IGS-STD-ANNEX-A v2.0| |Review Cycle|Annual, or upon any change to A.2 (Definitions) or A.5 (Severity Classification)| |Owner|IGS Standards Committee| |Approval Authority|IGS Standards Committee (majority vote, per IGS Governance Charter)| ### Revision History | Version | Effective Date | Summary of Changes | Sections Affected | | ------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | 1.0 | 02/17/2026 | Initial audit-ready edition. | All | | 2.0 | 03/19/2026 | (1) Split IGS-A-LOG-001 and IGS-A-CHG-001 into single-severity control IDs. (2) Replaced subjective "documented" carve-out in IGS-A-REG-003 with a defined Compensating Control Acceptance process. (3) Added Document Control / Revision History. (4) Added operational tests for "Material Change" (A.2) and formalized the Compensating Control Acceptance process referenced by A.7. (5) Resolved A.12.3 "ANY STATE" transition ambiguity and added a Concurrent Condition Precedence Rule to A.12.1. (6) Expanded A.20 to include sampling methodology, auditor independence requirements, and evidence chain-of-custody standards. | A.2, A.5, A.7, A.12.1, A.12.3, A.14, A.17, A.20 | | 2.1 | 06/13/2026 | (1) Split IGS-A-RET-001 into two single-severity controls (IGS-A-RET-001 High; IGS-A-RET-002 Critical) to comply with A.5's one-control-one-severity rule. (2) Introduced SESSION_BREAK as a formal state in A.2.1 and replaced the ambiguous "COOLING_OFF (short)" label in A.13. (3) Added return/exit transitions to A.12.3 for COOLING_OFF, SELF_EXCLUDED, RG_SUSPENDED, KYC_EXPIRED, SESSION_BREAK, and RESTRICTED. (4) Clarified A.4 Tor browser testing to resolve conflict with IGS-A-GEO-002 blocking requirement. (5) Added IGS-A-ARCH-005 (Session Token Lifecycle), IGS-A-ARCH-006 (Account Recovery Security), and IGS-A-ARCH-007 (Multi-Factor Authentication). | A.2.1, A.4, A.11, A.12.3, A.13, A.15 | **Change Control for This Standard:** Amendments to this Annex are themselves subject to a lightweight form of A.17 — no substantive change to a Control ID, Severity table, or State Machine table may be published without (a) a redline diff against the prior version, (b) a documented rationale, and (c) a minimum 30-day notice period to certified operators before the revised version becomes the basis for audit findings. Editorial changes (typos, formatting, clarifying non-normative prose) are exempt from the notice period but must still be logged in the Revision History. --- ## A.1 Scope This Annex defines the mandatory technical controls for Player Access, Financial Integrity, and Platform Architecture. It interfaces with Annex B (Responsible Gambling) and Annex C (Game Fairness) via the Compliance State Machine defined in A.12. Certification against this Annex is a prerequisite for IGS Certification Status as defined in A.6. --- ## A.2 Definitions **Material Change:** Any alteration to KYC/Geo providers, payment gateways, server-side authorization logic, cloud infrastructure, client application binaries, or RG rule engines that could reasonably affect compliance outcomes. _Operationalization of "reasonably affect compliance outcomes":_ A change is deemed to meet this threshold — and therefore constitutes a Material Change subject to A.17 — if it satisfies **any one** of the following objective tests: 1. **Control-Path Test:** The change modifies code, configuration, or infrastructure that executes within the decision path of any Control ID in A.7–A.13 (i.e., the change touches a function, service, or config value that a control's Test Procedure would exercise). 2. **Vendor Test:** The change adds, removes, or replaces a compliance-critical third party as defined in the A.16 vendor inventory (Geo, KYC, RNG, Payments), regardless of whether the integration contract or API surface is unchanged. 3. **State Machine Test:** The change alters any state name, transition trigger, transition target, or timer default/range defined in A.2.1, A.12.1, or A.12.3. 4. **Threshold Test:** The change modifies a version-controlled compliance threshold or parameter (e.g., KYC confidence threshold, `geoRecheckGraceSeconds`, `depOutageGraceSeconds`, RG limit defaults). 5. **Negative Control (Safe Harbor):** Changes that touch only presentation-layer code with no data-binding to a compliance decision (e.g., CSS, static marketing copy, non-compliance UI copy not referenced in any control's Evidence requirement) are presumed **not** Material. This presumption is rebuttable if IGS demonstrates the change altered user-visible denial/warning messaging governed by a control (see Medium-severity finding class in A.5). Any change that does not clearly resolve under Tests 1–5 must be escalated to the operator's compliance officer for a written determination, which itself becomes an auditable record retained per A.15 and reviewable by IGS during the next audit cycle. **Fail-Closed:** A system state where any failure in a compliance dependency (timeout, 5xx error, unavailable service) results in a blocked or restricted user state (deny by default). **Active Wager:** A bet placed where the outcome has not yet been resolved by Annex C logic. **Management Action Plan (MAP):** A formal, time-bound remediation plan submitted by the operator and accepted by IGS for non-critical findings. **Compensating Control:** A documented, IGS-reviewed alternative safeguard that reduces the risk of a partially-met control to an acceptable level, used only where explicitly permitted (see IGS-A-REG-003). See A.7.1 for the acceptance process and required documentation standard. ### A.2.1 Formal Compliance State Definitions |State|Formal Definition|System Invariants| |---|---|---| |UNVERIFIED|The player has registered but has not submitted or passed any KYC/ID verification.|No deposits, withdrawals, or real-money play permitted. View-only access.| |PENDING_KYC|Identity data has been submitted and is undergoing automated or manual adjudication.|No deposits or real-money play permitted until transition to VERIFIED.| |VERIFIED|The player has successfully passed all applicable Age & Identity controls (per A.8).|Financial deposits are unlocked. Geolocation and RG checks are not yet confirmed for this session.| |AUTHORIZED|The player has passed VERIFIED, current Geolocation (A.9), and active RG limits (Annex B).|Full access to deposits, play, and withdrawals. This is the only state in which real-money wagering is legally permitted.| |SESSION_BREAK|A mandatory, system-enforced temporary suspension of game activity triggered by a configured continuous-play duration threshold (Reality Check). Not player-initiated. The player's session and account remain active.|Game launch blocked for the duration of the configured cooldown period. Deposits, withdrawals, and lobby browsing permitted. Automatic system-driven return to AUTHORIZED upon timer expiry — no player action required.| |GEO_RECHECK|The player's network topology or physical location has changed, requiring re-verification.|New deposits and new bets are blocked. Existing active wagers may resolve per Annex C (A.12.2).| |LIMIT_WARNING|The player has reached a defined Deposit Limit (Annex B) but not a Loss/Time limit.|Deposits blocked; existing balance may be wagered until loss/time limits are reached.| |RG_SUSPENDED|Loss Limit, Time Limit, or Reality Check breach has occurred.|All play and new deposits halted. Cash-out of existing balance permitted.| |COOLING_OFF|Player-initiated 24hr–6 week voluntary break.|Total lockout. Withdrawals processed via separate manual flow. Active wagers voided.| |SELF_EXCLUDED|Player-initiated 6+ month exclusion (or regulatory-mandated).|Total lockout. No early reactivation. Active wagers voided. Withdrawals honored.| |KYC_EXPIRED|The player's verified identification documents have passed their expiration date.|Deposits and play blocked. Withdrawals permitted for a jurisdiction-configurable grace period (see A.8.4).| |RESTRICTED|Critical dependency (Geo/KYC) is unreachable, or system is in degraded failover.|New registrations and new deposits blocked globally. Existing AUTHORIZED users operate under `depOutageGraceSeconds` (A.12.1).| --- ## A.3 Certification Domains Certification is evaluated across six functional domains, instantiated as controls in A.7 through A.13: 1. Registration & Account Integrity (A.7) 2. Age & Identity Assurance (A.8) 3. Geolocation & Jurisdiction (A.9) 4. Financial Access Controls (A.10) 5. Server-Side Authorization & Source Code (A.11) 6. Responsible Gambling Integration (A.13) --- ## A.4 Supported Client Environments The Standard requires testing against the following minimum baseline environments: - **Devices:** Mobile, Laptop, Desktop. - **Operating Systems:** iOS, Android, Windows. - **Browsers (Web-based clients):** Chrome, Firefox, Safari, Edge, Tor. **Mandate for Extended Environments:** Operators must formally declare and maintain a published inventory of all officially supported platforms within their certified scope. This includes, but is not limited to, Smart TV browsers (e.g., Tizen, WebOS), console-based browsers, or native apps on alternative OSs. Any environment not listed in the baseline must be subjected to risk-based testing equivalent to the controls defined herein prior to certification. **Clarification — Tor Browser Testing:** Tor Browser is included in the baseline test matrix to verify that the platform correctly _blocks_ access, consistent with IGS-A-GEO-002. The Tor test does not assess functional platform access; it assesses the completeness of spoofing-resistance enforcement. A passing result for Tor Browser is a compliant denial — not successful access. Test procedures under A.9 that reference Tor Browser are understood accordingly. Any result other than a compliant denial message (e.g., partial access, silent failure, or unhandled error state) constitutes a failure of IGS-A-GEO-002. --- ## A.5 Control Severity Classification Findings are classified to determine certification eligibility and remediation timelines. **Each Control ID maps to exactly one Severity.** Where a single underlying requirement previously produced more than one plausible failure mode, that requirement has been decomposed into separate Control IDs (see A.7, A.15, and A.17) so that severity assignment is unambiguous and does not require auditor judgment about "which" failure occurred. |Severity|Definition|Remediation Window| |---|---|---| |Critical|Allows prohibited-jurisdiction play; underage/self-excluded real-money play; financial activity pre-verification; client-side bypass of server auth; state inconsistency during failover; undetectable audit log tampering.|24 hours| |High|Systematic logging failure (chain-of-custody broken); geo-re-evaluation failure; KYC threshold bypass; Material Change deployed without assessment; missing or unreliable log timestamp integrity.|7 days| |Medium|UX misrepresentation of denial states; missing one vector in duplicate detection where a Compensating Control has been accepted per A.7.1.|30 days| |Low|Minor logging omissions; non-critical UI text errors.|Next release cycle| |Observation|Best-practice deviation with no regulatory exposure.|No mandatory fix; tracked.| --- ## A.6 Certification Status Outcomes & MAP Enforcement |Status|Criteria|MAP Deadline Consequences| |---|---|---| |Certified|Zero Critical/High findings. All Medium/Low remediated or under an accepted Management Action Plan (MAP).|N/A| |Certified with Conditions|Zero Critical findings. High findings have an accepted MAP with a documented remediation date.|Maximum 7 calendar days from Report issuance. If remediation is not verified within this window, status auto-degrades to Suspended.| |Not Certified|Any Critical finding exists during the initial audit.|Full re-audit required. No MAP accepted for Critical findings.| |Suspended|High-finding MAP deadline missed; or Material Change deployed without proper impact assessment.|Operator has 30 calendar days to resolve. Failure results in automatic Revocation.| |Revoked|Critical finding un-remediated >24hrs; deliberate obfuscation; Suspension period expired.|Certification is voided. Public registry updated. Full re-certification required from scratch.| --- ## A.7 Registration & Account Integrity **Control ID: IGS-A-REG-001 (Mandatory Data Collection)** - **Requirement:** The system must require the collection of all mandatory regulatory fields (including Date of Birth, legal name, and residential address) and documented acceptance of Privacy Policy & Terms & Conditions before permitting any real-money play. - **Test:** Auditor attempts to access real-money game lobbies and deposit buttons without completing mandatory fields. - **Pass Criteria:** All real-money functionalities remain locked; UI clearly indicates outstanding requirements. - **Evidence:** Screenshots of the restricted UI; server-side API logs showing 403/blocked responses on deposit attempts. - **Severity:** Critical. **Control ID: IGS-A-REG-002 (Positive Contact Verification)** - **Requirement:** The system must positively verify the user's provided email address and mobile phone number via a one-time passcode (OTP) or click-confirm link before account activation. - **Test:** Auditor registers a test account and attempts to deposit before clicking the email link or entering the SMS OTP. - **Pass Criteria:** Deposit, play, and withdrawal functions remain disabled until verification is complete. - **Evidence:** Test account logs showing pending verification state; OTP audit logs. - **Severity:** High. **Control ID: IGS-A-REG-003 (Multi-Vector Duplicate Detection)** - **Requirement:** The system must detect and block duplicate account creation using a combination of: device fingerprinting, IP correlation, identity document hashing, and payment method matching (the "Four Vectors"). - **Test:** Auditor attempts to create two accounts using the same identity document hash, same device, and same funding source (e.g., same credit card BIN). - **Pass Criteria:** Second registration attempt is flagged, blocked, or automatically linked to the primary account with a clear management alert. - **Evidence:** Fraud-detection engine logs showing the matching hashes and the resulting block decision. - **Severity:** High if fewer than three of the Four Vectors are implemented and enforced. Severity of Medium applies **only** where all of the following conditions in A.7.1 (Compensating Control Acceptance) are independently satisfied for the single missing vector; absent a completed A.7.1 acceptance, a missing vector is scored High regardless of operator intent to document it later. ### A.7.1 Compensating Control Acceptance Process (governs IGS-A-REG-003 and any other control permitting a documented exception) To prevent open-ended discretion in what counts as "documented," any reduction of a finding's severity on the basis of a missing control element being compensated for must satisfy **all** of the following before the reduced severity may be recorded in the Certification Report: 1. **Written Compensating Control Submission** filed by the operator's compliance officer, identifying: the specific control element not met, the compensating measure in place, and the residual risk. 2. **Independent Efficacy Evidence** — objective evidence (e.g., fraud-loss data, false-negative rate from the remaining three vectors over a minimum 90-day sample) demonstrating the compensating measure achieves detection efficacy within 10 percentage points of the full four-vector baseline. 3. **IGS Reviewer Sign-Off** — a named IGS auditor (not the field auditor who identified the finding) must countersign the acceptance in writing, with rationale, before the audit report is finalized. 4. **Time-Boxing** — every accepted Compensating Control has a mandatory expiry of 12 months, after which the missing vector reverts to High severity unless the operator has since implemented it or resubmits a renewed acceptance under this same process. Absent all four elements, "documented" has no effect on severity. --- ## A.8 Age & Identity Assurance (KYC) **Control ID: IGS-A-KYC-001 (Documentary Verification)** - **Requirement:** The system must accept and verify valid, unexpired government-issued identification, and programmatically reject underage submissions, expired documents, and fraudulent/forged documents (via provider scoring). - **Test:** Auditor submits a test identity with an expired document and a second test with a manipulated document (e.g., photoshopped DOB). - **Pass Criteria:** Both are rejected with a clear "unable to verify" user message; account remains UNVERIFIED. - **Evidence:** KYC provider response codes; application logs showing denial reason; UI screenshot. - **Severity:** Critical. **Control ID: IGS-A-KYC-002 (ID & Selfie Match – if implemented)** - **Requirement:** If biometric liveness/selfie capture is used, the system must detect and flag a mismatched ID-to-selfie confidence score below the operator's defined threshold. - **Test:** Auditor submits a valid ID and a clearly different test selfie. - **Pass Criteria:** System flags the mismatch, triggers a manual review hold, or rejects the verification. - **Evidence:** Liveness provider score; workflow routing logs showing the hold/rejection. - **Severity:** High. **Control ID: IGS-A-KYC-003 (Automated Confidence Threshold Enforcement)** - **Requirement:** The operator must enforce the approved soft-KYC (non-documentary) confidence threshold via an automated server-side policy. The threshold value must be version-controlled and auditable. - **Test:** Auditor submits test identities returning scores: Below threshold, At threshold, and Above threshold. - **Pass Criteria:** Below = UNVERIFIED (blocked); At = permitted only if policy defines inclusive (>=); Above = VERIFIED (unlocked). - **Evidence:** Config export; server auth logs; change audit trail. - **Severity:** Critical. **Control ID: IGS-A-KYC-004 (Documentary Address Verification – if implemented)** - **Requirement:** Where address verification is implemented via documentary proof (e.g., utility bill), the system must validate the player's declared residence against the physical proof and reject mismatches or expired submissions. - **Test:** Auditor submits a valid ID but a utility bill with an address that does not match the declared residential address. - **Pass Criteria:** System flags the mismatch and prevents transition to VERIFIED until resolved. - **Evidence:** KYC provider logs; workflow routing showing the hold. - **Severity:** High. **Control ID: IGS-A-KYC-005 (Jurisdiction-Aware KYC Expiry Grace)** - **Requirement:** Upon transition to KYC_EXPIRED, the system must permit withdrawals (but block deposits/play) for a duration defined per licensed jurisdiction via a configurable parameter `kycWithdrawalGraceDays` (e.g., NJ = 7 days, UK = 30 days). After this period, the account transitions to UNVERIFIED, and all financial functions are frozen until re-verification. - **Test:** Auditor configures a test jurisdiction with a 2-day grace, ages a VERIFIED account's document expiry, and attempts a deposit on Day 1, then a deposit on Day 3. - **Pass Criteria:** Day 1 deposit blocked, withdrawal allowed. Day 3 withdrawal also blocked; account state reverts to UNVERIFIED. - **Evidence:** Config file showing `kycWithdrawalGraceDays`; state transition logs; API deny logs. - **Severity:** High. --- ## A.9 Geolocation & Jurisdiction **Control ID: IGS-A-GEO-001 (Accurate Location Resolution)** - **Requirement:** The system must accurately resolve the user's physical location using a combination of server-side IP intelligence and device-native GPS/WiFi positioning. - **Test:** Auditor accesses the platform from a physical device physically located in a permitted state (e.g., NJ) and a prohibited state (e.g., TX). - **Pass Criteria:** Access granted in permitted state; access blocked in prohibited state. - **Evidence:** Geo-provider responses (lat/long); application decision logs. - **Severity:** Critical. **Control ID: IGS-A-GEO-002 (Obfuscation & Spoofing Resistance)** - **Requirement:** The system must actively detect and block VPN, Proxy, TOR, SmartDNS, browser-level IP spoofing (DevTools), Firefox Advanced Geo Spoofing, Android GPS mock locations, and Windows default location changes. - **Test:** Auditor executes each spoofing method (VPN client, DevTools location override, GPS mock app, Tor Browser) while attempting to access the platform. Per A.4, the Tor Browser test specifically verifies that access is blocked; a compliant denial is the expected passing result. - **Pass Criteria:** All attempts result in a compliant denial message; the system logs each blocked spoof attempt. - **Evidence:** Security logs showing each blocked spoof attempt; timestamp correlation. - **Severity:** Critical. **Control ID: IGS-A-GEO-003 (Session Location Re-Evaluation)** - **Requirement:** The system must re-evaluate geolocation upon any significant network change (WiFi/Mobile switch, IP address change, or location permission reactivation). If the new location is prohibited, the system must transition to GEO_RECHECK and restrict new actions. - **Test:** Auditor connects via permitted WiFi, starts a session, then switches to a mobile hotspot with an IP resolving to a prohibited state. - **Pass Criteria:** New bets/deposits are immediately blocked; active wagers may finish per Annex C (see A.12.2); user receives a location-change warning. - **Evidence:** Network handoff logs; state transition logs; user warning UI screenshot. - **Severity:** High. --- ## A.10 Financial Access Controls **Control ID: IGS-A-FIN-001 (Pre-Verification Financial Block)** - **Requirement:** Deposit and withdrawal functionalities must be strictly unavailable to any user in the UNVERIFIED or PENDING_KYC states. - **Test:** Auditor attempts to initiate a deposit API call using a test account that has passed Registration but not KYC. - **Pass Criteria:** API returns a 403/blocked response; UI shows "verification required". - **Evidence:** API request/response logs; UI screenshot. - **Severity:** Critical. **Control ID: IGS-A-FIN-002 (Post-Verification Financial Unlock)** - **Requirement:** Upon successful transition to VERIFIED or AUTHORIZED state, the system must dynamically unlock financial functions without requiring manual operator intervention. - **Test:** Auditor completes KYC; checks the UI and API endpoints immediately after verification confirmation. - **Pass Criteria:** Deposit/withdrawal buttons appear; API accepts transaction requests. - **Evidence:** Timestamped KYC completion log; subsequent API accept logs. - **Severity:** High. --- ## A.11 Server-Side Authorization & Source Code **Control ID: IGS-A-ARCH-001 (Server-Side Final Authority)** - **Requirement:** The final allow/deny decision for all sensitive actions (login, game launch, deposit, withdrawal) must be enforced server-side. Client-side UI blocking is supplemental and cannot be the sole control. - **Test:** Auditor uses a web proxy (Burp Suite) to intercept a deposit request and re-send it to the server, bypassing client-side UI restrictions, while the account is UNVERIFIED. - **Pass Criteria:** Server rejects the replayed request with a 403/deny response. - **Evidence:** Proxy log showing the replayed request and server 403 response. - **Severity:** Critical. **Control ID: IGS-A-ARCH-002 (Secure IP Extraction)** - **Requirement:** The server must securely extract the user's real IP address from the connection socket, explicitly ignoring user-supplied headers (e.g., X-Forwarded-For) that are easily spoofed. - **Test:** Auditor sends a request with a forged X-Forwarded-For header pointing to a permitted state while the socket IP is prohibited. - **Pass Criteria:** Server uses the socket IP and blocks access. - **Evidence:** Server logs showing the ignored header and the socket IP used for the geo-lookup. - **Severity:** Critical. **Control ID: IGS-A-ARCH-003 (Universal Enforcement Points)** - **Requirement:** Access blocking must be enforced at every critical user journey entry point, including: Login, Game Lobby load, Game Launch, Deposit initiation, and Withdrawal request. - **Test:** Auditor attempts to directly access the game-launch API endpoint via a direct URL call without a valid AUTHORIZED session token. - **Pass Criteria:** Endpoint returns 403/redirect; no game data is transmitted. - **Evidence:** API endpoint response logs. - **Severity:** High. **Control ID: IGS-A-ARCH-004 (Platform-Specific Mock Location & Bypass Detection)** - **Requirement:** iOS and Android native clients must implement platform-specific controls to detect mock location settings, developer bypass flags, and rooted/jailbroken environments that could subvert geolocation. Such detections must trigger a hard block. - **Test:** Auditor installs the native app on a rooted Android device with a mock GPS app enabled and attempts to access real-money play. - **Pass Criteria:** The application detects the insecure environment and blocks access; state remains RESTRICTED. - **Evidence:** Client-side security logs; server-side denial logs. - **Severity:** Critical. **Control ID: IGS-A-ARCH-005 (Session Token Lifecycle & Re-Authentication)** - **Requirement:** The system must enforce the following session security properties server-side: 1. **Token Expiry:** Session tokens must carry a server-enforced absolute expiry (maximum 24 hours) and an inactivity expiry (maximum 30 minutes of no authenticated API activity), after which the token is invalidated and the user must re-authenticate. 2. **Concurrent Session Limits:** The system must detect and enforce a defined maximum number of simultaneous active sessions per account (operator-configurable, default ≤ 3). Excess session creation must be rejected or must invalidate the oldest session. 3. **Step-Up Re-Authentication:** Withdrawal initiation, Self-Exclusion activation, Cooling-Off activation, and password changes must each require explicit re-authentication (password confirmation or MFA challenge per IGS-A-ARCH-007) within the same request chain, regardless of existing session validity. 4. **Token Invalidation on Sensitive State Change:** Any transition into COOLING_OFF, SELF_EXCLUDED, or RESTRICTED must immediately invalidate all active session tokens for the affected account, forcing re-authentication upon return. - **Test:** (a) Auditor lets a session sit idle for >30 minutes and then issues an authenticated API call. (b) Auditor initiates a withdrawal via API without completing a step-up re-authentication challenge. (c) Auditor triggers a state transition to COOLING_OFF and confirms existing tokens are invalidated. - **Pass Criteria:** (a) API returns 401 Unauthorized. (b) Server demands re-authentication before processing. (c) All prior tokens are rejected immediately post-transition. - **Evidence:** Token expiry configuration; server auth logs showing 401 on expired token; re-authentication challenge logs; token invalidation logs at state transition. - **Severity:** High. **Control ID: IGS-A-ARCH-006 (Account Recovery & Password Reset Security)** - **Requirement:** Account recovery and password reset flows must satisfy all of the following: 1. **Identity Re-Verification:** A password reset must require verification of at least one pre-registered factor beyond the email address alone (e.g., SMS OTP to the registered mobile, or a backup recovery code issued at registration). Email-only reset links without a secondary factor are prohibited. 2. **Token Binding:** Reset tokens must be single-use, expire within 15 minutes of issuance, and be cryptographically bound to the requesting session. Replay of a consumed token must be rejected. 3. **Account Lockout on Abuse:** Five or more failed OTP or recovery-code attempts within a 15-minute window must trigger a temporary lockout of the reset flow (minimum 30 minutes) and generate a security alert to the account's registered email and mobile. 4. **Server-Side Enforcement:** All reset flow decisions (token validity, factor verification, lockout state) must be enforced server-side. Client-side flow control is supplemental only. - **Test:** (a) Auditor initiates a password reset using only the email address, without the secondary factor. (b) Auditor captures a reset token, uses it, then replays it. (c) Auditor submits six incorrect OTP attempts in sequence. - **Pass Criteria:** (a) Reset does not complete without secondary factor. (b) Second use of the token returns a rejection. (c) Flow locks after the fifth failure; security alert is generated to registered contact channels. - **Evidence:** Reset flow architecture diagram; server auth logs; lockout trigger logs; OTP expiry configuration. - **Severity:** High. **Control ID: IGS-A-ARCH-007 (Multi-Factor Authentication for Financial & Sensitive Actions)** - **Requirement:** The system must enforce Multi-Factor Authentication (MFA) — defined as requiring possession of a registered second factor in addition to the account password — for the following actions, regardless of existing session validity: 1. Withdrawal of any amount. 2. Modification of registered account details (email address, mobile number, bank account or payment method). 3. Activation of Self-Exclusion or Cooling-Off. 4. Password change. Accepted second factors: TOTP authenticator app, SMS OTP to the registered mobile, or a hardware security key (FIDO2/WebAuthn). Email-only OTP is not a compliant second factor for this control (it is acceptable for IGS-A-REG-002 account activation only). The second factor must be verified server-side within the same authenticated request chain as the sensitive action it protects. _Jurisdictional note:_ Where a licensed jurisdiction mandates Strong Customer Authentication (SCA) under PSD2 or equivalent regulation, MFA as defined here is the minimum compliant implementation. Operators in SCA-mandated jurisdictions must additionally satisfy dynamic linking requirements per their applicable regulatory technical standards; IGS may inspect SCA compliance evidence as part of the A.20 testing framework. - **Test:** (a) Auditor initiates a withdrawal via direct API call using only a valid session token, without completing an MFA challenge. (b) Auditor attempts to change the registered email address without MFA. - **Pass Criteria:** Both requests are rejected with a 403/challenge-required response; server logs show the MFA gate was evaluated and not bypassed. - **Evidence:** MFA configuration; server-side challenge/response logs; API rejection logs for both test cases. - **Severity:** High. --- ## A.12 Compliance State Machine ### A.12.1 Governance Rule – Grace Timer Separation The system must maintain two distinct, independently configurable grace timers, both defined per licensed jurisdiction: - **`geoRecheckGraceSeconds`** (Intentional Network Change): Applies when the user physically moves, switches WiFi/Cellular, or their IP changes while the Geo provider is online and responding. Default: 5–15 seconds (sufficient to finish a single reel spin). Configurable per jurisdiction. - **`depOutageGraceSeconds`** (Third-Party Dependency Failure): Applies when the Geo or KYC provider API is unreachable, timing out, or returning 5xx errors. Default: 0–60 seconds (allowing for brief network blips, but acknowledging the higher risk of an outage). Configurable per jurisdiction. **Configuration Note:** Regulators in high-risk jurisdictions may mandate `depOutageGraceSeconds = 0`. The configuration file containing these values must be version-controlled and auditable per A.17. **Concurrent Condition Precedence Rule:** Where a user is already subject to one grace timer and a second, independent triggering condition arises before the first timer expires, the following precedence applies: 1. **No timer restart.** A second trigger of the _same_ condition type (e.g., a further network change while already in GEO_RECHECK) does not reset the running `geoRecheckGraceSeconds` timer. The original countdown continues from its original start point. 2. **Dependency outage takes precedence over network-change recheck.** If a user already in GEO_RECHECK (running under `geoRecheckGraceSeconds`) experiences a compliance-dependency outage (Geo or KYC provider unreachable) before that timer expires, the user transitions to RESTRICTED and the applicable timer becomes `depOutageGraceSeconds`, evaluated from the moment the outage was detected — not from the original GEO_RECHECK entry time. `depOutageGraceSeconds` takes precedence because it reflects the operator's inability to make _any_ compliance determination (including resolving the original recheck), which is a strictly more severe condition than an unconfirmed but potentially resolvable location change. 3. **No stacking of grace periods.** A user may not accumulate sequential grace windows to extend permitted play beyond the longer of the two applicable timers. The system must track a single authoritative "restricted since" timestamp per user session; whichever timer is currently active is evaluated against that timestamp, not reset by subsequent state re-entries. 4. **Recovery re-evaluation.** If the dependency outage resolves before `depOutageGraceSeconds` expires, and the user's most recent known location is still prohibited or unconfirmed, the user returns to GEO_RECHECK with the _remaining_ balance of the original `geoRecheckGraceSeconds` window (not a fresh window), per Rule 1. ### A.12.2 Interface to Annex C: Active Wager Financial Treatment When a state transition (per A.12) restricts a user, Annex C (Game Logic) must apply the following financial rules to any active, unresolved wagers. Annex C must query the compliance state via a server-side API prior to settling any wager. |Restrictive Transition|Financial Treatment of Active, Unresolved Wagers| |---|---| |UNVERIFIED → PENDING_KYC|No active wagers exist. (Deposits blocked).| |AUTHORIZED → GEO_RECHECK (via `geoRecheckGraceSeconds`)|Permitted to resolve naturally (win/loss) during the grace window. New bets blocked immediately. If timer expires without re-verification, any still-running wagers are voided and stakes returned.| |AUTHORIZED → RESTRICTED (via `depOutageGraceSeconds`)|Permitted to resolve naturally if outcome already determined client-side and awaiting server confirmation. If outcome not yet determined, wagers are suspended and resumed upon service restoration. No voiding required unless outage exceeds 5 minutes.| |AUTHORIZED → RG_SUSPENDED (Loss/Time limit)|Immediately voided. Stakes returned to the player's cash balance. Winnings are forfeited. Audit log must record the void reason and timestamp.| |AUTHORIZED → COOLING_OFF or SELF_EXCLUDED|Immediately voided. Stakes returned. No exceptions.| |VERIFIED → KYC_EXPIRED|No active wagers permitted post-transition. Pre-existing wagers resolve naturally; no new wagers allowed.| |GEO_RECHECK → RESTRICTED (dependency outage arising during an active recheck; see A.12.1 Concurrent Condition Precedence Rule)|Treated identically to AUTHORIZED → RESTRICTED above, evaluated against `depOutageGraceSeconds` from the outage-detection timestamp.| **Audit Requirement:** The system must log the specific state-transition event that triggered any void, alongside the wagered amount, game ID, and timestamp. This log must be retained for 7 years (per A.15). ### A.12.3 Formal State Transition Matrix **Entry transitions:** |Current State|Trigger / Event|Next State|Allowed Actions During Transition|Impact on Annex C (Active Wagers)| |---|---|---|---|---| |UNVERIFIED|User registers with valid data.|PENDING_KYC|View lobby only; no deposits/play.|N/A| |PENDING_KYC|KYC threshold met (A.8).|VERIFIED|View lobby; deposits unlocked.|N/A| |VERIFIED|Geolocation passes (A.9).|AUTHORIZED|Full access (play, deposit, withdraw).|Full game logic allowed.| |AUTHORIZED|Configured continuous-play threshold reached (system-driven).|SESSION_BREAK|Game launch blocked for cooldown duration; deposits, withdrawals, and lobby access permitted.|In-flight wagers resolve normally; no new bets permitted during break.| |AUTHORIZED|IP/Network changes to prohibited jurisdiction.|GEO_RECHECK|Existing actions paused; `geoRecheckGraceSeconds` countdown begins.|Per A.12.2 matrix.| |AUTHORIZED / GEO_RECHECK|User hits Deposit Limit (Annex B).|LIMIT_WARNING|Play allowed with existing funds; deposits blocked.|Game play continues; winnings accrue, but no new funds added.| |AUTHORIZED / LIMIT_WARNING|User hits Loss/Time Limit.|RG_SUSPENDED|Play & deposits blocked; cash-out available.|Per A.12.2 matrix (immediate void).| |AUTHORIZED|User initiates Time-Out (24hr – 6 weeks).|COOLING_OFF|Total lockout; withdrawals allowed via separate flow.|Per A.12.2 matrix (immediate void).| |AUTHORIZED|User initiates Self-Exclusion (6+ months).|SELF_EXCLUDED|Total lockout; only withdrawal of balance allowed.|Per A.12.2 matrix (immediate void). No reactivation allowed before expiry.| |AUTHORIZED|KYC documents expire (date passed).|KYC_EXPIRED|Deposits blocked; withdrawals allowed for `kycWithdrawalGraceDays`.|Play blocked until new docs verified.| |AUTHORIZED (dependency unreachable)|Geo/KYC provider unreachable while user is in AUTHORIZED.|RESTRICTED (Degraded)|New registrations/deposits blocked globally; this user gets `depOutageGraceSeconds`.|Per A.12.2 matrix.| |GEO_RECHECK (dependency unreachable)|Geo/KYC provider becomes unreachable while user is already in GEO_RECHECK, before `geoRecheckGraceSeconds` expires.|RESTRICTED (Degraded)|`depOutageGraceSeconds` begins from outage-detection time per A.12.1 Concurrent Condition Precedence Rule; original recheck timer is preserved but paused.|Per A.12.2 matrix (see added row).| |Any pre-AUTHORIZED state (UNVERIFIED, PENDING_KYC, VERIFIED)|Geo/KYC provider unreachable.|RESTRICTED (Degraded) — new registrations/verifications blocked|No new registrations, verifications, or deposits system-wide for the duration of the outage.|N/A (no active wagers possible pre-AUTHORIZED).| _Note: the three RESTRICTED-entry rows above replace the single undifferentiated "ANY STATE → dependency unreachable → RESTRICTED" row in the prior edition, so that the applicable timer and preserved-state behavior is unambiguous for every originating state._ **Exit / return transitions:** |Current State|Trigger / Event|Next State|Allowed Actions During Transition|Impact on Annex C (Active Wagers)| |---|---|---|---|---| |SESSION_BREAK|Configured cooldown timer expires (system-driven; no player action required).|AUTHORIZED|Full access restored automatically.|No wagers were blocked during SESSION_BREAK; any in-flight resolution continues normally.| |COOLING_OFF|Cooling-off period duration expires (system-driven). Player initiates a new login.|VERIFIED|Player must pass a fresh Geolocation check (A.9) before reaching AUTHORIZED. Deposits remain accessible from VERIFIED onward.|No active wagers exist (all were voided at COOLING_OFF entry).| |SELF_EXCLUDED|Exclusion period expires (minimum 6 months, or applicable regulatory minimum if longer). Player submits a written reactivation request to the operator.|PENDING_KYC|Operator must perform a fresh full KYC verification before any financial access is restored. No automatic reactivation permitted.|No active wagers exist (all were voided at SELF_EXCLUDED entry).| |RG_SUSPENDED|Annex B rule engine determines the triggering limit condition is no longer active (e.g., daily/weekly loss-limit period has reset per the operator's configured calendar; mandatory time-limit break period has elapsed).|AUTHORIZED|Full access restored per Annex B re-evaluation. No manual operator intervention required unless Annex B specifies a review hold for the applicable limit type.|Active wagers voided at RG_SUSPENDED entry; no carry-over on restoration.| |KYC_EXPIRED|Player submits updated, valid, unexpired identity documentation and KYC provider returns a passing score per A.8.|VERIFIED|Deposits unlocked; a fresh Geolocation check is required before AUTHORIZED is reached. The `kycWithdrawalGraceDays` grace timer is cleared; the new document's expiry date governs the next KYC_EXPIRED transition.|No active wagers were permitted post-KYC_EXPIRED; none to carry over.| |RESTRICTED (Degraded)|Compliance dependency (Geo/KYC provider) becomes reachable again and returns valid responses.|GEO_RECHECK — if user was in GEO_RECHECK when RESTRICTED was entered (per A.12.1 Rule 4), with the _remaining_ balance of the original `geoRecheckGraceSeconds` window. **Or** AUTHORIZED — if user was in AUTHORIZED when the outage began and the first successful re-evaluation confirms a permitted location.|System must re-evaluate the user's most recent known location immediately upon dependency restoration. If location is confirmed permitted, AUTHORIZED is restored. If location is unconfirmed or prohibited, GEO_RECHECK applies with remaining timer balance.|Per A.12.2 — wagers suspended during outage resume upon restoration if outcome was undetermined; already-resolved wagers settle normally. No new grace window is issued on recovery.| --- ## A.13 Responsible Gambling (RG) – Intervention Types The Standard mandates server-side enforcement of the following distinct intervention types, governed by Annex B rule sets: |Intervention Type|System Behavior|State Applied| |---|---|---| |Deposit Limit (Daily/Weekly/Monthly)|Blocks new deposit API calls; displays remaining allowance; permits play with existing balance.|LIMIT_WARNING| |Loss Limit|Blocks new bets once cumulative losses meet the legal-opinion-derived threshold.|RG_SUSPENDED| |Session Time-Out (Reality Check)|Forces a mandatory break (e.g., 5-minute cooldown) after a configured continuous play period. Game launch is blocked for the cooldown duration. Play resumes automatically after cooldown without player action.|SESSION_BREAK| |Cooling-Off Period (24hr – 6 weeks)|Full account lock; automated re-activation after period expires per A.12.3 exit transitions.|COOLING_OFF| |Self-Exclusion (6+ months)|Full account lock; mandatory wait period; no reactivation before expiry; active wagers immediately voided per A.12.2; fresh KYC required upon reactivation per A.12.3 exit transitions.|SELF_EXCLUDED| **Control ID: IGS-A-RG-001 (Enforcement of All RG Limits)** - **Requirement:** All RG limits (Deposit, Loss, Time, and Self-Exclusion) must be enforced server-side. Client-side UI must update to reflect the restricted state, but the server must reject any attempt to place a bet or deposit that breaches the limit. The system must query Annex B's rule engine prior to authorizing any sensitive action. - **Test:** Auditor attempts to place a bet via direct API call after a loss limit has been triggered. Auditor separately attempts a deposit after a deposit limit has been reached. - **Pass Criteria:** Server returns a 409 Conflict or 403 Forbidden response with a reason code for both attempts. - **Evidence:** API logs; RG engine audit trail showing the limit breach and enforcement decision. - **Severity:** Critical. --- ## A.14 Audit Logging & Clock Integrity **Control ID: IGS-A-LOG-001 (Tamper-Evident Storage of Audit Logs)** - **Requirement:** All compliance-relevant events (state transitions, geo decisions, KYC outcomes, RG limit triggers, and financial actions) must be logged in an immutable, write-once, append-only store with cryptographic integrity protections (e.g., hash chaining, WORM storage) sufficient to make any retroactive alteration detectable or prevented outright. - **Test:** Auditor reviews the logging architecture and attempts to modify a historical log entry via direct database access (in a test environment). - **Pass Criteria:** Modification attempt is either prevented at the storage layer, or the alteration is detectable via a cryptographic checksum/hash chain verification. - **Evidence:** Architecture diagram; database permission settings; log integrity verification report showing a successful tamper-detection run. - **Severity:** Critical. **Control ID: IGS-A-LOG-002 (Timestamp Integrity & Event Metadata Completeness)** - **Requirement:** Every compliance-relevant log entry must carry a trusted UTC timestamp (sourced per IGS-A-LOG-003 clock synchronization), a user identifier, a session ID, and a complete event payload sufficient to reconstruct the decision. Timestamp source must be distinguishable from client-supplied time values, and client-supplied timestamps must never be trusted as the record of truth. - **Test:** Auditor inspects a sample of log entries (per the sampling methodology in A.20) for the presence and internal consistency of timestamp, user ID, session ID, and payload fields, and confirms the timestamp is server-assigned rather than client-supplied. - **Pass Criteria:** 100% of sampled compliance-relevant log entries contain all four required fields, with timestamps demonstrably server-assigned. - **Evidence:** Log schema documentation; sample export of log entries; code or config showing server-side timestamp assignment. - **Severity:** High. **Control ID: IGS-A-LOG-003 (Clock Synchronization & Drift Monitoring)** _(Renumbered from IGS-A-LOG-002 in v1.0; no change to requirement.)_ - **Requirement:** All application servers must synchronize their system clocks via NTP to a trusted stratum source (e.g., pool.ntp.org or a national time standard). Clock drift must not exceed ±1 second. Drift anomalies exceeding this threshold must trigger a security alert and default all compliance decisions to RESTRICTED until resolved. - **Test:** Auditor forces a test server's clock offset by +5 seconds and monitors system behavior. - **Pass Criteria:** Alert is generated; compliance API calls return a degraded/restricted state. - **Evidence:** NTP configuration files; drift monitoring logs; alerting system records. - **Severity:** High. --- ## A.15 Data Retention **Control ID: IGS-A-RET-001 (Retention Policy Adequacy)** - **Requirement:** The operator must maintain a documented data retention policy specifying that all audit logs, geolocation decisions, IP changes, denial events, RG intervention triggers, and state transition records are retained for a minimum of seven (7) years, or the maximum statutory requirement of the operator's licensed jurisdictions, whichever is longer. The policy must be version-controlled, reviewed annually, and reference the specific storage systems covered. - **Test:** Auditor reviews the operator's data retention policy document and cross-references it against the jurisdictions in the operator's licensed scope to confirm the stated retention period is compliant. - **Pass Criteria:** A documented, version-controlled policy exists, names all covered log categories, and specifies a retention period meeting or exceeding the 7-year floor and any applicable statutory maximum. - **Evidence:** Retention policy document; version history; licensed jurisdiction list. - **Severity:** High. **Control ID: IGS-A-RET-002 (Log Retrievability Within Regulatory Window)** - **Requirement:** All records subject to IGS-A-RET-001 must be stored in a non-rewritable, auditable format and be retrievable and readable within 72 hours of a formal regulatory request, for the full duration of the retention period. - **Test:** Auditor submits a formal retrieval request for a specific user's compliance logs from 6.5 years prior and measures time to production. - **Pass Criteria:** Logs are produced in a readable, complete format within 72 hours. - **Evidence:** Retrieval report; timestamped backup manifests; storage architecture diagram confirming non-rewritable medium. - **Severity:** Critical. _(Rationale for split: IGS-A-RET-001 previously assigned High or Critical severity depending on failure mode, creating a dual-severity control that violates A.5's one-control-one-severity rule. The two failure modes — an insufficient policy and an irretrievable log corpus — are independently testable and carry genuinely different regulatory risk. They are now expressed as separate Control IDs consistent with the same decomposition applied to A.17 in this revision.)_ --- ## A.16 Third-Party Dependency Management Operators must maintain a formal inventory of all compliance-critical third parties (Geo, KYC, RNG, Payments). For each, the operator must: 1. Have an active Service Level Agreement (SLA) defining maximum allowable downtime and required support response times. 2. Implement automated fail-closed logic for new access if the provider is unreachable (see A.12.1 for `depOutageGraceSeconds`). 3. Retain and provide, upon regulatory or IGS request, objective third-party assurance evidence for each vendor, such as: - SOC 2 Type II Report (specifically covering Security, Availability, and Confidentiality trust principles). - ISO/IEC 27001:2022 Certification. - A qualified independent security assessment (e.g., a penetration test conducted within the last 12 months by a recognized firm). 4. Notify IGS of any provider change within 5 business days (treated as a Material Change, per A.17; evaluated against the Vendor Test in A.2). **Control ID: IGS-A-TPD-001 (Vendor Inventory & Outage Fallback)** - **Requirement:** Operators must maintain an up-to-date vendor inventory. If any compliance-critical provider is unreachable, new registrations and new deposits must fail-closed for the duration of the outage, subject only to the jurisdiction-configured `depOutageGraceSeconds` timer for existing AUTHORIZED users. - **Test:** Auditor simulates a timeout from the configured Geolocation provider. - **Pass Criteria:** New user registrations receive a "location verification temporarily unavailable" error. Existing AUTHORIZED users receive the configured `depOutageGraceSeconds` window; after expiry, new bets are rejected. - **Evidence:** Monitoring alerts; outage logs; user-facing error screenshots; API logs. - **Severity:** Critical (if new users can bypass); High (if existing sessions are not gracefully handled). --- ## A.17 Material Change Management **Control ID: IGS-A-CHG-001 (Pre-Deployment Impact Assessment)** - **Requirement:** No Material Change (as defined in A.2, evaluated against the five objective tests therein) may be deployed to a certified production environment without a documented impact assessment identifying which controls (A.7–A.13) are affected. - **Test:** Auditor reviews deployment tickets and compares them against the certified architectural baseline recorded during the last audit, confirming an impact assessment document exists and correctly identifies affected controls. - **Pass Criteria:** Every Material Change ticket sampled (per A.20 sampling methodology) has a corresponding impact assessment that accurately identifies all affected Control IDs. - **Evidence:** Jira/ServiceNow or equivalent change tickets; impact assessment documents. - **Severity:** High. **Control ID: IGS-A-CHG-002 (QA Regression Sign-Off)** - **Requirement:** No Material Change may be deployed without QA regression testing covering the controls identified in the corresponding IGS-A-CHG-001 impact assessment, with formal sign-off. - **Test:** Auditor reviews the QA test plan and results for a sample of Material Change tickets and confirms regression coverage maps to the controls named in the impact assessment. - **Pass Criteria:** Every sampled Material Change has QA sign-off evidencing execution of tests covering each affected control. - **Evidence:** QA test reports; sign-off records (named approver, timestamp). - **Severity:** Medium. **Control ID: IGS-A-CHG-003 (IGS Notification Timeliness)** - **Requirement:** IGS must be notified of any Material Change within 5 business days of deployment. - **Test:** Auditor compares deployment timestamps against IGS notification records for a sample of Material Changes. - **Pass Criteria:** 100% of sampled Material Changes were notified to IGS within 5 business days of deployment. - **Evidence:** Notification emails or portal submission records; deployment timestamps. - **Severity:** Low. **Control ID: IGS-A-CHG-004 (Demonstrable Control Failure Resulting From an Unassessed Change)** - **Requirement:** Where a deployed change — Material or otherwise — demonstrably breaks a Critical or High control defined elsewhere in this Annex (regardless of whether IGS-A-CHG-001/002/003 were separately satisfied), that outcome is scored under this control independent of, and in addition to, any process finding above. - **Test:** Auditor traces any Critical/High finding identified elsewhere in the audit back to a recent deployment and determines whether that deployment underwent the process in IGS-A-CHG-001/002. - **Pass Criteria:** No Critical/High control failure is traceable to a deployed change that bypassed the impact assessment or QA sign-off process. - **Evidence:** Deployment logs cross-referenced with the finding's root-cause analysis; change tickets. - **Severity:** Critical. _(Rationale for split: v1.0 assigned three different severities — High, Medium, Critical — to a single control ID depending on which of sub-clauses (a) process-only, (b) notification-only, or (c) demonstrated-breakage had failed. Because a single Control ID must map to a single Severity under the revised A.5, the requirement is now expressed as four Control IDs, each independently testable and each carrying one severity.)_ --- ## A.18 Business Continuity & Disaster Recovery **Control ID: IGS-A-BCP-001 (Dependency Outage Grace Period Enforcement)** - **Requirement:** During a compliance dependency outage, the system must enforce a jurisdiction-specific `depOutageGraceSeconds` timer for existing AUTHORIZED users, applying the Concurrent Condition Precedence Rule in A.12.1 where the user was already in another restricted state. New users and new financial transactions are blocked immediately. The configuration of these timers must be version-controlled and auditable. - **Test:** Auditor disables the Geo provider for a test environment. An existing AUTHORIZED user attempts a new bet after `depOutageGraceSeconds` has elapsed. - **Pass Criteria:** New bet is rejected; user receives a "location verification temporarily unavailable" message; logs show the state transition to RESTRICTED. - **Evidence:** Configuration file showing jurisdiction timers; application logs; UI screenshot. - **Severity:** Critical (if no fail-closed mechanism exists or if timers are not jurisdiction-aware). **Control ID: IGS-A-BCP-002 (State Consistency During Database Failover)** - **Requirement:** The compliance state database (containing all UNVERIFIED → AUTHORIZED statuses, RG limits, and KYC statuses) must utilize synchronous replication between the primary and secondary nodes. Upon failover, the system must guarantee zero loss of committed state transitions and read-after-write consistency. No "split-brain" scenario may occur (the old primary cannot accept writes after the replica is promoted). The system must serve a consistent view of user states within 5 minutes of failover initiation, but the primary metric is state accuracy, not recovery time. - **Test:** Auditor initiates a planned failover of the primary database while simultaneously issuing a high volume of state-change API calls (e.g., KYC approvals, deposit limit changes). - **Pass Criteria:** - No committed state transition is rolled back or lost. - Any API call that received a 200 OK prior to failover reflects its new state on the replica immediately upon promotion. - No "split-brain" occurs. - A reconciliation report shows 0 unmatched transactions. - **Evidence:** Database transaction logs pre- and post-failover; application-side state checksum validation; reconciliation report. - **Severity:** Critical (if a state is lost or inconsistent, as it could permit unauthorized play or block legitimate withdrawals). --- ## A.19 Certification Reporting Upon completion of the audit, the Certification Report shall be structured to provide regulators and operator leadership with clear, actionable intelligence. The Report must include: 1. **Scope Narrative** – A detailed description of the audit's approach, coverage, and tested environments. 2. **Control Descriptions** – A narrative for each domain (A.7–A.13) detailing how the operator manages and maintains the control. 3. **Findings & Observations** – A clear enumeration of any deviations from this Standard, classified per A.5 (Critical/High/Medium/Low/Observation), by individual Control ID. 4. **Remediation Confirmation** – Formal confirmation that any findings identified have been successfully remediated prior to issuance, unless otherwise classified. 5. **Management Action Plans (MAPs)** – For any outstanding, non-critical findings, a documented response and timeline from the operator's management, subject to the deadlines in A.6. 6. **Compensating Control Acceptances** – Any acceptances granted under A.7.1, including expiry dates and the named IGS reviewer. 7. **Certification Status** – The formal status per A.6 (Certified, Certified with Conditions, Not Certified, Suspended, or Revoked). 8. **Evidentiary Artefacts** – Screenshots, logs, and configuration extracts necessary to substantiate conclusions, collected and retained per the chain-of-custody requirements in A.20. --- ## A.20 Control Testing Methodology All controls defined in A.7 through A.18 must be tested using the following standardized framework, which is embedded within each control definition: |Element|Description| |---|---| |Requirement|The mandatory system behavior.| |Test Procedure|The specific, repeatable action the auditor performs.| |Pass Criteria|The objective, measurable conditions that constitute a pass.| |Required Evidence|The specific artefacts the auditor must collect and retain.| |Failure Classification|The severity (Critical/High/Medium/Low/Observation) assigned if the test fails.| Auditors must maintain a formal test log documenting the execution of each control test, including date, time, tester identity, test outcome, and evidence references. This test log forms part of the Certification Report per A.19. ### A.20.1 Sampling Methodology Where a control's Test Procedure references a population of items (e.g., log entries, change tickets, user accounts, transactions) rather than a single deterministic test, the following sampling rules apply unless a control explicitly specifies otherwise: - **Population Definition:** The auditor must first define and document the full population (e.g., "all Material Change tickets deployed in the 12 months preceding the audit"). - **Sample Size:** Minimum sample size is the lesser of 25 items or the full population, using statistically random selection (not auditor- or operator-selected convenience samples). For populations exceeding 500 items, minimum sample size increases to 45 items, consistent with standard attribute-sampling practice for a 95% confidence / ≤5% expected deviation rate. - **Exception Handling:** Any single sampled item that fails Pass Criteria requires the auditor to double the original sample size for that control and re-test. If the expanded sample contains further failures, the finding is scored against the full, unsampled population (i.e., treated as systemic) rather than as an isolated exception. - **Auditor Discretion Limit:** Sample selection criteria and the resulting sample must be recorded in the test log (A.20) before test execution begins, to prevent post-hoc selection of favorable items. ### A.20.2 Auditor Independence Requirements - The individual(s) executing control tests must not have provided consulting, implementation, or remediation advisory services to the operator for the system under audit within the preceding 12 months. - The IGS reviewer who countersigns any Compensating Control Acceptance (A.7.1) must not be the same individual who conducted the underlying field test. - Audit firms must attest, in writing, to the absence of a material financial relationship with the operator beyond the audit engagement itself (e.g., no contingent or success-based fee structures tied to Certification outcome). - Rotation: the lead auditor for a given operator may not lead more than three consecutive annual audits of the same operator without a rotation to a different lead auditor for at least one cycle. ### A.20.3 Evidence Chain of Custody Evidence collected under A.19(8) is itself subject to integrity requirements, applied by the auditor rather than the operator: - **Collection Record:** Every evidentiary artefact must be logged at the point of collection with: collector identity, timestamp (UTC), source system, and collection method (e.g., screenshot, API export, log pull). - **Hashing:** Every collected artefact must be hashed (SHA-256 minimum) at the point of collection. The hash value, alongside the collection record metadata above, must be entered into the auditor's tamper-evident test log before the artefact is transmitted or stored. Any artefact whose hash cannot be verified against the collection-time record at the point of report finalization must be re-collected or, if re-collection is not possible, excluded from the report with a documented explanation. - **Transmission & Storage:** Artefacts must be transmitted to and stored in an access-controlled repository maintained by the audit firm, not the operator. The operator must not have write or delete access to the artefact repository at any point after the artefact is collected. - **Retention by Auditor:** The audit firm must retain the full evidentiary artefact set, with collection records and hashes, for a minimum of 7 years from the date of the Certification Report, consistent with the retention obligations imposed on operators under IGS-A-RET-001/002. --- _End of IGS-STD-ANNEX-A v2.1_