Notices of Violations and Reporting Deadlines

1) Purpose and area

Establish a uniform, verifiable and repeatable procedure for mandatory notifications in case of incidents and violations in the contours of Operations and Compliance: data security, payments/financial transactions, regulatory requirements, responsible play, partner integrations, reputational risks. The document sets deadlines, addressees, formats, as well as preparation and control procedures.

2) Key terms

Reportable incident: an event in which notification to external parties is required by law/license/contract.
DPA is a data protection authority (GDPR and analogues).
FIU - Financial Intelligence (AML/CFT; SAR/STR).
PSP/Acquirer/Card Scheme - payment providers/acquirers/payment systems.
CERT/CSIRT - National/Industry Cyber Security Incident Response Centers.
LEA - law enforcement.
Holding statement - the first short notice with basic facts and the time of the next update.

3) Classes of notifiable events (categories)

1. Information security/confidentiality: leakage of PII/financial data, compromise of accounts.
2. Gambling regulator: glitches affecting game availability/integrity/balances; violation of license/advertising/RG terms.
3. AML/CFT: suspicious operations/patterns → SAR/STR in FIU.
4. Payments: massive unavailability of PSP, high deviations, compromise of payer data.
5. Consumer/player: notifications to affected persons (data breach, money transactions, comp. measures).
6. Partners/affiliates/providers: impact on tracking, reporting, financial settlements.
7. CERT/LEA: cyber incidents of public importance, phishing/brand cloning.
8. Audit/license holders: SLA reporting compliance, confirmation of elimination.

4) Timeline matrix (benchmarks)

5) RACI and roles

IC (Incident Commander) is the owner of the timeline and "war room." (A)

Legal/Compliance Lead - qualification "reportable," choice of addressees and deadlines, final sign. (R/A)

Security Lead - information security facts, volume of compromise/PII, interaction with CERT/LEA. (R)

Payments Lead - PSP/bank/schemes, PCI issues, returns/chargebacks. (R)

Comms Lead - text and send channel, status page, CS macros. (R)

Data/Analytics - list of affected subjects/transactions, impact assessment. (R)

CS/CRM Lead - delivery of notifications to players, compensation. (R)

Exec Sponsor/CEO - S1 public statements. (C/I)

6) End-to-end process (from detection to closure)

• detection → Legal qualification → "reportable? to? timing? ».

• fact/artifact collection → severity classification → template selection → reconciliation (Legal/Comms/IC).

• delivery via channels (regulator portals, secure mail, API, paper forms) → recording the time of sending and confirmation of receipt.

• schedule/milestones → text versioning → synchronization with the status page.

• final report → CAPA plan → closure and retro (≤ 7 days).

7) Minimum composition of notice (skeleton)

1. Incident ID, date/time (UTC and local).
2. Brief description of the event and radius of influence.
3. Categories of data/customers/transactions affected.
4. Actions taken (containment/recovery).
5. Risk assessment and current status.
6. Next step plan and ETA of the next update.
7. Contact person/feedback channel.
8. Legal details of the license/company (if required).
9. Applications: timeline, technical artifacts, lists of subjects.

8) Templates (quick inserts)

8. 1 DPA (data breach, initial notification):

Discovery Event/Date

Data Categories/Volume/Geographies

Harm minimization measures (token reset, MFA, monitoring)

Subject Risk Assessment

Subject notification plan and timeframe

Contact DPO/Legal

8. 2 To players (data breach):

Subject: Important information about your account security

Body: what happened (without tech. details and without PII), what measures have been taken, what to do for the player now (change the password, enable MFA), where to follow the updates, how to get help/compensation.

8. 3 Gambling regulator (accessibility/integrity failure):

What: service/games/wallet, time slot, zones

Impact: interest/number of rates/balances

Measures: rollback, reserve, safe-mode wallet

Expected Recovery ETA, Integrity/Balance Control

Final Verification and Reporting Plan

8. 4 FIU (SAR/STR, brief):

Facts and grounds of suspicion (without "customer warning")

Amounts/linked accounts/behaviors

Applications (transactions/link graph)

AML Responsible Contact

8. 5 PSP/Acquirer/Card Scheme:

What happened (schemes/methods affected), PCI risk markers

Business impact (auth-rate, failure/latency)

Measures/bypasses taken, request for joint diagnostics

Customer Compensation Plan/Returns Processing

8. 6 CERT/CSIRT:

Indicators of compromise (IoC), TTP, vectors

Measures taken and remaining risks

Telemetry Coordination/Sharing Request

9) Checklists

Before sending the initial notification

• Facts confirmed; excluded secrets/PII.
• Agreed with Legal/Compliance; Destination/channel selected.
• The following update (date/time/channel) is specified.
• Screenshots/ARTEFACTS and app hash are captured.
• Checked localization/language (if required).

After sending

• Acknowledgement received/ticket number/registry ID.
• Update plan and owners created.
• Synchronized texts on status page/FAQ/CS macros.

Closing

• Final report sent and confirmed.
• CAPAs are registered with timelines and performance metrics.
• Retro ≤ 7 days.

10) Register of terms and addressees (data structure)

11) Artifacts and retention

Time line (minute accuracy), versions of all notifications, acknowledgements.
Those. artifacts: logs, dumps, export metrics, IoC, configuration snapshots.
Entity/transaction lists used for notification/compensation.
Retention: storage according to the requirements of licenses/laws (usually 1-7 years, specified by jurisdiction).

12) Compliance metrics

Timeliness:% of notifications sent on time (by category).
Completion - The percentage of notifications received the first time (without patch requests).
Acknowledgement SLA: average time to receive acknowledgement.
Update Discipline: compliance with update intervals.
CAPA Effectiveness: percentage of closed CAPAs on time.

13) Tools and Automation

Incident bot: commands '/notify <category> ', auto-substitution of deadlines/channels, reminders about deadlines.
Template engine: assembling notifications from incident parameters; versions/localization.
Status page: synchronous with external updates; TTS (time-to-statement) monitoring.
SOAR/SIEM: automatic artifact collection for DPA/CERT.
DWH/CRM: Affected Subjects Segments, Delivery and Discovery Tracking.

14) Governance

Section owner: Head of Compliance (reserve - Legal Counsel).
Register revision (§ 10): at least quarterly and after each S1/S2.
Exercises: table-top by DPA/Regulator/AML - quarterly; live-drill information security - once every six months.
Audit: annual independent verification of compliance with the timing and completeness of notifications.

15) Quick start (30-day implementation)

1. Create a list of mandatory addressees for all licenses/markets and enter them in the register (§ 10).
2. Approve notification templates (§ 8) and connect them to the incident bot.
3. Configure SLA metrics (§ 12) and "Regulatory Reporting" dashboard.
4. Conduct exercise: data breach → DPA + players, payment crisis → PSP, AML-SAR → FIU.
5. Enable deadline reminders and auto-generation holding statements.
6. Launch retro following the results of the first exercise, update playbooks.

• Crisis management and communications
• Incident playbooks and scripts
• Business Continuity Plan (BCP)
• Disaster Recovery Plan (DRP)
• Escalation Matrix
• Notification and alert system
• Responsible play and player protection