iGaming security logging asks a specific question: which events must the platform be able to reconstruct months later, and what proves the reconstruction was not altered? A log line is not an audit trail until an investigator can rebuild one decision from it and show that the record survived the systems it describes.
For an operator security lead, platform architect, compliance owner or supplier facing an independent review, the decision is where the record lives, who can change it and how long it stays reproducible. The useful delivery artifact is a logging control pack: an event inventory tied to the critical systems, a record schema, protection and access rules, a named time source, a retention and disposal schedule, retrieval procedures and acceptance tests.
Separate security logging from the audit trail
Security logging and the audit trail are related, and they are not the same artifact. The OWASP Logging Cheat Sheet notes that process monitoring, audit and transaction logs are usually collected for different purposes, which often means they should be kept separate: an audit log carries a chronological record of activity that permits reconstruction and examination of the original sequence of attributable transactions, while security event logging answers detection, anti-automation and investigation questions.
Both are worth having. They differ in event scope, retention, access rights and the question they answer. The RGS observability guide covers traces, metrics and logs for game rounds; that telemetry is operational evidence, and an auditor asking who changed a payout configuration will not accept a metrics dashboard as the record.
Start from the critical systems and the decisions they must explain
Great Britain’s remote gambling technical standards security requirements define the critical systems their controls apply to: electronic systems that record, store, process, share, transmit or retrieve sensitive customer information such as authentication information, card details or account balances; systems that generate, transmit or process random numbers used to determine outcomes; systems that store results or the current state of a customer’s gamble; points of entry to and exit from those systems; and communication networks carrying sensitive customer information.
That scope is jurisdiction-specific rather than a universal duty, but it is a useful starting inventory. Derive the log scope from decisions you may have to explain later: who authenticated and how, which privileged action was taken, which configuration or policy version was active, which wallet or ledger movement occurred, which game result or state transition was recorded, which data export or support action happened, and who read the log store itself. The back-office access control guide covers the privileged access side of that inventory, and the wallet reconciliation guide covers the ledger evidence.
Record the event, not everything around it
A record schema should carry the fields an investigation actually needs: a stable event name, the actor and its authentication method, the target resource, the action, the outcome, a reason code, a correlation identifier, the policy or release version in force, the source component, a timestamp with its time source, and the minimum context that explains the decision.
Keep credentials, session tokens, full payment-card data and unnecessary personal data out of the record. OWASP notes that an attacker with read access to a log can use it to exfiltrate secrets, and that logging platforms can be attacked through what is written into them. Data minimisation is not only a storage question: the storage-limitation principle in the GDPR’s Article 5 applies to personal data that appears in logs, so an event inventory and a retention schedule belong together.
Protect the record store as a system in its own right
The security requirements above are drawn from Annex A of ISO/IEC 27001:2022, and the control list includes logging (8.15), clock synchronisation (8.17), information backup (8.13), privileged access rights (8.2) and information access restriction (8.3) alongside the collection of evidence. Read together, they describe a store that is engineered and governed like the systems it observes.
In practice that means reading and writing the record store is a separate privilege from administering the application; an application administrator should not be able to edit or delete the record of their own actions. Append-only or retention-locked storage, integrity digests over batches, narrowly scoped query roles and health monitoring of the logging pipeline itself all serve that goal. Events arriving from systems outside your trust boundary should be treated as untrusted input: OWASP warns that data from another trust zone may be missing, modified, forged or replayed.
Synchronise clocks before arguing about ordering
Clock synchronisation has its own control because ordering across components is only as good as the time sources behind it. PCI DSS requirement 10 applies industry-accepted time sources to systems in scope. In practice: one documented time-source policy, monitored drift alerting, UTC storage with local time applied only at display, a monotonically increasing identifier for events inside one component, and the time source recorded in the record itself. Two systems disagreeing by a few seconds turns an incident timeline into a dispute about the timeline.
Answer retention with two separate questions
The first question is how long the record must be kept. That depends on the obligation and the jurisdiction. PCI DSS requires audit log history to be retained for at least twelve months, with at least the most recent three months immediately available for analysis. Data-protection rules pull in the other direction for personal data: the ICO’s storage limitation guidance records that UK GDPR sets no specific time limits, and that the controller decides how long data is needed for its purposes. Keeping everything forever is a liability, not a control.
The second question is how fast the record must be produced. Retrieval capability is part of the control, not an operational detail. Great Britain’s security audit advice expects a full audit report to be supplied within seven days of a request; a log export that takes three weeks fails that obligation even though the data exists. Write the retention schedule, the disposal evidence trail, the legal-hold path for open investigations and the change process for new obligations into the same document.
Collect evidence for the review, not for the dashboard
The same audit advice describes what a security audit report must contain: the scope of testing including the information-technology systems reviewed, the evidence obtained with document versions and dates, the walkthroughs performed, the samples used to verify compliance, the results by control element and a management plan for findings. Audit against BS ISO/IEC 27001:2022 is the expected standard for the licence classes it names.
That shape of evidence should determine what the logging control produces: the policy, the record schema, the query and export procedure with its access controls, the retention and disposal schedule, and a set of worked reconstructions. A dashboard screenshot is not a sample. The incident response guide covers the adjacent case where the record has to support a live investigation rather than a periodic review.
Accept the logging control with a real reproduction
Acceptance starts by choosing one event from each critical category and reproducing it end to end from the store, including the version of the policy that was in force. Then test the failure modes: an application administrator attempting to delete or edit a record, the log pipeline losing a source, a time source drifting, an export of a defined date range for an investigator, retention expiry and disposal evidence, alerting when writing fails, and the review of who read the record store.
NIST SP 800-92 frames log management as a lifecycle — generating, transmitting, storing, analysing and disposing of log data — and its draft revision describes planning improvements in support of regulatory requirements and recommended practice. Each stage needs an owner, a test and a recorded result, and the acceptance pack should say which systems, releases and environments it actually covers.
For operators and suppliers preparing for an independent security review, Wizards certification and compliance coordinates the technical evidence for gambling licensing, independent testing and regulated-market reviews.
Frequently asked questions
What should an iGaming security logging policy define?
A security logging policy should define the critical systems in scope, the events recorded for each of them, the fields of each record, the time source, who may read or write the store, the retention and disposal schedule, the retrieval procedure and the acceptance tests that prove the record can be reproduced.
Is an observability platform enough for audit evidence?
No. Observability platforms are built for detection, performance and investigation, and they usually sample, aggregate or expire data. An audit trail needs a complete chronological record of attributable actions, with access controls and retention that match the obligation it answers.
How long should iGaming security logs be retained?
Retention follows the obligation, so it differs by jurisdiction and by data type. Payment-card rules commonly require twelve months with the most recent three months immediately available, while data-protection rules require that personal data in logs is not kept longer than necessary. The schedule should record both the minimum and the disposal evidence.
Why does clock synchronisation matter for log evidence?
Because ordering is the argument. If components disagree about the time, an investigator cannot prove which action preceded another, and a dispute or audit finding becomes hard to answer. A monitored time source, UTC storage and a recorded time source in each event keep the sequence defensible.
What evidence should a logging control provide for an independent audit?
It should provide the policy, the event and record schema, the store’s access model, the time-source configuration, the retention and disposal records, the retrieval procedure, and worked reconstructions of representative events with the policy versions in force. It should also state which systems and environments the evidence covers.
Can an application administrator be trusted to maintain the audit log?
Not as the only control. Administration of the application and access to the record store should be separate privileges, so that the people who operate a system cannot quietly change the record of what it did. Append-only storage, integrity checks and logged access to the store support that separation.
